Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Qualidade de Software | SW-CMM, CMMI e MPS.BR

Qualidade de Software | SW-CMM, CMMI e MPS.BR

Slides utilizados em aula na disciplina Qualidade de Software do Instituto de Ciências Exatas e Informática - Sistemas de Informação. Pontifícia Universidade Católica de Minas Gerais - Unidade Barreiro, 1º Semestre 2015.

Eduardo Miranda

April 15, 2015
Tweet

More Decks by Eduardo Miranda

Other Decks in Education

Transcript

  1. Qualidade de Software Pontifícia Universidade Católica de Minas Gerais Unidade

    Barreiro — 1º Semestre 2015 Prof. Eduardo Miranda [email protected] SW-CMM, CMMI e MPS.BR
  2. o que são processos? O SW-CMM (Capability Maturity Model for

    Software) é um modelo de desenvolvimento criado após um estudo feito a partir dos dados coletados das organizações que fizeram contratados com o Departamento de Defesa dos EUA. O termo "maturidade" (maturity) refere-se ao grau de formalidade e otimização de processos, a partir de práticas ad hoc, a passos formalmente definidos, a métricas de resultados gerenciados, para otimização de ativos dos processos.
  3. • Poucos processos são definidos e o sucesso depende muitas

    vezes de heroísmos individuais. nível 1 : inicial
  4. • Poucos processos são definidos e o sucesso depende muitas

    vezes de heroísmos individuais. nível 1 : inicial
  5. • Poucos processos são definidos e o sucesso depende muitas

    vezes de heroísmos individuais; • Organizações neste nível são até bem-sucedidas, mas isso em geral se restringe ao desenvolvimento de produtos que já estiveram envolvidos anteriormente; • Enfrentam dificuldades ao realizarem precisões e quando estas são feitas, geralmente contêm erros; • Os cronogramas e planos são irrealistas e acabam sendo alterados inúmeras vezes durante o desenvolvimento do software; nível 1 : inicial
  6. • Os imprevistos são comuns e, para serem resolvidos, dependem

    geralmente da capacidade individual; • A falta de credibilidade do planejamento leva a um desenvolvimento confuso de software. nível 1 : inicial
  7. nível 2 : repetitivo • As organizações têm maior probabilidade

    de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente; • Há preocupação com a gerência de projeto. Os gerentes conseguem, então, identificar problemas antes que estes apareçam ou se tornem críticos; • Uma organização no nível 2 é disciplinada ao executar projetos, mas não está bem preparada para mudanças; • É incapaz de prever o resultado da adoção de novas ferramentas e métodos, ou desenvolvimento de novos produtos;
  8. 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 adaptação a mudanças; • As ferramentas passam a ser aplicadas de forma sistemática, padronizada e coerente; • 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;
  9. nível 3 : definido • Como o processo é bem

    definido, caso um desenvolvedor abandone o projeto antes do seu término, o impacto é relativamente menor que os níveis anteriores. • Os gerentes têm maior conhecimento do progresso dos projetos, pois as atividades são planejadas, estáveis e repetitivas. • Há melhoria da qualidade do software, uma vez que os custos, escalonamentos de tarefas, prazos e funcionalidades estão sob controle.
  10. nível 4 : gerenciado • A produtividade e a qualidade

    são medidas em todos os projetos como parte de um programa organizacional; • São definidas 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ção são cuidadosamente gerenciados; • Os produtos tendem a apresentar maior qualidade.
  11. nível 5 : otimizado • Neste nível os processos estão

    em melhoria contínua. • Os gerentes identificam pontos fracos de cada processo e agem de forma pró- ativa para que estes sejam melhorados; • 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. Suas causas são estudadas para não serem repetidas.
  12. Caso de estudo : Systematic Uma análise dos efeitos em

    introduzir práticas ágeis em uma empresa CMMI nível 5
  13. A Systematic é uma empresa de sistemas de software independente

    que foi fundada em 1985 e emprega mais de 400 pessoas em todo o mundo com escritórios na Dinamarca, EUA e no Reino Unido. A Systematic desenvolve soluções para 5 áreas principais: (i) setor público, (ii) saúde, (iii) defesa, (iv) inteligência e (v) segurança nacional. caso de estudo : Systematic A Systematic é compatível com o nível 5 do CMMI. Neste nível a Systematic conseguiu reduzir em 42% o retrabalho, o desvio da precisão de estimativa é abaixo de 10% e garantia de 92% de que todos resultados são entregues antes ou na data.
  14. caso de estudo : Systematic Em resumo, a Systematic, antes

    da introdução do Scrum, já era capaz de entregar o que o cliente encomendou dentro do cronograma, custo e qualidade usando 69% do esforço em comparação a empresas no nível 1 do CMMI 1. Os clientes reconhecem que o nível 5 do CMMI dá alta previsibilidade e produtos melhores projetados para escalabilidade, manutenibilidade, adaptabilidade e confiabilidade.
  15. Métodos ágeis e CMMI O sucesso do desenvolvimento de software

    é desafiado pela capacidade do fornecedor em gerenciar a complexidade, inovação tecnológica e as mudanças de requisitos. Os métodos ágeis e o CMMI ambos enfrentam esses desafios, mas possuem uma grande diferença na abordagem e na perspectiva da aplicação dos métodos. Gestão de complexidade requer disciplina no processo. Enquanto a gestão da mudança requer adaptabilidade. O CMMI fornece disciplina aos processos e o Scrum aumenta adaptabilidade.
  16. Métodos ágeis e CMMI O CMMI fornece insights sobre quais

    processos são necessário para manter uma organização disciplinadamente madura, capaz de prever e melhorar o desempenho da organização e dos projetos. O Scrum fornece orientação para a gestão eficaz dos projetos de uma forma que permite alta flexibilidade e adaptabilidade.
  17. Individualmente o SCRUM e o CMMI apresentam benefícios como também

    armadilhas. Uma empresa pode implementar o SCRUM corretamente mas falhar devido a falta de institucionalização, inconsistência ou execução insuficiente dos processo de gestão. O CMMI define institucionalização como: "uma forma enraizada de fazer negócios que uma organização segue rotineiramente como parte de sua cultura corporativa." Métodos ágeis e CMMI
  18. O CMMI pode auxiliar empresas executando métodos ágeis a institucionalizar

    estes métodos de uma forma mais consistente e permitindo entender quais processos devem ser trabalhados. Uma empresa pode estar conforme o CMMI, mas não conseguir alcançar performance ótima desvio a uma implementação inadequação dos processos. O SCRUM e os métodos ágeis podem auxiliar estas empresas no sentido de uma implementação mais eficiente dos requisitos dos processos CMMI. Métodos ágeis e CMMI
  19. A Systematic estabeleceu e mantém um baseline de desempenho da

    produtividade (Productivity Performance Baseline – PPB). Na Systematic, a produtividade de um projeto é definido como o número total de linhas de código produzida, dividido pelo esforço total do projeto gasto em horas. Os dados são atribuído com informações relacionadas a linguagem programação, tipo de código: novo, reuso ou teste. Os dados mostram que a produtividade é alta em projetos pequenos e diminui com o aumento do tamanho do projeto. A baseline de desempenho da produtividade da Systematic é dividido em 2 grupos: 1. Projetos pequenos – Menos de 4000 horas; 2. Projetos grandes – Mais de 4000 horas. baseline de desempenho da produtividade
  20. A produtividade de pequenos projetos é 181% da produtividade dos

    grandes projetos. Ao comparar os projetos utilizando Scrum com a baseline de desempenho da produtividade é notado que o ganho de produtividade altera-se muitíssimo pouco quando compara-se projetos pequenos. No entanto, a produtividade dos grandes projetos mostra um aumento de 201% na produtividade. Nem todo este ganho pode ser atribuído apenas ao Scrum, devido a outras melhorias implementas. Apesar disso, os envolvidos concordam que o Scrum foi uma parte significava desta melhora. baseline de desempenho da produtividade
  21. Em um grande projeto com 10 pessoas na equipe, trabalhou

    em um sistema de mensagens militar. Neste projeto eles buscaram investigar como fazer o testar inicial e para isso eles aprimoraram a abordagem baseada em história. A abordagem incluiu também novos aspectos como: incrementos curtos, inspeções e foco nas funcionalidades. A idéia de desenvolvimento baseado em história era subdividir funcionalidades, tipicamente estimada em centenas de horas de trabalho em pequenas histórias de 20-40 horas de trabalho. A implementação de uma história seguiU um novo processo, em que a primeira atividade era decidir como a história poderia ser testado antes de qualquer código ser escrito. experimentos
  22. Muitos benefícios do desenvolvimento baseado em história foram imediatamente aparente.

    A combinação de uma boa definição de quando uma história é concluída com o início cedo do teste incremental das funcionalidades propiciaram uma visão precisa do progresso do status do projeto para ambos: a equipe e os stakeholders. Este projeto terminou antes do prazo e reduziu o número de defeitos de código encontrado nos testes finais em 38% comparando com os processos anteriores. experimentos
  23. Em outro projeto com 19 membros na equipe, desenvolveu um

    módulo para um sistema de prontuário eletrônico de pacientes. Neste projeto eles também trabalharam com testes no início. Eles asseguraram que as atividades de teste foram integradas ao desenvolvimento, com um forte foco em "tenha a visão do todo" e compreensão de como a solução se encaixa no domínio do cliente. Como consequência, a quantidade de defeitos restantes no código no teste final foram reduzidos em 42% em comparação com processos anteriores. experimentos
  24. Com base nesses dois projetos, concluíram que atividades de teste

    deve ser uma atividade integrada durante todo o tempo de vida dos projetos, e Scrum inerentemente permite isso através de equipes multifuncionais e entregas frequentes para o cliente. Além disso, concluiu-se que o desenvolvimento de software baseado em história deve ser o método padrão recomendado para desenvolvimento de software em projetos. conclusões
  25. Usando CMMI e Scrum em conjunto resultou em melhorou significativa

    no desempenho, mantendo o cumprimento ao CMMI. Os projetos piloto com Scrum mostrou ganhos significativos de produtividade e qualidade comparando aos métodos tradicionais. Estes resultados levaram a decisão de considerar introduzir o Scrum e outras práticas ágeis em uma forma mais ampla na Systematic. O Scrum agora reduz a cada categoria de trabalho (defeitos, retrabalho, o total trabalho necessário, e sobrecarga de processo) em quase 50%. conclusões
  26. O MPS.BR é um programa mobilizador que foi criado em

    2003 pela Softex para melhorar a capacidade de desenvolvimento de software visando preferencialmente às micro, pequenas e médias empresas (mPME). O modelo MPS estabelece dois modelos de referência de processos de software e serviços, e um processo/método de avaliação de processos. Esta estrutura fornece sustentação e garante que o modelo MPS seja empregado de forma coerente com as suas definições. MPS
  27. A iniciativa foi responsável pelo desenvolvimento do Modelo de Referência

    para Melhoria do Processo de Software Brasileiro (MPS-SW), que levou em consideração normas e modelos internacionalmente reconhecidos, boas práticas da engenharia de software e as necessidades de negócio da indústria de software nacional. O modelo MPS está dividido em quatro (4) componentes: • Modelo de Referência MPS para Software (MR-MPS-SW); • Modelo de Referência MPS para Serviços (MR-MPS-SV); • Método de Avaliação (MA-MPS) e • Modelo de Negócio (MNMPS). MPS
  28. Atributos do Processo Descrição AP 1.1 O processo é executado

    Este atributo evidencia o quanto o processo atinge o seu propósito. AP 2.1 O processo é gerenciado Este atributo evidencia o quanto a execução do processo é gerenciada. AP 2.2 Os produtos de trabalho do processo são gerenciados Este atributo evidencia o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente. AP 3.1 O processo é definido Este atributo evidencia o quanto um processo padrão é mantido para apoiar a implementação do processo definido. AP 3.2 O processo está implementado Este atributo evidencia o quanto o processo padrão é efetivamente implementado como um processo definido para atingir seus resultados. processos no MR-MPS-SW
  29. Atributos do Processo Descrição AP 4.1 O processo é medido

    Este atributo evidencia o quanto os resultados de medição são usados para assegurar que a execução do processo atinge os seus objetivos de desempenho e apoia o alcance dos objetivos de negócio definidos. AP 4.2 O processo é controlado Este atributo evidencia o quanto o processo é controlado estatisticamente para produzir um processo estável, capaz e previsível dentro de limites estabelecidos. AP 5.1 O processo é objeto de melhorias incrementais e inovações Este atributo evidencia o quanto as mudanças no processo são identificadas a partir da análise de defeitos, problemas, causas comuns de variação do desempenho e da investigação de enfoques inovadores para a definição e implementação do processo. AP 5.2 O processo é otimizado continuamente Este atributo evidencia o quanto as mudanças na definição, gerência e desempenho do processo têm impacto efetivo para o alcance dos objetivos relevantes de melhoria do processo. processos no MR-MPS-SW
  30. Níveis de maturidade do MR-MPS- SW Nível Processos Atributos do

    Processo A AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1, AP 4.2, AP 5.1 e AP 5.2 B Gerência de Projetos – GPR (evolução) AP 1.1, AP 2.1, AP 2.2, AP 3.1, AP 3.2, AP 4.1 e AP 4.2 C Gerência de Riscos – GRI Desenvolvimento para Reutilização – DRU Gerência de Decisões – GDE AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 D Verificação – VER Validação – VAL Projeto e Construção do Produto – PCP Integração do Produto – ITP Desenvolvimento de Requisitos – DRE AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2
  31. Níveis de maturidade do MR-MPS- SW Nível Processos Atributos do

    Processo E Gerência de Projetos – GPR (evolução) Gerência de Reutilização – GRU Gerência de Recursos Humanos – GRH Definição do Processo Organizacional – DFP Avaliação e Melhoria do Processo Organizacional – AMP AP 1.1, AP 2.1, AP 2.2, AP 3.1 e AP 3.2 F Medição – MED Garantia da Qualidade – GQA Gerência de Portfólio de Projetos – GPP Gerência de Configuração – GCO Aquisição – AQU AP 1.1, AP 2.1 e AP 2.2 G Gerência de Requisitos – GRE Gerência de Projetos – GPR AP 1.1 e AP 2.1
  32. • Avaliações realizadas: 596 Software e 7 Serviços = TOTAL

    603 • Instituições Implementadoras (II): 19 • Instituições Organizadoras de Grupos de Empresas (IOGES): São 17 instituições e 72 projetos. • Instituições Avaliadoras: 13 • Cursos realizados: 277 • Provas realizadas: 60 • Participantes de cursos oficiais MPS presenciais: 5974 • Participantes de cursos oficiais MPS EAD: 117 • Aprovados em provas oficiais MPS: 1416 Dados com base em outubro de 2014 Fonte: : http://www.softex.br/mpsbr/mps/mps-br-em-numeros/ MPS.BR em números
  33. Nível F O nı́vel de maturidade F é composto pelos

    processos do nı́vel de maturidade anterior (G) acrescidos dos processos • Aquisic ̧ ão, • Garantia da Qualidade, • Gere ̂ ncia de Configurac ̧ ão, • Gere ̂ ncia de Portfólio de Projetos e • Medic ̧ ão.
  34. Estudo do artigo disponível no site da disciplina, seção leitura

    complementar, e no SGA. Próxima aula IMPLEMENTAÇÃO DO NÍVEL F DO MR-MPS COM PRÁTICAS ÁGEIS DO SCRUM EM UMA FÁBRICA DE SOFTWARE. Catunda, Edmar, et al. X Simpósio Brasileiro de Qualidade de Software (SBQS’11), Curitiba–Brasil (2011)
  35. Nível F Neste nível a implementação dos processos deve satisfazer

    os atributos de processo: • AP 1.1 – O processo é executado ◦ Este atributo evidencia o quanto o processo atinge o seu propósito. • AP 2.1 – O processo é gerenciado ◦ Este atributo evidencia o quanto a execução do processo é gerenciada. • AP 2.2 – Os produtos de trabalho do processo são gerenciados ◦ Este atributo evidencia o quanto os produtos de trabalho produzidos pelo processo são gerenciados apropriadamente.
  36. Sutherland, Jeff, Carsten Ruseng Jakobsen, and Kent Johnson. "Scrum and

    cmmi level 5: The magic potion for code warriors." Hawaii International Conference on System Sciences, Proceedings of the 41st Annual. IEEE, 2008. http://www.goodagile.com/resources/SCRUM_AND_CMMI_LEVEL_5-1.pdf BR, MPS. "MPS. BR–Melhoria de Processo do Software Brasileiro – Guia Geral MPS de Software" (Agosto de 2012) http://www.softex.br/wp-content/uploads/2013/07/MPS.BR_Guia_Geral_Software_2012-c-ISBN-1.pdf Koscianski, André, and Michel dos Santos Soares. Qualidade de software (2 Edição). Novatec (2007). Capítulos 5: CMM e CMMI. p. 95- 115. Koscianski, André, and Michel dos Santos Soares. Qualidade de software (2 Edição). Novatec (2007). Capítulos 7: MPS.BR: Melhoria de Processo do software Brasileiro. p. 142-155. referências