GESTÃO DA QUALIDADE DE SOFTWARE

Transcrição

1 GESTÃO DA QUALIDADE DE SOFTWARE Fernando L. F. Almeida

2 Principais Modelos Capability Maturity Model Integration (CMMI) Team Software Process and Personal Software Process (TSP/PSP) Project Management Book of Knowledge (PMBOK) IT Service Management (ITIL) Expreme Programming e Métodos Ágeis (SCRUM e XP)

3 Paradoxo da Produtividade é para jogar o computador no lixo? (Exame Negócios, pag. 56, 04/04/01) Na década de 80, economistas norte-americanos como o Prêmio Nobel Robert Solow verificaram que, apesar de gastarem cada vez mais com computadores, as empresas e a economia como um todo não obtinham ganhos significativos de produtividade. Tal constatação ficou conhecida como paradoxo de Solow ou paradoxo da produtividade!

4 Problemas dos Processos e Software Prefiro deixar como está e atender ao prazo. Nós podemos corrigir o problema depois. A agenda é primordial. As minhas promoções e aumentos são baseados unicamente em encontros agendados. The botton line is schedule. My promotions and raises are based on meeting schedule first and foremost.

5 Problemas dos Processos e Software Perda do foco no objetivo (compromisso) Entrega fora do prazo Problemas de última hora Alteração de custos durante o processo Ausência de visibilidade durante o processo Surpresas constantes Problemas na qualidade Retrabalho Os requisitos do cliente não foram implementados correctamente Pedidos adicionais pós entrega Insatisfação Frustração Quem é o responsável?

6 CMMI Visão Geral O SW-CMM (Capability Maturity Model for Software) é um modelo de capacitação de processos de software, desenvolvido pelo SEI (Software Engineering Institute) e patrocinado pelo Departamento de Defesa Americano (DoD), para a avaliação da capacidade dos fornecedores de software deste último. Em 1999, foi publicado o esboço (draft), versão 0.2: CMMI-SE/SW (Capability Maturity Model -Integrated System / Software Engineering). Objetivo Principal: guiar organizações a conhecerem e melhorarem seus processos de software. Identifica práticas para um processo de software maduro, definindo as características de um processo de software efetivo.

7 CMMI Objectivos Além da integração dos modelos e redução dos custos com melhorias de processo, os seguintes objetivos também fazem parte do projeto CMMI: Aumento do foco das atividades Integração dos processos existentes Eliminar inconsistências Reduzir duplicações Fornecer terminologia comum Assegurar consistência com a norma ISO e ISO 9001 Flexibilidade e extensão para outras disciplinas

8 CMMI Representação Há duas formas de representar modelos CMMI Por etapas Contínuo Uma representação adequada permite que a organização siga caminhos diferentes no processo de melhoria A organização e a apresentação dos dados são diferentes em cada representação. Porém, o conteúdo é o mesmo.

9 CMMI Representação

10 CMMI Representação

11 CMMI Capability Levels Um Capability Level é um nível de evolução bem definido que descreve a capacidade da organização em relação a uma determinada area do processo Há seis níveis de evolução (Capability Levels) Cada nível é uma camada de fundamentos para o processo contínuo de melhoria Logo, os Capability Levels são acumulativos (i.e., a higher capability level includes the attributes of the lower levels)

12 CMMI Capability Levels

13 CMMI Nível 1 (inicial) O processo de software é caracterizado como sendo imprevisível e ocasionalmente caótico. Poucos processos são definidos e o sucesso depende de esforços individuais e, muitas vezes, heróicos. O processo de software é uma caixa preta, de forma que somente as entradas e os produtos finais podem ser vistos com clareza.

14 CMMI Nível 1 (inicial) Organizações no nível 1 apresentam deficiências de planeamento e enfrentam dificuldades ao realizarem previsões. Cronogramas e planos são irrealistas. Como não há credibilidade no planeamento, mesmo aquilo que foi planeado não é seguido. Não há controle de requisitos e o cliente só os avalia na entrega do produto. É comum passar diretamente dos requisitos à codificação. A documentação é encarada como algo inútil. São comuns reações intransigentes à recolha de dados e ao uso de padrões, documentação e ferramentas.

15 CMMI Nível 2 (Repetível) Processos básicos de gestão de projetos são estabelecidos para controle de custos, prazos e escopo. É possível repetir sucessos de projetos anteriores em aplicações similares. Ao invés do processo ser uma única caixa preta, ele passa a ser uma sequência de caixas pretas que asseguram a visibilidade em determinados pontos, os marcos do projeto.

16 CMMI Nível 2 (Repetível) Neste nível, organizações têm maior probabilidade de cumprir compromissos de requisitos, prazos e custos, mas desde que sejam semelhantes a outros realizados anteriormente. A organização é disciplinada, mas não está bem preparada para mudanças. Há preocupação com a gestão do projeto. Os gestores acompanham custos, cronogramas e funcionalidades de cada um dos projetos. Porém, a gestão ainda não é pró-ativa, tomando ações normalmente quando se está diante de uma crise. Controla-se a evolução dos requisitos, permitindo avaliações ao final de cada marco do projeto, e controla-se, também, a evolução das configurações do software.

