Qualidade de Software

  • 2,911 views
Uploaded on

Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de …

Seminário sobre Qualidade de Software e modelos de maturidade apresentado no primeiro semestre de 2012 na disciplina de Engenharia de Software no programa de pós-graduação do Departamento de Computação da Universidade Federal de São Carlos.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,911
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
145
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Qualidade de Software: Produto e Processo Conceitos, ISO, CMMI e MPS.Br Reinaldo de Oliveira Castro Tiago Antônio da Silva Victor Gomes da Silva
  • 2. Roteiro● Conceitos● Histórico ○ Crise do software● Qualidade de software ○ Produto e processo● ISO● CMMI● MPS.Br● Referências
  • 3. Questão sobre qualidadePor que qualidade de software? 1. Aumento da complexidade 2. Atender as especificações do cliente 3. Concorrência 4. Confiabilidade dos resultados
  • 4. Conceitos de qualidade Conformidade com requisitos funcionais e dedesempenho explicitamente declarados,normas de desenvolvimento explicitamentedocumentadas e características implícitas, quesão esperadas em todo software desenvolvidoprofissionalmente. (PRESSMAN, p. 580, 2006)
  • 5. Conceitos de qualidade É um conceito complexo que não édiretamente comparável com a qualidade namanufatura. (SOMMERVILLE, p.423, 2007) Na manufatura, a noção de qualidade temsido aquela em que o produto desenvolvidodeve atender às suas especificações. (CROSBY, 1979)
  • 6. Histórico● Crise do software● Engenharia de software era raridade● Dificuldades no desenvolvimento● Alta demanda● Prazos e orçamentos sempre estouravam● Baixa qualidade● Não atingiam requisitos Por quê?
  • 7. Histórico
  • 8. Qualidade de produto● Baixo número de defeitos● Atinge padrões necessários? Ex: manutenção, confiabilidade, etc...● Diretamente proporcional a qualidade do processo de desenvolvimento Ex: linha de produção
  • 9. Qualidade de Produto● ISO/IEC 9126: norma para qualidade de produto de software.● O modelo propõe a analise de um produto de software por meio de atributos de qualidade.
  • 10. Qualidade de produto● ISO/IEC 9126: divisão das características e sub-características
  • 11. Qualidade de produto● Funcionalidade ○ As funcionalidades desejadas pelo usuário, explícitas ou implícitas, foram atendidas?● Confiabilidade ○ O produto se mantém confiável (sem perda de dados, recuperando-se de falhas, etc) em situações adversas?● Usabilidade ○ O software é intuitivo e fácil de usar pelo usuário?
  • 12. Qualidade de produto● Eficiência ○ O software se comporta como esperado em relação às restrições de tempo e recurso?● Manutenabilidade ○ O software é flexível para suportar as manutenções corretivas, evolutivas e perfectivas?● Portabilidade ○ O sistema pode ser facilmente transferido de um sistema para outro?
  • 13. Principais fatores de qualidade deproduto (SOMMERVILLE, 2007)
  • 14. Qualidade de processo
  • 15. Qualidade do produto baseada emprocesso (SOMMERVILLE, 2007)
  • 16. Qualidade de processoA qualidade do processo corresponde ao nívelutilizado na implementação de um processoaceitável e na produção dos artefatos. Esseprocesso inclui medições e critérios dequalidade.
  • 17. Características de processo ● Facilidade de compreensão ● Visibilidade ● Facilidade de apoio ● Aceitabilidade ● Robustez ● Facilidade de manutenção ● Rapidez (SOMMERVILLE, p. 440, 2007)
  • 18. Ciclo de aprimoramento do processo (SOMMERVILLE, 2007)
  • 19. ISOsISO - International Organization forStandardization9000 - Padrões de qualidade gerais paraqualquer tipo de organização9001 - Mais específica: processo de qualidadenas organizações que projetam, desenvolvem emantêm produtos
  • 20. ISO 9001Quatro seções principais: 1. Objetivos 2. Relações com outras normas 3. Definições 4. Requisitos do sistema de qualidade
  • 21. ISO 9001: requisitos do sistema dequalidade4.1: requisitos de natureza organizacional einstitucional4.2: requisitos da documentação do Sistemada Qualidade4.3 a 4.20: demais requisitos como especificação, projeto, documentos e dados, aquisição, rastreabilidade, processos, testes, produto não-conforme, ação corretiva, manuseio, registros, auditorias, treinamento, serviços, técnicas estatísticas
  • 22. ISO 9000-3Orientações para aplicação da ISO 9001 aoprojeto, desenvolvimento, fornecimento,instalação de manutenção de software.● Entendimento dos requisitos funcionais entre contratante e contratado● Uso de metodologias consistentes para o desenvolvimento de software● Gerenciamento de projeto desde a concepção até a manutenção.
  • 23. ISO 9000-3Definições sobre o planejamento da qualidadede software:● Definição do ciclo de vida utilizado● Definição dos critérios para início e fim de cada fase de projeto● Identificação dos tipos de análise crítica● Identificação dos procedimentos de gestão de configuração, validação, verificação e teste
  • 24. ISO 9000-3● Não tem melhoria continua de processo como o CMM.● Não diz como fazer, somente o quê tem que ser feito.● Qualidade do processo não do produto.
  • 25. Estado da Arte ISOSoftware Quality Engineering in the new ISO standard:ISO/IEC 24748 - Systems and software engineering - Guidefor life cycle management (2012)Problema: ISO não está de acordo com o que o mercado precisa.Objetivo: Investigar a ISO em questão do ciclo de vida e mostrar que não ésuficiente para ter um software de qualidade usando o processo que eladescreve.Solução: Adicionar conceitos de Engenharia de Software baseados na qualidadepara aprimorar e melhorar a norma. Baseadas nas normas da IEEE e ISO/IEC.Resultado: A Engenharia de software é quase totalmente ausente nesse novopadrão da ISO.
  • 26. Estado da Arte ISODo Software Process Improvements Lead to ISO 9126Architectural Quality Factor Improvement? (2010)Problema: Pesquisas não são voltadas para a melhoria da arquitetura e sim paramelhoria dos processos e definições de qualidade. Qualidade do processoCMMI tem uma ligação muito fraca com a ISO 9126.Objetivo: Fazer a revisão sistemática e orientar para um trabalho futuro,considerando a arquitetura como fator de qualidade.Solução: Criar um modelo que abrange tanto processo para melhoria dequalidade do produto quanto a arquitetura da ISO 9126.Resultado: A pesquisa mostrou que a arquitetura definida pela ISO influênciadiretamente na qualidade do produto e ajudaria no processo do CMMI.
  • 27. Estado da Arte ISOApplying ISO 9001:2000, MPS.BR and CMMI to AchieveSoftware Process Maturity: BL Informatica’s Pathway (2010)Problema: Como utilizar uma um desses processos para incorporar o modelo dematuridade em micro e pequenas empresas.Objetivo: Estudar os processos, compará-los e reduzir esses processos paraaplicar em pequenas empresas.Solução: Aplicar os processos modificados na empresa.Resultado: Os processos modificados resultaram em baixa qualidade doproduto desenvolvido negando a viabilidade de reduzir os processos dequalidade e reafirmando que a qualidade do produto esta ligada com aqualidade do processo.
  • 28. Estado da Arte ISOProcess Assessment Issues of the ISO/IEC 29110 emergingstandard (2011)Problema: Talvez o novo padrão de ciclo de vida de processo da ISO não sejaeficiente para pequenas empresas.Objetivo: Avaliar o processo da ISO /IEC 29110Solução: Criar um modelo exemplar de avaliação de processos (PAM) e avaliaro processo ISO baseado no PRM (Process Reference Model)Resultado: Criou o modelo exemplar, mas não sitou testes com a ISO/IEC29110
  • 29. FerramentasARM - Nasa - fornece medidas que podem serusadas para avaliar a qualidade de umdocumento de requisitos de software.QPR ProcessGuide and Scorecard, desenvolvidapor QPRSoftware, fornece apoio para SeisSigma e outras abordagens de gestão dequalidade
  • 30. FerramentasQuality Tools Cookbook, desenvolvida porSysma e Manley, fornece descricões úteis deferramentas de gestão clássica de qualidade talcomo diagramas de controle, espalhamento,afinidade e matriciais.Quality Tools and Templates, desenvolvida poriSixSigma, descreve uma ampla gama deferramentas e métodos úteis para gestão dequalidade.
  • 31. CMMI - Definição● CMMI: Capability Maturity Model Integration● Modelo de referência que contém as melhores práticas (genéricas ou específicas) necessárias ao desenvolvimento e manutenção de produtos e serviços, englobando todo o ciclo de vida (desde concepção até a entrega e manutenção).
  • 32. CMMI - Corpo de conhecimento● O corpo de conhecimento (body of knowledge) é dividido em disciplinas: ○ System Engineering (SE) ○ Software Engineering (SW) ○ Integrated Product and Process Development (IPPD) ○ Supplier Sourcing (SS)Uma disciplina é formada por áreas de processos.
  • 33. CMMI - Estrutura dos elementos
  • 34. CMMI - Estrutura dos elementosGerenciamento derequisitos
  • 35. CMMI - Estrutura dos elementos O objetivo do Gerenciamento de Requisitos (REQM) é gerenciar os requisitos dos produtos do projeto (e dos componentes do produto) e identificar inconsistências entre estes requisitos e os planos e produtos de trabalho do projeto.
  • 36. CMMI - Estrutura dos elementos
  • 37. CMMI - Estrutura dos elementos Referencie a área de processo Planejamento de Projeto para maiores informações sobre como planos de projeto são baseados nos requisitos e precisam ser revisados com as mudanças destes. (...)
  • 38. CMMI - Estrutura dos elementosSG1 - Gerenciar requisitos
  • 39. CMMI - Estrutura dos elementos SP 1.1 Obter e entender os requisitos. SP 1.2 Obter comprometimento em relação aos requisitos. SP 1.3 Gerenciar mudanças de requisitos. SP 1.4 Manter rastreabilidade bidirecional dos requisitos. SP 1.5 Indentificar inconsistências entre requisitos e planos/produtos de projeto.
  • 40. CMMI - Estrutura dos elementos ● Estabelecer critérios para avaliação e aceitação de requisitos. ● Analisar os requisitos para garantir que os critérios foram alcançados. ● Chegar em um entendimento sobre os requisitos com o provedor dos requisitos para garantir o comprometimento do restante dos participantes do projeto.
  • 41. CMMI - Estrutura dos elementos ● Lista de critérios para avaliação e aceitação de requisitos. ● Resultado da análise em relação aos critérios. ● Documento de aceitação dos requisitos por ambas as partes.
  • 42. CMMI - Estrutura dos elementos
  • 43. CMMI - Estrutura dos elementos
  • 44. CMMI - Estrutura dos elementos
  • 45. CMMI - Níves de maturidade
  • 46. CMMI - Representação Staged Legenda: todas as áreas de processo.
  • 47. CMMI - Representação Continuous Legenda: uma ou mais áreas de processo.
  • 48. CMMI - Estado da arteUso de Práticas Ágeis para Alcançar o CMMI 5: UmaAbordagem Inovadora (1/2)Problema enfrentado no artigo: dificuldade de integração entre osmétodos ágeis e os modelos de maturidade.Objetivo do artigo: descrever como essa integração foi possível na área deprocesso Inovação e Desenvolvimento Organizacional, utilizando o métodoDefine, Measure, Analyse, Design and Verify (DMADV) definido nametodologia Six Sigma.
  • 49. CMMI - Estado da arteUso de Práticas Ágeis para Alcançar o CMMI 5: UmaAbordagem Inovadora (2/2)Conclusões após a leitura:1a.) Título dá maior amplitude em relação ao que realmente foi abordado.2a.) Não fez o relacionamento direto de como as práticas selecionadas estavamatendendo os objetivos específicos da área de processo.
  • 50. CMMI - Estado da arteIs Process Compliance a Driver for Project Success? (1/5)Problema enfrentado no artigo: descobrir formalmente até que ponto ocumprimento de processos em uma organização influencia os resultados de umprojeto.Objetivo do artigo: tratar um projeto como um sistema, representando-o pormeio de um "modelo de função de transferência", listando as entradas/saídas ecorrelacionando estatisticamente as várias saídas com o cumprimento deprocessos como entrada.
  • 51. CMMI - Estado da arteIs Process Compliance a Driver for Project Success? (2/5)
  • 52. CMMI - Estado da arteIs Process Compliance a Driver for Project Success? (3/5)
  • 53. CMMI - Estado da arteIs Process Compliance a Driver for Project Success? (4/5)
  • 54. CMMI - Estado da arteIs Process Compliance a Driver for Project Success? (5/5)Conclusões após a leitura:1a.) Sim, influencia diretamente na qualidade das saídas e consequentementeno sucesso do projeto.2a.) Quanto maior o cumprimento do processo maior é a redução do "barulho"que é um fator de entrada inerente a todo projeto.
  • 55. CMMI - Estado da arteSoftware Maintenance Productivity and Maturity (1/3)Problema enfrentado no artigo: verificar se a aplicação de modelos dematuridade em organizações dedicadas a manutenção de software podemresultar em melhoria dos indicadores de manutenção corretiva e adaptativa.Objetivo do artigo: extrair dados durante um período de 4 anos de umaorganização dedicada à manutenção de software e, em paralelo, aplicar práticaspara melhoria de processo de software, confirmando se é útil a utilização demodelos de maturidade de software nessas organizações.
  • 56. CMMI - Estado da arteSoftware Maintenance Productivity and Maturity (2/3)
  • 57. CMMI - Estado da arteSoftware Maintenance Productivity and Maturity (3/3)Conclusões após a leitura:1a.) O gráfico deixa claro que é benéfica a implantação de modelos dematuridade de software em organizações dedicadas à manutenção de software.
  • 58. CMMI - Estado da arteScrum and CMMI - Going from Good to Great (1/1)Problema enfrentado no artigo: não se aplica.Objetivo do artigo: demonstrar como a utilização de Scrum juntamente comCMMI resultou em adaptabilidade e em predictabilidade e servir como um guiade como adotar essa combinação em outras organizações.Conclusões após a leitura:1a.) Novamente, não existe um formalismo na descrição do mapeamento entreas práticas do Scrumm e os objetivos específicos e genéricos da área de processoplanejamento de projeto.
  • 59. MPS.Br: Melhoria do Processo deSoftware Brasileiro● Criado pela Softex, universidades e apoiado pelo governo.● Mais acessível a empresas menores.● Modelo de Referencia "Inspirado" no CMMI (Normas ISO 12 207 e 15 504 -> Spice).● Movimento de qualidade: garantir sobrevivencia das empresas.● Implementação mais gradual (7 níveis).● Dividido em 3 partes.
  • 60. MPS.Br: Melhoria do Processo deSoftware Brasileiro
  • 61. MPS.Br: Melhoria do Processo deSoftware Brasileiro1) MR-MPS: Modelo de referencia composto por 7 níveis de maturidade ■ Cada subnível possui sua área de processo: ■ Processos fundamentais ● Exemplos: gerencia de requisitos e solução técnica. ■ Processos organizacionais ● Exemplos: gerencia de projeto e definição do processo Organizacional. ■ Processo de apoio ● Exemplos: Garantia de qualidade e treinamento.
  • 62. MPS.Br: Melhoria do Processo deSoftware Brasileiro
  • 63. MPS.Br: Melhoria do Processo deSoftware Brasileiro
  • 64. MPS.Br: Melhoria do Processo deSoftware Brasileiro2) MA-MPS: Modelo de avaliação● Como é feita => 1 Avaliador líder No mínimo 1 avaliador adjunto No mímimo 1 técnico da empresa● Estruturando a avaliação: ○ Planejar, preparar e orientar a avaliação. ○ Conformidade com as normas. ○ Relatar, registrar e publicar os resultados. ○ Duração: 2 à 4 dias. ○ Válida por 3 anos
  • 65. MPS.Br: Melhoria do Processo deSoftware Brasileiro3) MN-MPS: Modelo de Negócio● Permite que uma instituição torne-se certificadora MPS. Br de outras instituições. E para tal realiza-se o credenciamento em documento (apresentação) na Softex, por exemplo. ○ Apresentado-se o "know-how" necessário, a empresa passa a ser um agente certificador, quando apresentada as estratégias para: ■ Implementação do modelo. ■ Seleção e treinamento de consultores. ■ Seleção e treinamento de avaliadores. ○ E ainda havendo pessoal capacitado e aprovado nas provas específicas: ■ Consultores e avaliadores.
  • 66. MPS.Br: Estado da Arte (1/4)Dificuldades e Fatores de Sucesso naImplementação de Processos de SoftwareUtilizando o MR-MPS e o CMMIObjetivo: Identificar dificuldades fatores de sucesso na implementação doMR-MPS e CMMI.Problema: Falta de competência, comprometimento, liderança. Erro naestratégia de implementação.Solução: Motivação da equipe, grau de experiência e comprometimento.Resultado: O comprometimento dos colaboradores é um agente facilitador naimplantação dos modelos propostos.
  • 67. MPS.Br: Estado da Arte (2/4)Práticas do Modelo MPS em Fábricas de Software: um estudoexploratório sobre as percepções dos gerentes de projetoObjetivo: Avaliar as expectativas dos gerentes de projeto sobre o modelo MPSnas fábricas de software no Brasil.Problema: Como o modelo MPS é visto nas fábricas de software no Brasil?Solução: Aprimoramento ou "reciclagem" dos gerentes. Tendo em vista queeles (gerentes) entendem a importancia do modelo (MPS).Resultado: 44% dos entrevistados utiliza poucas vezes os modelos CMMI ouMPS.BR, sendo que foi notada uma grande discrepancia entre os conceitos e aimplementação prática.
  • 68. MPS.Br: Estado da Arte (3/4)Implementação do Nível F do MR-MPS com Práticas Ágeisdo Scrum em uma Fábrica de SoftwareObjetivo: Alcançar o nível F do MR-MPS em um ambiente ágil.Problema: Quais as aobrdagens para superar os obstaculos e alcançar o nívelF do MR-MPS em um ambiente ágil?Solução: Integração das ferramentas (Redmine e MS Project), gerando umaprimeira baseline e eliminando as baselines intermediárias, sendo que serãogeradas novas baselines ao final de cada sprint. Sendo que as auditoriasocorreriam antes da documentação ser entregue ao cliente.Resultado: Com ferramental adequado, não se perde qualidade do MR-MPScom a adoção da metododologia Scrum.
  • 69. MPS.Br: Estado da Arte (4/4)Influência e Impacto do Programa MPS.BR na PesquisaRelacionada à Qualidade de Software no BrasilObjetivo: Identificar a influencia do MSP.BR do ponto de vista bibliográfico naqualidade de software produzido.Problema: Qual o impacto do MPS.BR na qualidade do software produzido noBrasil?Solução: Não foram identificados estudos objetivos que descreviam o MPS.BRna qualidade de software no Brasil.Resultado: Como demostrado anteriormente, trabalhos dedicados ainvestigação da influencia do MPS.BR foram realizados.
  • 70. ReferênciasPRESSMAN, R. S. Engenharia de Software. São Paulo: McGraw-Hill, 2006.SOMMERVILLE, I. Engenharia de Software. São Paulo: Pearson Education,2007.CHRISSIS, M. B., KONRAD, M., SHRUM, S. CMMI: Guidelines for ProcessIntegration and Product Improvement. Boston: Pearson Education, 2004.ROCHA, A. R. C., MALDONADO, J. C., WEBER, K. C. Qualidade deSoftware. São Paulo: Makron Books, 2001.CHRISSIS, M. B., KONRAD, M., SHRUM, S. CMMI - Guidelines forProcess Integration and Product Improvement. Addison- Wesley, 2003.CMMI Product Team. CMMI-Dev. Techinal Report, SEI, 2010.
  • 71. ReferênciasDUNTIL, D. et al. Software Quality Engineering in the new ISOstandard: ISO/IEC 24748 - Systems and software engineering -Guide for life cycle management . Disponível em: <http://bit.ly/HPbUVR>. Acesso em: 04 abr. 2012.LAVALLÉE, M. et al. Do Software Process Improvements Lead to ISO9126 Architectural Quality Factor Improvement?. Disponível em: <http://bit.ly/HmyunW>. Acesso em: 04 abr. 2012.SANTOS, G. et al. Applying ISO 9001:2000, MPS.BR and CMMI toAchieve Software Process Maturity: BL Informatica’s Pathway.Disponível em: <http://bit.ly/HPcZ03> . Acesso em: 04 abr. 2012.SALIOU, P. Process Assessment Issues of the ISO/IEC 29110 emergingstandard. Disponível em: <http://bit.ly/Hil4HF> . Acesso em: 04 abr. 2012.
  • 72. ReferênciasJAKOBSEN, C. R., SUTHERLAND, J. Scrum and CMMI – Going fromGood to Great. Proceedings of Agile Conference, 2009.SHENVI, A. A. Is Process Compliance a Driver for Project Success?Proceedings of the 5th India Software Engineering Conference, ACM, 2012.DESHARNAIS, J., APRIL, A. Software Maintenance Productivity andMaturity. Proceedings of the 11th International Conference on ProductFocused Software, ACM, 2010.MARÇAL, A. S. C. et al. Uso de Práticas Ágeis para Alcançar o CMMI 5:Uma Abordagem Inovadora. Proceedings of the IX Simpósio Brasileiro deQualidade de Software, 2010.
  • 73. ReferênciasROCHA, A. R. et al. Dificuldades e Fatores de Sucesso naImplementação de Processos de Software Utilizando o MR-MPS e oCMMI. Disponível em: <bit.ly/HRX02S>. Acesso em: 04 abr. 2012.MENOLLI, A. et al. Práticas do Modelo MPS em Fábricas de Software:um estudo exploratório sobre as percepções dos gerentes de projeto. Disponível em: <http://bit.ly/HRXfux>. Acesso em: 04 abr. 2012.CATUNDA, E. et al. Implementação do Nível F do MR-MPS comPráticas Ágeis do Scrum em uma Fábrica de Software. Disponível em:<http://bit.ly/IQ7EpC>. Acesso em: 04 abr. 2012.SANTOS, G. Influência e Impacto do Programa MPS.BR na PesquisaRelacionada à Qualidade de Software no Brasil. Disponível em: <http://bit.ly/IlzLe2>. Acesso em: 04 abr. 2012.