Baixe Fatores de Acompanhamento da Qualidade de Software: Uma Abordagem Completa e outras Slides em PDF para Programação Orientada a Objetos, somente na Docsity!
ENGENHARIA DE SOFTWARE II
CAPÍTULO 2 – QUALIDADE E PRODUTIVIDADE DE SOFTWARE, r
Neste capítulo serão abordados os seguintes itens:
2.1 Fatores de acompanhamento da qualidade de software 2.1.1 Processos de controle da qualidade do software 2.1.2 GQS – Garantia de qualidade de software ( SQA – Software Quality Assurance ) 2.1.3 Custo da qualidade 2.2 Fatores e métricas da qualidade do software 2.2.1 Principais métricas de qualidade do software 2.3 Qualidade do produto da engenharia de software: ISO/IEC 9126 e ISO 25000 2.3.1 Objetivo 2.3.2 Estrutura do modelo de qualidade 2.3.3 Modelo de qualidade para qualidade externa e interna 2.3.4 Modelo de qualidade para qualidade em uso 2.3.5 Norma Square ISO/IEC 25000 - Software Product Quality Requirements and Evaluation 2.4 Sistemas da qualidade: ISO 9001 e ISO 90003 2.4.1 A serie ISO 9000 2.4.2 ISO 9001 2.4.3 ISO 90003 2.5 ISO 12207 - Processos do Ciclo de Vida do Software 2.6 Modelo de qualidade de software: CMMI ( Capability Maturity Model Integration ) 2.6.1 Os cinco níveis de maturidade 2.6.2 ACP – Áreas Chave de Processo (KPA – Key Process Area ) 2.7 Modelo de qualidade de software : SPICE – ISO 15504 2.7.1 Elementos normativos da ISO 15504 2.7.2 Dimensão dos processos da ISO 15504 2.8 Modelo de qualidade de software : MPS.BR 2.8.1 Modelo de maturidade da MPS-BR
2.1 FATORES DE ACOMPANHAMENTO DA QUALIDADE DE SOFTWARE
Os objetivos da qualidade são:
Reunir um conjunto de características, regras e procedimentos de modo que o software satisfaça às necessidades de seus usuários; Levar menos tempo para fazer uma coisa correta, do que explicar o porquê foi feito errado; Garantir a qualidade mesmo depois de estar pronto o produto; Estabelecer cronogramas e custos reais.
Os principais fatores da qualidade do software incluem: Processo de controle da qualidade ; Garantia da qualidade; e Custo da qualidade.
2.1.1 Processo de Controle da Qualidade do software
Figura: Processo de controle da qualidade do software.
2.1.2 GQS – Garantia de Qualidade de Software (SQA – Software Quality Assurance)
O propósito da Garantia de Qualidade de Software é fornecer à gerência a visibilidade da eficácia (aquilo que dá bom resultado):
Examinar minuciosamente um artefato de software ou estado do projeto com a finalidade de determinar se há algum desvio com relação aos padrões, diretrizes, especificações, procedimentos e planos aprovados;
As revisões devem ser aplicadas em vários pontos de função durante o desenvolvimento e servem para descobrir defeitos enquanto estes ainda são relativamente baratos para serem tratados.
2.2 FATORES E MÉTRICAS DA QUALIDADE DO SOFTWARE
Pressman em 2002 descreve que a qualidade de software é uma mistura complexa de fatores que vão variar com cada aplicação diferente e com os clientes que as encomendam.
Os fatores de qualidade do software caracterizam um conjunto de métricas da qualidade. As métricas de qualidade do software são medidas quantitativas que permitem acompanhar a evolução do processo, para se ter a ideia “do quanto o processo é eficaz e/ou eficiente”. Os fatores de qualidade são usados também para detectar áreas de problemas de maneira que soluções possam ser apresentadas e que o processo de software possa ser melhorado.
Os fatores de qualidade do software podem ser divididos em dois grupos:
- Fatores que podem ser medidos diretamente. Exemplo: defeitos por ponto de função.
- Fatores que podem ser medidos indiretamente. Exemplo: usabilidade ou mantenabilidade (ou manutenabilidade).
São coletados dados básicos de produtividade e qualidade pelos engenheiros de software , esses dados são analisados, comparados com médias anteriores e avaliados para verificar se ocorreu melhoria ou não pelos gerentes de software.
Exemplo de análise: Fatores X Métricas da qualidade do software. Fonte: Pressman, 2007.
MÉTRICA DE QUALIDADE FATORES DE QUALIDADE
Confiabilidade Eficiência Mantenabilidade Utilização
Auto Documentação X Complexidade X Concisão X X Consistência X X Eficiência de Execução X X Instrumentação X X Modularidade X X Operabilidade X X Simplicidade X X Tolerância a erro X
2.2.1 Principais métricas de qualidade do software [Fontes: Pressman, 2007; NBR 9126; NBR 12207]
MÉTRICA DEFINIÇÃO
Acurácia Capacidade do produto d necessário, resultados ou efeitos corretos ou conforme acordados.e software de prover, com o grau de precisão
Adaptabilidade
Capacidade do produto de software de ser adaptado para diferentes ambientes especificados, sem necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado.
Adequação Capacidade do produto de para tarefas e objetivos do usuário especificados.^ software^ de prover um conjunto apropriado de funções
Analisabilidade Capacidade causas de falhas no software, ou a identificação de partes a serem modificadas.^ do produto de software de permitir o diagnóstico de deficiências ou
Apreensibilidade (^) Capacidade do produto de software de possibilitar ao usuário aprender sua aplicação.
Atratividade Capacidade do produto de software de ser atraente ao usuário.
Auditabilidade Facilidade no atendimento as normas que pode ser verificado.
Auto documentação Nível em que o código fonte fornece documentação significativa.
Capacidade Capacidade d atender aos requisito produto deos de funcionamento.^ software^ em^ ser instalado em ambiente especificado.e
Coexistência Capacidade do produto de independentes, em um ambiente comum, compartilhando recu^ software^ de coexistir com outros produtos dersos comuns.^ software
Confiabilidade A efetiva realiz precisão especificadasação das funções de um programa um nível de desempenho e.
Conformidade
Capacidade do produto de software de estar de acordo com normas, convenções ou regulamentações previstas em leis e prescrições similares relacionadas ao atributo do software.
Estabilidade Capacidade do produto de software de evitar efeitos inesperados decorrentes de modificações no software.
Eficácia Capacidade do produto de software de permitir que usuários atinjam m especificadas com acurácia e completitude, em um contexto de uso especificado.etas
Eficiência Quantidade de recursos e códigos de computação para realização da função. Quanto menor a quantidade, maior será o desempenho do software.
Expansibilidade Nível em que o projeto arquitetural de dados ou procedimental pode ser estendido.
Flexibilidade (^) Esforço necessário para modificar um programa operacional.
Funcionalidade
Capacidade do produto de software de prover funções que atendam às necessidades explícitas e implícitas, quando o software estiver sendo utilizado sob condições especificadas.
Generalidade Âmbito da aplicação potencial dos componentes do programa.
Integridade Diz respeito ao pode ser controlado.^ acesso^ do^ software^ ou dados por pessoas não autorizadas^ e^ que
Modificabilidade Capacidade do produto de seja implementada.^ software^ de permitir que uma modificação especificada
Interoperabilidade Capacidade do produto de especificados.^ software^ de interagir com um ou mais sistemas
2.3 QUALIDADE DO PRODUTO DA ENGENHARIA DE SOFTWARE: ISO/IEC 9126 E ISO 25000
2.3.1 Objetivo
Esta parte da NBR ISO/IEC 9126 descreve um modelo de qualidade do produto de software, composto de duas partes : a) qualidade interna e qualidade externa e b) qualidade em uso.
2.3.2 Estrutura do modelo de qualidade
Abordagens para qualidade: Figura: Qualidade no ciclo de vida. Fonte: NBR 9126-1.
2.3.3 Modelo de qualidade para qualidade externa e interna
Como mostra a Figura abaixo, o modelo de qualidade externa e interna categoriza os atributos de qualidade de software em seis características, que por sua vez são subdivididas em subcaracterísticas :
Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade e Portabilidade
Figura: Modelo de qualidade para qualidade externa e interna.
Fonte: NBR 9126-1.
2.3.4 Modelo de qualidade para qualidade em uso
Os atributos de qualidade em uso são categorizados em quatro características (ver figura abaixo): Eficácia, Produtividade, Segurança e Satisfação.
Figura: Modelo de qualidade para qualidade em uso.
Fonte: NBR 9126-1.
Enquanto que a ISO 9000 determina os padrões para a gerencia e garantia da qualidade, outras normas especificam a área de aplicação, como é mostrado abaixo:
ISO 9001: Modelo de Garantia de Qualidade em projeto, instalação, desenvolvimento, produção, arquitetura e serviço. ISO 9002: Modelo de Qualidade em produção, ensaios e instalação. ISO 9003: Modelo de Garantia de Qualidade em inspeção e ensaios finais (testes). ISO 9004: Gestão da Qualidade e elementos do sistema da qualidade
2.4.2 ISO 9001
A ISO 9001 é usada para demonstrar capacidade de atender aos requisitos do cliente , os regulamentos da própria organização. Define um conjunto de requisitos para o SGQ – Sistema de Gestão da Qualidade com base nas seguintes cláusulas :
Responsabilidade Gerencial Sistema de Qualidade Análise Crítica de Contratos Controle de Projetos Controle de Dados e Documentos Controle de Produtos fornecidos pelo Cliente Identificação de Produtos e rastreabilidade Controle do Processo Teste e Inspeção Controle de equipamentos de testes, medições e inspeções Situação de testes e inspeções Controle de produto sem conformidade Ação Corretiva e Preventiva Manuseio, armazenamento, empacotamento, proteção e entrega Controle de Registros de Qualidade Auditorias Internas de Qualidade Treinamento Assistência Técnica Técnicas Estatísticas
2.4.3 ISO 90003
A ISO 90003 é uma evolução da norma ISO 9000-3:2000 , que descreve as Diretrizes para à aplicação da ISO 9001. Na ISO 90003:2004 os principais pontos são :
Planejamento da realização do Produto:
Ciclo de Vida - deve conter as etapas de Teste, Verificação, Acompanhamento (análise crítica) e Validação. Plano de Qualidade – Para um projeto específico, Requisitos específicos e Definição das alterações em vigor do SGQ. Requisitos da qualidade (produto e processo).
Processos relacionados ao Cliente:
Determinação dos Requisitos do Produto – Elicitação dos requisitos, Aprovação pelo cliente, Requisitos implícitos, requisitos legais, normativos ou do próprio fornecedor. Análise crítica dos requisitos – Edital, Proposta, Contrato, Capacidade para atender, Orientações específicas do software , padrões,/plataformas/ambientes, ferramentas, ciclo de vida e risco. Comunicação com o cliente – suporte, manutenção e helpdesk.
Projeto de Desenvolvimento:
Planejamento – WBS – Work Breakdown Structure (Estrutura Analítica do Projeto), Cronograma, Etapas, Responsabilidades, Atividades de controle, Interfaces, Recursos e Ambiente. Entradas – elementos necessários para compor a WBS. Saídas – saídas das Fases, Produto final, Código fonte e Objeto, Manuais, Documentação e Relatórios de testes. Análise crítica de projeto – Design review e tomada de decisão. Verificação – simulações, walkthrough, inspeções, demonstrações com protótipo. Validação – atendimento aos requisitos no ambiente de uso pretendido?; teste: unitário, integração, sistema, regressão e aceitação. Alteração de projeto – havendo alterações, deve retornar ao planejamento.
Aquisição:
Aquisição de Insumos (ferramentas e hardware ). Subcontratações ou aquisição de Partes das funções do software****. Inspeção e Recebimento – Verificação, Validação, Aceitação e Testes.
Produção e Fornecimento de serviço:
Controle de produção – Release, Entrega, Instalação, Operação e Manutenção. Identificação e Rastreabilidade – Gestão de configuração. Propriedade do cliente – Componentes, Ferramentas, Ambiente operacional e de Testes, e Propriedade intelectual. Preservação do produto – Armazenamento, Acesso, Proteção contra vírus ou Deterioração.
Medição, Análise e Melhoria.
2.6 MODELO DE QUALIDADE DE SOFTWARE : CMMI - CAPABILITY MATURITY
MODEL INTEGRATION
Originalmente definido na v1.1 em 1993 por Paulk , o Modelo de Maturidade e Capacidade para Software (CMM – Capability Maturity Model for Software ) foi baseado em seis anos de experiência com melhoria de processo de software e a contribuição de centenas de revisores.
O CMMI é o modelo de maturidade sugerido atualmente com o fim de unificar e agrupar as diferentes usabilidades do CMM e de outros modelos de processos de melhoria corporativo, tais como o ISO 9001. São raras as empresas no mundo que conseguem atingir o nível 5, a grande maioria fica nos estágios iniciais. No Brasil, até o ano (2007), existiam somente 4 empresas que tinham alcançado o nível 5 do CMMI.
O CMMI determina práticas recomendadas em um certo número de Áreas Chaves de Processo (KPA – Key Process Area ) , que provê a organização do desenvolvimento de software, baseada nas melhores estratégias para controlar, manter e evoluir os processos administrativos do desenvolvimento de software.
2.6.1 Os cinco níveis de maturidade
Os níveis de maturidade estão baseados em pequenas etapas no lugar de inovações revolucionárias. Estes níveis estão organizados de forma que garantem a melhoria contínua do processo. Cada nível de maturidade constitui em um conjunto de metas que quando satisfeita estabilizam um componente importante do processo.
Os cinco níveis de maturidade do CMMI.
Nível 1 INICIAL
Processo Caótico Ad Hoc
Nível 2 REPETITIVO
Processo Disciplinado Gerência de Projeto
Nível 3 DEFINIDO
Processo Padronizado e Consistente Processo Integrado a Engenharia
Nível 4 GERENCIADO
Processo Previsível Controle Quantitativo
Nível 5 EM OTIMIZAÇÃO
Processo de Melhoria Contínua Estado da Arte
2.6.2 ACP – Áreas Chave de Processo (KPA – Key Process Area )
Gerencial Planejamento de projeto de software e gerência
Organizacional Revisão e controle pela gerencia sênior
Engenharia de software , Especificação, design , codificação e controle de qualidade Nível 1 – Inicial (Processo Caótico - indica a fase de iniciação da implementação dos processos) Nível 2 – Repetitivo (Processo Disciplinado)
Acompanhamento e Controle de Projeto Gerência de Configuração Gerência de Requisitos Gerência de Subcontratação Medição e e Análise Planejamento do Projeto Garantia de Qualidade de Processo e Produto Nível 3 – Definido (Processo Padronizado e Consistente)
Análise de Decisão e Resolução Gerência de software Integrada
Definição do Processo da Organização Foco no Processo da Organização Programa de Treinamento Validação
Desenvolvimento de requisitos Gerenciamento de Risco Integração do produto Solução técnica dos requisitos Verificação Nível 4 – Gerenciado (Processo Previsível)
Gerenciamento Quantitativo de Processos
Desempenho do processo organizacional Nível 5 – Otimização (Melhoria Contínua) Gestão do processo organizacional
Análise e Resolução de Causas
2.7 MODELO DE QUALIDADE DE SOFTWARE : SPICE – ISO 15504
A ISO/IEC 15504 , também conhecida como SPICE – Software Process Improvement & Capability dEtermination (Melhoria do Processo de Software e Determinação da Capacidade) é a norma que define uma série de atividades para manter a qualidade de software , foi publicada em outubro de 2003, mas foi seu projeto começou em 1993 pela ISO com base nos modelos já existentes como ISO 9000 e CMMI. Ela é uma “evolução” da ISO/IEC 12207, que possui níveis de capacidade para cada processo.
O framework inclui um modelo de referência, que serve de base para o processo de avaliação. Um conjunto processos fundamentais que orientam para uma boa engenharia de software , e estabelece duas dimensões:
- Dimensão de processo e a
- Dimensão de capacidade.
2.7.2 Dimensão dos processos da ISO 15504
Dimensão dos processos da ISO 15505 - SPICE
2.8 MODELO DE QUALIDADE DE SOFTWARE : MPS.BR
O MPS-BR (Melhoria do Processo de Software Brasileiro) é uma metodologia voltada à área de desenvolvimento de sistemas e que foi criada por um conjunto de organizações ligadas ao desenvolvimento de software. Dentre as instituições envolvidas pode-se citar: a Softex (SP), a RioSoft (RJ), o COPPE/UFRJ (RJ) e o CESAR (PE). Estas organizações são não governamentais e muitas vezes de origem acadêmica, possuindo uma atuação de destaque junto à comunidade de software brasileira.
Enfatiza-se, dentro do MPS-BR, o uso das principais abordagens internacionais voltadas para a definição, a avaliação e a melhoria dos processos de software. O MPS- BR é compatível com as práticas do CMMI, como mostra a Figura abaixo com uma estrutura de níveis de maturidade, de forma similar àquela existente dentro do CMMI.
2.8.1 Modelo de maturidade da MPS-BR
Modelo MPS.BR definido em 7 níveis e seus relacionamentos com CMMI.
BIBLIOGRAFIA CMMI Product Development Team. CMMI for Systems Engineering/Software Engineering, Version 1.02. Staged Representation. Pittsburgh, U.S.A: Carnegie Mellon, SEI, 2000. CÔRTES, Mario L. Modelos de Qualidade de Software: ISO 15504. São Paulo, IC-UNICAMP. FIORINI, Soeli T.; STAA, Arndt von; BAPTISTA, Renan Martins. Engenharia de Software com CMM. Rio de Janeiro: BRASPORT, 1999. ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 9126-1 – Engenharia de software – Qualidade de produto. Rio de Janeiro: ABNT, Junho de 2003. ABNT – Associação Brasileira de Normas Técnicas. Guia para utilização das normas sobre avaliação de qualidade de produto de software - NBR ISO/IEC 9126 e NBR ISO/IEC
14598. Curitiba: ABNT, Maio de 1999. ABNT – Associação Brasileira de Normas Técnicas. NBR ISO/IEC 12207 – Tecnologia de informação - Processos de ciclo de vida de software. Rio de Janeiro: ABNT, 1998. PAULK, Mark C.; CURTIS, Bill; CHRISSIS, Mary Beth; WEBER, Charles V. The Capability Maturity Model for Software v1.1. Pittsburgh – USA: SEI - Software Engineering Institute Customer Relations , 1993. Artigo. PFLEEGER, Shari Lawrence. Engenharia de Software. – 2 a^ ed. São Paulo: Prentice Hall, 2004. PRESSMAN, Ph.D. Roger S. Engenharia de Software. – 6 a^ ed. Rio de Janeiro: McGraw-Hill, 2007. PRESSMAN, Ph.D. Roger S. Engenharia de Software. – 5 a^ ed. Rio de Janeiro: McGraw-Hill, 2002. MCT. Qualidade e Produtividade no Setor de Software Brasileiro N.4 (2002). Brasília: Ministério da Ciência e Tecnologia / Secretaria de Política de Informática, 2002. SALVIANO, Clenio F. Introdução aos modelos de Processo de Software: ISO/IEC 15504 (SPICE), CMM e CMMI. São Paulo: Simpósio, ITI - Instituto nacional de Tecnologia da Informação, 2001. SOMMERVILLE, Ian. Engenharia de software. São Paulo: Pearson Addison Wesley, 2003.
Relacionamento com CMMI
Nível 5 – Em Otimização
Nível 4 – Gerenciado
Nível 3 – Definido
Nível 2 – Repetitivo
Modelo MPS.BR
