Desenvolvimento e qualidade de software utilizando metodos Ageis

1,372 views
1,269 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,372
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
53
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Desenvolvimento e qualidade de software utilizando metodos Ageis

  1. 1. Gerência de Configuração de SoftwareeQualidade de Software<br />Fagner Souza e Eurípedes Silva<br />São Paulo IPT, 28 de Abril de 2011<br />
  2. 2. Agenda<br />Introdução<br />Objetivo<br />Referências Bibliográficas<br />Premissas e Restrições<br />Gerência de Configuração de Software<br />Hipóteses<br />Recapitulando o estudo de caso<br />Modelo de Processo<br />Arquitetura de Software<br />Plano de Gerência de Configuração<br />Infraestrutura de Gerência de Configuração<br />Qualidade de Software<br />Hipóteses<br />Modelo de Processo<br />Plano de Garantia da Qualidade<br />28 de Abril de 2011<br />2<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  3. 3. Objetivo<br />Proposta para um plano de Gerência de Configuração do Processo de Software.<br />Proposta para um plano de Garantia da Qualidade.<br />3<br />28 de Abril de 2011<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  4. 4. Referências Bibliográficas<br />[SWEBOK2004] IEEE SWEBOK 2004, IEEE Guide to the Software Engineering Body of Knowledge 2004 Version.<br />[IEEE12207] IEEE/EIA 12207.0TM-1996, IEEEStandard for Information Technology Software Life Cycle Processes.<br />[IEEE828-2005] IEEE Std 828­­TM-2005, IEEE Standard for Software Configuration Management Plans.<br />[IEEE730-2002] IEEE Std 730TM-2002, IEEE Standard for Software Quality Assurance Plans.<br />[IEEE610-1990] IEEE Std 610.12TM-1990, IEEE Standard Glossary of Software Engineering Terminology.<br />[Whi02] White, B.A. Software Configuration Management Strategies and Rational ClearCase. Addison-Wesley 2000.<br />[Fai09] Fairley, R.E. Managing And Leading Software Projects. Wiley-IEEE Computer Society Press 2009.<br />[Bec99] Beck , K.. Extreme Programming Explained. Addison-Wesley 1999.<br />[App04] Appleton, B.. AgileConfiguration Management Environments. Chicago SPIN, 2004.<br />[Has02] Hass, A.M.J. Configuration Management PrinciplesandPractice. Addison-Wesley 2000.<br />[Ast03] Astels, D. Test-Driven Development: A Practical Guide. Prentice Hall PTR 2003.<br />[Lew04] Lewis, W. E. Software Testing and Continuous Quality Improvement2 edition. 2004.<br />[PMBOK2004] Project Management Body Of knowledge. Project Management Institute 2004.<br />[ISO] International Organization for Standardization- Séries 9000 e 14000, 9001:2000, 12207, 15504, <br />4<br />28 de Abril de 2011<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  5. 5. Premissas e Restrições<br />Consultoria de TI   E & F Systems Tecnologia da Informação está contratada para a implementação do Sistema GMS GinoManagmentSystem, (denominação, conforme apresentação do Grupo G3); bem como a prestação de serviços de suporte e manutenção pós- implantação, incluindo Qualidade de software.A Empresa RestaturantesDaGino não é da Área de Tecnologia da Informação e portanto não tem “expertise” técnico nesta área;A Gestão de Qualidade, conforme contrato estabelecido entre as partes vai prestar serviços de controle de qualidade e garantia de qualidade exclusivamente para o projeto de implementação e manutenção do GMS, estando fora os processos organizacionais da Empresa.Os trabalhos apresentados pelos grupos anteriores foram adaptados e parcialmente incorporados ao planejamento da E & F Systems TI.<br />5<br />28 de Abril de 2011<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  6. 6. Premissas e Restrições<br />O Desenvolvimento será local e na E & F Systems, conforme definições do Planejamento do projeto. Este trabalho foi baseado em alguns aspectos de apresentações anteriores (não em todos).<br />O contrato entre a E & F Systems e RestaturantesDaGino está assinado pela Direção das Empresas e é composto de documento de Termo de Confidencialidade de informações e Acordo de nível de Serviços estabelecido entre as partes.<br />A Empresa Restaurantes DaGino está ciente da metodologia de Desenvolvimento e Homologação de Softwares, Gestão de projetos da E & F fundamentadas nas recomendações da IEEE SWEBOK 2004e ] IEEE/EIA 12207.0TM-1996<br />Não é escopo desse trabalho apresentar e detalhar metodologias ou métodos Ágeis e Qualidade em termos organizacionais.<br />28 de Abril de 2011<br />6<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  7. 7. Restrições<br />Custo do projeto:<br />Para a implementação e fases de suporte e manutenção o orçamento não deverá ultrapassar o valor definido em reunião da Direção das Empresas DaGino e E & F Systems.<br />28 de Abril de 2011<br />7<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza, Eurípede, Alan<br />
  8. 8. Gerência de Configuração do Software<br />Estudo de caso: Restaurante DaGino<br />
  9. 9. Hipóteses<br />Modelo de processo de software.<br />Arquitetura de Software.<br />9<br />28 de Abril de 2011<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  10. 10. HipótesesModelo de processo de software<br />10<br />28 de Abril de 2011<br />Extreme Programming<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  11. 11. Recapitulando o estudo de caso<br />11<br />28 de Abril de 2011<br />Application Server<br />Pocket PC<br />Display de Pedidos<br />Terminal de Cozinha<br />Reservar mesa<br />Fechar mesa<br />Pedir prato<br />Pedidos prontos<br /> <br />RECEPÇÃO<br />COZINHA<br />SALÃO<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  12. 12. HipótesesArquitetura de Software<br />12<br />28 de Abril de 2011<br />Sistema DaGino<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  13. 13. É um time ágil (XP). Composto por:<br />1 Líder;<br />2 Desenvolvedores Plenos;<br />4 Desenvolvedores Juniores;<br />!!!!!Todos são desenvolvedores!!!!!<br />28 de Abril de 2011<br />13<br />HipótesesO time de desenvolvimento do sistema DaGino<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  14. 14. Software Configuration Management PlanO que é?<br />28 de Abril de 2011<br />14<br />É um documento que define as estratégias para o controle de alterações no software.<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  15. 15. No escopo da 12207<br />28 de Abril de 2011<br />15<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  16. 16. O que há no plano?<br />Definição dos itens da configuração;<br />Versionamento desses itens ao longo do tempo;<br />Ferramentas para controle das versões dos itens de configuração;<br />Ferramentas para controle das requisições de alterações nos itens da configuração;<br />...enfim, controle da MUDANÇA.<br />28 de Abril de 2011<br />16<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  17. 17. Por que eu preciso disso?<br />Porque o software muda (evolui);<br />Porque o time muda (as pessoas vão e vem);<br />Porque a empresa muda (estratégia, processo);<br />Porque até você muda (se você estiver aprendendo, então você também evolui);<br />28 de Abril de 2011<br />17<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  18. 18. Aplicando para o DaGinoIdentificando os ICS<br />Item de Configuração de Software (ICS): conjunto de software que é designado para GC e tratado como uma entidade única no PGC (IEEE610-1990).<br />Exemplos típicos: planos, especificações, documentação de design, material de teste, ferramentas de software, código fonte (.java, .c, .html e etc) e executáveis (.class, .jar, .exe, .so e etc), bibliotecas (.h, .jar, e etc), dados e dicionário de dados, documentação para instalação, manutenção e operação e uso do software (SWEBOK2004).<br />28 de Abril de 2011<br />18<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  19. 19. Aplicando para o DaGinoIdentificando os ICS<br />28 de Abril de 2011<br />19<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  20. 20. Aplicando para o DaGinoIdentificando os ICS<br />28 de Abril de 2011<br />20<br />UserStories: requisitos do sistema;<br />Achitectural Spike: System Metaphor, ou arquitetura do sistema;<br />Release Plan: plano de liberação, contendo quais UserStories estarão presentes no trabalho a ser realizado na iteração seguinte;<br />AcceptanceTests: testes de aceitação;<br />Small Releases: versões finalizadas e aprovadas pelo cliente. São compostas por um ou mais dos módulos presentes na arquitetura do sistema;<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza, Eurípedes, Alan<br />
  21. 21. O objetivo deste documento é descrever quais ICs devem ser armazenados e versionados, bem como estabelecer as regras para alteração desses itens. O documento é destinado aos desenvolvedores, cliente e demais pessoas diretamente envolvida no desenvolvimento do Software DaGino para o Restaurante DaGino.<br />28 de Abril de 2011<br />21<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />Introdução: Propósito<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  22. 22. a) O projeto a que este documento se refere é software para automação das atividades de reserva de mesa, pedido de pratos, controle de receitas de pagamento do restaurante DaGino.<br />b) Os seguintes itens de configuração fazem parte desse projeto: UserStories, System Metaphor, Software releases e etc;<br />c) Os seguintes sistemas de apoio constam do plano e das atividades realizadas no processo de desenvolvimento: JUnit, Subversion, Redmine e etc;<br />d)Este plano relaciona-se com o PGCH na medida que funcionalidade do sistema de software dependem de características específicas disponíveis e controladas pelas diversas versões do hardware. Sempre que esse for o caso, o PGCH deverá ser citado, e uma relação entre o IC do PGCH e de sua contraparte no PGCS devem ser claramente relacionadas.<br />e) O grau de formalidade deste plano será limitado ao permitido pelo paradigma ágil, e o controle de alteração não envolverá nenhum tipo de autorização senão aqueles já previstos no processo de desenvolvimento XP.<br />f) Nenhuma limitação.<br />g) Nenhuma questão adicional;<br />28 de Abril de 2011<br />22<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />Introdução: Escopo<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  23. 23. IC: Item de Configuração.<br />ICS: Item de Configuração de Software.<br />PGCS: Plano de Gestão de Configuração de Software.<br />Pocket PC: Computador de mão, utilizado na solução de software a que se refere este documento;<br />PVRT: Plano de Validação de Resultados de Testes;<br />EF: Especificação Funcional;<br />...<br />28 de Abril de 2011<br />23<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />Introdução: Glossário<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  24. 24. [SWEBOK2004] IEEE SWEBOK 2004, IEEE Guide to the Software Engineering Body of Knowledge 2004 Version.<br />[IEEE12207] IEEE/EIA 12207.0TM-1996, IEEEStandard for Information Technology Software Life Cycle Processes.<br />[IEEE828-2005] IEEE Std 828­­TM-2005, IEEE Standard for Software Configuration Management Plans.<br />[IEEE730-2002] IEEE Std 730TM-2002, IEEE Standard for Software Quality Assurance Plans.<br />[IEEE610-1990] IEEE Std 610.12TM-1990, IEEE Standard Glossary of Software Engineering Terminology.<br />…<br />28 de Abril de 2011<br />24<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />Introdução: Referências<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  25. 25. 28 de Abril de 2011<br />25<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Organização<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  26. 26. Papeis<br />28 de Abril de 2011<br />26<br />Desenvolvimento<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Organização | Papeis - Desenvolvimento<br />Cliente<br /><ul><li>Solicita novos requisitos (UserStories)
  27. 27. Aprova o resultado das iterações
  28. 28. Desenvolvem requisitos
  29. 29. Aprova novos requisitos (UserStories)</li></ul>Desenvolvedores<br />Gerente do Projeto<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  30. 30. Papeis<br />28 de Abril de 2011<br />27<br />Manutenção<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Organização | Papeis - Manutenção<br />Cliente<br /><ul><li>Reporta falhas no software
  31. 31. Aprova o resultado das iterações</li></ul>Desenvolvedores<br /><ul><li>Desenvolvem correções para as falhas</li></ul>Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  32. 32. …<br />28 de Abril de 2011<br />28<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />Responsabilidades<br />Unidade<br />GCS Gestão: Responsabilidades<br />Cliente<br /><ul><li>Aprova o resultado das iterações. A Baseline é estabelecida após aprovação da Iteração 0
  33. 33. Decide prioridade das UserStories e ChangeRequests
  34. 34. Aprova novos requisitos (UserStories):
  35. 35. Somente alterações funcionais na Baseline passam por aprovação</li></ul>Desenvolvedores<br />Gerente do Projeto<br /><ul><li>Estima esforço para cada UserStorye ChangeRequest;
  36. 36. Implementa as UserStories e Changerequests</li></ul>Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  37. 37. O time de desenvolvimento é ágil (XP) e PGCS deve ser leve o suficiente para permitir que o time continue sendo (ágil).As principais características do time estão listadas abaixo e devem ser usadas como restrição a aplicação do PGCS:<br />Projetos ágeis dependem de: um bom diálogo com o usuário, entrega da execução, código testado a cada duas a doze semanas e frequente feedback sobre a qualidade de requisitos e projeto.<br />28 de Abril de 2011<br />29<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Políticas, diretrizes e procedimentos<br />[Has02]<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  38. 38. Os seguintes termos e conceitos no PGCS devem ser considerados com base nas restrições definidas aqui:<br />Controle de Alteração, começa no primeiro dia de projeto para o time ágil, e é baseado na comunicação com o usuários e clientes. Com isso os requisitos são extraídos ou na forma de novas funcionalidades ou na forma de changerequests de funcionalidades já desenvolvidas. O time estima o esforço e o cliente estima a prioridade de cada solicitação para a próxima iteração; Esse processo é dinâmico, constante e é o equivalente ágil para o CCB.<br />Autorização para Alteração. O time tem autorização automática para alterar o código em duas situações: <br />Implementar novas características (ex. UserStories), já aprovadas;<br />Refactoring para melhorar a simplicidade do código (leitura e manunteção);<br />Identificação, armazenamento, integração e build. Releases e marcos importantes dos builds são facilitados pelo recurso “tag” da ferramenta de controle de versão; O desenvolvedor executa testes unitários, realizam builds privados do sistema e executa SmokeTests antes de realizar commits de seu ambiente privado para o repositório de desenvolvimento do time. Builds de integração devem passar nos testes de regressão e serem reconstruídos do zero antes de serem submetidos aos testes de aceitação (funcional).<br />28 de Abril de 2011<br />30<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Políticas, diretrizes e procedimentos | Termos e efeitos<br />[Has02]<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  39. 39. …<br />28 de Abril de 2011<br />31<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Gestão: Gestão do processo de GCS<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  40. 40. 28 de Abril de 2011<br />32<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />BASELINE<br /> <br /> <br /> <br />COMPOSIÇÃO<br />GCS Atividades: Identificação da Configuração| Composição da Baseline<br />MÓDULO RECEPÇÃO<br />MÓDULO COZINHA<br />MÓDULO ESTOQUE<br />MÓDULO CAIXA<br /> <br /> <br /> <br /> <br /> <br /> <br /> <br />...<br />userstories<br />release plans<br />codes<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  41. 41. 28 de Abril de 2011<br />33<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Identificação da Configuração | Evolução da Mudança<br />[App04]<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  42. 42. 28 de Abril de 2011<br />34<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Nomeando Cis | Sistema para identificação<br />MMNN é um número composto da seguinte maneira:<br /> MM : runningnumber<br /> NN : número da iteração<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  43. 43. 28 de Abril de 2011<br />35<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Nomeando Cis | Sistema para identificação | Ticket Eletrônico<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  44. 44. 28 de Abril de 2011<br />36<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Nomeando Cis | Sistema para identificação | Ticket Eletrônico<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  45. 45. …<br />28 de Abril de 2011<br />37<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Aquisição dos itens de configuração<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  46. 46. 28 de Abril de 2011<br />38<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Controle da configuração<br />Autorização para desenvolvedores fazerem alterações precisam ser instantâneas:<br />Uma vez que o desenvolvedor tenha sido definido, ele não deveria ter que esperar para começar a fazer check out de itens do repositório;<br />Se um bug quebra o build ou um teste de requisito falha, o desenvolvimento deve ser capaz de realizar o reparo sem ter que aguardar qualquer período de tempo para receber “Autorização”;<br />Nenhuma permissão adicional é requerida para o refactoring;<br />[App04]<br />É necessário autorização da gerência de projeto na definição de quais UserStories serão produzidas ao longo do projeto;<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  47. 47. Atendimento através das ferramentas de apoio e infra-estrutura para GCS:<br />Sistema de Controle de Versão, através de Check-in documentado. Ex.:<br />Ferramenta para gestão através de Tickets Eletrônicos, através da geração automática de relatórios de quantidades de falhas registradas para um IC, tempo gasto para a correção das falhas, tempo gasto no desenvolvimento de UserStories e etc;<br />28 de Abril de 2011<br />39<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Estado da configuração | Relatórios<br />User ID.........: fagnerls.<br />Issue ID........: 2885.<br />Description..: Messagem de erro ao excluir usuário.<br />Solution.......: Corrigido nome da tabela no select principal.<br />Comments....: atualização replicada para o teste unitário.<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  48. 48. Deverá ser atendido em face do Plano de Garantia da Qualidade;<br />A revisão será feita com base nas UserStories armazenadas no sistema de controle por tickets, e cada não conformidade deve ser registrada no ticket relativo a UserStory avaliada, sendo que seu status deve ser alterado para refletir sua nova condição para que a equipe de desenvolvimento possa atuar;<br />28 de Abril de 2011<br />40<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Revisão da configuração<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  49. 49. …<br />28 de Abril de 2011<br />41<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Interface de Controle<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  50. 50. …<br />28 de Abril de 2011<br />42<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Controle de Subcontrato<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  51. 51. …<br />28 de Abril de 2011<br />43<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Atividades: Gerenciamento de Entrega<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  52. 52. …<br />28 de Abril de 2011<br />44<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Agendamentos: .<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  53. 53. …<br />28 de Abril de 2011<br />45<br />Aplicando para o DaGinoPlano de Gestão de Configuração de Software<br />GCS Manutenção do Plano: .<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  54. 54. O que mais poderia fazer parte do Plano?<br />o conjunto de software em execução nesses equipamentos, como SO, plataformas de execução (VM), plugins, firmwares e etc:<br />Pocket PC;<br />Servidor de aplicação;<br />Workstation; <br />28 de Abril de 2011<br />46<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  55. 55. Qualidade de Software<br />Estudo de caso: Restaurante DaGino<br />
  56. 56. O que é qualidade ?<br />Qualidade é estar em conformidade com os requisitos dos clientes<br />Qualidade é antecipar e satisfazer os desejos dos clientes<br />Segundo a atual norma brasileira sobre o assunto (NBR ISO 8402), qualidade é:<br />A totalidade das características de uma entidade<br />que lhe confere a capacidade de satisfazer<br />às necessidades explícitas e implícitas.<br />28 de Abril de 2011<br />48<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  57. 57. Qualidade Segundo os “Gurus<br />Crosby<br />Conformidade com as especificações<br />“Fazer certo da primeira vez”<br />O gerenciamento da qualidade deve ser feito desde o início<br />Evitar defeitos e diminuir o retrabalho<br />Juran<br />“Adequaçãoaouso”<br />As expectativas dos clientes são atendidas ou até excedidas<br />Qualidade obrigatória: o produto faz o que devia fazer<br />Qualidade atrativa: o produto oferece algo que o cliente nem imaginava, mas que ele gostou<br />Weinberg<br />“Valor paraalgumapessoa”<br />Deming<br />“Qualidade é orgulho da manufatura”<br />85% do custo da qualidade é um problema de gerenciamento<br />28 de Abril de 2011<br />49<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  58. 58. TQM (Total Quality Management), amplamente usado nas organizações<br />Kan (2002)<br />28 de Abril de 2011<br />50<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  59. 59. Complexidade na definição<br />28 de Abril de 2011<br />51<br />"Criar um conjunto de atividades que irão ajudar a garantir que cada produto de trabalho da engenharia de software exiba alta qualidade"; (PRESSMAN, 2005, p. 193) <br />"Realizar atividades de segurança da qualidade em cada projeto de software";(PRESSMAN, 2005, p. 193) <br />"Usar métricas para desenvolver estratégias para a melhoria de processo de software e, como conseqüência, a qualidade no produto final"; (PRESSMAN, 2005, p. 193) <br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  60. 60. Os Fatores da Qualidade de McCall<br />28 de Abril de 2011<br />52<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  61. 61. Qualidade de Software segundo a ISO 9126-1<br />Funcionalidade(Satisfação das Necessidades): É a capacidade do produto de software de prover funcionalidades que irão satisfazer as necessidades quando o software está em uso dentro das condições especificadas. <br />Confiabilidade(Imunidade a Falhas): É a capacidade do produto de software de manter um nível especificado de performance quando o software está em uso dentro das condições especificadas. <br />Usabilidade(Facilidade de Uso): É a capacidade do produto de software de ser entendido, aprendido, usado e atrativo quando o software está em uso dentro das condições especificadas. <br />Eficiência(Rápido e "Enxuto"): É a capacidade do produto de software de prover performance apropriada, relativa ao conjunto de recursos usados quando o software está em uso dentro das condições especificadas. <br />Manutenibilidade(Facilidade de Manutenção): É a capacidade do produto de software de ser mudado. Modificações incluem correções, melhorias ou adaptações do software de mudar em um ambiente, e em requisitos e especificações funcionais. <br />Portabilidade(Uso em outros Ambientes): É a capacidade do produto de software de ser transferido de um ambiente para outro. <br />28 de Abril de 2011<br />53<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  62. 62. Outras normas da série ISO 9126<br />ISO/IEC 9126-2 - Métricas Externas: Podem ser aplicadas para um produto não executável durante os estágios de desenvolvimento. Medem a qualidade de produtos intermediários e predizem a qualidade do produto final. <br />ISO/IEC 9126-3 - Métricas Internas: Utilizadas para medir a qualidade do software através do comportamento do sistema ou de parte dele. Só podem ser usadas durante a fase de testes do ciclo de vida e durante a operação do sistema. <br />ISO/IEC 9126-4 - Métricas da Qualidade do Uso: medem se o produto atende ou não as necessidades dos usuários, fazendo-os atingir seus objetivos com efetividade, produtividade, segurança e satisfação. Só podem ser usadas no ambiente real ou em uma aproximação do ambiente real. <br />28 de Abril de 2011<br />54<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  63. 63. A Qualidade segundo o PMBOK<br />28 de Abril de 2011<br />55<br />[PMBOK2004]<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  64. 64. CMMI 1.2<br />Produtividade<br />Foco<br />Nível<br />Áreas de Processos<br />Qualidade<br />Melhoria<br />5 Em<br />Inovação e Implantação Organizacional<br />Contínua do<br />Otimização<br />Análise e Prevenção de Defeitos<br />Processo<br />4 Gerenciado<br />Gerenciamento Quantitativo do Projeto<br />Gerência<br />Quantitativam.<br />Performance do Processo Organizacional<br />Quantitativa<br />Desenvolvimento de Requisitos<br />Solução Técnica<br />Integração de Produtos<br />Verificação<br />Validação<br />Padronização<br />3 Definido<br />Foco no Processo Organizacional<br />do Processo<br />Definição do Processo Organizacional<br />Treinamento Organizacional<br />Gerência Integrada de Projeto<br />Gerência de Riscos<br />Análise e Tomada de Decisão<br />Gerência de Requisitos<br />Planejamento de Projeto<br />Monitoramento e Controle de Projeto<br />Gerência<br />Gerência de Acordos com Fornecedores<br />Básica de<br />2 Gerenciado<br />Medição e Análise<br />Projetos<br />Garantia da Qualidade do Processo e do Produto<br />Gerência de Configuração<br />Risco<br />Retrabalho<br />1 Inicial<br />14/04/2007<br />© 2007<br />
  65. 65. Qualidade do Processo e do Produto<br />Qualidade do produto está ligada às características do resultado do processo, geralmente especificadas naforma de requisitos<br />Requisitos de negócio, de usuário, funcionais, não-funcionais,técnicos<br />Qualidade do processo está ligada à forma como o produto é feito<br /> Monitoramento da execução, uso adequado dos artefatos e<br /> ferramentas, seqüência das tarefas<br />28 de Abril de 2011<br />57<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  66. 66. Diferenças entre Garantia da Qualidade e Controle da Qualidade<br />28 de Abril de 2011<br />58<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  67. 67. Qualidade de Software - SWEBOK<br />SWEBOK(Software Engineering Body of Knowledge) versão 2004<br />28 de Abril de 2011<br />59<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  68. 68. Técnicas de Gestão de qualidade de Software<br />Técnicasestáticas,<br />Analíticas<br />Dinâmicas<br />28 de Abril de 2011<br />60<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  69. 69. Métricas – Qualidade de software<br />Estatistica ( Análise Pareto, gráficos<br />Gráfico de dispersão, distribuição normal)<br />Testes estatísticos (binomial)<br />Análise de Tendência<br />Modelos de confiabilidade<br />28 de Abril de 2011<br />61<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  70. 70. Âmbito da ISO12207<br />62<br />[ISO12207-95 p.17] <br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  71. 71. Processos de gestão da qualidade de Software (SQM) <br />Garantia da qualidade<br />Verificação<br />Validação<br />Revisão<br />Auditoria<br />28 de Abril de 2011<br />63<br />[IEEE12207.0-96] <br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  72. 72. PADRÃO IEEE Std 730-2002 <br />O objetivo desta norma é fornecer uniformes, os requisitos mínimos aceitáveis ​​para a preparação econteúdo dos planos de software de qualidade.Ao considerar a adopção desta norma, as entidades reguladoras devem estar cientes de que a aplicação específica destepadrão já pode ser coberta por um ou mais documentos ou IEEE padrões ANSI relativos à qualidadegarantia, as definições, ou outros assuntos.<br />28 de Abril de 2011<br />64<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  73. 73. Custo da Qualidade de Software<br />custo de qualidade de software proposto por Bartié (2002)<br />a) Custo da Detecção de Defeitos:<br />Revisões de requisitos; modelagem, planos de testes, inspeções<br />Custo da Prevenção de Defeitos<br />Definição de Metodologias; <br />- Treinamentos; <br />- Ferramentas de apoio ao processo de desenvolvimento; <br />- Definição de Políticas; <br />- Procedimentos; <br />Custo da Não-Conformidade:<br />Re-reviões; <br />- Re-testes; <br />- Correções de código-fonte e documentação muito constantes; <br />28 de Abril de 2011<br />65<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  74. 74. Gestão da qualidade de processo de software<br />Gestão da qualidade de software se aplica a todas perspectivas de processos de software, produtos e recursos. Define processos, os responsáveis ​​pelo processo, e osrequisitos para os processos, as medições dacanais de processo as saídas e feedback.<br />28 de Abril de 2011<br />66<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza, Eurípedes, Alan<br />
  75. 75. Hipóteses<br />Modelo de processo de software para o<br />estudo de casoRestaurantesDaGino<br />Foco: Gerência da qualidade do software.<br />67<br />28 de Abril de 2011<br />• modelo de processo.<br />• a aplicação de um plano de garantia da qualidade – garantia do produto e do processo – para o estudo de caso. <br />Justificativas.<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  76. 76. 28 de Abril de 2011<br />68<br />Projeto DaGino - XP e Qualidade <br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  77. 77. Qualidade: modelos ágeis<br />A aferição da qualidade do produto está totalmente atrelada a inspeção do processo.No caso do XP, podemos considerar que a programação pareada como um forma de inspeção e isto associado a outras práticas tais como uso de TDD (Desenvolvido orientado a Testes) podem dar a qualidade ao produto.<br />28 de Abril de 2011<br />69<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  78. 78. TDD – Test Driven Development<br />28 de Abril de 2011<br />70<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  79. 79. TDD<br />● DesenhoSimplificado e Evolucionário<br />● Refatoração<br />● Feedback Constante<br />● Suíte de Testes (Regressão)<br />● Documentação Para Programadores<br />28 de Abril de 2011<br />71<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  80. 80. Artigo XP e CMM - Mark Paulk<br />28 de Abril de 2011<br />72<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  81. 81. Responsabilidades da equipe de garantia<br />Interargir com Equipedo projeto<br />Rever planos e artefatos<br />Facilitar reuniões e revisões<br />Auditar atividades e artefatos do projeto<br />Coletar, analisar e reportar dados de medição<br />Trabalhar com o grupo de processos para assegurar<br />que os processos são úteis e utilizáveis<br />14/04/2007<br />© 2007<br />
  82. 82. Composto por:<br />Coordenador de Garantia de Qualidade;<br />1 Analista de Controle de Qualidade;<br />Reporte externo ao Gerente de Qualidade da Consultoria<br />28 de Abril de 2011<br />74<br />Hipóteses Projeto GMS DaGinoO Equipe de garantia de Qualidade para o projeto<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  83. 83. Justificativas<br />As características do projeto requerem uma equipe dinâmica, uma vez que o projeto em grande parte será na sede da Consultoria.<br />Projeto considerado de médio porte, conforme documentação anterior.<br />Comunicação<br />Simplicidade<br />Feedback constante<br />[ISO12207-95, Anexos A e B] <br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  84. 84. PLANO DE GARANTIA DE QUALIDADE DE SOFTWARE Std 730-2002<br />1) Finalidade2) documentos de referência3) Gestão4) Documentação5) As normas, práticas, convenções e métricas6) Software opiniões8) o relatório de problemas e ações corretivas9) Ferramentas, técnicas e metodologias10) controle de mídia11) controle de fornecedores12) A recolha Records, manutenção e conservação13 Formação)14 A gestão de riscos)15 Glossário)16) SQAP processo de mudança e história<br />28 de Abril de 2011<br />76<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  85. 85. Glóssário<br />28 de Abril de 2011<br />77<br />CMMi Capability Maturity Model Integrated COTS Commercial Off-the-shelf Software Plano PDCA Plan, Do, Check, Act SQA Garantia da Qualidade de Software SQM Gestãoda Qualidade de Software TQM Gestãoda Qualidade Total V & V Verificaçãoe Validação<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  86. 86. Considerações Finais<br />Qualidade não deve ser só inspecionada, mas embutida!<br />Antes de questionar o custo da qualidade, questione o custo da falta de qualidade<br />Lembre-se que a qualidade é um dos 4 principais compromissosdo projeto<br />As ferramentas devem ser as aliadas da qualidade nosprocessos<br />Pessoas + Processos + Ferramentas = Sucesso<br />28 de Abril de 2011<br />78<br />Estudo de Caso - Restaurante DaGino<br />Fagner Souza e Eurípedes Silva<br />
  87. 87. Obrigado ;)<br />Fagner Souza e Eurípedes<br />

×