Teresa Camelo Guimarães
1 Programa de Qualidade Qualidade de Software Prof. Gerson Prando Mai/06 A Qualidade, como Programa de Gestão, teve seu início no Japão do pós-guerra, nascido da necessidade de reconstrução do país. Deming, estatístico americano, levou a filosofia do programa a indústria japonesa em 1950 e em 5 anos, o Japão já exportava seus produtos para o mundo. 1 2 Qualidade Definição de Software Você sabe o que é qualidade? Existem diversas definições. Algumas pessoas que tentaram uma definição simples chegaram a frases como: Qualidade é estar em conformidade com os requisitos dos clientes Qualidade é antecipar e satisfazer os desejos dos clientes Qualidade é escrever tudo o que se deve fazer e fazer tudo o que foi escrito 3 Os sistemas de SOFTWARE sob um ponto de vista do cliente e do usuário, viabilizam rotinas de trabalho que não seriam realizáveis de outro modo, como o tratamento integrado de dados possibilitando o aumento de competitividade em todos os setores empresariais. 4 Objetivos de um Software Alta qualidade de software é: O objetivo principal de um software é possibilitar o controle efetivo de um processo, com economicidade de serviço, confiabilidade e usabilidade, conforme as necessidades dos usuários e/ou dos processos a serem controlados. Defeito zero Grande número de funções Codificação elegante Possuir alto desempenho Ter baixo custo Desenvolvimento rápido Facilidade para o usuário 5 6 1
2 Fatores de qualidade de software Qualidade em Software Correção Confiabilidade Eficiência Integridade Usabilidade Mantenabilidade Flexibilidade Testabilidade Portabilidade Reusabilidade Interoperabilidade Intra-operabilidade 7 De uma forma genérica podemos dizer que um software de boa qualidade produz resultados úteis e confiáveis na oportunidade certa; é ameno ao uso; é mensurável e auditável; é corrigível, modificável, e evolutível; opera em máquinas e ambientes reais; foi desenvolvido de forma econômica e no prazo estipulado; e opera com economia de recursos. 8 Propriedades da Qualidade em Software Padrão de Funcionalidade Padrão de Funcionalidade Padrão de Projeto Padrão de Desenvolvimento Padrão de Representação Para podermos aceitar a solução de algum problema, precisamos verificar a especificação e requisitos do problema, as funções tornadas disponíveis, a organização dos dados, controles, interfaces (eventos, estímulos, respostas) e o feedback do sistema para o universo e vice-versa, sem se preocupar com a forma de sua mecanização Padrão de Projeto Para podermos aceitar a solução mecanizada de um problema, precisamos analisar a arquitetura da solução do que é mecanizado, a alocação de recursos computacionais aos componentes dos sistema, interfaces externas e interfaces entre os componentes do sistema, a capacidade de evolução, assim como a justificativa para a solução através da avaliação de custos (de desenvolvimento e de uso) e dos benefícios (o que a solução resolve e o que ela não resolve). 11 Padrão de Desenvolvimento Esta propriedade da qualidade, envolve todo o processo de desenvolvimento, devendo-se analisar quais os produtos intermediários a serem gerados, quais as tarefas que geram estes produtos (em que tarefas se decompõe), qual a seqüenciação destas tarefas, porque realizar a tarefa, pré-condições e pós-condições (resultados das tarefas) e qual a natureza que devem ser alocados a tarefa. 12 2
3 Padrão de Representação Garantia de qualidade num software Este padrão pode ser implementado através de critérios de controle de qualidade (controle de versões, gerência de configuração, walkthroughs e testes sistemáticos) de como apresentar os resultados e as linguagens de representação a serem utilizadas. 13 A garantia de qualidade melhora o produto da programação, sendo de se esperar portanto que a produtividade diminua os custos, refletindo finalmente na base financeira. A qualidade de um sistema já deve estar embutida, não podendo ser acrescentada posteriormente. 14 Funções da qualidade de software Ações de um Controle de qualidade Desenvolvimento de padrões Certificado das necessidades Revisão dos documentos de fases Inspeção de código Mensuração do software Planejamento de testes Planejamento de auditoria Análise e coleção de dados Prevenção de defeitos Ação corretiva Gerenciamento de configurações 15 Certificação (argumentação formal) Inspeção (exame sistemático) Testes (experimentação) Verificação (avaliação do resultado quanto a qualidade interna (acabamento, normas e padrões)) Validação (avaliação do resultado quanto a interfaces e às necessidades e expectativas do usuário) 16 Controle de qualidade num software Qualidade de software É função do controle de qualidade efetuar as medidas e avaliações, indicando ao final a aceitação ou rejeição do produto que está sendo controlado. O C.Q. opera do detalhe para o geral, primeiro são obtidas as métricas e depois, através das funções de normalização, são quantificados os diversos fatores. 17 Produtos de software são complexos, até mais que o hardware onde executam Software não têm produção em série. Seu custo está no projeto e desenvolvimento Software não se desgasta e nem de modifica com o uso Software é invisível. Sua representação em grafos e diagramas não é precisa. A Engenharia de Software ainda não está madura, é uma tecnologia em evolução Não há um acordo entre os profissionais da área sobre o que é Qualidade de Software 18 3
4 Elementos indesejáveis Falhas e Defeitos Agressores Involuntários (elementos que inconscientemente danificam e/ou fazem uso indevido do sistema por não ter recebido o treinamento necessário para operar o sistema) Sistemas com Falhas (o próprio sistema pode possuir falhas capazes de danificar o seu contexto operacional) Agressores Voluntários (elementos que conscientemente danificam e/ou fazem uso indevido do sistema procurando deliberadamente negligenciar as regras de bom uso do sistema, objetivando fraudar e sabotar os processos). Falha é o afastamento dos resultados externos da operação do programa dos requisitos. Defeito é uma imperfeição dentro do programa que quando executada sob condições particulares, causa uma falha Detecção de erros Problemas comuns de processos Falhas de algum tipo de execução de código de máquina, tais como testes de software em máquina, beta testes e utilização operacional pelos clientes. Há também casos que não requer execução do código em máquina. Esses mecanismos incluem acidentes (tais como encontrar por acaso um erro enquanto se observa o código), diversas revisões técnicas; e ferramentas que processam o código, projetos e requisitos como documentos passíveis de análise, sugerindo falhas sem a execução em máquina do próprio código. 21 Prefiro deixar como está e atender ao prazo. Nós podemos corrigir o problema depois. A agenda é primordial. 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. 22 Sintomas causadores da falha no processo Intensificação dos softwares Perda do foco no objetivo (compromisso) Entrega fora do prazo Problemas de última hora Alteração de custos durante o processo Falta de visibilidade durante o processo Surpresas constantes Problemas na qualidade Retrabalho As funções não acontecem corretamente Pedidos adicionais pós entrega Insatisfação Frustração Quem é o responsável? O software está ganhando cada vez mais terreno em produtos e serviços. Tradicionalmente, disciplinas de sistemas e software não estão bem integradas. A importância do software em sistemas tem crescido drasticamente
5 Melhorias básicas de processos A regra do processo A premissa do gerenciamento de processos: A qualidade de um sistema é fortemente influenciada pela qualidade do processo usado para produzi-lo, adquiri-lo e mantê-lo. Esta premissa defende que o foco no processo é tão importante quanto o foco no produto. Essa premissa já existia na manufatura This is a long-established premisse in manufaturing (and is based on TQM principles as taught by Shewhart, Juran, Deming and Humphrey) Acredita-se que essa premissa é mundialmente conhecida em movimentos de qualidade na manufatura e serviços industriais. Belief in this premisse is visible worldwide in quality movements in manufacturing and service industries (e.g. ISO standarts) Todos reconhecem a importância do trabalho com qualidade, motivação e tecnologia de ponta, mas mesmo as melhores pessoas não são capazes de fazer o melhor quando o processo não é entendido ou executado da melhor forma. Everyone realizes the importance of having a motived, quality work force and the latest technology, but even the finest people can t perform at their best when the process is not understood or operating at its best Conceitos distorcidos Conceitos de Maturidade Visão Geral Eu não preciso de processos, eu tenho Profissionais capacitados;... Tecnologia de ponta;... Uma administração experiente atrapalha a criatividade;... É o mesmo que burocracia + regras;... Não é preciso quando se constrói protótipo;... Só é necessário em projetos longos;... Impede a agilidade e a velocidade das negociações;... É muito caro. Modelo de maturidade é a coleção estruturada de elementos que descrevem características de um processo efetivo. Um modelo de maturidade oferece Um ponto do partida Benefício à comunidade priorizando a experiência Uma linguagem comum e compartilhada a todos Um framework priorizando ações Um caminho para definir o que as melhorias significam para a sua organização Um modelo de maturidade pode ser usado como um banchmark, comparando diversas organizações IPE Qualidade de software GESTÃO MELHORIA CONTÍNUA SISTEMAS DA QUALIDADE E DE GESTÃO AMBIENTAL ISO-9000 ISO OS NÍVEIS DE MATURIDADE 29 O que é o CMM? Uma estrutura que descreve os elementos chaves de um processo de software eficaz. Um caminho de melhoramento evolucionário (5 níveis de maturidade) para organizações de software mudarem de um processo de software imaturo, ad hoc, para um processo maduro, disciplinado. 30 5
6 Capability Maturity Model for Software Modelo de Maturidade de Capacitação para Software Framework que descreve os principais elementos de um processo de software efetivo (praticado, documentado, medido e passível de melhoria). Fornece diretrizes para adoção de estratégias de melhoria evolutiva de processos e da qualidade de software Não é um método, mas um modelo que precisa ser estuda do, compreendido e adaptado a cada organização 31 Histórico do CMM Governo americano (DoD) solicita ao SEI Software Engineering Institute - um método para avaliar a capacitação de seus fornecedores de software Estrutura de Maturidade de e questionário de maturidade (Watts Humphey) TR-24 - Capability Maturity Model for Software (V. 1.0) e TR-25 - Key Practices of the CMM CMM for Software (V. 1.1) Carnegie Mellon University 32 Definições básicas Estrutura do Modelo de Software: conjunto de atividades, métodos, práticas e transformações utilizadas para desenvolver, manter e evoluir software e artefatos associados Capacitação do : habilidade inerente ao processo de software de produzir resultados planejados. Desempenho de : resultado das medições de consumo de recursos e da qualidade de resultados decorrentes da realização de determinado processo de software. Maturidade do : extensão para a qual um processo é explicitamente definido, praticado, gerenciado, medido e controlado 33 Capacitação do Metas Implementação Institucionalização Atividades ou Infra-estrutura Indicam Alcançam Abordam Descrevem Níveis de Maturidade Contém Áreas-chave de Características Comuns Práticaschave Organizadas pelas Contém São Compromisso Habilitação Atividade Medição e Análise Verificação 34 Organização Imatura Organização Madura
7 Os níveis de maturidade Os 5 níveis de Maturidade 1-Inicial 2-Repetitivo caótico Ad-hoc 3-Definido Melhoria contínua 4-Gerenciado disciplinado Gerência de Projeto 5-Otimizado previsível Controle quantitativo padronizado e consistente Integrado de Engenharia Inicial - O processo de software é caracterizado como ad hoc e ocasionalmente pode ser caótico. Poucos processos estão definidos e o sucesso depende de esforços individuais. 2. Repetível Os processos básicos de gerenciamento estão estabelecidos para controlar custo, cronograma e funcionalidade. A disciplina necessária dos processos permite repetir o sucesso em outros projetos com aplicações similares. 3. Definido O processo de software para as atividades de gerenciamento e de engenharia é documentado, padronizado e integrado em um processo padrão de software para a organização. 4. Gerenciado Medições detalhadas do processo de software e da qualidade do produto são coletadas. Tanto o processo de software quanto o produto de software são quantitativamente entendidos e controlados. 5. Otimizado A melhoria continua do processo é feita através do feedback quantitativo dos processos e das aplicações de novas idéias e tecnologias Inicial ou caótico 1 Inicial ou caótico O processo de software não está documentado e usualmente sequer existe. Poucos processos estáveis existem ou são usados e o sucesso depende de esforços individuais. Caracterização programadores consideram-se artistas; padrões não existem, ou tendem a ser ignorados; ferramentas são usadas ao acaso, por iniciativa pessoal; metodologias são praticadas informalmente; resultados não são previsíveis; a organização não provê um ambiente estável para o desenvolvimento e manutenção de software; cronogramas e orçamentos são freqüentemente abandonados por não serem baseados em estimativas realísticas; numa crise para cumprir cronograma, etapas planejadas do ciclo de vida não são realizadas prejudicando a qualidade do software; coleta e análise de dados é ad-hoc. 39 Embora a empresa possa ter procedimentos formalizados, orçamentos e planejamentos, este não são seguidos de maneira uniforme em toda empresa. Até que o processo esteja sob controle estatístico, não é possível progredir ordenadamente na melhoria do processo. Desempenho basicamente em função da competência e heroísmo das pessoas que fazem o trabalho. O processo de software é imprevisível, vel, já que é constantemente alterado no decorrer do projeto Os maiores problemas com os quais se defrontam as organizações de software são gerenciais e não técnicos. 40 Os níveis de maturidade 2 Repetitivo Estão estabelecidos processos básicos de gerência de projeto para planejar e acompanhar custos, prazos e funcionalidades. Compromissos são firmados e gerenciados e sucessos podem ser repetidos. disciplinado 1-Inicial 2-Repetitivo 41 Caracterização Caracterizado pela existência de um processo efetivo de planejamento e gerenciamento do projeto de software onde os controles sobre os procedimentos, compromissos e atividades são bem fundamentados; os processos de planejamento e gerenciamento do projeto de software devem ser praticados na organização, documentados, treinados e controlados; neste nível ainda não há preocupação com o processo de engenharia de software; gerência de projetos estabelecida; processo organizado; alguns procedimentos técnicos escritos; acompanhamento de qualidade; gerência de configuração inicial; sucesso depende do gerente do projeto. 42 7
8 2 Repetitivo Nível 2 Áreas-chave de processo A organização desenvolveu um processo estável com um nível repetitivo de controle estatístico, iniciando um rigoroso gerenciamento de custos, cronogramas e mudanças do projeto. O planejamento e gerenciamento de novos projetos são baseados na experiência obtida com projetos similares, que tenham obtido sucesso no passado Um fator relevante para a organização nesse nível é a dependência das experiências anteriores. O desenvolvimento de novos tipos de produtos pode causar um desequilíbrio no projeto, nas estimativas de custos e nos cronogramas Os projetos de software podem ser expedidos repetitivamente com pontualidade e qualidade razoável. 43 Gerenciamento de requisitos Planejamento de projeto de software Acompanhamento e supervisão de projeto de software Gerenciamento de subcontrato de software Garantia da Qualidade de Software (SQA- Software Quality Assurance) Gerenciamento da configuração de software (SCM- Software Configuration Management) 44 Nível 3 Definido Nível 3 Definido Atividades de gerência básica e as de engenharia de software são documentadas, padronizadas e integradas num processo único, chamado de Software Padrão da Organização. Todos os projetos usam uma versão deste processo, adaptada às características específicas do projeto. Caracterização caracterizado principalmente pela existência de um processo de engenharia de software bem definido, documentado e padrão para a empresa; as saídas de uma atividade fluem naturalmente para as entradas da próxima atividade; cada projeto de software utiliza o processo padrão da organização como base para implementar seu próprio processo; processos gerenciais e técnicos bem definidos; possibilidade de avaliação do processo; ferramentas e metodologias padronizadas; medições iniciais de desempenho; inspeções e auditorias rotineiras; testes padronizados; gerência de configuração; evolução controlada dos processos técnicos e gerenciais. 45 A organização definiu o processo como uma base para implementação consistente e melhor entendimento. O processo de software é definido, treinado e seguido pelos engenheiros de software. Existe um grupo para processos de software (SEPG) responsável por facilitar atividades de definição e melhoria de processos. Existe um programa de treinamento que assegura que todos tenham o conhecimento e a capacidade requerida para desenvolver suas tarefas, utilizando as ferramentas e os métodos disponíveis s que dêem poderes as pessoas para realizarem o trabalho Tecnologia avançada pode ser introduzida de forma útil. 46 Os níveis de maturidade Nível 3 Áreas-chave de processo consistente, padrão disciplinado 2-Repetitivo 3-Definido Foco no processo da organização Definição do processo da organização Programa de treinamento Gerenciamento integrado de software Engenharia de produto de software Coordenação intergrupal Revisões 1-Inicial
9 Nível 4 Gerenciado Nível 4 Gerenciado São coletadas medições detalhadas do processo de software e da qualidade dos produtos. Relatórios estatísticos são gerados. O processo e os artefatos de software são avaliados quantitativamente e são controlados. Caracterização caracterizado pela existência de processos de software passíveis de medida. a produtividade e a qualidade são medidas em todas as etapas do processo de software e para todos os projetos da organização. o controle sobre produtos e processos de todos os projetos são adquiridos através da diminuição da variação do seu desempenho para dentro de limites quantitativos aceitáveis. estabelecido e em uso rotineiro um programa de medições; estabelecido um grupo de garantia da qualidade; a qualidade é planejada; a qualidade é rotineiramente avaliada e aprimorada. 49 A organização iniciou um processo consistente de medidas e análises. A organização começa a aplicar métricas m de controle de qualidade para aumentar a qualidade e a produtividade do software entregue aos clientes. À medida que a organização adquire mais conhecimento sobre o produto, tem a oportunidade de remover várias fontes de comprometimento da qualidade final Isto proporciona a oportunidade de colocar o produto sob um controle estatístico stico de qualidade. Iniciam-se as mais significativas melhorias em qualidade. 50 Os níveis de maturidade Nível 5 Otimizado disciplinado 1-Inicial consistente, padrão 2-Repetitivo previsível 3-Definido 4-Gerenciado 51 É realizada rotineiramente a melhoria do processo como um todo. São realizados projetos piloto para a absorção e internalização de novas tecnologias. Caracterização caracterizado pela existência de processos de software com contínua nua melhoria; os processos de software são avaliados para prevenir tipos de defeitos conhecidos devido à recorrência, e as lições aprendidas são disseminadas para outros projetos; tecnologias que proporcionem mais retorno para processos específicos, utilizados pela organização, são selecionadas para serem introduzidas, de maneira gerenciável na organização; alto nível de qualidade é alcançado rotineiramente; melhoria contínua; alto nível de satisfação dos clientes. 52 Nível 5 Otimizado Os níveis de maturidade A organização tem uma base para melhoria continua e otimização do processo. Apesar de o processo ser maduro, ele é alvo de contínuas nuas melhorias. Os grupos de projetistas analisam o rendimento do projeto para determinar as causas dos defeitos. Nesse nível foi atingido um ambiente de excelência em engenharia de software Todos os engenheiros de software aplicam ferramentas e princípios do Gerenciamento as da Qualidade Total para aprimorar continuamente o processo e, conseqüentemente, os produtos de software. 53 disciplinado 1-Inicial consistente, padrão 2-Repetitivo previsível 3-Definido Melhoria continua do processo 4-Gerenciado 5-Otimizado 54 9
10 Os níveis de maturidade não podem ser omitidos Os níveis de maturidade não podem ser omitidos s dos níveis mais altos de maturidade podem ser realizados até mesmo por organizações do nível 1 (embora talvez ineficazmente). Competência em processos é construída em estágios gios, uma vez que alguns processos não são eficazes quando outros não estão estáveis. Cada nível oferece um fundamento necessário para melhorias a serem implementadas no nível seguinte. Sem a disciplina de gerenciamento o processo de engenharia é sacrificado. Medidas detalhadas são inconsistentes sem um processo definido. O efeito de inovação de processo não é claro em um processo cheio de ruído Capacidade x Desempenho CMM: Gerenciado (4) medido e controlado Definido (3) é caracterizado e claramente bem entendido Repetível (2) Pode repetir tarefas executadas com sucesso Inicial (1) Pobremente controlado e imprevisível Otimizado (5) Foco na melhoria contínua do processo Capacidade x Desempenho Capacidade de processo - o espectro de resultados esperados que podem ser alcançados seguindo-se um processo, inicialmente estabelecido a nível organizacional. Um instrumento para previsão de resultados de projetos futuros. Desempenho de processo - uma medida de resultados reais alcançados ao se seguir um processo. Está relacionado com um projeto em particular na organização Nível 5 4 Otimização Gerenciado 3 Definido 2 Repetível 1 Inicial Evolução do processo Características do processo Melhoria do processo é institucionalizada. Produto e processo são controlados quantitativamente. Engenharia de software e gerenciamento de processos definidos e integrados. Sistema de gerenciamento de projetos em vigor; desempenho é repetido. é informal e imprevisível. Diferença a entre Capacidade e Desempenho 59 Capacidade x Pessoas, tecnologia e medidas CMM: Inicial (1) Pobremente controlado e imprevisível Gerenciado (4) medido e controlado Definido (3) é caracterizado e claramente bem entendido Repetível (2) Pode repetir tarefas executadas com sucesso Otimizado (5) Foco na melhoria contínua do processo 60 10
11 CMM: Capacidade x Pessoas Nível 1 Nível 2 Nível 3 Nível 4 Nível 5 sucesso depende de heróis individuais apagando incêndio é o modo de viver sucesso depende de indivíduos, apoio administrativo comprometi mentos são compreendidos e administrados grupos de projeto trabalham juntos treinamento é planejado e de acordo com os papéis forte senso de trabalho em equipe dentro de cada projeto forte senso de trabalho em equipe na organização todos estão envolvidos na melhoria do processo CMM: Capacidade x Tecnologia Nível 1 Nível 2 Nível 3 Nível 4 Nível 5 introdução de nova tecnologia é um risco tecnologia apóia atividades estáveis e estabelecidas novas tecnologias são avaliadas em bases qualitativas novas tecnologias são avaliadas em bases quantitaivas novas tecnologias são procuradas e desenvolvidas relacão entre disciplinas são descordenadas e até adversas as pessoas são treinadas CMM: Capacidade x Medidas As Inspirações do CMM Nível 1 Nível 2 Nível 3 Nível 4 Nível 5 coleta de dados e análise são feitas ad hoc dados de administração e planejamento usados em projetos individuais dados são coletados e usados em todo processo definido dados são compartilhados ao longo do projeto definição e coleta de dados padronizados na organização dados são usados para compreender o processo quantitativamente e estabilizá-lo dados são usados para avaliar e selecionar melhorias de processo 63 A estrutura do modelo de maturidade de processo de software está baseada nos princípios pios de qualidade de produto que existem há 60 anos Shewart (AT&T) promulgou os princípios de controle estatístico stico de qualidade. Os princípios de Shewart foram posteriormente desenvolvidos e demonstrados com sucesso no trabalho de Deming e Juran. O trabalho desses pioneiros princípios do TQM (Total Quality Management) 64 A reação em cadeia de Deming A qualidade do produto melhora O custo diminui devido a menos re-trabalho, menos problemas, menos demora, melhores projetos uso eficiente de recursos e materiais. A capacidade melhora. O mercado é conquistado devido a melhores produtos e preços menores Lucro e mais serviço é conseguido Permanência no negócio 65 Adaptação da reação em cadeia de Deming ao Projeto de Software A organização amadurece O processo de software torna-se melhor definido e mais consistemente implementado através da organização. Software com maior qualidade, aumento de produtividade, menos retrabalho, melhores planos e melhor administração de projeto de software 66 11
12 Para se pensar, antes de se deitar! Deve ser observado que o SOFTWARE não é o fim em si mesmo, e sim o meio para alcançar determinados fins. 67 Metodologias e s ISO/IEC Framework para Avaliação de s de Software para: melhoria contínua determinação da capacitação CMMI - Capability Maturity Model Integration Software Engineering Institute - Carnegie Mellon University PSP - Personal Software Process TSP - Team Software Process 68 CMMI CMM, TSP e PSP SW-CMM - Capability Maturity Model for Software P-CMM - People CMM SA-CMM - Software Acquisition CMM SE-CMM - Systems Engineering CMM IPD-CMM - Integrated Product Development CMM Equipes Eficientes - TSP e PSP Qualidade do Software Normas do conjunto ISO/IEC 9126; ISO/IEC Características da Qualidade de Software ISO/IEC Guias de Avaliação de Produto de Software ISO/IEC Requisitos de Qualidade e Testes de Pacotes de Software