0                Centro Universitário - CESMAC      Faculdade de Ciências Exatas e Tecnológicas – FACET                  C...
1                    ADSON WENDEL CIRILO FERREIRA  MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO    APLICADO NO NÍVEL DE MAT...
2              ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO   APLICADO NO NÍVEL DE MATURIDADE ...
3A minha mãe, Nailda, por ser a pessoa mais importante na minha vida.
4                                AGRADECIMENTOS      Em primeiro lugar, a Deus, por todas as bênçãos e vitórias acontecida...
5                      “Não temais, nem vos assusteis            por causa desta grande multidão, porque apeleja não é vos...
6                                       RESUMO               Esta monografia tem como objetivo apresentar a possibilidade ...
7                                        ABSTRACT               The goal of this monograph is to present the tangible poss...
8                                            LISTA DE FIGURASFigura 1: Logotipo da ISO e da IEC .............................
9                                              LISTA DE QUADROSQuadro 1: Visão da formação do projeto MPSBR..................
10             LISTA DE ABREVIATURAS E SIGLASAQU        AquisiçãoBID        Banco Interamericano de DesenvolvimentoCMM    ...
11                                                  SUMÁRIOINTRODUÇÃO .......................................................
122 MPS.BR ................................................................................................422.1 Conceito ...
13ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DOPROJETO                                                                      ...
14INTRODUÇÃO              MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa que avaliaqualidade e produti...
15               Com o modelo MPS.BR, solução brasileira para a melhoria de processo desoftware que é até utilizada por pa...
16              O MPS.BR compatível com o modelo de referência internacional CMMI(Capability Maturity Model Integration), ...
17MPS.BR, o modelo brasileiro sendo aprofundado nos níveis de maturidade G e F, mostrandoquadros comparativos entre os mod...
181 BASE HISTÓRICA DA MELHORIA DE PROCESSO DESOFTWARE               Neste capítulo, será feita uma abordagem sobre a base ...
19                       A ISO/IEC 12207 é a primeira norma internacional que descreve em detalhes os                     ...
201.1.1 Processos Fundamentais              Em linhas gerais, são todas as atividades que a organização executa nos serviç...
21verificação, processo de validação, revisão conjunta, auditoria e resolução de problemas. Com oobjetivo de auxiliar os o...
22       produtividade e da qualidade do trabalho, há uma aceitação do usuário do sistema       proporcionando ótimas cond...
23                      Em 2002, foi feita uma atualização na norma ISO/IEC 12207 (ISO/IEC PDAM 12207,                    ...
241.2 ISO/IEC 15504               Uma evolução da ISO/IEC 12207, a ISO/IEC 15504, também conhecida comoSPICE, é uma norma ...
25              De cada processo a ser usado, é analisada a situação do problema, e deste pontoem diante, sabendo-se o que...
261.2.2 Processos              Para cada categoria com processos específicos, existem seis níveis numerados de 0a 5 para c...
271.2.2.1 Incompleto                Também conhecido como Inicial ou Não-Realizado, tem uma má performancegeneralizada no ...
281.2.2.5 Previsível              Medido, previsível e controlado quantitativamente. Nesse nível, são realizadasmedidas de...
29            Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois.            Fonte: ASR < http://w...
30assim, a organização ganhará uma melhoria nos processos e em toda a sua estrutura, habilitando aganhos consecutivos e lo...
31nos níveis inferiores; e que a qualidade, produtividade e visibilidade são supremas no nívelMáximo, tendo variações de r...
32processos estáveis, reutilização de projetos com sucessos, utilização contínua de planejamentorealista, processos de Ger...
33ultrapassando limites. Caso aconteça, rapidamente são tomadas providências para corrigi-las,mantendo assim um produto de...
34                       Figura 6: Ilustra os acontecimentos em cada nível do CMM.                       Fonte: CQPD < htt...
35                         Figura 7: Logotipo da norma CMMI.                         Fonte: < http://www.pucrs.campus2.br/...
36              Figura 8: Comparação das duas representações a de Maturidade e Contínua.              Fonte: (RINCON; 2009...
37podem    ser     agrupadas   também    em    quatro   categorias: Gerenciamento de Processos,Gerenciamento de Projetos, ...
381.4.1.3 Definido              A diferença em relação ao nível anterior, é que neste acontece uma padronizaçãonos process...
39                       Neste nível de maturidade o foco é a melhoria contínua da performance do processo                ...
40Projeto contém atividades de planejar, monitorar e controlar o projeto; a Engenharia refere-se àsvárias engenharias; e o...
411.4.2.4 “3” Definido              Tendo os processos da organização padronizados, serão progressivamentemelhorados com m...
422 MPS.BR               Neste capítulo será feita uma explanação sobre o programa de melhoria deprocessos do software bra...
43            Figura 11: Logotipo do modelo MPS.BR            Fonte: < http://www.swprocess.com.br/uploadImagens/Logo_MPS....
44entendimento dos processos avaliativos; e no documento de programa contém informações sobreo modelo de negócio (MN-MPS)....
45                        O Projeto MPs.Br é uma iniciativa envolvendo universidades (Universidade Católica de            ...
46                      Os níveis de maturidade são definidos pelo MR-MPS, que são uma combinação entre                   ...
47                       A organização para atingir o nível E deve executar os processos do nível G e F, e mais           ...
48                  Para que uma empresa adapte sua forma de desenvolver software, que é evolução de produtos para tornare...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
 PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDOR...
Upcoming SlideShare
Loading in …5
×

PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE

2,891 views
2,810 views

Published on

PDF da Monografia apresentada por Adson Wendel (Adson_wendel@hotmail.com), como requisito final à obtenção do grau de bacharelado do Curso de Análise de Sistemas, no do Centro Universitário - CESMAC - Maceió

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,891
On SlideShare
0
From Embeds
0
Number of Embeds
10
Actions
Shares
0
Downloads
77
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

PDF - MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE

  1. 1. 0 Centro Universitário - CESMAC Faculdade de Ciências Exatas e Tecnológicas – FACET Curso de Análise de Sistemas ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMAEMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE Maceió/AL 2010
  2. 2. 1 ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMA EMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE Monografia apresentada como requisito final à obtenção do grau de bacharelado do Curso de Análise de Sistemas, orientada pelo Prof. Alexandre Paes dos Santos, do Centro Universitário - CESMACOrientador: Prof. Esp. Mozart de Melo Alves Jr. Maceió/AL 2010
  3. 3. 2 ADSON WENDEL CIRILO FERREIRA MELHORIA DE PROCESSO DE SOFTWARE BRASILEIRO APLICADO NO NÍVEL DE MATURIDADE F EM UMAEMPRESA ALAGOANA DESENVOLVEDORA DE SOFTWARE Indicação da natureza acadêmica do trabalho (trabalho final de graduação), o objetivo (aprovação na disciplina, grau pretendido), e outras informações como o nome do professor da disciplina e da instituição. Data de Aprovação: ____ / ____ / ________ COMISSÃO EXAMINADORA _________________________________________ Orientador – Prof. Esp. Mozart de Melo Alves Jr. _________________________________________ Avaliador 1 – Prof. Esp. Sandney Farias da Cunha _________________________________________ Avaliador 2 – Prof. Esp. Marcelo Tenório Malta Maceió/AL 2010
  4. 4. 3A minha mãe, Nailda, por ser a pessoa mais importante na minha vida.
  5. 5. 4 AGRADECIMENTOS Em primeiro lugar, a Deus, por todas as bênçãos e vitórias acontecidas em minha vida; A minha mãe, Nailda, por todo apoio e amor; A minha avó, Nair, pelo suporte que sempre me deu; Ao meu avô, Naziozeno, hoje descansa no Senhor, o qual ajudou na minha criação eeducação; A toda minha família, pela confiança e apoio moral; Ao meu orientador prof. Mozart, pelo imenso ensino e compartilhamento à realização destetrabalho; Ao meu amigo James, pela base criada, para que eu pudesse ingressar no ramo profissionalda informática; Ao meu tio Aroldo, por ter me mostrado a necessidade e realidade de fazer um cursosuperior; Ao meu prof. Alexandre Paes, na orientação e na validação este trabalho; Aos meus amigos da faculdade, em especial, Antonio Pascoal, Josenildo Paixão e ClaudioChaves, pelo companheirismo e amizade; Ao Sandney, gerente de medição; e ao Jonas, gerência da qualidade, os quais me cederamas entrevistas, sobre a certificação da empresa KMF no MPSBR; Aos professores do CESMAC, os quais me transmitiram parte de seus conhecimentos.
  6. 6. 5 “Não temais, nem vos assusteis por causa desta grande multidão, porque apeleja não é vossa, mas de Deus. (II Crônicas 20.15)”
  7. 7. 6 RESUMO Esta monografia tem como objetivo apresentar a possibilidade tangível dasempresas de software de Alagoas em busca de um patamar de qualidade, planejamento e controlepara então ficarem em um nível de organização reconhecido internacionalmente, e seu produtoaceito no mercado com aprovação, utilizando o projeto Melhoria de Processo do SoftwareBrasileiro mais conhecido pelas suas siglas MPSBR, o qual avalia a qualidade e a produtividadedo software e serviços relacionados com padrões e características semelhantes às normas dedesenvolvimento internacional, como: CMMI, baseado no ISO/IEC 12207; e ISO/IEC 15504; asquais são explanadas suas definições e estruturas. O projeto brasileiro é direcionados a realcondição de mercado, para o alcance das empresas públicas e privadas de diferentes tamanhos,com maior atenção as micros, pequenas e médias empresas, retirando principalmente adependência do modelo CMMI, o qual utiliza valor de aquisição alta e complexa naimplementação, e como foi aplicado e certificado na empresa de software alagoana KMF Análisee Desenvolvimento de Sistemas e Websites, no nível de maturidade F do Modelo de Referência,em um contrato cooperado, juntamente com mais três empresas, as quais foram as primeiras doEstado a adquirir este feito inédito de aprovação no MPSBR no nível F.Palavras-chaves: MPSBR. CMMI. ISO/IEC 12207. ISO/IEC 15504. Maturidade.
  8. 8. 7 ABSTRACT The goal of this monograph is to present the tangible possibility of softwarecompanies from Alagoas to reach a baseline of quality, planning, management and being in alevel of organization accepted internationally and the product accepted in the market withapproval, using the project Melhoria de Processo do Software Brasileiro known as MPSBR,which evaluates the quality and productivity of the software and services related, with standardand features similar as the standards of software development as, CMMI based on ISO/IEC12207 and ISO/IEC 15504 that are explained, the definition and structure , the Brazilian project isdirected to the real condition of the Brazilian market, so companies from different sizes, publicand private, with more attention on micro, small and medium companies, that way removingmainly the dependency of the model CMMI that has higher cost and more installation complexityand as it was applied and certified in the alagoana software company KMF Análise eDesenvolvimento de Sistemas e Websites, on the maturity level F in the Modelo de Referência, ina cooperative contract, with three other companies, that were the first in the State to acquire thisfirst-time accomplishment, of approval on MPSBR in level F.Key-words: MPSBR. CMMI. ISO/IEC 12207. ISO/IEC 15504. Maturity
  9. 9. 8 LISTA DE FIGURASFigura 1: Logotipo da ISO e da IEC ............................................................................................ 17Figura 2: Demonstra a estrutura da ISO/IEC 12207 .................................................................... 22Figura 3: Demonstra os níveis de processo do modelo SPICE, ISO 15504. ............................... 25Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois....................... 28Figura 5: Demonstra os níveis de processo do modelo CMM. .................................................... 29Figura 6: Ilustra os acontecimentos em cada nível do CMM....................................................... 33Figura 7: Logotipo da norma CMMI............................................................................................ 34Figura 8: Comparação das duas representações a de Maturidade e Contínua. ............................ 35Figura 9: CMMI Representação por estágios. .............................................................................. 36Figura 10: Demonstra os níveis de processo do modelo CMM. .................................................. 38Figura 11: Logotipo do modelo MPS.BR .................................................................................... 42Figura 12: Estrutura do projeto MPS.BR ..................................................................................... 42Figura 13: Logotipo da Coordenadora do projeto MPS.BR ........................................................ 43Figura 14: Descrição dos níveis de maturidade do (MR-MPS.BR) com seus processos. ........... 45Figura 15: Descrição dos processos do Modelo de Negocio (MN-MPS.BR) ............................. 63Figura 16: Comparação dos Níveis de Maturidade do modelo MPSBR com o modelo CMMi .. 65Figura 17: Logotipo da empresa KMF. ........................................................................................ 67Figura 18: Logotipo da Instituição Implementadora II COPPE/UFRJ ........................................ 68Figura 19: Escopo do Projeto ClippingNews. .............................................................................. 70Figura 20: Logotipo do Software Estação TABA desenvolvido na COPPE/UFRJ ..................... 74Figura 21: Logotipo da Instituição Avaliadora, RIOSOFT. ........................................................ 75
  10. 10. 9 LISTA DE QUADROSQuadro 1: Visão da formação do projeto MPSBR....................................................................... 44Quadro 2: Descrição dos resultados esperados para o processo de Gerência de Projetos .......... 47Quadro 3: Descrição dos resultados esperados para o processo de Gerência de requisito .......... 49Quadro 4: Descrição dos resultados esperados para o processo de Aquisição ............................ 51Quadro 5: Descrição dos resultados esperados para o processo de Gerência de Configuração .. 52Quadro 6: Descrição dos resultados esperados para o processo de Gerência de Portfólio de . .... Projetos ....................................................................................................................... 54Quadro 7: Descrição dos resultados esperados para o processo da Garantia da Qualidade ........ 55Quadro 8: Descrição dos resultados esperados para o processo de Medição .............................. 56Quadro 9: Descrição dos processos de avaliação ........................................................................ 62Quadro 10: comparativos MPSBR e CMMI ................................................................................ 65Quadro11: Resultado da Avaliação ............................................................................................. 76
  11. 11. 10 LISTA DE ABREVIATURAS E SIGLASAQU AquisiçãoBID Banco Interamericano de DesenvolvimentoCMM Capability Maturity ModelCMMI Capability Maturity Model IntegrationCMMI-SVC CMMI for ServicesCMMI-ACQ CMMI for AcquisitionCMMI-DEV CMMI for DevelopmentFINEP Financiadora de Estudos e ProjetosFNDCT Fundo Nacional de Desenvolvimento Científico e TecnológicoGCO Gerência de ConfiguraçãoGPP Gerência de Portfólio de ProjetosGPR Gerência de ProjetosGQA Garantia da QualidadeGRE Gerência de requisitoISO Institute of Organization for StandardizationIEC International Electrotechnical CommissionKPAs Key Process AreasMA-MPS Método de avaliaçãoMED MediçãoMN-MPS Modelos de negócioMPSBR Melhoria de Processos do Software BrasileiroMR-MPS Modelo de ReferênciaMTC Ministério de Ciência e TecnologiaSEBRAE Suporte do Serviço Brasileiro de Apoio às Micro e Pequenas EmpresasSEI Software Engineering InstituteSOFTEX Associação para Promoção da Excelência do Software BrasileiroSPICE Software Process Improvement and Capability Determination
  12. 12. 11 SUMÁRIOINTRODUÇÃO ......................................................................................141 BASE HISTÓRICA DA MELHORIA DE PROCESSO DESOFTWARE ...........................................................................................181.1 ISO/IEC 12207............................................................................................... 18 1.1.1 Processos Fundamentais ......................................................................... 20 1.1.2 Processo de Apoio .................................................................................... 20 1.1.3 Processos Organizacionais ...................................................................... 221.2 ISO/IEC 15504............................................................................................... 24 1.2.1Categoria................................................................................................... 24 1.2.2.1 Incompleto........................................................................................... 27 1.2.2.2 Executado ............................................................................................ 27 1.2.2.3 Gerenciado .......................................................................................... 27 1.2.2.4 Estabelecido ........................................................................................ 27 1.2.2.5 Previsível............................................................................................. 28 1.2.2.6 Otimizado ............................................................................................ 281.3 CMM .............................................................................................................. 28 1.3.1 Níveis de Maturidade .............................................................................. 30 1.3.1.1 Inicial .................................................................................................. 31 1.3.1.2 Repetível.............................................................................................. 31 1.3.1.3 Definido............................................................................................... 32 1.3.1.4 Gerenciado .......................................................................................... 32 1.3.1.5 Em Otimização .................................................................................... 331.4 CMMI ............................................................................................................ 34 1.4.1 CMMI - Representação Por estágios ...................................................... 36 1.4.1.1 Inicial .................................................................................................. 37 1.4.1.2 Gerenciado .......................................................................................... 37 1.4.1.3 Definido............................................................................................... 38 1.4.1.4 Gerenciado Quantitativamente ............................................................ 38 1.4.1.5 Otimizado ............................................................................................ 38 1.4.2 CMMI - Representação Contínua .......................................................... 39 1.4.2.1 “0” Incompleto ................................................................................... 40 1.4.2.2 “1” Realizado ..................................................................................... 40 1.4.2.3 “2” Gerenciado................................................................................... 40 1.4.2.4 “3” Definido ....................................................................................... 41 1.4.2.5 “4” Gerenciado quantitativamente ..................................................... 41 1.4.2.6 “5” Otimizado ..................................................................................... 41
  13. 13. 122 MPS.BR ................................................................................................422.1 Conceito MPSBR ........................................................................................... 422.2 Modelo de Referência (MR-MPS) ................................................................ 45 2.2.1 G - Parcialmente Gerenciado.................................................................. 47 2.2.1.1 Gerência de Projetos ........................................................................... 48 2.2.1.2 Gerência de requisito .......................................................................... 50 2.2.2 F – Gerenciado......................................................................................... 50 2.2.2.1 Aquisição............................................................................................. 51 2.2.2.2 Gerência de Configuração .................................................................. 53 2.2.2.3 Gerência de Portfólio de Projetos ....................................................... 54 2.2.2.4 Garantia da Qualidade........................................................................ 55 2.2.2.5 Medição............................................................................................... 56 2.2.3 E - Parcialmente Definido ....................................................................... 57 2.2.4 D - Largamente Definido ........................................................................ 58 2.2.5 C – Definido ............................................................................................. 59 2.2.6 B - Gerenciado ......................................................................................... 60 2.2.7 A - Em Otimização .................................................................................. 602.3 Método de Avaliação (MA-MPS).................................................................. 612.4 Modelo de Negócio (MN-MPS) ..................................................................... 642.5 Quadro comparativos entre os modelos MPSBR e CMMI ......................... 663 IMPLANTAÇÃO DO MPSBR NA KMF UMA EMPRESAALAGOANA. .........................................................................................673.1 A KMF ........................................................................................................... 673.2 A escolha do Nível ......................................................................................... 683.3 Viabilização Financeira ................................................................................. 693.4 O processo de Certificação ............................................................................ 70 3.4.1 Equipe e papel na certificação ................................................................ 70 3.4.2 Fluxo do processo do Escopo .................................................................. 71 3.4.3 Documentações Geradas ......................................................................... 72 3.4.3.1 Software Taba ..................................................................................... 74 3.4.4 Avaliação.................................................................................................. 75 3.4.4.1 Resultado ............................................................................................ 76CONCLUSÃO ........................................................................................78REFERÊNCIAS .....................................................................................80ANEXO ...................................................................................................86ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DOPROJETO ...............................................................................................86
  14. 14. 13ANEXO A - MODELO DE DECLARAÇÃO DE ESCOPO DOPROJETO (CONTINUAÇÃO) 87ANEXO B - MODELO DE TERMO DE ABERTURA DOPROJETO ...............................................................................................88ANEXO C - MODELO DE LAUDO DE AVALIAÇÃO DADECLARAÇÃO DO ESCOPO PELO GQPP ....................................89ANEXO D - MODELO DE PLANO DE GERÊNCIA DEDOCUMENTOS E COMUNICAÇÃO ................................................90ANEXO E - MODELO DE CONTROLE DE ALTERAÇÃO DEREQUISITOS .........................................................................................91ANEXO G - PLANO DO PROCESSO DO PROJETOCLIPPINGNEWS ..................................................................................94ANEXO H - PLANO DO PROCESSO DO PROJETOCLIPPINGNEWS ..................................................................................96
  15. 15. 14INTRODUÇÃO MPS.BR (Melhoria de Processo do Software Brasileiro) é um programa que avaliaqualidade e produtividade de software, e serviços relacionados com padrão e qualidade dasnormas de desenvolvimento internacional, como CMMI, baseado no ISO/IEC 12207, e ISO/IEC15504. Estes melhoramentos são direcionados à real condição do mercado brasileiro, para oalcance das empresas públicas e privadas de diferentes tamanhos, com maior atenção as micros,pequenas e médias empresas, pois atenderá as suas necessidades de negócio, para que possam serreconhecidas nacional e internacionalmente por um modelo de maturidade MPS.BR. Para isso,esta monografia tem como propósito mostrar a possibilidade tangível das empresas de softwarede Alagoas a buscarem um patamar de qualidade, planejamento e controle, para ficarem em umnível de organização reconhecido internacionalmente e seu produto aceito no mercado comaprovação. Desta forma, objetiva-se a amostragem de como devem ser utilizadas as normas epadrões de projetos para a melhoria de processos de qualidade de softwares, e como foi aplicadoe certificado em uma empresa de software alagoana no nível de maturidade F, mostrando ospadrões de certificações, ISO/IEC 12207 e 15504, CMM, CMMI e MPS.BR, com quadroscomparativos entre os modelos, pontuando a implantação do MPS.BR nível F na empresaalagoana KMF, demonstrando os requerimentos do guia de maturidade G e F do modelobrasileiro. A dificuldade enfrentada pelas empresas de software Alagoanas, em acompanharas mudanças que estão acontecendo nos ambientes de negócios, tem motivado tais empresas aprocurarem e estabelecerem uma estrutura organizacional, visando processos de produção,produtos e serviços com padrão internacional de qualidade. Os padrões (ISO/IEC 15504 eCMMI), mesmo nos seus níveis mais baixos dos modelos CMMI (2 e 3) e a ISO/IEC 12207dividida em classes, estão fora do alcance da micro, pequena e média empresa, especialmente noBrasil, devido ao seu custo elevado. Como melhorar os processos de uma empresadesenvolvedora de software se os padrões internacionais são muito caros e complexos deimplantar.
  16. 16. 15 Com o modelo MPS.BR, solução brasileira para a melhoria de processo desoftware que é até utilizada por países latino-americanos, as empresas de pequeno porte têmpossibilidades de atuarem no mercado com certificação de qualidade, com o Grau de Maturidade“F”, onde a organização tem que passar pelos processos de: Gerência de Configuração, Gerênciade Portfólio de Projetos, Garantia da Qualidade, Aquisição, Medição e do nível “G” com osprocessos de Gerência de Projeto e Gerência de Requisitos. Com a principal solução para asempresas de Micro e Médio porte, já que a diferença orçamentária para a aquisição da normaInternacional é muito superior à brasileira, as transições de níveis de maturidade são mais suavesem comparação ao CMMI. Com a implantação do modelo MPS.BR, a organização ganharávisibilidade nacional e internacional e terá uma cobrança maior na qualidade dos seus produtos eserviços por ela prestados. O Ministério de Ciência e Tecnologia (MTC) divulgou uma pesquisa ainda em2001 (MCT, 2001), que relacionou indicadores de produtividades sistêmicas para as micros,pequenas e médias empresas, e a partir dos resultados, pode se constatar a real diferença dedesempenho para as grandes organizações brasileiras. Os motivos para este largo intervalo dedesenvoltura entre os portes das empresas é um conjunto de fatores: a escassez de recursofinanceiro; uma quantidade de RH debilitado ou sem preparo para o cargo ocupado; e o maisimportante, a imaturidade dos cargos de gerência. Este, por sua vez, e deixa os processos/projetosda empresa com uma série de problemas, atraso no tempo previsto de entrega, ou a implantaçãodo software com erros de funcionamentos, retornando posteriormente para que seja feitocorreções no procedimento realizado com ineficácia, entre outras causas que acontecem por faltade um planejamento. Com isso, pode comprometer sua competitividade no mercado e até a vidaútil da empresa. O desenvolvimento desta monografia partiu do interesse de mostrar uma soluçãopara as empresas de softwares, com a utilização do modelo de Melhoramento de processo doSoftware Brasileiro (MPS.BR), projeto proposto em 2003 e coordenado pela Associação paraPromoção da Excelência do Software Brasileiro (SOFTEX), criado para suprir as necessidades deacordo com as carências brasileiras. Assim seria retirada uma dependência ao modelo CMMI, oqual o valor de aquisição é alto e complexo na implementação de uma empresa. Neste projetointernacional, poucas empresas eram certificadas por este conjunto de fatores.
  17. 17. 16 O MPS.BR compatível com o modelo de referência internacional CMMI(Capability Maturity Model Integration), desenvolvido pelo SEI (Software Engineering Institute),conciliável às normas ISO/IEC 12207 e a ISO/IEC 15504, tem como objetivo traçar os resultadosesperados a serem seguidos de maneira eficiente e produtiva para a criação da estrutura dosprocessos e o ciclo de vida do Software. O comitê gestor do MPS é formado pela SOFTEX(Coordenadora); COPPE/UFRJ (coordenadora da ETM - Equipe Técnica do Modelo); RIOSOFTem Rio de Janeiro/RJ; CenPRA em Campinas/SP; CESAR em Recife/PE e CELEPAR emCuritiba/PR. Esse comitê recebe o apoio financeiro dos seguintes órgãos: do Ministério daCiência e Tecnologia (MCT); do Fundo Nacional de Desenvolvimento Científico e Tecnológico(FNDCT); da Financiadora de Estudos e Projetos (FINEP); do Fundo Nacional deDesenvolvimento Científico e Tecnológico (FNDCT); do fundo VERDE-AMARELO; do BancoInteramericano de Desenvolvimento (BID) e do suporte do Serviço Brasileiro de Apoio às Microe Pequenas Empresas (SEBRAE). De acordo com o relatório de avaliação contida na divulgação do dia 22 de janeirode 2010 da SOFTEX, existem hoje 205 empresas vigentes, certificadas no modelo de MPS.BR,divididas pelo Grau de maturidade. No nível A, com seis empresas; no nível B não tem nenhumaempresa com esta graduação; no C com duas; no nível D, com uma; E com seis, F com 59 e, parafinalizar, 131 com o grau de maturidade G, da qual quatro empresas de softwares Alagoanas,participa do seleto grupo, avaliadas no nível F do MPS.BR (SOFTEX, 2010). Esta monografia iráexplanar a certificação da empresa alagoana KMF Análise e Desenvolvimento de Sistemas, quese encontra no seleto grupo das organizações que contêm o certificado do modelo MPS.BR, eestá no grau de maturidade F, pois é uma das quatros organizações de Alagoas que utiliza oprojeto brasileiro de melhoria de processo de Software, das quais no nordeste apenas seteempresas são certificadas (ASSESPRO, 2009). Com os padrões instalados na organização,estabelece uma comunicação formal e uma documentação que assim possibilita um desempenhocrescente da empresa, que com a melhoria de processo proporciona conseqüentemente um grandesalto na qualidade no desenvolvimento dos processos e dos produtos e serviços, possibilitandoum domínio sobre o projeto/equipe e clientes. A organização da monografia se dará em três capítulos, onde no primeiro é umavisão geral sobre melhoria de processo de software com ISO 12207/15504 e CMM/CMMI,abordando definição, Características, tempo de implantação. No segundo capítulo é detalhado o
  18. 18. 17MPS.BR, o modelo brasileiro sendo aprofundado nos níveis de maturidade G e F, mostrandoquadros comparativos entre os modelos CMMI e MPSBR. O terceiro e último capítulo consisteno desenvolvimento de um estudo de caso aplicado na empresa alagoana KMF, certificada nonível de maturidade F do MPS.BR.
  19. 19. 181 BASE HISTÓRICA DA MELHORIA DE PROCESSO DESOFTWARE Neste capítulo, será feita uma abordagem sobre a base histórica da melhoria deprocesso de software, delimitando a ISO/IEC 12207 e sua evolução, a ISO/IEC 15504; o CMMcom seu melhoramento o CMMI, descrevendo sua origem e seus desenvolvedores. Seráapresentado, também, o conceito com as características de cada norma de melhoria de processode software.1.1 ISO/IEC 12207 A norma ISO/IEC 12207, criada pela ISO (Institute of Organization forStandardization - Organização Internacional para Padronização), juntamente com a IEC(International Electrotechnical Commission - Comissão Eletrotécnica Internacional), teve seudesenvolvimento proposto em 1988. Segundo Weber (20--b), “a norma foi publicadainternacionalmente em 1995, e no Brasil em 1998”. Posteriormente revisada em 2002, ela foicriada para sanar uma preocupação de modelagem e melhoria no processo de software, tornado-se uma das mais antigas normas que definem os processos de desenvolvimento da área abordada. Figura 1: Logotipo da ISO e da IEC Fonte: MIT < http://www.techshout.com/images/iso-iec-logos.jpg>
  20. 20. 19 A ISO/IEC 12207 é a primeira norma internacional que descreve em detalhes os processos, atividades e tarefas que envolvem o fornecimento, desenvolvimento, operação e manutenção de produtos de software. A principal finalidade desta norma é servir de referência para os demais padrões que venham surgir. Lançada em agosto de 1995, ela é citada em quase todos os trabalhos relacionados à engenharia de software desde então, inclusive aqueles relativos à qualidade (GUSMÃO; MOURA; 2004). Estabelecer uma estrutura comum para os processos de ciclo de vida e dedesenvolvimento do softwares é o objetivo principal do modelo. Projetada a ser flexível, não temrelações com métodos, ferramentas, treinamentos, métricas e também não tem ligações comlinguagens empregadas no desenvolvimento do programa, o que possibilita um acompanhamentoda evolução da engenharia de software e de organizações com culturas distintas, flexibilidadeimportante, pois implica no “o que fazer” e não ficando refém “como fazer”, tornando o modeloatual ubíquo, modular e adaptável às necessidades fundamentadas em dois princípios, amodularidade e a responsabilidade. Modularidade se refere a processos com número reduzido deacoplamento e junções, entre (módulos ou processos) e um máximo de coesão elevada, excluindoassim falhas, e como manter e testar a dificuldade na compreensão, entre outros; contendo assimum forte relacionamento entre as partes de um processo e o número mínimo de interfaces entre osprocessos. A responsabilidade estabelece um responsável para cada processo, facilitando aaplicação da norma, onde várias organizações ou parte dela podem estar legalmente envolvidas.Com a utilização correta do modelo de melhoramento de software, as empresas adquirem umconhecimento na área de processos. A ISO/IEC 12207 tem sido amplamente utilizada em muitos países como referência para contratação de serviços de desenvolvimento e manutenção de software. No Brasil, muitas organizações têm tomado conhecimento da existência da norma e algumas já as utilizam para definição de processos de desenvolvimento de software. Muitos trabalhos de pesquisa têm utilizado a norma, o que vislumbra uma ampla utilização da mesma no futuro (WEBER et al; 20--b; p6). Os Processos padrões que abrangem o desenvolvimento são classificados deacordo com suas características similares no ciclo de vida de software. Segundo Gusmão e Moura(2004) “Esta norma divide os processos em três grandes classes: Processos Fundamentais,Processos de Apoio e Processos Organizacionais”, cada classe com suas atividades.
  21. 21. 201.1.1 Processos Fundamentais Em linhas gerais, são todas as atividades que a organização executa nos serviçosda criação, desenvolvimento, manutenção ou operação do software. Segundo Weber ( et al; 20--b)os processos fundamentais são formados pelos processos de aquisição, fornecimento,desenvolvimento, operação e manutenção, os quais são descritos abaixo. • Processo de Aquisição: define as atividades para a organização que vier a adquirir um produto ou serviço de software que satisfaça as necessidades do cliente, incluindo seleção de fornecedores e emissão de pedido de proposta. • Processo de Fornecimento: define as atividades da empresa de software, com o comprometimento na execução dos processos de desenvolvimento, manutenção do produto ou serviço, determinando os procedimentos e recursos necessários para gerenciar e garantir o projeto, até a entrega do software ou serviço. • Processo de Desenvolvimento: define as atividades e tarefas do processo de desenvolvimento do produto seguindo a seguinte sequência: análise de requisitos, projeto, construção “codificação”, integração, testes, instalação e o recebimento do software ao adquirente, sabendo que o propósito do desenvolvimento é a transformação de um conjunto de requisitos pré-analisados em um produto de software, que satisfaça as necessidades explícitas do cliente. • Processo de Operação: define as atividades e tarefas para a operação do software e suporte operacional aos usuários, para que possa utilizar o software produzido. • Processo de Manutenção: é ativado quando há necessidade de modificações no código fonte do sistema produzido, para que possa ser feito melhorias, correção de erros, ou mesmo adaptação do software para que assim possa haver uma integridade do software existente.1.1.2 Processo de Apoio Segundo Machado (2001), o processo de apoio é empregado e executado quando énecessário para documentação, gerência de configuração, garantia da qualidade, processo de
  22. 22. 21verificação, processo de validação, revisão conjunta, auditoria e resolução de problemas. Com oobjetivo de auxiliar os outros processos, visando à qualidade e o sucesso do projeto, o processode apoio é constituído pelos seguintes itens: • Processo de Documentação: tem a tarefa de registrar as informações dos processos e atividades provenientes do ciclo de vida do projeto. Nesse processo, são planejados, projetados, desenvolvidos, produzidos, editados e distribuídos os documentos necessários a todos os interessados. • Processo de Gerência de configuração: contém atividade administrativa, define itens para o desenvolvimento do software apontando linhas básicas, controlando modificações e liberações, registrando as codificações para total compreensão da consistência nas correções dos itens modificados, garantindo seu funcionamento. • Processo de Garantia da qualidade: com o principal intuito de promover a seus clientes um importantíssimo produto, o alvo é o funcionamento com êxito do software, de acordo com os requisitos, padrões e normas pré-estabelecidas e documentadas para o desenvolvimento dos processos • Processo de Verificação: tem o propósito de averiguar se o produto ou serviço de software está de acordo com os requisitos previamente impostos. • Processo de Validação: é a atividade que confirma se os serviços realizados atendem aos requisitos proposto ao ciclo de vida do Software. • Processo de Revisão conjunta: avalia a situação de uma atividade e dos produtos, para manter um entendimento geral dos requisitos realizados, ou não, no nível de gerenciamento técnico. • Processo de Auditoria: tem o propósito de determinar a total validação entre as comparações, entre os requisitos e o produto. • Processo de Resolução de problemas: tem a finalidade de assegurar a solução de problemas levantados, com uma análise adequada e documentada. • Processo de Usabilidade: é voltado para a otimização do suporte e do treinamento, cujo objetivo é garantir que sejam considerados os interesses e necessidades dos funcionários e, principalmente, do usuário. Assim tendo uma grande possibilidade de aumento da
  23. 23. 22 produtividade e da qualidade do trabalho, há uma aceitação do usuário do sistema proporcionando ótimas condições de trabalho sem rejeição. A norma de referência para os processos de ciclo de vida de software no MR mps é a ISO/IEC 12207, conforme sua atualização publicada em 2002. Esta norma pode ajudar as organizações na definição de seus processos, pois ela contém uma clara definição da arquitetura, terminologia e responsabilidades inerentes a processos. Essa atualização inseriu processos e acrescentou na sua descrição propósito e resultados de implementação, o que possibilita a avaliação da capacidade do processo. (WEBER et al; 20--b)1.1.3 Processos Organizacionais São utilizados para auxiliar e gerenciar a organização, com o objetivo de melhoraro ciclo de vida do software. As atividades contidas nos processos organizacionais visam amelhoria da empresa, apresenta os processos de gerência, infra-estrutura e treinamento. • Processo de Gerência: tem o propósito de definir as atividades para a área do gerenciamento do projeto, produto, atividades dos processos, aquisição, fornecimento, desenvolvimento, operação, manutenção e processos de apoio, objetivando ter um controle e organização sobre o que está acontecendo do inicio ao fim do processo em desenvolvimento. • Processo de Infra-estrutura: é a atividade responsável em manter as necessidades de infra-estrutura da organização em um nível que possa ser usado como hardware, software, condições de trabalho, ferramentas especiais de desenvolvimento, suporte e implantação de todos os setores da organização. • Processo de Melhoria: é a atividade que estabelece melhoria no ciclo de vida do software, com avaliações e medições, tendo controle sobre o produto desenvolvido. • Processo de Recursos Humanos: segundo MACHADO (20--), o objetivo principal do processo de recursos humanos é “garantir o melhor aproveitamento das pessoas envolvidas no projeto, o que consiste em planejamento organizacional, alocação de pessoal e desenvolvimento de equipe”. • Processo de Treinamento: define as atividades de treinamento para os funcionários da empresa que adquiriram o software, entre elas, melhorias e mudanças no sistema, o que necessita de uma instrução sobre a forma de usar o produto. • Processo de Gestão de ativos: utilizáveis desde de seu desenvolvimento até o desuso, sendo introduzido em 2002.
  24. 24. 23 Em 2002, foi feita uma atualização na norma ISO/IEC 12207 (ISO/IEC PDAM 12207, 2002) em forma de anexo que visava representar a evolução da engenharia de software, as necessidades vivenciadas pelos usuários da norma e a harmonização com a série de normas ISO/IEC 15504 – Avaliação de Processos de Software. (WEBER et al; 20--b) • Processo de Gestão de programa de reuso: na gestão de reuso há um planejamento para gerenciar, estabelecer, controlar e monitorar. Esse objetivo específico em uma organização é sistematicamente explorar as oportunidades de reuso, não perdendo tempo e, com certeza, aumentado os lucros. • Processo de Engenharia de domínio: na engenharia de domínio são desenvolvidos e mantidos os modelos, arquiteturas e ativos de domínio. Weber (et al; 20--b; p6) afirma a atualização em 2002 de novos processos edescreve como foram divididos nos processos fundamentais de apoio e organizacionais, comoacima citados, a baixo quadro que mostra a estrutura da ISO/IEC12207Figura 2: Demonstra a estrutura da ISO/IEC 12207.Fonte: < http://qualidade.wdfiles.com/local--files/mpsbr-qualidade-de-software/ISO12207.png>
  25. 25. 241.2 ISO/IEC 15504 Uma evolução da ISO/IEC 12207, a ISO/IEC 15504, também conhecida comoSPICE, é uma norma de processos de desenvolvimento de software criado pela ISO e pela IEC,tendo diferença em sua versão de origem, pois trabalha com níveis de capacidades equivalentesao CMMI. Essa norma teve uma versão aprovada em 1998 (ISO/IEC, 2003), sendo abastecidapelas necessidades de requisitos de padrão internacional para avaliação de processos de software,a qual foi publicada em 2003 pela ISO em união com a comunidade internacional, através doprojeto SPICE (Melhoria de Processo de software e determinação de Capacidade - SoftwareProcess Improvement and Capability Determination). Tendo como estrutura as normas jáexistentes, a ISO 9001 e o CMM, juntamente com a ISO/IEC 12207, descreve um conjunto deprocessos considerados universais e fundamentais para que se possa ter um planejamento edesenvolvimento com qualidade, com o propósito na melhoria de processos de criação desoftware e serviços relacionados com execução de avaliações específicas na área determinada.Sabendo assim quais partes da organização terão que ser feitas melhorias, e quais característicasmanter, é utilizado avaliações de capacidades. Segundo WEBER (et al; 20--b; p6) “a organizaçãopode realizar a avaliação, gerando um perfil dos processos que será usado para a elaboração deum plano de melhorias”, das quais a empresa deve continuar sempre à procura, sem perder aqualidade e o foco no cliente.1.2.1Categoria Os processos da norma SPICE são agrupados em cinco grandes categorias de processo:cliente/fornecedor, engenharia, suporte e organização. Cada uma das categorias de processo é detalhada em processos mais específicos, ou subcategorias (Cliente-fornecedor, Engenharia, Projeto, Suporte e Organização). Este modelo visa também avaliar a capacidade da organização em cada processo, permitindo assim sua melhoria. Cada um dos processos deve ser classificado em níveis (incompleto, executado, gerenciado, estabelecido, previsível e otimizado) (LAHOZ, SANT’ANNA).
  26. 26. 25 De cada processo a ser usado, é analisada a situação do problema, e deste pontoem diante, sabendo-se o que fazer para a melhoria de processo, é aplicado o processo especificopara a solução do entrave. A dimensão de processos do modelo de avaliação apresenta os processos relevantes dentro de um determinado contexto. Ela é baseada em um subconjunto de processos os quais são descritos em um modelo de referência de processo. O modelo de referência, voltado para o setor de software, utilizado pela 15504, define um conjunto universal de processos de software com base na norma ISO 12207 (ISO; 2002). • Cliente/fornecedor: a dimensão do processo de Cliente fornecedor, segundo Bernardo e Becerra (2005) “São processos que impactam diretamente os produtos e serviços de software na entrega do fornecedor para o cliente”. • Engenharia: na categoria Engenharia, são encontrados os processos que guiam a implementação e manutenção do produto ou serviço de software, com sua documentação formal dos requisitos necessários para a sequência do desenvolvimento. • Projeto: tem como objetivo organizar, monitorar e controlar a execução de qualquer processo na empresa. • Suporte: é a atividade responsável em documentar e interagir com o usuário do sistema de software produzido. Segundo Bernardo e Becerra (2005) “são processos que podem ser empregados por quaisquer um dos outros processos, por tratarem da documentação, configuração e revisões”. • Organização: é a empresa que cria focos de empreendimentos para que possam ser alcançados e superados.
  27. 27. 261.2.2 Processos Para cada categoria com processos específicos, existem seis níveis numerados de 0a 5 para cada processo incompleto, executado, gerenciado, estabelecido, previsível e otimizado. A segunda dimensão é a de capacidade do processo. Essa dimensão apresenta uma estrutura de medição composta por seis níveis de capacidade, os quais definem uma escala ordinal de capacidade que são aplicáveis a qualquer processo do modelo de referência de processos. Cada nível de capacidade é composto por atributos de processo, que definem um aspecto particular da capacidade do processo. Assim, a partir das observações resultantes de uma avaliação, é atribuída uma das seguintes quatro notas a cada atributo: N-não atingido, P-parcialmente atingido, L-largamente atingido ou F- completamente atingido. Para estar em um nível de capacidade, um processo tem que ter notas L ou F nos atributos do nível, e F em todos os atributos dos níveis anteriores (ANACLETO, WANGENHEIM, SALVIANO, 2004) Figura 3: Demonstra os níveis de processo do modelo SPICE, ISO 15504. Fonte: < http://www.bcs.org/upload/img_400/cmmi_spice_fig1.gif> A figura 3 retrata os níveis de processos pertencentes à norma ISO 15504,demonstrando os graus de maturidade dos processos estabelecidos para as organizações quevenham a implementar o modelo. Segundo Lahoz e Sant’anna “este modelo visa também avaliara capacidade da organização em cada processo, permitindo assim sua melhoria, pois cada um dosprocessos deve ser classificado em níveis (incompleto, executado, gerenciado, estabelecido,previsível e otimizado)” conforme descrito a seguir.
  28. 28. 271.2.2.1 Incompleto Também conhecido como Inicial ou Não-Realizado, tem uma má performancegeneralizada no desenvolvimento dos objetivos específicos das práticas bases do processo desoftware, o qual, não encontra o produto final ou resultados vindos dos processos realizados.1.2.2.2 Executado Os processos são finalizados com um básico acompanhamento e sem muitoscuidados, e depende muito do esforço individual. Existem, também, produtos de trabalhofinalizados com o uso identificáveis do processo, os quais em outras versões são nomeados deRealizados ou Realizados Informalmente.1.2.2.3 Gerenciado Os processos são planejados e acompanhados. Já os procedimentos específicos sãoaveriguados, visando a qualidade, levando a organização a uma boa estimativa de direção, e umprocesso de software com qualidade bem definido.1.2.2.4 Estabelecido Com o processo estabelecido, a organização busca práticas de acordo com osprocessos definidos, usando versões de normas já trabalhadas com sucesso ganho, e trabalhandocom a mesma qualidade, as quais já estão documentadas, ajudando assim o entendimento para ospróximos projetos.
  29. 29. 281.2.2.5 Previsível Medido, previsível e controlado quantitativamente. Nesse nível, são realizadasmedidas detalhadas, onde as reais condições dos processos são recolhidas e analisadas paralevarem a uma compreensão quantitativa da capacidade do processo, e a uma melhor aptidão paraantecipar a realização. O processo definido é entendido e controlado quantitativamente.1.2.2.6 Otimizado Metas de eficiência são estabelecidas para a realização do processo. Tendo comobase os objetivos de negócios na empresa, é dado partida para o aperfeiçoamento contínuo dosprocessos de desenvolvimento sobre estas metas, através do retorno quantitativo da realização doprocesso definido, e também de tecnologias inovadoras, o que resultará em melhorias sempre dealto nível.1.3 CMM O CMM-SW (Capability Maturity Model for Software - Modelo de Maturidadede capacidade para Software) ou simplesmente conhecido por CMM, é uma norma decertificação de qualidade utilizada para avaliação e melhorias na maturidade dos processos emdesenvolvimento de software e serviços correlacionados, com origem na década de 1980 nosEstados Unidos. Segundo PESSÔA (2005) “O desenvolvimento desse modelo foi financiado pelodepartamento de defesa americano, com o objetivo de se estabelecer um padrão de qualidade parasoftware desenvolvido para as forças armadas”. Com este modelo de avaliação, seria capaz demedir os processos de construção do software fabricado pelas as empresas que concorriam pelalicitação, tendo em vista a indicação pela qualidade, valor do produto e garantia de prazos deentrega completa ou por módulos dos projetos contratados. Embora o modelo tenha sido geradopara a composição de grandes corporações de desenvolvimento de software que iriam sercontratadas para projetos militares, seus princípios são válidos para vários tipos de projetos desoftwares.
  30. 30. 29 Figura 4: Logotipo do modelo CMM referenciando ao nível de maturidade dois. Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf > Embora, historicamente, o CMM tenha surgido no contexto de grandes empresas de desenvolvimento de software contratadas pelas Forças Armadas dos EUA para projetos militares, tem-se verificado que seus princípios são válidos para todo tipo de projetos de software. Isto não é de se estranhar, já que o CMM nada mais é que a aplicação dos princípios da Qualidade Total e do Gerenciamento de Projetos ao mundo do software. Assim, o CMM tem sido usado com sucesso, na íntegra ou adaptado, nos mais variados tipos de empresas grandes e pequenas, em várias áreas de atuação. Entre as citadas por Belloquim (2006) estão Pequenas softwarehouses (10 a 20 desenvolvedores); Grandes Bancos e Seguradoras; Empresas de Telecomunicações; Fabricantes de hardware com software embarcado (pagers, aviônicos, componentes automobilísticos, telefones celulares); Empresas de consultoria em desenvolvimento de sistemas (ALEXANDRINI et al; 2006). . Para a implantação do projeto CMM, as forças aéreas instituíram, paradesenvolvimento do projeto, o SEI (Software Engeneering Estitute) sediado na Carneggie MellonUniversity na Pennsylvania, a qual até hoje é a responsável pela evolução do CMM. Atualmentecom a versão 1.2, evolução da anterior 1.1, o modelo de maturidade de capacidade CMM forneceuma guia de como obter controle nas execuções de construções de softwares, que quando éseguido, as suas práticas garantem a qualidade do produto, com o propósito principal de medir amaturidade de uma área de desenvolvimento de software, e como evoluir em direção a umacultura de engenharia de software e excelência de gestão. Para isso é preciso analisar ecompreender a forma de trabalho, adaptando as características de empresa por empresa, uma vezque cada uma tem formas diferentes de trabalho. Os principais objetivos do CMM são auxiliar as empresas a conhecerem e melhorarem seus processos de desenvolvimento e manutenção de software; Fornecer uma estrutura conceitual para guiar as empresas para obterem controles de seus processos, com melhoria continua de seus produtos de software (REZENDE, 2002, p. 155). Projetado para a garantia da melhor seleção das estratégias de melhorias, trabalhafocado em um número limitado de atividades e trabalhos a serem concluídos com êxito. Sendo
  31. 31. 30assim, a organização ganhará uma melhoria nos processos e em toda a sua estrutura, habilitando aganhos consecutivos e longos na capacidade do processo de software da empresa.1.3.1 Níveis de Maturidade Para o uso continuo e progressivo, o CMM fornece uma estrutura de cinco níveisde maturidade, são eles: inicial, repetível, definido, gerenciado e otimização que fornecemfundamentos sucessivos para a excelência do processo, dos quais os cinco níveis de maturidadetêm a finalidade de medir a atual situação da organização nos desenvolvimentos de seus projetose ajudar a priorizar o foco de seus esforços de melhoria. Segundo Gusmão e Moura (2004)afirma que O SW-CMM foi o primeiro modelo desenvolvido na área de maturidade e capacidade,o qual tem cinco níveis de maturidade onde o nível mais avançado corresponde a uma maiormaturidade do processo que está associado a uma maior produtividade e qualidade, e a um menorrisco organizacional, na área de desenvolvimento de software. A busca por processo maduro,evolutivo em estágios, definido em fundamentos para a melhoria, e que cada nível de maturidadefica responsável, compreende um conjunto de objetivos de processos há serem seguidos. Figura 5: Demonstra os níveis de processo do modelo CMM. Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf > Na Figura 5, há uma exibição de dois gráficos: um (à esquerda) são os caminhosevolutivos que as organizações terão que passar para obterem um processo de implementação edisciplina com excelência; o outro (à direita) demonstra que os riscos e desperdícios são maiores
  32. 32. 31nos níveis inferiores; e que a qualidade, produtividade e visibilidade são supremas no nívelMáximo, tendo variações de risco versos qualidade ao ganhar maturidade.1.3.1.1 Inicial É um processo comumente chamado de “ad hoc” ou, em algumas ocasiõescaóticos, depende do esforço individual para que o sucesso aconteça e poucos processos sãodefinidos. Em uma visão ampla, a organização não fornece um ambiente estável para a estruturado desenvolvimento e a manutenção do produto. Para a evolução do trabalho diário, a prática degestão sem rumo certo, muitas vezes prejudica o desenvolvimento das boas práticas peloplanejamento ineficiente “encache” de novos projetos, tirando da ordem dos cronogramas dosprojetos os próximos processos a serem criados. Um gerente excepcional para o sucesso doprojeto e uma equipe de software madura e eficiente, é de quem depende inteiramente oprocedimento do projeto, porém ,mesmo com uma boa prática de desenvolvimento, não podesuperar a instabilidade criada pela ausência de práticas sólidas de gestão. Alteração constante noprojeto ‘ad hoc’ é geralmente imprevisível aos orçamentos, funcionalidades, cronogramas equalidades do produto, com um momento casual de estabilidade. Grande parte das organizações que enquadram-se neste nível, o qual caracteriza-se pelo desenvolvimento de software sendo visualizado como uma caixa preta, onde apenas as entradas e saídas são vistas com clareza. O sucesso e a qualidade do produto dependem de esforços individuais sem qualquer nível de gerenciamento ou controle definido explicitamente (SANTANDER; VASCONCELOS; 20--).1.3.1.2 Repetível A estabilidade rege os procedimentos para a gestão de projeto do software. Osprojetos novos são analisados com experiência de projetos similares, anteriormente produzidoscom práticas bem sucedidas de desenvolvimento, com atuação de processos documentados,medidos, testados e com condições de melhoramentos, com controle básico de gestão desoftware, acompanhamento no cronograma, custos, funcionalidades e armazenando os requisitos,produtos de trabalho que a integridade é rigidamente controlada. Os padrões do projeto sãocaracterizados, validados, e a organização garante que o uso dos procedimentos será seguidosempre. O nível dois de maturidade é conhecido como disciplinado, pelos seguintes motivos:
  33. 33. 32processos estáveis, reutilização de projetos com sucessos, utilização contínua de planejamentorealista, processos de Gerenciamento de requisitos, planejamento, monitoramento, controle deprojeto, gerenciamento de fornecedores, medição, análise, garantia da qualidade do processo, doproduto e da gerenciamento de configuração.1.3.1.3 Definido Os processos de desenvolvimento, a manutenção de software e a gestão deprocessos da empresa, como um todo, são documentados. Os processos são utilizados para apoiaros gerentes de software e a área técnica, através de programas de treinamentos que sãoimplantados para que os gerentes e funcionários tenham conhecimentos e controle nas funções,resumidamente conhecida como padronizada e consistente, pois a engenharia de software e asatividades de gestão são estáveis e repetíveis, que segundo Santander e Vasconcelos (20--), “écaracterizado principalmente pela existência de um processo de engenharia de software bemdefinido, documentado e padrão para a empresa. O processo de software é satisfatoriamenteentendido”. No nível definido, os produtos são produzidos, desenvolvidos, a qualidade éacompanhada e o cronograma é cumprido, além das funcionalidades e custos. Seus processosabrangem o desenvolvimento de requisitos, solução técnica, integração do produto, verificação evalidação, foco e definição no processo organizacional, treinamento organizacional,gerenciamento de riscos, gerenciamento integrado do projeto, análise da decisão e resolução.1.3.1.4 Gerenciado Com o nível gerenciado, a organização cria metas de qualidade para os produtosdesenvolvidos e processos de software, onde acontece medição na produtividade e na qualidadedos processos de todo o projeto. Os dados disponíveis dos processos são armazenados pra quepossam ser utilizados, coletados e analisados, reduzindo a variação no desempenho com controlesobre seus produtos e processos. Nível de maturidade gerenciado, é conhecido como previsível,pois os processos e operações são feitos sobre os limites mensuráveis, prevendo que aorganização tenha uma previsão de tendências de qualidade dos produtos e processos, não
  34. 34. 33ultrapassando limites. Caso aconteça, rapidamente são tomadas providências para corrigi-las,mantendo assim um produto de software com alta qualidade.1.3.1.5 Em Otimização A organização é totalmente madura e entra em um círculo de melhoria contínua deprocesso, os quais são fortalecidos de maneira proativa quando surgem oportunidades demelhorias com objetivo de antecedência a falhas. Com os processos armazenados, são realizadasanálises de custo, benefícios de tecnologias novas e mudanças solicitadas para o projeto. Asnovas práticas de engenharia são identificadas, armazenadas e repassadas para toda aorganização, onde os processos são revistos periodicamente para prevenir os tipos de falhas jáconhecidos que geralmente se repetem, e os erros são catalogados para que não aconteça emoutros projetos. O nível cinco de maturidade fica sendo conhecido como melhoria contínua, poisestá continuamente procurando a melhoria, expandido sua capacidade de processos juntamentecom o projeto. Avanços incrementais são adicionados aos processos com inovações que utilizamnovos métodos e tecnologias. Na figura número 6, basicamente é exibida como a gerência presencia osprocessos em cada nível de maturidade; no nível 1, o processo é uma caixa preta, o entendimentodo processo é caótico, onde acontecem inúmeras situações para que o projeto atrase e tenhaprejuízos; no nível 2, há controle sobre os requisitos e sobre o projeto; no nível 3, já é visível asatividades dentro dos processos, onde os gerentes e os engenheiros compreendem suas tarefas; nonível 4, os gerentes têm a possibilidade de medir quantitativamente os processos, facilitando asdecisões futuras; e no último nível 5, novas tecnologias são adicionadas aos processos,substituindo as antigas, no intuito de melhorar a produtividade, tempo e qualidade com totalcontrole nas mudanças.
  35. 35. 34 Figura 6: Ilustra os acontecimentos em cada nível do CMM. Fonte: CQPD < http://www.gaea.com.br/pdf/CMM-TR24_.V1.2.pdf>1.4 CMMI Com a existência de vários CMM e com objetivo em desenvolvimento de softwaresendo eles: Engenharia de Sistemas (SE-CMM); Aquisição de Software (SA-CMM) e Gestão deRecursos Humanos de Empresas de Softwares (P-CMM) entre outros. Mesmo com a utilizaçãobenéfica dos modelos, as excessivas diversificações trouxeram problemas, pois cada modelotinha que ser avaliado separadamente, gerando um aumentado custo de treinamento, ocasionandoo acontecimento de dificuldades de comunicação entre eles, já que cada modelo possuicaracterísticas específicas.
  36. 36. 35 Figura 7: Logotipo da norma CMMI. Fonte: < http://www.pucrs.campus2.br/~jiani/es2/cmmi-logo.gif>. CMMI ajuda a integrar tradicionalmente funções organizacionais separadas, definir processo de melhoria, metas e prioridades, bem como fornecer orientações para processos de qualidade, e proporcionar um ponto de referência para avaliar processos atuais. Muitas organizações no mundo todo têm adotado este modelo com o objetivo de possibilitar a elevação da maturidade da capacidade de suas equipes nas atividades relacionadas ao software (Silva, Andrade, Pimentel,2008). Para sanar esse entrave de diversidade de modelos e com o intuito de unificar, foicriada uma integração das práticas em conflito, o SEI criou o CMMI, que é a evolução do CMM(Capability Maturity Model Integration - Modelo de Maturidade da Capacitação Integrado).segundo WEBER(20--b) “O CMMI surgiu para resolver o problema de se usar vários modelos eé o resultado da evolução do SW-CMM, SECM (System Engineering Capability Model) e IPD-CMM (Integrated Product Development Capability Maturity Model)”. CMMI É um modelo de referência para desenvolvimento de processo de software,e tem como objetivo eliminar suas inconsistências no projeto como um todo, fornecer uma práticaconsistente com regras de construção como seus anteriores. O CMMI não define como o processodeve ser desenvolvido, porém reúne características estruturais e como deve ser finalizadoprocesso. O CMMI, na atual versão 1.2, tem três modelos publicados: CMMI forDevelopment(CMMI-DEV), para processo de desenvolvimento de produtos e serviços; CMMIfor Acquisition (CMMI-ACQ), para a aquisição e terceirização de bens e serviços; e CMMI forServices (CMMI-SVC), para processos de empresas prestadoras de serviços publicados nasequência 2006, 2007 e 2009. O CMMI possui duas representações: a por estágios e Contínua.
  37. 37. 36 Figura 8: Comparação das duas representações a de Maturidade e Contínua. Fonte: (RINCON; 2009). [...] para que uma organização possa evoluir de um nível para o outro no CMMI, ela deve implementar um conjunto de processos pré-definidos. Para isso, ela deve cumprir o que é descrito nas metas e práticas genéricas e nas metas e práticas específicas de cada Área de processo. O documento oficial do modelo, o CMMI-DEV, traz detalhadamente quais são as metas e práticas específicas de cada Área de Processo (RINCON,2009). Estas duas formas de sequência fazem com que as organizações possam ter umaescolha de qual caminho deve ser percorrido à procura da melhoria de seus processos, de acordocom seus interesses. Segundo PESSÔA (2005) “para entender o significado do termo capacidadepode se pensar na capacidade que alguém possui para realizar um trabalho: quanto maior acapacidade do processo, melhor deve ser o resultado obtido”.1.4.1 CMMI - Representação Por estágios A organização busca uma avaliação por nível de maturidade com conjuntospreviamente definidos para que seja cumprido o KPAs (Key Process Areas - área chave deprocesso), mesmo modelo adotado pelo CMM. Na representação por estágios possui níveis dematuridade com conjunto de áreas de processo que caracterizam diferentes comportamentosorganizacionais, que é uma imagem para que a capacidade das organizações possa desenvolverprojetos complexos e grandes, dependendo dos níveis que tenha adquirido. Segundo MARÇAL(2007) “a representação em estágios, por sua vez, organiza as áreas de processo em 5níveis de maturidade para suportar e guiar a melhoria dos processos. As áreas de processos
  38. 38. 37podem ser agrupadas também em quatro categorias: Gerenciamento de Processos,Gerenciamento de Projetos, Engenharia e Suporte” como descrito a seguir.1.4.1.1 Inicial Neste nível, os processos são caóticos, os padrões não são seguidos pelaorganização, por estarem no nível mais baixo do CMMI. Isso não implica dizer que o produtonão seja bom, porém o êxito do projeto fica por conta de algumas pessoas que, por esforços,conseguem entregar o software, às vezes sendo obrigadas a abandonarem o processo por motivode alguma crise, provocando, assim, atraso na entrega do software, aumentando excessivamente ocusto do que foi planejado. Como a organização geralmente não fornece um ambiente estável, osprocessos a serem cumpridos, neste nível não são encontrados.1.4.1.2 Gerenciado Os projetos têm a garantia de que seus requisitos são gerenciados e os processosplanejados. Com o foco de gerenciamento básico, o nível dois traz uma análise nas tarefas queestão sendo desenvolvidos. Assim, encontrados os requisitos que não são compatíveis com os queforam planejados, são rapidamente corrigidos para não interferir no prazo de entrega. Caso oproblema não seja sanado, a organização tentará uma solução. Figura 9: CMMI Representação por estágios. Fonte: (RINCON, 2009).
  39. 39. 381.4.1.3 Definido A diferença em relação ao nível anterior, é que neste acontece uma padronizaçãonos processos, os quais são melhores caracterizados e entendidos, e assim sendo descritos osprocedimentos e métodos. As ferramentas são melhoradas e definidas com mais rigor, tendo ofoco na padronização do processo e nos requisitos de desenvolvimento. São eles: análise dedecisões, soluções técnicas, integração da equipe de trabalho, integração de produtos,gerenciamento de projeto integrado, verificação, validação, treinamento organizacional, foco noprocesso organizacional, definição do processo organizacional, gerenciamento de riscos,gerenciamento integrado de suprimentos e ambiente organizacional para integração.1.4.1.4 Gerenciado Quantitativamente Os processos no nível quatro são gerenciados quantitativamente, onde aconteceum controle de processos utilizando métodos estatísticos e outras técnicas quantitativas. Sendofácil a identificação de qualidade e o desempenho de um processo, estes são armazenados em umrepositório para que possa ter um suporte para decisões futuras. Os requisitos de desenvolvimentosão: performance organizacional do processo e gerenciamento quantitativo de projetos. Neste nível de maturidade são definidos objetivos quantitativos da qualidade e performance dos processos, estes estão baseados nas necessidades dos clientes, usuários finais do produto. A qualidade e a performance dos processos são analisadas com base em dados estatísticos e são gerenciados conforme estes resultados por toda a extensão do processo (JAGUARIBE; MARIANO; 20--).1.4.1.5 Otimizado No ultimo nível do processo de maturidade do CMMI, na representação porestágios, os processos são continuamente melhorados com uma análise quantitativa dasalterações; e no desempenho, os processo desse nível são a inovação organizacional e análise decausas e resoluções.
  40. 40. 39 Neste nível de maturidade o foco é a melhoria contínua da performance do processo através de melhorias incrementais e de inovações, objetivos quantitativos de melhoria são estabelecidos e continuamente revisados para refletir as atualizações dos objetivos do negócio. (JAGUARIBE; MARIANO; 20--)1.4.2 CMMI - Representação Contínua Em movimento contrário do processo por estágio, onde a organização tem umcaminho já traçado para chegar a um nível de maturidade, a representação contínua utiliza ummétodo que permite que a empresa escolha qual a área ou áreas de processos que irão utilizarpara que adquira melhoramentos nos processos selecionados para as validações. Utilizando níveisde capacidade, a Representação Contínua apresenta seis níveis de capacitação com numeraçãoiniciada no número zero e finalizada no numero cinco. As áreas de processo são agrupadas porcategorias afins. É importante ressaltar que muitos aspectos são os mesmos da Representação porEstágios. Figura 10: Demonstra os níveis de processo do modelo CMM. Fonte: ASR < http://www.asrconsultoria.com.br/docs/SPIN_BH_CMMI.pdf > As áreas de processos são agrupadas em quatro categorias: Gerência de Processos,Gerência de Projeto, Engenharia e Suporte. Analisando um pouco mais a fundo essas áreas,temos o seguinte cenário: a categoria Gerência de Processos contém atividades relacionadas paradefinir, planejar, implantar, monitorar, controlar, medir e melhorar processos; a Gerência de
  41. 41. 40Projeto contém atividades de planejar, monitorar e controlar o projeto; a Engenharia refere-se àsvárias engenharias; e o Suporte fornece suporte ao desenvolvimento e à manutenção de produtos. Segundo MANERA (et al ;2007) “na representação contínua, o enfoque oucomponentes principais são as áreas de processo, pois existem metas e práticas de dois tipos:específicas a uma determinada área de processo e genéricas aplicáveis indistintamente a todas asáreas de processo”, e são classificadas na ordem a seguir.1.4.2.1 “0” Incompleto O nível incompleto se refere a não finalização de um processo, ou quando um oumais objetivos específicos do processo não são convincentes e satisfatórios, quando avaliado pelaorganização.1.4.2.2 “1” Realizado Com a área escolhida pela organização, os objetivos específicos de cada processosão finalizados com eficácia. Segundo MANERA (et al ;2007) “um processo realizado satisfaztodos os objetivos específicos da área de processo e produz algum trabalho”.1.4.2.3 “2” Gerenciado Herdando a característica do nível anterior, contendo processos realizados complanejamentos gerenciados, os processos são monitorados, revisados e controlados, assim comoos produtos de software e serviços, por pessoas com habilidades adequadas para produzirem oque cada processo pede.
  42. 42. 411.4.2.4 “3” Definido Tendo os processos da organização padronizados, serão progressivamentemelhorados com mais rigor nas descrições dos processos provindos do nível dois.1.4.2.5 “4” Gerenciado quantitativamente Com utilização de técnicas quantitativas e estatísticas, os processos sãocontrolados e a qualidade é entendida por estatísticas sempre que melhorada. Algumas atividadesque se encontram nesse nível é a identificação de sub-processos que podem ser controladas pornormas estatísticas; e a identificação das causas de alterações de desempenho.1.4.2.6 “5” Otimizado O processo otimizado é a visão objetiva em melhoramentos contínuos edesempenho, com a utilização de melhorias tecnológicas incrementais de inovação, visando asvárias modificações, de maneira a estabilizar as variações e a obtenção de melhoria de processos,em busca de um funcionamento próximo da perfeição.
  43. 43. 422 MPS.BR Neste capítulo será feita uma explanação sobre o programa de melhoria deprocessos do software brasileiro (MPS.BR), apresentando informações básicas sobre oscomponentes de método de avaliação (MA-MPS), os modelos de negócios (MN-MPS), o modelode Referência (MR-MPS) e todos seus níveis de maturidade, aprofundando os subsídios para osníveis de maturidade G e F, como previsto na delimitação do tema desta monografia, apresentadoas vantagens estabelecidas para as organizações e a certificação brasileira de melhoria processode software.2.1 Conceito MPSBR O modelo MPS.BR, Melhoria de Processo do Software Brasileiro, é um programaque tem como objetivo a melhoria de processo de software, direcionando a organização, aqualidade e a produtividade dos produtos desenvolvidos e serviços relacionados. SegundoWEBER (20--b, P3) “O Projeto MPS.Br visa a melhoria de processos de software em empresasbrasileiras a um custo acessível, especialmente na grande massa de micro, pequenas e médiasempresas”, sendo utilizado, também, para empresas públicas e privadas, no entanto com padrão equalidade das normas de desenvolvimento internacional, como CMMI desenvolvido pelo SEI,baseado no modelo ISO/IEC 12207 e ISO/IEC 15504. Referente à composição do modelo demelhoria de processo, o projeto MPSBR é constituído por três componentes: Modelo deReferência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de Negócio (MN-MPS). [...] desenvolvimento e aprimoramento do Modelo MPS, compatível com o CMMI e em conformidade com as normas ISO/IEC 12207 e ISO/IEC 15504; e a implementação e avaliação do Modelo MPS, a um custo acessível em todas as regiões do país, com foco em grupos de pequenas e médias empresas (PMEs) (WEBER, 20--a).
  44. 44. 43 Figura 11: Logotipo do modelo MPS.BR Fonte: < http://www.swprocess.com.br/uploadImagens/Logo_MPS.BR.JPG> As duas metas que compreendem o projeto MPS.BR, segundo publicou WEBER(20--a) é justamente o desenvolvimento e aprimoramento do Modelo MPS com totalcompatibilidade com o CMMI e as ISO/IEC 12207 e ISO/IEC 15504, como segunda meta aimplementação e avaliação do modelo brasileiro, a um custo acessível em todo o país, com foconas pequenas e médias empresas. Figura 12: Estrutura do projeto MPS.BR Fonte: ULBRA < http://www.garcia.pro.br/Qualidade/Qualidade%20de%20Software %20- %20Aula%207%20-%20MPS-BR.pdf> A figura 12 demonstra a estrutura do projeto MPS.BR, as suas bases desustentação nas normas internacionais da ISO/IEC 12207, da ISO/IEC 15504, e do CMMI, esta éa mais utilizada em relação à melhoria de processos de software. Já os demais componentes queformam o conjunto do projeto tem as seguinte funções: o guia geral contém informações queobjetivam o modelo de Referência (MR-MPS), seus níveis e etc; o guia de aquisição descreve osprocessos de aquisição de software e serviços correlatos; no guia de avaliação, é apresentado ométodo de avaliação (MA-MPS), contendo principalmente os passos necessários para o
  45. 45. 44entendimento dos processos avaliativos; e no documento de programa contém informações sobreo modelo de negócio (MN-MPS). Cada componente é descrito em documentos ou guias. Segundo SILVA (20--) “oprojeto tem como objetivo promover a qualificação de um grupo amplo de empresas compatívelcom os padrões de qualidade aceitos internacionalmente. Este projeto está sendo desenvolvidodesde dezembro de 2003” o qual foi criado no Brasil para a solução do melhoramento doprocesso de software, objetivando ajudar em número expressivo as micros, pequenas e médiasempresas. Estudos sobre a qualidade de software brasileiro realizados pela SOFTEX mostram a necessidade de um esforço significativo das empresas e governos, no sentido de aumentar a maturidade dos processos de software. A partir dessa necessidade, surgiu o projeto MPS.BR - melhoria de processo do software.(PRIKLADNICKI, BECKER, YAMAGUTI, 2005, p 39). Figura 13: Logotipo da Coordenadora do projeto MPS.BR Fonte: < http://www.estrategia.eti.br/images/logo_softex.jpg > O comitê gestor do projeto MPS.BR é formado pela Associação para Promoção daExcelência do Software Brasileiro (SOFTEX) que a é a Coordenadora, pela COPPE/UFRJ(coordenadora da ETM - Equipe Técnica do Modelo); pela RIOSOFT no Rio de Janeiro/RJ; pelaCenPRA em Campinas/SP; pelo CESAR em Recife/PE e pela CELEPAR em Curitiba/PR. Essecomitê recebe apoio financeiro do Ministério da Ciência e Tecnologia (MCT), através de recursosdo Fundo Nacional de Desenvolvimento Científico e Tecnológico (FNDCT), Financiadora deEstudos e Projetos (FINEP); do Fundo Nacional de Desenvolvimento Científico e Tecnológico(FNDCT) com fundo do VERDE-AMARELO; do Banco Interamericano de Desenvolvimento(BID) e do suporte do Serviço Brasileiro de Apoio às Micro e Pequenas Empresas (SEBRAE) .
  46. 46. 45 O Projeto MPs.Br é uma iniciativa envolvendo universidades (Universidade Católica de Brasília – UCB e Coppe/UFRJ), grupos de pesquisa (Coppe/UFRJ, Cesar, CenPRA) e empresas (Celepar, Riosoft e Núcleo Softex Campinas), sob a coordenação da SOFTEX (Sociedade para Promoção da Excelência do Software Brasileiro (Silva, 20--).Quadro 1: Visão da formação do projeto MPSBRFonte: Weber (WEBER, 20--b).2.2 Modelo de Referência (MR-MPS) No modelo de referência, é o componente do programa brasileiro que fica com aresponsabilidade, Segundo a SOFTEX (2009a), coordenadora do projeto MSPBR disponibilizaque: “O Modelo de Referência MR-MPS contém os requisitos que os processos das unidadesorganizacionais devem atender para estar em conformidade com o MR-MPS. Ele contém asdefinições dos níveis de maturidade, processos e atributos do processo” com seus requisitos emtotal conformidade com as normas internacionais ISO/IEC 12207, ISO/IEC 15504 e o CMMI.Segundo Weber (20--c) “O MR-MPS é definido através de sete níveis de maturidade seqüenciaise acumulativos. Cada nível de maturidade é uma junção entre processos e capacidade dosprocessos, ou seja, é composto por um conjunto de processos em um determinado nível decapacidade”. Tais níveis são nomeados por letras que representam o estado de maturidade quepossa atuar em uma organização. São elas de “A” até “G”, montado, assim, o perfil de processoda empresa que indica onde estão os erros para que possam ser sanados, colocando o esforço namelhoria do processo.
  47. 47. 46 Os níveis de maturidade são definidos pelo MR-MPS, que são uma combinação entre processos e sua capacidade. A evolução de processos, que caracterizam estágios de melhoria da implementação de processos na organização, estabelecem os níveis de maturidade. O desempenho futuro de uma organização, ao executar um ou mais processos, pode ser previsto através do seu nível de maturidade (Silva, 2009).Figura 14: Descrição dos níveis de maturidade do (MR-MPS.BR) com seus processos.Fonte: SOFTEX < http://api.ning.com/files/x2oO-xyZI57WUT8fq2NZoRlmGFJ-NNKXmkSe7OsLi2E9Ji1tryAd3YcySP9pHhtMwywGwAt3xpw*NkTf*NJnYI4oa7zDqPMJ/niveis2009.png> A figura 14 mostra Os níveis de maturidade do modelo de referência, os quais sãonomeados e lidos em ordem inversa, iniciando na letra “G” e finalizando em “A”. Tais níveis sãoos seguintes: Parcialmente Gerenciado, Gerenciado, Parcialmente Definido, LargamenteDefinido, Definido, Gerenciado Quantitativamente e o grau de maturidade mais elevado. EmOtimização, cada nível tem seus processos receptivos. Segundo a SOFTEX (2b009a) “O MR-MPS define sete níveis de maturidade: A (Em Otimização), B (Gerenciado Quantitativamente), C(Definido), D (Largamente Definido), E (Parcialmente Definido), F (Gerenciado) e G(Parcialmente Gerenciado)”.
  48. 48. 47 A organização para atingir o nível E deve executar os processos do nível G e F, e mais os processos: Gerência de Projetos – Evolução, Gerência de Reutilização, Gerência de Recursos Humanos, Definição do Processo Organizacional e Avaliação, Melhoria do Processo Organizacional. No nível D, os processos dos níveis G, F e E são executados e mais os processos: Verificação, Validação, Integração do Produto, Projeto e Construção do Produto, e Desenvolvimento de Requisitos. Para alcançar o nível C de maturidade, a organização deve executar os processos dos níveis G, F, E e D, e mais os processos: Gerência de Riscos, Análise de Decisão e Resolução, Desenvolvimento para Reutilização e Gerência de Reutilização – Evolução. No nível B, os processos dos níveis G, F, E, D e C devem ser executados e mais o processo: Gerência de Projetos – Evolução. Por fim, para alcançar o nível A, os níveis G, F, E, D, C e B devem ser executados e mais o processo: Análise de Causas de Problemas e Resolução. Portanto, os níveis de maturidade no MR-MPS são acumulativos (Silva, 2009) Nos níveis de maturidades que compõem o Modelo de Referência (MR-MPS), o Ge F serão mais detalhados, porém as atividades pertencentes ao nível G são dois processos:Gerência de Projetos e Gerência de Requisitos. no nível F, onde os processos são acumulativos,vindos do nível inferior, os processos do nível Gerenciado são: Medição, Garantia da Qualidade,Gerência de Portfólio de Projetos, Gerência da Configuração e Aquisição2.2.1 G - Parcialmente Gerenciado Nos níveis de maturidade do modelo relacional, o nível G é o primeiro a implantaras melhorias dos processos de software em uma organização. Por este motivo, deve ter cautelapara a capacidade da empresa, na Gerência de projetos, mesmo sendo parcialmente, e na gerênciade requisito, que são os dois processos que compõem o nível G. Dois pontos são crucias na formade trabalhar da organização: mudar a cultura da organização para a melhoria de processo, e adefinição de projeto para a organização No nível G, o projeto pode usar os seus próprios padrões e procedimentos, não sendo necessário que se tenha padrões em nível organizacional. Se, porventura a organização possuir processos já definidos e os projetos necessitarem adaptar os processos existentes, esse fato deverá ser declarado durante o planejamento do projeto. Essas adaptações podem incluir alteração em processos, atividades, ferramentas, técnicas, procedimentos, padrões, medidas, dentre outras. (SOFTEX, 2009d, pag. 6)
  49. 49. 48 Para que uma empresa adapte sua forma de desenvolver software, que é evolução de produtos para tornarem em orientação projetos, terá de redefinir algumas operações, como o próprio projeto e seu escopo, foco especifico no objetivo e no prazo de desenvolvimento. 2.2.1.1 Gerência de Projetos Segundo o guia específico do nível de maturidade G da SOFTEX (2009d) “O propósito do processo de Gerência de Projetos é estabelecer e manter planos que definam as atividades, recursos e responsabilidades do projeto, bem como prover informações sobre o andamento do projeto que permitam a realização de correções quando houver desvios significativos no desempenho do projeto”. Ao crescimento dos níveis de maturidades, muitos resultados são incorporados e outros sofrem evoluções. O nível G envolve, ainda, algumas atividades, tendo que desenvolver um plano geral de controle do projeto e obter garantia na manutenção do projeto até sua execução e conhecimento sobre o projeto, para quando for necessário tomar providencias nas ações de correção sem desviar o planejamento nem o cronograma. De acordo com o guia de implementação, a parte 1 que é a Fundamentação para Implementação do Nível G do MR-MPS (SOFTEX, 2009d), detalha os resultados esperados semelhante a quadro 2 abaixo. Resultados Gerência de Projetos (GPR) Esperados GPR1 O escopo do projeto é definido, determinando o que está e o que não está incluído, limitando as restrições e os produtos que serão entregues. GPR2 As tarefas e Produtos são dimensionados, resultado de estimativa de tamanho, a dimensão das funcionalidades são contadas, classes, objetos, relatórios, telas, consultas a banco de dados, transações, atores dos casos de uso e linhas de código etc. uma das técnicas mais utilizadas é a Ponto de Função GPR3 As fases do ciclo de vida do projeto são definidas, que podem ser modelos sequenciais, cascatas ou modelos incrementais e modelos evolutivos das fases, importante desenvolvimento de fases posteriores. GPR4 O esforço e o custo para a execução do projeto são estimados com base em dados históricos onde são recuperadas informações de tempo e complexidade, para equilibrar a comparação de riscos e mudanças que vão ser feitas, incluído viagens, nível de competência dos colaboradores e equipes de projeto. GPR5 O orçamento e o cronograma do projeto, incluindo a definição de marcos e pontos de controle, são estabelecidos e mantidos, dependência entre tarefas são estipuladas, gargalos são resolvidos e o cronograma das atividades com início, duração e término é estabelecido.Quadro 2: Descrição dos resultados esperados para o processo Gerência de Projetos (Continuação)Fonte: SOFTEX(SOFTEX, 2009d).

×