17 CMMI Nível 3 (Definido) Um processo de software, composto por atividades de gestão e engenharia, é documentado, padronizado e integrado em um processo de software padrão da organização. Todos os projetos utilizam uma versão aprovada e adaptada do processo organizacional para desenvolvimento e manutenção de software. A organização interna das tarefas está definida e visível

18 CMMI Nível 3 (Definido) Processos utilizados são estabelecidos e padronizados em toda a organização. Os processos pertencem à organização e não aos projetos. Apesar da padronização, é possível adaptar os processos para as necessidades particulares de um projeto. Processos de engenharia de software são considerados ao lado dos processos de gestão. A organização consegue se manter dentro do processo mesmo em períodos de crise. Como o processo é bem definido, caso um programador abandone o projeto antes de seu término, o impacto é relativamente menor que nos níveis anteriores. Passagem do nível 2 para o 3: a padronização já realizada garante a oportunidade de escolher as melhores práticas existentes na organização.

19 CMMI Nível 4 (Gerenciado) Métricas detalhadas do processo de software e da qualidade do produto são recolhidas. Tanto o processo como o produto de software são quantitativamente compreendidos e controlados.

20 CMMI Nível 4 (Gerenciado) A organização estabelece metas quantitativas de qualidade e produtividade para as atividades do processo e para os produtos produzidos. Medidas de qualidade e produtividade são recolhidas em todos os projetos como parte de um processo organizacional de medição e estabelecem uma base quantitativa para que os gestores possam avaliar o progresso do desenvolvimento e a ocorrência de problemas. Os projetos melhoram o seu controle sobre os produtos e processos e a variância das medidas é diminuída. É estabelecido o controle estatístico de processos. Uma organização no nível 4 passa a ter uma gestão feita com bases quantitativas.

21 CMMI Nível 5 (Otimizado) A melhoria contínua do processo é estabelecida por meio de sua avaliação quantitativa, e da implantação planeada e controlada de tecnologias e ideias inovadoras.

22 CMMI Nível 5 (Otimizado) A organização está compormetida na melhoria contínua de seus processos, possuindo meios para identificar fraquezas e fortalecer o processo de forma pró-ativa, prevenindo defeitos. O entendimento do processo ultrapassa os processos praticados, possibilitando compreender os efeitos de alterações potenciais no processo. Melhorias em processos e tecnologias são planeados e executados como parte das atividades de rotina. Mudanças mais significativas de processos ou de tecnologias são feitas a partir de análises de custo / benefício com base em dados quantitativos cuja recolha iniciou-se no nível 4.

23 CMMI Visão geral Níveis de Maturidade 2 1 Foco na melhoria do processo Processo medido e controlado Processo pró-ativo e caracterizado para a organização Processo caracterizado para projetos e frequentemente reativo Processo imprevisível, pouco controlado Inicial Repetível Definido Gerenciado Otimizado

24 CMMI Utilização Prática 1. Melhoria do planeamento do projecto 2. Ciclo de gestão do tempo melhorado 3. Produtividade agregada 4. Qualidade melhorada 5. Satisfação do cliente agregada 6. Satisfação da equipa agregada 7. Retorno do investimento (ROI) melhorado 8. Custo de qualidade reduzido

25 CMMI Utilização Prática

26 PSP Personal Software Process Introduz técnicas para o estimativa de tamanho do software e esforço (PROBE) Planeamento de tarefas e cronograma Relatório para registro dos dados de teste

27 PSP Personal Software Process Defects Tracking Experience Data Best of Practices Lessons Learned process Practice Direct Feedback Analysis Synthesis Project Data Product Product Development % Estimate Error Planning Product Quality Process Quality Time Estimating Accuracy 40 Project Number Productivity Defects/KLOC Project Number LOC/Hour Project Number Percent Early Defect Removal Productivity Trend Project Number

28 PSP Estrutura

29 PSP Exemplo

30 PSP Exemplo

31 PSP Será completo?

32 PSP Será completo? Pessoas trabalham em grupo Integração e planeamento de etapas de desenvolvimento Necessidade de estimativas compostas

33 TSP Visão Geral TSP é um framework para produção de software processo produto trabalho em equipe planeamento e gestão do projeto. Métodos prontos para otimizar a duração e gestão do projeto Voltado para a formação de equipas de desenvolvimento de alta produtividade Focado em métricas e inspeções

34 TSP Visão Geral PSP Habilidade Individual TSP Formação da Equipe (Team Launch) TSP Gestão Metricas individuais Disciplina Estimativa e Planeamento Gestão da Qualidade Acompanhamento Disciplina Individual Objetivos do Projeto Comunicacao Planos de Qualidades Análise de Riscos Relatório final Disciplina da Equipe Gestão Das Actividades Equipe Integrada

35 TSP Visão Geral

36 TSP Pontos fortes Formação de uma equipe coesa, que busca um objetivo comum Suas práticas melhoram a gestão do projeto Completamente alinhado com o SW-CMM, funcionando como catalisador

37 TSP Pontos fracos Requer formação prévia em Personal Software Process (PSP) Não possui modelos de documentos Não entra em detalhes sobre a execução das atividades