UNIDAVI - UNIVERSIDADE PARA O 
DESENVOLVIMENTO DO ALTO VALE 
DO ITAJAÍ 
FACITEC – FACULDADE DE CIÊNCIA E TECNOLOGIA 
BSI –...
Normas e Modelos de Qualidade de SW 
 ISO 9126 - Norma para qualidade de produtos de software 
 ISO 14598 - Guias para a...
O que é CMM? 
O CMM - Capability Maturity Model 
(Modelo de Maturidade da Capabilidade) 
é um modelo para avaliação da mat...
O que é CMM? 
O modelo foi proposto por Watts S. 
Humphrey, a partir das propostas de Philip B. 
Crosby, e vem sendo aperf...
OS CRIADORES 
Watts_S._Humphrey 
Philip B. Crosby
Modelos CMM
Modelos CMM 
 Software Acquisition CMM (SA-CMM) : usado para 
avaliar a maturidade de uma organização em seus 
processos ...
Modelos CMM 
 Integrated Product Development CMM (IPD-CMM) : 
ainda mais abrangente que o SE-CMM, inclui 
também outros p...
CMMI 
 O CMMI - Capability Maturity Model 
Integration foi criado pelo SEI como uma 
integração e evolução dos modelos: S...
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 
empres...
História do CMM 
 O líder do projeto que veio a resultar no CMM 
foi Watts Humphrey, anteriormente 
responsável por todo ...
Evolução 
 Nov/1986 - início do desenvolvimento do Framework 
 Set/1987 - lançada uma descrição geral do modelo 
 1988 ...
Onde é usado o CMM 
 Embora, historicamente, o CMM tenha 
surgido no contexto de grandes empresas de 
desenvolvimento de ...
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 T...
Onde é usado o CMM 
 Pequenas software-houses (10 a 20 
desenvolvedores) 
 Grandes Bancos e Seguradoras 
 Empresas de T...
Os Cinco Níveis de Maturidade 
 Nível de maturidade é um estágio evolutivo bem definido 
em busca de um processo de softw...
Os Cinco Níveis de Maturidade 
O CMM está dividido em cinco níveis de 
maturidade, os quais são: Inicial, 
Repetível, Def...
Nível 1- Inicial 
 Inexistência de um ambiente estável 
para desenvolvimento e manutenção de 
software. 
Ocasionalmente,...
Nível 1- Inicial 
Neste nível, não existem procedimentos padronizados, 
estimativas de custos e planos de projeto. Cada qu...
Nível 2 - Repetível 
Os processos básicos de gestão de 
projeto são estabelecidos para 
acompanhar custo, cronograma e 
fu...
Nível 2 - Repetível 
 No Nível Repetível, as políticas de gestão de projeto de 
software e os procedimentos para implemen...
Nível 2 - Repetível 
 Os projetos nas organizações de nível 2 
possuem controles básicos de gestão de 
software. Os compr...
Nível 2 - Repetível 
 Os requisitos e os produtos de trabalho de 
software desenvolvidos para satisfazê-los 
são armazena...
Nível 2 - Repetível 
 A capabilidade de processo de software das 
organizações de nível 2 pode ser resumida 
como sendo d...
Áreas-chave do nível 2 
As áreas-chave de processo do Nível 2 são 
focadas em assuntos de projeto de software 
relacionado...
Áreas-chave do nível 2 
 Gerenciamento dos Requisitos 
 Planejamento do Projeto de 
Software 
 Gerenciamento do Projeto...
Gerenciamento dos Requisitos 
O propósito do Gerenciamento de 
Requisitos é estabelecer um entendimento 
comum entre o cli...
Planejamento do Projeto de Software 
O propósito do Planejamento de Projeto de 
Software é estabelecer planos razoáveis 
p...
Gerenciamento do Projeto de Software 
 O propósito do Acompanhamento e 
