O documento aborda normas e modelos de qualidade de software, destacando o modelo CMM (Capability Maturity Model), que avalia a maturidade dos processos de software em cinco níveis. Também menciona a evolução do CMM, sua aplicação em diversas indústrias, e os benefícios de empresas que adotam tais práticas de qualidade. Além disso, o texto inclui informações sobre o processo de certificação, custos e etapas necessárias para obter a certificação CMMI.

1. UNIDAVI - UNIVERSIDADE PARA O
DESENVOLVIMENTO DO ALTO VALE
DO ITAJAÍ
FACITEC – FACULDADE DE CIÊNCIA E TECNOLOGIA
BSI – BACHARELADO DE SISTEMAS DE INFORMAÇÃO
ENGENHARIA DE SOFTWARES
PROF.: Fábio Alexandrini
ACADÊMICOS: Paulo Luis Steinhauser
Rodrigo Schlickmann

3. Normas e Modelos de Qualidade de SW
 ISO 9126 - Norma para qualidade de produtos de software
 ISO 14598 - Guias para avaliação de produtos de software
 ISO 12119 - Norma para qualidade de pacotes de software
 ISO 12207 - Processos de ciclo de vida do software.
 NBR ISO 9000-3 -Diretrizes para aplicação da norma ISO 9001 ao
desenvolvimento, fornecimento e manutenção de software.
 SPICE / ISO 15504 - Projeto da ISO/IEC para avaliação de
processo de desenvolvimento de software.
 CMM - Capability Maturity Model. Modelo do Software Engineering
Intitute (SEI) para avaliação de processos de software.
 PSP - Personal Software Process - Modelo do SEI que define
disciplinas para qualidade pessoal do engenheiro de software.

4. O que é CMM?
O CMM - Capability Maturity Model
(Modelo de Maturidade da Capabilidade)
é um modelo para avaliação da maturidade
dos processos de software de uma
organização e para identificação das práticas-chave
que são requeridas para aumentar a
maturidade desses processos. Ele prevê cinco
níveis de maturidade: inicial, repetível,
definido, gerenciado e otimizado.

5. O que é CMM?
O modelo foi proposto por Watts S.
Humphrey, a partir das propostas de Philip B.
Crosby, e vem sendo aperfeiçoado pelo
Software Engineering Institute – SEI da
Carnegie Mellon University
http://www.sei.cmu.edu

6. OS CRIADORES
Watts_S._Humphrey
Philip B. Crosby

7. Modelos CMM

8. Modelos CMM
 Software Acquisition CMM (SA-CMM) : usado para
avaliar a maturidade de uma organização em seus
processos de seleção, compra e instalação de
softwares desenvolvidos por terceiros.
 Systems Engineering CMM (SE-CMM) : avalia a
maturidade da organização em seus processos de
engenharia de sistemas, concebidos como algo
maior que o software. Um “Sistema” inclui o
hardware, o software e quaisquer outros elementos
que participam do produto completo. Se um novo
caça está sendo desenvolvido, o avião é o “Sistema”,
incluindo aí todo software que nele esteja
embarcado.

9. Modelos CMM
 Integrated Product Development CMM (IPD-CMM) :
ainda mais abrangente que o SE-CMM, inclui
também outros processos necessários à produção e
suporte ao produto, tais como suporte ao usuário,
processos de fabricação etc.
 People CMM (P-CMM) : avalia a maturidade da
organização em seus processos de administração de
recursos humanos no que se refere a software;
recrutamento e seleção de desenvolvedores,
treinamento e desenvolvimento, remuneração etc.

10. CMMI
 O CMMI - Capability Maturity Model
Integration foi criado pelo SEI como uma
integração e evolução dos modelos: SW-CMM -
Capability Maturity Model for Software; SECM -
System Engineering Capability Model, e IPD-CMM
- Integrated Product Development CMM. O
CMMI é um modelo alinhado com a Norma
ISO/IEC 15504 e é apresentado em duas
representações: uma por estágio (como o CMM),
e outra contínua (semelhante à ISO/IEC 15504).

11. História do CMM
 O CMM surgiu durante a década de 1980 como um
