CMM_CMMI_Koscianski

Prévia do material em texto

<p>Aprenda as metodologias e técnicas mais modernas para desenvolvimento de software Testes DEFEITOS CMMI Metodologias ageis UEG 05003587 novatec Michel dos Santos Soar</p><p>Capítulo 5 CMM e CMMI Uma organização saudável e inovante requer que trabalhemos com pessoas em vez de fazer coisas para elas. Alfie Kohn Dois dos principais modelos criados pelo SEI (Software Engineering Institute) para melhoria de processos são o SW-CMM e o CMMI. Criado no final da década de 1980 apenas para software, o SW-CMM obteve grande sucesso ao gerar novos padrões para a engenharia de sistemas. Posteriormente, como uma evolução dos vários CMMs existentes, foi criado o modelo CMMI. 5.1 modelo SW-CMM O SW-CMM (Capability Maturity Model for Software) [Paulk et al., 1991] é um modelo de capacitação de processo patrocinado pelo Departamento de Defesa dos EUA, para a avaliação da capacidade dos seus fornecedores de software. O SW-CMM baseou-se em algumas das idéias mais importantes do movimento de qualidade industrial das últimas décadas. Alguns dos princípios desse modelo foram inspirados por Crosby [1992], em Quality is Free. Nesse livro, Crosby descreveu cinco estágios de maturidade, conforme descrito no Capítulo 4. Por ser específico à área de software, não participam do escopo do SW-CMM outras áreas importantes da empresa, como Recursos Humanos e Finanças. Assim, sua aplicação não garante a viabilidade de uma organização, embora possa ser um fator importante de melhoria da eficácia e da competitividade. Além disso, o SW- CMM focaliza os processos, fator com maior potencial de melhoria a curto prazo.</p><p>Qualidade de 96 5.1.1 Níveis do SW-CMM principal do SW-CMM é que as organizações com a implementação conheçam e de objetivo processos de desenvolvimento de software baseada em vários pequenos definidas. seus A melhoria de um processo organiza é os passos evolucionários não em grandes definem revoluções. uma escala SW-CMM para avaliar a maturidade níveis. do processo dentro em cinco da empresa. níveis, que A Figura 5.1 apresenta um esquema dos Processos melhorados continuamente Processos medidos Nível e controlados otimizado quantitativamente Nível Processos gerenciado padronizados quantitativamente Processos Nível disciplinados definido Nível Processos ad-hoc gerenciado Nível inicial Figura 5.1 - Níveis de maturidade do SW-CMM. Cada nível do SW-CMM, com exceção do primeiro, é composto de várias as-chave de Processo (Key Process Areas [KPAs]). Cada KPA identifica um grupo de atividades correlatas que realizam um conjunto de metas. As KPAs de um nível identificam objetivos que devem ser cumpridos. Além disso, são cumulativas, ou seja, uma empresa que atinja o nível 5 satisfaz todas as KPAs dos níveis 2 a 5. Os cinco níveis de maturidade do SW-CMM, Inicial, Repetitivo, Definido, Gerenciado e Otimizado, são descritos a seguir. 5.1.1.1 Nível 1: inicial Neste nível, poucos processos são definidos e o sucesso depende muitas vezes de heroísmos individuais, conforme discutido no Capítulo 4. Organizações nesse nível, muitas vezes, são até bem-sucedidas, mas isso em geral se restringe ao desenvolvimento de produtos com os quais já estiveram envolvidas anteriormente [Weinberg, 1994]. Organizações que estão no nível 1 apresentam deficiências de planejamento que geralmente ocasionam vários problemas. Enfrentam dificuldades ao realizarem previsões e, quando estas são feitas, geralmente contêm</p><p>Capitulo 5 CMM e CMMI 97 Os cronogramas e planos são irrealistas e acabam sendo alterados inúmeras vezes durante o desenvolvimento do software. Nesse ambiente, os imprevistos são comuns e, para serem resolvidos, dependem geralmente da capacidade individual. Como todos na empresa estão acostumados à idéia de que previsões e planos não funcionam, mesmo aquilo que foi planejado não é seguido. A falta de credibilidade do planejamento leva a um desenvolvimento confuso de software. É comum passar diretamente dos requisitos à codificação e a documentação é encarada como algo inútil, feita apenas por profissionais que compreendem sua importância. Para que um gerente possa administrar uma equipe nessas condições, é preciso iniciar realizando uma mudança Dificilmente a equipe acreditará nos bene- fícios de processos bem organizados. São comuns reações intransigentes à coleta de dados, ao uso de padrões de desenvolvimento, de documentação e de ferramentas. A mudança deve ocorrer lentamente e o uso das KPAs pode contribuir justamente nisso. Um gerente pode planejar a introdução de cada KPA de maneira a habituar a equipe a seguir padrões organizacionais. 5.1.1.2 Nível 2: repetitivo Neste nível, as organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente. Por exemplo, organizações especializadas em desenvolvimento de softwares baseados em plataforma Web adquirem know-how nessa área para proje- tos futuros. Um novo projeto, desta vez envolvendo uma aplicação mainframe, terá chances menores de obter os mesmos sucessos anteriores. Há preocupação com a gerência do projeto; por exemplo, as práticas de fazer reuniões semanais e de acompanhar cronograma constantemente são definidas pelos gerentes e seguidas pela equipe. Os gerentes conseguem, então, identificar problemas como dificuldade em atingir prazos antes que estes apareçam ou se tornem críticos. Uma organização de nível 2 é disciplinada ao executar projetos, mas não está bem preparada para mudanças. É incapaz de prever resultado da adoção de novas ferramentas e métodos, ou do desenvolvimento de novos produtos. Áreas-chave: Gestão dos requisitos: permite a definição e o controle dos requisitos, evitando descontrole nas mudanças, e um acordo entre stakeholders e de- senvolvedores sobre as funcionalidades requeridas no software. Planejamento de projetos: estabelece planos do projeto, possibilitando a previsão de prazos e custos.</p><p>Qualidade de Software 98 verifica o atendimento Supervisão e acompanhamento comparando o que de projetos: foi atingido com o que havia sido dos planejado compromissos, e acionando providências corretivas sempre que haja desvios significativos. Gestão da subcontratação: gerencia as organizações subcontratadas desenvolver partes do software segundo padrões de qualidade Grupo de garantia da qualidade: verifica o cumprimento dos compromissos de forma independente em relação aos projetos e verificando a qualidade do processo e dos produtos. Gestão de configurações: garante a consistência permanente dos resultados dos projetos em relação aos requisitos, mesmo quando ocorrem alterações nos compromissos. 5.1.1.3 Nível 3: definido Neste nível, as organizações não repetem simplesmente os sucessos de projetos anteriores, mas estabelecem uma infra-estrutura de processos que permite a adap- tação a mudanças. A organização consegue manter-se dentro do processo mesmo em períodos de crise. As ferramentas passam a ser aplicadas de forma sistemática, padronizada e coerente. Com isso, passam a contribuir significativamente para a melhoria da qualidade e da produtividade. Por outro lado, o conhecimento a respeito dos processos ainda é basicamente qualitativo. As informações obtidas com os projetos anteriores são usadas para a gestão de projetos. Pode existir uma base de dados com tais informações, mas estas ainda não são aplicadas de forma sistemática em toda a organização. Tais bases de dados servem, já no nível 4, ao objetivo de definir e verificar metas quantitativas de desempenho de processo e de qualidade do produto. O processo para desenvolver o software é bem documentado, o que ajuda o gerente e a equipe a terem melhor controle. A equipe conhece bem o seu papel dentro do projeto e compreende que eventuais não-conformidades têm impacto na qualidade do software. Para que cada membro da equipe desenvolva seu traba- lho da melhor forma, há preocupação de que todos tenham os conhecimentos e habilidades necessários. Como o processo é bem definido, caso um desenvolvedor abandone o projeto antes do seu término, o impacto é relativamente menor que nos níveis anteriores. Os gerentes têm maior conhecimento do progresso dos projetos, pois as ativi- dades são planejadas, estáveis e repetitivas. Como há melhoria da funcionalidades estão sob controle. qualidade do software, uma vez que os custos, escalonamentos de tarefas, prazos e</p><p>Capítulo 5 CMM e CMMI 99 Areas-chave: Um grupo de engenharia de processos de software é estabelecido, sendo responsável pelas atividades de desenvolvimento, melhoria e manutenção de processos de software. Um de software no âmbito da organização é estabele- cido, a partir do qual devem ser derivados os processos definidos para os projetos. Programas de treinamento são estabelecidos para que os membros das equipes desenvolvam suas habilidades técnicas e seus conhecimentos e possam realizar seu trabalho de forma mais eficiente. Gestão integrada de projetos: baseada nos processos definidos para os pro- jetos, com o uso de procedimentos documentados para gestão de tamanho, esforços, prazos e riscos. Padronização no âmbito da organização dos métodos de engenharia de sof- tware, abrangendo requisitos, projeto, codificação, testes e documentação. Coordenação entre os grupos que participam de projetos de sistemas, no âmbito da organização. Coordenação de revisões no âmbito da organização, com os objetivos de remover e evitar defeitos. 5.1.1.4 Nível 4: gerenciado Neste nível, a administração de processos e produtos evolui para um tratamento quantitativo. Isso não implica que apenas agora devam ser coletadas métricas de processo. No nível 4, a organização é proficiente em fazê-lo e gerir a base de dados de processo. A produtividade e a qualidade são medidas em todos os projetos como parte de um programa organizacional. Uma base de dados de processos de software é usada para coletar e analisar dados disponíveis a partir dos processos de software definidos. São estabelecidas métricas quantitativas para avaliar os processos e os produtos de software. Os riscos envolvidos no aprendizado para desenvolvimento em um novo domínio de aplica- ções são cuidadosamente gerenciados. Como resultado desse maior controle, coleta de dados e gerenciamento de riscos, os produtos de software tendem a apresentar maior qualidade.</p><p>100 Qualidade de Software Áreas-chave: Gestão quantitativa dos processos: controla o desempenho dos processos usados pelos projetos. O foco é identificar causas especiais de variações de forma apropriada, corrigi-las. e, Gestão da qualidade de software: promove o entendimento quantitativo da qualidade dos produtos de software, aplicando métricas nos produtos de software. 5.1.1.5 Nível 5: otimizado Neste nível, os processos estão em melhoria contínua, sendo otimizados para as necessidades de cada momento. Os gerentes identificam pontos fracos de cada processo e agem de forma pró-ativa para que estes sejam melhorados. A eficiência medida é usada para a análise de custo-benefício de novas tecnologias. A equipe constantemente verifica novas tecnologias e processos e avalia se sua adoção tornaria sua forma de trabalho mais produtiva. Os defeitos são identificados e resolvidos, e suas causas são estudadas para não serem repetidas: as lições aprendidas com erros e acertos são usadas nos projetos seguintes. Prevenção dos defeitos por meio da identificação e remoção de suas Gestão da evolução tecnológica com procedimentos sistemáticos de identificação, análise e introdução de tecnologias apropriadas de forma eficiente nos projetos, como novas ferramentas, linguagens e técnicas de Gestão das mudanças de processos, com base nos dados coletados do processo, colocando-os em melhoria contínua. 5.1.2 SW-CMM em pequenas empresas O SW-CMM, que é baseado nas boas práticas da engenharia de software, foi criado para grandes organizações e projetos. uma grande questão sobre o uso do SW-CMM é em relação à sua aplicabilidade para pequenas e médias empresas e projetos. Contudo, o que significa o tamanho? Deve-se considerar o custo, o prazo, o número de pessoas ou alguma métrica como pontos por função para determinar o tamanho do projeto? De acordo com Paulk [1998], o modelo enfatiza a identificação da necessidade de melhoria nos processos, independentemente do tamanho da organização em que</p><p>Capítulo 5 CMM e CMMI 101 essa melhoria será aplicada, do tamanho do projeto ou do número de membros na equipe. A descrição do SW-CMM é extensa: o modelo é dividido hierarquicamente em 5 níveis, 18 áreas-chave, 52 objetivos e 316 práticas. Essa complexidade muitas vezes intimida pequenas empresas. Entretanto, os conceitos fundamentais do SW-CMM são as boas práticas da engenharia de software; logo são, em princípio, aplicáveis a quaisquer projetos e organizações. Uma prática adequada é adaptar gradativamente o SW-CMM de acordo com a organização e não alterar tudo repentinamente para se adequar a esse modelo. Isso as é interessante em relação à terminologia utilizada na empresa, que não deve ser alterada. Por exemplo, não importa se o nome de uma área no modelo é Gestão de Requisitos e na empresa é Controle de Requisitos. Ao dividir tarefas em equipes, é importante entender conceito de grupo no SW-CMM. Por exemplo, o grupo de a Garantia de Qualidade em uma organização pequena pode ser uma única pessoa e trabalhando em tempo parcial. Uma mesma pessoa pode acumular várias funções, sendo, por exemplo, responsável por várias práticas estabelecidas no modelo. Existem diversos casos de sucesso relatados quanto ao uso do SW-CMM em pequenas organizações, como indicam Abbott [1997], Hoffman [1998] e Johnson e Brodman [1997,1998]; ou, ainda, propostas de modelos baseados em SW-CMM, como demonstram Orci e Laryd [2000a, 2000b]. Nesses artigos, argumenta-se que pequenas organizações bem-sucedidas devem crescer, e, então, caos poderá ser instalado. Assim, a melhoria de processos pode ser iniciada cedo, criando uma cultura de qualidade que será útil no futuro. O modelo de Orci e Laryd é indicado para organizações com até 50 pessoas e considera práticas até o nível 2 do SW-CMM. Convém salientar que uma alternativa para as pequenas organizações é o uso do PSP e do TSP, conforme será discutido no Capítulo 6. 5.1.3 Conclusão do SW-CMM Os modelos de maturidade, entre os quais o SW-CMM é um dos principais, estão se tornando cada vez mais utilizados no mundo. Por exemplo, para alguns contratos de fornecimento de software para a Força Aérea e a Marinha Americana, é necessário que o fornecedor seja certificado em um nível mínimo do SW-CMM. As empresas brasileiras também demonstram interesse crescente na certificação, como mostra a Figura 5.2 (dados até novembro de 2005). O número de empresas certificadas a partir de 1997 coloca o Brasil entre os dez primeiros países do mundo em relação ao número de certificações SW-CMM. Os dados são do MCT (Ministério da Ciência e Tecnologia).</p><p>Qualidade de Software 102 Certificações CMM no Brasil 52 36 27 10 6 1 2 2 2 2000 2001 2002 2003 2004 2005 1997 1998 1999 Figura 5.2 Número de certificações SW-CMM no A maioria das empresas certificadas no Brasil ainda está no nível 2. A tendência é que as empresas certificadas com o SW-CMM evoluam para o novo modelo, 0 CMMI, o que já está acontecendo tanto no Brasil como no mundo. Finalmente, segundo Herbsleb et al., [1997], a implantação do modelo traz efe- tivamente um retorno do investimento realizado. Destacam-se aumento da produ- tividade, redução do tempo de desenvolvimento e da quantidade de defeitos. 5.2 Modelo CMMI Com o sucesso do SW-CMM, novos modelos semelhantes foram criados para di- versas áreas, como gestão de recursos humanos (P-CMM), de aquisição de software (SA-CMM) e de engenharia de sistemas (SE-CMM). Entretanto, os diversos padrões apresentam estruturas, formatos e termos diferentes, causando confusão quando é necessário o uso de mais de um deles simultaneamente. Com a finalidade de integrar os diversos modelos criados e como uma evolução do CMM foi criado o CMMI. Durante o desenvolvimento do CMMI (Capability Maturity Model Integration), houve preocupação com sua futura evolução. Desta forma, foi projetado prevendo a possibilidade de integração com outros modelos. Todos os textos desenvolvidos são consistentes e compatíveis com a ISO/IEC TR 15504. O objetivo do CMMI é servir de guia para a melhoria de processos na organi- zação e também da habilidade dos profissionais em gerenciar o desenvolvimento, aquisição e manutenção de produtos ou serviços. Assim como no caso do SW-CMM, seus espera-se que com o uso do CMMI a organização seja mais eficiente, respeitando dicam próprios prazos e construindo software com menos Alguns estudos in- uma visão que, de fato, esses objetivos têm sido atingidos. Neste capítulo é apresentada geral do CMMI, mas sem esgotar o</p><p>Capítulo 5 CMM e CMMI 103 Alguns termos importantes do CMMI são explicados a seguir. Áreas de processo: uma área de processo é um conjunto de práticas que, quando executadas coletivamente, satisfaz um conjunto de objetivos que é importante para que haja melhoria significativa nessa área. Objetivos específicos: são aplicados para uma área de processo e identi- ficam características únicas que descrevem o que deve ser implementado para satisfazer essa área de processo. Práticas específicas: são atividades importantes para atingir um determi- nado objetivo específico. Cada prática específica é associada com um nível de maturidade. Objetivos genéricos: cada nível de maturidade possui apenas um objetivo genérico que descreve o que uma organização deve fazer para atingir um nível determinado. Portanto, existem cinco objetivos genéricos, um para cada nível. Práticas genéricas: asseguram que os processos associados com as áreas de processo serão efetivos e repetíveis. Práticas genéricas são categorizadas por nível de maturidade. 5.2.1 Disciplinas do CMMI Existem quatro corpos de conhecimento (ou disciplinas) presentes no modelo CMMI: Engenharia de sistemas, Engenharia de software, Desenvolvimento e inte- gração de produtos e processos e aontes de Aquisição, conforme mostrado na Figura 5.3. Cada disciplina é apresentada brevemente a seguir. CMMI Desenvolvimento Fontes de Engenharia de Engenharia de Integrado do Produto Software Aquisição Sistemas e do Processo Figura 5.3 - Disciplinas do CMMI. 5.2.1.1 Engenharia de sistemas A Engenharia de sistemas [Abran et al. 2004] é uma abordagem interdisciplinar, cujo objetivo é a obtenção bem-sucedida de sistemas, envolvendo ou não software. Segundo as necessidades, restrições e expectativas apresentadas pelos clientes, os</p><p>Qualidade de Software 104 de sistemas produtos e soluções suporte. por meio da análise, validação, engenheiros teste, implementação, treinamento e 5.2.1.2 Engenharia de software dos problemas percebidos no desenvolvimento pesquisadores de software com na década Em razão de 1960, a Engenharia de software foi idealizada tratamento por de engenharia intuito atividade de tratada como arte [Naur e Randell, 1968]. A Engenharia de software, software disciplinar a produção de software, dando de a também se às atividades de gerenciamento de projetos, desenvolvimento não uma dedica somente aos processos técnicos de desenvolvimento de mas teorias dêem apoio à produção de software. De acordo com o a Engenharia métodos e de software que é a "aplicação de uma abordagem sistemática, disciplinada e quantificável para o desenvolvimento, operação e manutenção do Ou seja, é a aplicação de engenharia ao desenvolvimento de software. 5.2.1.3 Desenvolvimento integrado do produto e do processo O Desenvolvimento integrado do produto e do processo é uma abordagem tica que utiliza a colaboração dos stakeholders para melhor satisfazer as expectativas e requisitos dos clientes. Esses processos são integrados aos outros que existem na organização. 5.2.1.4 Fontes de aquisição À medida que os esforços de desenvolvimento tornam-se mais complexos, os projetos podem precisar de fornecedores que realizem funções específicas ou adicionem mo- dificações em produtos específicos do projeto. Quando essas atividades são críticas, o projeto é beneficiado por atividades de monitoramento antes do seu lançamento. A disciplina CMMI de Fontes de aquisição atua na aquisição de produtos nessas 5.2.2 Representação por estágios X contínua O CMMI estágios existe em duas representações: "por estágios" ou A abordagem geral, por segue a mesma estrutura do SW-CMM, com níveis de maturidade. Em manter organizações a que já possuam experiência com o SW-CMM O mesmo mesma pode abordagem, por estágios, para a condução do programa podem de preferir melho- e os modelos SE-CMM, seu processo de melhoria. Já organizações com que recém-iniciaram acontecer com organizações sem experiência SW-CMM representação EIA/IS 731 ou ISO/IEC TR 15504, podem preferir que empregam adotar a contínua do CMML</p><p>Capítulo 5 CMM e CMMI 105 Na representação contínua é possível selecionar a de melhorias que convém aos objetivos dos negócios da organização e que diminui os A mi- gração do EIA/IS 731 e do ISO/IEC 15504 para CMMI é mais natural. A representação por estágios começa com práticas básicas de gerenciamento e progride por um caminho predefinido de níveis de sucesso, cada um servindo de base para o próximo. Com esta representação é mais fácil efetuar a migração do SW-CMM para o CMMI, ou, ainda, realizar a comparação de nível entre organizações. 5.2.3 CMMI: Representação por estágios Os componentes comuns das representações por estágios e contínua são: áreas de processo, objetivos específicos, práticas específicas, objetivos genéricos, práticas genéricas, produtos típicos de trabalho, subpráticas, notas, disciplinas, práticas genéricas e referências. A representação por estágios organiza as áreas de processo em cinco níveis de maturidade (como no SW-CMM) para suportar e guiar a melhoria de processos. Esses níveis de maturidade representam um caminho de melhoria de processos para toda a organização. A Figura 5.4 apresenta uma estrutura gráfica por estágios do CMMI para software. Objetivos Práticas Específicos Específicas Área de Processo 1 Nivel de Maturidade 1 Objetivos Genéricos Área de Processo n Nível de Maturidade 2 Caracteristicas comuns Compromisso Habilidade Direção da Verificação da Nível de Maturidade 5 com Execução para Execução Implementação Implementação Práticas Genéricas</p><p>de Software 106 Na representação por estágios, os níveis de maturidade sugerem uma ordem para a melhoria dos processos. A cada nível de maturidade existem diversas áreas de Em cada área de processo há objetivos e práticas genéricos e específicos. Aspectos muns organizam práticas genéricas. Esta representação possui foco nas práticas a melhoria de processos especificamente para o nível de maturidade Um nível de maturidade consiste em práticas específicas e genéricas para uma área de processo, que podem levar a melhorias nos processos Ao satisfazer objetivos específicos e genéricos para uma dada área de processo de um nível particular, a organização obtém os benefícios da melhoria de processos. Na representação do CMMI por estágios, existem cinco níveis de maturidade, designados pelos números de 1 a 5: inicial, gerenciado, definido, gerenciado quan- titativamente e otimizado. Os níveis de maturidade consistem em um conjunto predefinido de áreas do processo. É importante salientar que quando uma organi- zação atinge as práticas necessárias para estar em um nível, isto significa que pratica todos os requisitos necessários dos níveis imediatamente anteriores. Por exemplo, uma organização nível 3 observa todas as características também do nível 2. As próximas seções descreverão as características de cada nível. 5.2.3.1 Nível 1: inicial No nível 1, os processos são caóticos. Geralmente a organização não possui um am- biente estável de desenvolvimento de software. Padrões não existem, ou se existem, não são seguidos. Geralmente os projetos apresentam problemas de cumprimento de custos e prazos, bem como de cumprimento de requisitos. A organização depende com frequência de talentos individuais (os "heróis" mencionados no Capítulo 4), para cumprir com seus compromissos. O fato de uma organização estar no nível 1 e ter processos de desenvolvimento caóticos não significa necessariamente que seus produtos finais são ruins. É possível, até mesmo, que bons produtos sejam entregues. Entretanto, geralmente isto se deve ao trabalho dos heróis que fazem muitas horas extras para compensar planejamentos mais mal Pode ocorrer também de os produtos serem entregues, mas a um custo alto ou com prazo Algumas características são comuns a diversas organizações cujos são mais individuais Dificilmente é possível repetir sucessos anteriores processos são seguintes que organizacionais. A ausência de um técnico-chave porque os sucessos nos dono seus de responsáveis não está mais presente. Outra aban- principais significa que sucessos anteriores serão difíceis de alcançar, pois projetos um dos processos em tempos de crise, com característica o apoio dos é gerentes. o</p><p>Capitulo 5 CMM e CMMI 107 Quando os prazos ficam menores, normalmente se decide por abandonar os poucos processos definidos para acelerar a entrega do projeto. Algumas fases normalmente negligenciadas nestes casos são a documentação e os testes. 5.2.3.2 Nível 2: gerenciado Neste nível, os projetos da organização possuem requisitos gerenciados e proces- SOS planejados, medidos e controlados. As práticas possibilitam que a organização cumpra os planos no desenvolvimento dos projetos. Os requisitos, processos e serviços são gerenciados. Isto significa que há grande preocupação em seguir os planos. Essa preocupação é refletida no fato de o anda- mento das tarefas ser sempre analisado. Desta forma, eventuais não-conformidades são identificadas com alguma antecedência, possibilitando que ações corretivas sejam implantadas. Por exemplo, podem existir marcos de entregas bem definidos no cronograma e tais datas intermediárias são constantemente acompanhadas. Caso exista alguma possibilidade de um prazo não ser cumprido, possivelmente o gerente do projeto conseguirá identificar esse fato e tentará resolver problema, por exemplo, alocando mais pessoas em uma determinada tarefa, em um dado período de tempo. As datas intermediárias de entregas de partes dos produtos são estabelecidas em comum acordo com os stakeholders e revisadas, com os produtos, sempre que necessário. O acompanhamento pelos gerentes aumenta a probabilidade de que os prazos sejam cumpridos. O mesmo ocorre com respeito a cumprir requisitos, aderir a padrões e cumprir os objetivos do projeto. 5.2.3.3 Nível 3: definido No nível 3, os processos são bem caracterizados e entendidos. A padronização de processos possibilita maior consistência nos produtos gerados pela organização. Na descrição dos processos são usados padrões, procedimentos, ferramentas e métodos bem definidos. Esses fatores diferenciam o nível 3 do nível 2. Organizações no nível 2 podem variar padrões, descrições de processo e procedimentos a cada projeto. No nível 3, isso não ocorre mais: os procedimentos são padronizados e de- vem prever a aplicação em projetos diferentes. Outra distinção em relação ao nível anterior é o maior nível de detalhe e rigor na descrição dos processos. 5.2.3.4 Nível 4: gerenciado quantitativamente Os processos são selecionados para contribuir com o desempenho geral dos demais processos. São controlados usando métodos estatísticos e outras técnicas quanti-</p><p>108 Qualidade de Software Aspectos qualitativos devem ser traduzidos em números, o que permite que jam mais bem compreendidos e comparados. A qualidade e o desempenho de um processo são, em geral, mais claramente entendidos e mais precisamente gerenciados se forem empregados valores em vez de escalas qualitativas. No nível 4, dados sobre todos os processos são coletados e analisados ticamente, facilitando acompanhamento do desempenho da empresa. Eventuais problemas específicos que ocasionem variações nas medidas são corrigidos para prevenir futuras ocorrências. As medidas de qualidade e de desempenho do processo são armazenadas em um repositório de dados históricos, para suportar decisões futuras. Desta forma, as decisões corretas são lembradas e podem ser repetidas. Uma distinção marcante do nível 4 em relação ao anterior é o aumento da previsibilidade do desempenho de processos, graças ao controle quantitativo. No nível 3, previsões também são realizadas, porém de forma qualitativa e, portanto, em geral menos precisas. 5.2.3.5 Nível 5: otimizado No nível de maturidade otimizado, os processos são continuamente melhorados com base em um entendimento quantitativo das causas comuns de alterações de desempenho. A melhoria contínua é obtida com inovações e melhor uso de tecnologias. Objetivos quantitativos de melhoria de processos são estabelecidos, continuamente revisados de acordo com os negócios da organização e usados como critério no Os efeitos da implantação da melhoria de processos são medidos e avaliados. A melhoria de processos é uma tarefa de todos, não apenas uma ordem específica dos níveis hierárquicos mais altos. Desta forma, é possível que seja criado um ciclo de melhoria contínua dos processos, evitando-se acomodação e, eventualmente, uma volta a níveis inferiores do CMML tação por estágios. A Tabela 5.1 encerra esta subseção resumindo as áreas de processo da represen- Tabela 5.1 Áreas de processo CMMI por estágios Gerência de requisitos Planejamento do projeto Nível de maturidade Gerência e controle do projeto 2 Gerência de acordos com fornecedores Medição e análise Garantia da qualidade do processo e do produto Gerência de configuração</p><p>ware Capítulo 5 CMM e CMMI se. 109 um Desenvolvimento de requisitos dos Solução técnica Integração do produto Verificação Validação ais Nível de maturidade Foco no processo organizacional 3 Treinamento organizacional ra Gerência de projeto integrada Gerência de riscos Análise de decisão e resolução Desempenho do processo organizacional Definição do processo organizacional a Nível de maturidade Desempenho do processo organizacional 4 Gerência quantitativa do projeto Nível de maturidade Inovação e implantação na organização 5 Análise e resolução de causas 5.2.4 CMMI: representação contínua A representação contínua estabelece seis níveis de capacitação. Nessa representação, as áreas de processo são agrupadas por categorias afins. Os perfis de capacitação representam caminhos de melhoria, indicando a evolução para cada uma das áreas. Em cada área de processo, os objetivos e as práticas específicos são listados, seguidos por objetivos e práticas genéricos. Muitos aspectos da representação contínua são os mesmos da representação por estágios. A Figura 5.5 apresenta a estrutura contínua do CMMI para As áreas de processo do CMMI para software na representação contínua são agrupadas em quatro categorias: Gerência de processos, Gerência de projeto, En- genharia e Suporte. Objetivos Práticas Específicos Específicas Níveis de Área de Processo 1 Capacidade Objetivos Práticas Genéricos Genéricas Área de Processo 2 de Processo n Figura 5.5 Estrutura do CMMI, representação contínua (adaptado do relatório técnico do SEI, ref. CMU/SEI-2002-TR-028).</p><p>Qualidade de Software 110 As áreas de processo relativas à categoria de Gerência de processos contém vidades relacionadas para definir, planejar, implantar, monitorar, de Gerência controlar, medir melhorar processos. As áreas de processo relativas à categoria de pro- jeto e contêm as atividades de planejar, monitorar e controlar projeto. de A categoria de Engenharia refere-se às diversas engenharias, como de sistemas As atribuições de fornecer suporte ao desenvolvimento e à manutenção de produtos são relativas à categoria de Suporte. A Tabela 5.2 apresenta as áreas de processo na representação contínua. Tabela 5.2 Áreas de processo na representação contínua Foco no processo Definição de processos Gerência de processos Treinamento Desempenho de processo Inovação e implantação Planejamento de projeto Controle e monitoramento de projeto Gerência de acordos com fornecedores Gerência de projeto integrada Gerência de projeto Gerência de riscos Integração de equipe Integração de fornecedores Gerência quantitativa de projeto Gerência de requisitos Gerência de desenvolvimento Solução técnica Engenharia Integração de produto Verificação Validação Gerência de configuração Garantia de qualidade de produto e processo Medida e análise Suporte Análise de decisão e resolução Ambiente organizacional para integração Resolução e análise de causas tivos e práticas específicos são aplicados em áreas de processo Obje- Cada prática específica e genérica corresponde a um nível de capacitação. ticas genéricos definem uma de níveis de maturidade e e práticas genéricos são aplicados a múltiplas áreas de Os objetivos Objetivos prá- melhorias na implementação e na efetiva melhoria dos processos que escolhidos. representam</p><p>Capitulo 5 CMM e CMMI 111 Os modelos CMMI são especificados para descrever níveis discretos de melhoria de processos. Na representação contínua, os níveis de maturidade sugerem uma sequência para melhoria de processos em cada área. Ao mesmo tempo, a represen- tação contínua permite alguma flexibilidade em relação à ordem em que as áreas S de processo são abordadas. Na representação contínua existem seis níveis de capacitação denominados: incom- pleto, realizado, gerenciado, definido, gerenciado quantitativamente e otimizado. 5.2.4.1 Nível 0: incompleto nível incompleto corresponde, no caso mais simples, à não-realização de um pro- cesso. Se o processo é implementado pela organização, o nível 0 é atribuído quando um ou mais objetivos específicos da área de processo não é(são) satisfeito(s). 5.2.4.2 Nível 1: realizado Para estar em nível 1, cada processo deve cumprir todos os objetivos específicos de sua área. Um processo utiliza entradas determinadas e leva à obtenção de produtos específicos, identificados como saídas. 5.2.4.3 Nível 2: gerenciado Cada processo cumpre com todos os requisitos do nível 1 e, além disso, é planejado e executado de acordo com uma política determinada. Os funcionários que dele participam possuem as habilidades necessárias e os recursos apropriados, envol- vendo todos os stakeholders relevantes. Processos são monitorados, controlados e revisados, assim como os produtos resultantes. Todo processo é institucionalizado, sendo ancorado nos objetivos da organização e devendo cumprir com metas como custo, prazo e qualidade. É planejado e seu desempenho é gerenciado de acordo com tal plano. Ações corretivas são tomadas quando os resultados desviam do que fora planejado. Além disso, o controle do pro- cesso deve ser capaz de mantê-lo em operação mesmo em situações desfavoráveis. Requisitos e objetivos são estabelecidos. O status dos produtos elaborados e o dos serviços prestados são visíveis para a gerência em pontos definidos. Compro- missos são estabelecidos entre desenvolvedores e stakeholders relevantes, sendo, posteriormente, revisados quando necessário. Os produtos são também revisados e controlados constantemente e devem satisfazer aos requisitos especificados. Alguns pontos a observar, para implementar na organização um processo ge- renciado, são: adesão às políticas organizacionais, cumprimento de planejamentos, existência de recursos necessários, realização de treinamentos, identificação dos</p><p>112 Qualidade de Software principais stakeholders envolvidos, revisão constante de processos pela alta e tomada de ações corretivas quando 5.2.4.4 Nível 3: definido Um processo no nível 3 cumpre todos os requisitos do nível 2. Está adaptado a um junto de processos padronizados da organização, seguindo as diretivas desta Processos padronizados são estabelecidos e melhorados continuamente. A descri- ção de um processo definido inclui, entre outros tópicos, suas entradas, atividades, medidas, verificações e saídas. Comparativamente ao nível definido, os processos gerenciados (nível 2) contêm padrões e procedimentos aplicáveis a um projeto ou função organizacional particular. Dessa forma, em dois projetos diferentes pode haver grandes diferenças em um processo gerenciado. Já os processos definidos são descritos e executados de maneira mais rigorosa. São estabelecidos em função do conjunto padronizado de processos organizacionais e, por isso, são consistentes em toda a empresa. 5.2.4.5 Nível 4: gerenciado quantitativamente Os processos neste nível são definidos e controlados quantitativamente, por exem- plo, aplicando-se técnicas estatísticas. A administração dos processos, bem como a avaliação da qualidade destes, é fundamentada em critérios quantitativos. Um conjunto de processos envolvidos na obtenção de um produto ou serviço é gerenciado quantitativamente. Dados referentes a subprocessos são coletados e analisados estatisticamente. Quando apropriadas, as fontes de variações devem ser tratadas para prevenir futuras ocorrências. A organização possui uma base de dados históricos utilizada para apoiar tomadas de decisão. Uma distinção clara entre os níveis 3 e 4 é a previsibilidade do desempenho de processos. Isso significa que o desempenho quantitativo de um processo é estimado antes de sua execução. No caso de processos definidos, a previsibilidade exigida é menos estrita, sendo apenas qualitativa. Algumas atividades para gerenciar quantitativamente o desempenho de um processo são: a identificação de subprocessos que possam ser controlados esta- tisticamente, a identificação das medidas de atributos significativos de processo e de produtos e a identificação de causas de alterações de desempenho e possíveis ações corretivas.</p><p>vare Capitulo 5 CMM e CMMI cia 113 5.2.4.6 Nível 5: otimizado Um processo otimizado cumpre todos os requisitos do nível 4 e é adaptado para cumprir os objetivos de negócio da organização. Um processo otimizado possui como foco a melhora contínua de desempenho. Esse objetivo é buscado por melhorias tecnológicas incrementais e de inovação. Essas melhorias são selecionadas baseadas em análises quantitativas de sua contribuição esperada em relação ao custo e impacto para a organização. Processos selecionados são sistematicamente gerenciados e implantados. Os efei- tos da implantação da melhoria de processos são medidos e avaliados em relação aos objetivos de melhoria quantitativa previamente estabelecidos. Os processos otimizados são melhorados continuamente, pela intervenção nas causas de variação de desempenho Embora mais previsíveis, os processos de nível 4 podem falhar em atingir seus objetivos. Os processos otimizados são modificados justamente de maneira a estabilizar as variações. 5.2.5 Comparação entre as representações A representação contínua usa níveis de capacitação para medir a melhoria de pro- cessos, enquanto a representação por estágios utiliza níveis de maturidade para medir a melhoria de capacidade da organização. Na prática, a principal diferença é a forma como cada representação é aplicada. Os níveis de capacitação são aplicados na melhoria de processos de uma organização para cada área. Existem seis níveis de capacitação, numerados de 0 a 5, cada um com um objetivo geral e um conjunto de práticas gerais e específicas, conforme mostra a Tabela 5.3. Tabela 5.3 Níveis de capacitação da representação contínua Nível Descrição 0 Incompleto 1 Realizado 2 Gerenciado 3 Definido 4 Gerenciado quantitativamente 5 Otimizado Na representação por estágios, os níveis de maturidade não servem para analisar áreas de processo, mas sim para indicar melhorias na organização como um Há cinco níveis apresentados na Tabela 5.4.</p><p>114 Qualidade de Software Tabela 5.4 Níveis de maturidade da representação por estágios Nível Descrição 1 Inicial 2 Gerenciado 3 Definido 4 Gerenciado quantitativamente 5 Otimizado Ao fazer a avaliação de uma organização, é possível mapear os valores de capaci- dade de processo, da Tabela 5.3, para maturidade organizacional, da Tabela 5.4. Uma organização que apresente nível de capacidade 2 para todas as áreas de processo correspondentes ao nível de maturidade 2 é classificada nesse nível. Para todos os níveis superiores de maturidade, de 3 a 5, exige-se um nível de capaci- dade mínimo igual a 3 para as áreas de processo correspondentes ao nível 5.2.6 Conclusão do CMMI Uma crítica possível ao modelo CMMI é sua complexidade. Para a integração dos diversos aspectos apresentados em diferentes CMMs, foi criado este modelo com muitos termos novos e detalhes difíceis de serem totalmente implantados. A docu- mentação do modelo provida pelo SEI é extensa e complexa: uma única descrição contém mais de 700 páginas. Em geral, é imprescindível recorrer a consultorias especializadas em implementar CMMI e efetuar as reorganizações necessárias dentro da empresa em si. A migração do SW-CMM para CMMI já vem ocorrendo nas empresas tanto Brasil quanto no exterior. A Figura 5.6 mostra a evolução do número de no (Ministério da Ciência e Tecnologia). brasileiras certificadas a partir de 2002 até agosto de 2006. Os dados são empresas do MCT 21 17 2 0 1 2002 2003 2004 2005 2006 (até agosto) Figura 5.6 Certificações CMMI no</p>