Supervisão de Projeto de Software é 
estabelecer ...
Gerência do Subcontrato de Software 
O propósito da Gestão de Subcontratação de 
Software é selecionar subcontratados qual...
Garantia da Qualidade de Software 
O propósito da Garantia de Qualidade de 
Software é fornecer uma gestão com 
visibilida...
Gerência de Configuração de Software 
O propósito da Gestão de Configuração de 
Software é estabelecer e manter a 
integri...
Avaliações CMM no Brasil 
 No último relatório do SEI/CMU, publicado 
em setembro de 2005 com dados até junho 
do mesmo a...
Empresas Qualificadas no Brasil
Fonte: http://www.mct.gov.br
Qualificações CMMI no Brasil
Qualificações CMMI no Brasil
Depoimento de uma empresa 
com CMM Nível 2 
(BSI Tecnologia)
Bsi Tecnologia 
 As mudanças que a empresa passou para 
receber a certificação, tanto na área física, 
tecnológica e pess...
Alguns dos benefícios que tiveram: 
 Processos definidos e documentados 
 Definição e uso de padrões 
 Gestão de requis...
As reais vantagens de ser certificado 
· [Marcelo Chamorro] O processo de 
regularização das atividades, a própria 
maturi...
O tempo que demora o processo para a 
certificação 
· [Marcelo Chamorro] Depende do seu nível 
inicial. Um bom approach é ...
O custo para o processo em geral 
(aproximadamente) 
 [Marcelo Chamorro] Podemos dizer com 
mais certeza para a atividade...
Como funciona o processo? O que é 
avaliado? De que forma? Quem avalia? 
[Marcelo Chamorro] O processo é composto por algu...
Como funciona o processo? O que é 
avaliado? De que forma? Quem avalia? 
 6º Ajustes / maturação dos processos e coleta d...
Fontes: 
 http://www.bsitecnologia.com.br 
 http://pt.wikipedia.org/wiki/CMM 
 http://www.gnosisbr.com.br 
 http://www...
Trabalho CMM
Trabalho CMM
Trabalho CMM
Trabalho CMM
Trabalho CMM
Próximos SlideShares
Carregando em…5
×

Trabalho CMM

379 visualizações

Publicada em

Slides referentes ao trabalho proposto sobre CMM, apresentado para a disciplina ENGENHARIA DE SOFTWARES, focando o nível 2 do mesmo. Trabalho realizado em conjunto com a parceria de Rodrigo Schlickmann.

Publicada em: Tecnologia
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
379
No SlideShare
0
A partir de incorporações
0
Número de incorporações
4
Ações
Compartilhamentos
0
Downloads
8
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Trabalho CMM

  1. 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
  2. 2. 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.
  3. 3. 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.
  4. 4. 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
  5. 5. OS CRIADORES Watts_S._Humphrey Philip B. Crosby
  6. 6. Modelos CMM
  7. 7. 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.
  8. 8. 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.
  9. 9. 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).
  10. 10. 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.
  11. 11. 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.
  12. 12. 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 .
  13. 13. 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.
  14. 14. 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:
  15. 15. 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)
  16. 16. 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.
  17. 17. 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.
  18. 18. 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
  19. 19. 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.
  20. 20. 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.
  21. 21. 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.
  22. 22. 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.
  23. 23. 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.
  24. 24. 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.
  25. 25. Á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:
  26. 26. Á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
  27. 27. 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.
  28. 28. 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.
  29. 29. 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.
  30. 30. 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.
  31. 31. 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.
  32. 32. 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.
  33. 33. 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).
  34. 34. Empresas Qualificadas no Brasil
  35. 35. Fonte: http://www.mct.gov.br
  36. 36. Qualificações CMMI no Brasil
  37. 37. Qualificações CMMI no Brasil
  38. 38. Depoimento de uma empresa com CMM Nível 2 (BSI Tecnologia)
  39. 39. 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.
  40. 40. 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
  41. 41. 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.
  42. 42. 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
  43. 43. 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.
  44. 44. 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
  45. 45. 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.)
  46. 46. 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

×