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.
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.
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
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;
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;
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.
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.
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.
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.
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.
é 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.
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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)
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.
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
emiranda
matleenalaakso
signer
cbtlibrary
yasulab
guvalif
pnuslide
bernhardsvt
masakamayama
hachama
obzr
brad_frost
swwweet
tammyeverts
eileencodes
phodgson
bkeepers
skipperchong
eitanlees
morganepeng
shpigford