modelo para avaliação de risco na contratação de
empresas de software pela Força Aérea Norte-
Americana, que desejava ser capaz de avaliar os
processos de desenvolvimento utilizados pelas
empresas que concorriam em licitações, como
indicação da previsibilidade da qualidade, custos e
prazos nos projetos contratados. Para desenvolver este
modelo, a Força Aérea constituiu, junto à Carnegie-
Mellon University, o SEI (Software Engineering
Institute), o qual, além de ser o responsável pela
evolução do CMM, realiza diversas outras pesquisas
em Engenharia de Software.

12. História do CMM
 O líder do projeto que veio a resultar no CMM
foi Watts Humphrey, anteriormente
responsável por todo o desenvolvimento de
software da IBM, onde aplicou pela primeira
vez os conceitos tradicionais de qualidade,
largamente conhecidos e utilizados em
manufatura, no desenvolvimento e
manutenção de software. Neste trabalho,
Humphrey baseou-se na sua experiência
anterior como engenheiro de hardware.

13. Evolução
 Nov/1986 - início do desenvolvimento do Framework
 Set/1987 - lançada uma descrição geral do modelo
 1988 - publicado o artigo “Characterizing the Software
Process” de Watts Humphrey
 1989 - publicado o livro “Managing the Software Process”,
de Watts Humphrey
 1991/1992 - lançamento e reviões da primeira versão, por
Paulk e Weber (TR24 e TR25)
 1993 - lançada a versão 1.1 e o livro “The Capability Maturity
Model”, de Mark Paulk .

14. Onde é usado o CMM
 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.

15. Onde é usado o CMM
 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. Exemplos
ilustrativos desta diversidade incluem:

16. Onde é usado o CMM
 Pequenas software-houses (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 (outsourcing)

17. Os Cinco Níveis de Maturidade
 Nível de maturidade é um estágio evolutivo bem definido
em busca de um processo de software maduro. Cada
nível de maturidade fornece uma gama de fundamentos
para a melhoria contínua do processo. Cada nível
compreende um conjunto de objetivos de processos
que, quando satisfeitos, estabilizam um componente
importante do processo de software. Alcançando cada
nível da estrutura de maturidade, estabelecesse
diferentes componentes no processo de software,
resultando em um crescimento na capabilidade de
processo da organização.

18. Os Cinco Níveis de Maturidade
O CMM está dividido em cinco níveis de
maturidade, os quais são: Inicial,
Repetível, Definido, Gerenciado e Em
Otimização.

21. Nível 1- Inicial
 Inexistência de um ambiente estável
para desenvolvimento e manutenção de
software.
Ocasionalmente, durante os momentos
de crise, procedimentos planejados são
abandonados e a atenção é focada na
codificação.
 Poucos processos definidos, sucesso
dependente de iniciativas individuais;
ocasionalmente caótico

22. Nível 1- Inicial
Neste nível, não existem procedimentos padronizados,
estimativas de custos e planos de projeto. Cada qual
desenvolve como quer, não existe documentação e não
há mecanismos de controle que permitam ao gerente
saber o que está acontecendo, identificar problemas e
riscos e agir de acordo. Como conseqüência, os
desvios não são corrigidos e ocorrem os problemas
como prazos não cumpridos, orçamentos estourados,
software sem qualidade e usuários insatisfeitos. Na
verdade, raramente existe um cronograma ou um
orçamento. Infelizmente, estima-se que mais de três
quartos das empresas norte-americanas encontram-se
neste nível, e não há razões para acreditar que a
situação seja melhor no Brasil.

23. Nível 2 - Repetível
Os processos básicos de gestão de
projeto são estabelecidos para
acompanhar custo, cronograma e
funcionalidade. A necessária disciplina
do processo existe para repetir sucessos
anteriores em projetos com aplicações
similares.

24. Nível 2 - Repetível
 No Nível Repetível, as políticas de gestão de projeto de
software e os procedimentos para implementá-las são
estáveis. O planejamento e a gestão de novos projetos
são baseados na experiência adquirida em projetos
similares. Um dos objetivos alcançados no nível 2 é a
institucionalização dos processos para os projetos de
software, possibilitando que as organizações repitam as
práticas bem sucedidas desenvolvidas em projetos
anteriores, apesar dos processos específicos
implementados pelos projetos serem diferentes. Um
processo efetivo pode ser caracterizado como hábil,
documentado, robusto, treinado, medido e com
capacidade de poder ser melhorado.

25. Nível 2 - Repetível
 Os projetos nas organizações de nível 2
possuem controles básicos de gestão de
software. Os compromissos realistas do
projeto são baseados em resultados
observados em projetos anteriores e nos
requisitos do projeto atual. Os gerentes de
software do projeto acompanham custos,
cronogramas e funcionalidades do software;
os problemas com compromissos são
identificados quando surgem.

26. Nível 2 - Repetível
 Os requisitos e os produtos de trabalho de
software desenvolvidos para satisfazê-los
são armazenados de forma criteriosa e a
integridade dos mesmos é controlada. Os
padrões do projeto de software são definidos
e a organização garante que eles sejam
seguidos fielmente. Existindo subcontratados,
o projeto de software trabalha em conjunto
com os mesmos, visando fortalecer a relação
cliente-fornecedor.

27. Nível 2 - Repetível
 A capabilidade de processo de software das
organizações de nível 2 pode ser resumida
como sendo disciplinada, uma vez que o
planejamento e o acompanhamento de
projeto de software são estáveis e os
sucessos mais recentes podem ser
repetidos. Os processos estão sob um
controle efetivo de um sistema de gestão de
projeto, seguindo planos realistas baseados
no desempenho de projetos anteriores.

28. Áreas-chave do nível 2
As áreas-chave de processo do Nível 2 são
focadas em assuntos de projeto de software
relacionados com o estabelecimento de
controles básicos de gerência de projeto. As
descrições de cada área-chave do Nível 2
são apresentadas a seguir:

29. Áreas-chave do nível 2
 Gerenciamento dos Requisitos
 Planejamento do Projeto de
Software
 Gerenciamento do Projeto de
Software
 Gerência do Subcontrato de
Software
 Garantia da Qualidade de Software
 Gerência de Configuração de
Software

30. Gerenciamento dos Requisitos
O propósito do Gerenciamento de
Requisitos é estabelecer um entendimento
comum entre o cliente e o projeto de software
sobre os requisitos do cliente que serão
tratados pelo projeto. Este acordo com o
cliente é a base para o planejamento e para
a gerência do projeto de software. A
coordenação do relacionamento com o
cliente depende da observância de um
efetivo processo de controle de alteração.

31. Planejamento do Projeto de Software
O propósito do Planejamento de Projeto de
Software é estabelecer planos razoáveis
para a execução das atividades de gerência
e desenvolvimento de projeto de software.
Estes planos constituem a base necessária
para se gerenciar o projeto. Sem planos
realistas, uma gestão efetiva de projeto não
pode ser implementada.

32. Gerenciamento do Projeto de Software
 O propósito do Acompanhamento e
Supervisão de Projeto de Software é
estabelecer a adequada visibilidade do
progresso real, de tal maneira que a gerência
possa tomar ações efetivas quando o
desempenho do projeto sofre um desvio
significativo com relação ao planejado.

33. Gerência do Subcontrato de Software
O propósito da Gestão de Subcontratação de
Software é selecionar subcontratados qualificados e
gerenciá-los de modo efetivo. Esta área-chave
combina os assuntos relativos à Gestão de
requisitos, Planejamento de Projeto de Software e
Acompanhamento e Supervisão de Projeto de
Software, para obter um controle básico de gestão,
juntamente com a necessária coordenação da
Garantia de Qualidade de Software e da Gestão de
Configuração de Software, que são aplicadas
apropriadamente aos subcontratados.

34. Garantia da Qualidade de Software
O propósito da Garantia de Qualidade de
Software é fornecer uma gestão com
visibilidade apropriada sobre os processos
utilizados e produtos desenvolvidos pelo
projeto de software. A Garantia de Qualidade
de Software é parte integrante da maioria dos
processos de gerência e de desenvolvimento
de software.

35. Gerência de Configuração de Software
O propósito da Gestão de Configuração de
Software é estabelecer e manter a
integridade dos produtos do projeto ao longo
de todo o ciclo de vida. A Gestão de
Configuração de Software é parte integrante
da maioria dos processos de gerência e de
desenvolvimento de software.

36. Avaliações CMM no Brasil
 No último relatório do SEI/CMU, publicado
em setembro de 2005 com dados até junho
do mesmo ano, o Brasil encontra-se em 14º
lugar dentre os países com maior número de
avaliações CMM realizadas por esse instituto
(após ter permanecido na 13ª posição desde
dezembro de 2001), sendo o único país da
América Sul que aparece com mais de 20
avaliações (29).

37. Empresas Qualificadas no Brasil

40. Fonte: http://www.mct.gov.br

41. Qualificações CMMI no Brasil

42. Qualificações CMMI no Brasil

43. Depoimento de uma empresa
com CMM Nível 2
(BSI Tecnologia)

44. Bsi Tecnologia
 As mudanças que a empresa passou para
receber a certificação, tanto na área física,
tecnológica e pessoal.
 [Marcelo Chamorro] Os colaboradores tiveram
que tornar público seus conhecimentos e
práticas, institucionalizando as mesmas para
todos. E isso trouxe os benefícios de uma
empresa de comportamento mais uniforme e
interativo com as necessidades do mercado.

45. Alguns dos benefícios que tiveram:
 Processos definidos e documentados
 Definição e uso de padrões
 Gestão de requisitos
 Planejamento de Atividades
 Acompanhamento periódico
 Maior visibilidade dos projetos
 Gerência da Configuração
 Ênfase na Garantia da Qualidade - Processo e Produto
 Redução do nível de resistência a mudanças e melhoria do
clima organizacional

46. As reais vantagens de ser certificado
· [Marcelo Chamorro] O processo de
regularização das atividades, a própria
maturidade das pessoas e dos processos já
são ganhos efetivos da empresa, fora isso, a
empresa se qualifica para empreitadas
maiores frente a empresas governamentais
do tipo Petrobrás, etc.

47. O tempo que demora o processo para a
certificação
· [Marcelo Chamorro] Depende do seu nível
inicial. Um bom approach é realizar um
diagnóstico inicial por auditores
credenciados. Nossa sensibilidade para este
assunto, pois ainda estamos em evolução é a
seguinte:
 Nível 2: 18 meses
 Nível 3: 12 meses
 Nível 4 e 5: 10 meses

48. O custo para o processo em geral
(aproximadamente)
 [Marcelo Chamorro] Podemos dizer com
mais certeza para a atividade de fábrica de
programas, para projetos custa mais devido
aos ferramentais de testes:
 Nível 3 - CMMI: US$ 500,000.00 sendo
que a parte do certificador fica por volta de
US$ 30,000.00. Isto incluindo tudo,
inclusive despesas de transportes,
licenças, literaturas, curso team member e
SCE.

49. Como funciona o processo? O que é
avaliado? De que forma? Quem avalia?
[Marcelo Chamorro] O processo é composto por alguns
passos importantes:
 1º Diagnóstico inicial - Avaliação classe C
 2º Curso básico de CMMI - Formação de team
members
 3º Definição e implantação das PA - Process áreas
 4º Avaliação da eficácia da implantação
 5º Avaliação Classe B - Passa / Não passa. O
certificador verifica se a empresa pode ir para a
avaliação final

50. Como funciona o processo? O que é
avaliado? De que forma? Quem avalia?
 6º Ajustes / maturação dos processos e coleta de
evidências
 7º Curso SCE (Antes era SCAMPI - CMM) para
todos team members
 8º Avaliação oficial
 9º Registro oficial no site do SEI
 Nota importante: A maturidade da empresa
é verificada desde o primeiro contato
agendamento e cumprimento de datas,
material utilizado, etc.)

51. Fontes:
 http://www.bsitecnologia.com.br
 http://pt.wikipedia.org/wiki/CMM
 http://www.gnosisbr.com.br
 http://www.inatel.br
 http://www.pernambuco.com
 http://www.mct.gov.br
 http://www.spress.com.br
 http://www.sei.cmu.edu
 http://www.cpqd.com.br