Introdução à Qualidade de Software

Transcrição

1 Universidade Salgado de Oliveira Sistemas da Informação Introdução à Qualidade de Software Por Prof. MSc. Edigar Antônio Diniz Júnior Goiânia Janeiro de

2 Índice UNIDADE 1 - INTRODUÇÃO À QUALIDADE DE SOFTWARE Qualidade no Contexto da Engenharia de Software Conceitos Fundamentais relacionados à Qualidade de Software Organização de Software Métricas Garantia de Qualidade... 6 UNIDADE 2 - QUALIDADE DE PRODUTO DE SOFTWARE MODELO DE QUALIDADE DE PRODUTO DE SOFTWARE Modelo para Características Externas e Internas Modelo para Qualidade em Uso AVALIAÇÃO DE PRODUTOS DE SOFTWARE O Processo Avaliação de Produtos de Software EXEMPLO PRÁTICO DE AVALIAÇÃO DE PRODUTO DE SOFTWARE Etapas para Realização de uma Avaliação AVALIAÇÃO Propósito da Avaliação Identificação do Tipo de Produto Especificação do Modelo de Qualidade - Atributos Métricas para os Atributos Níveis de Pontuação das Métricas - Escala Critérios de Julgamento do Produto de Software Plano Avaliação PACOTES DE SOFTWARE: TESTES E REQUISITOS DE QUALIDADE Requisitos de Qualidade de um Pacote de Software Instruções para Teste de um Pacote de Software UNIDADE 3 - QUALIDADE DOS PROCESSOS DE SOFTWARE PROCESSOS DO CICLO DE VIDA DO SOFTWARE Processos Fundamentais Processos de Apoio Processos Organizacionais Processo de Adaptação Tecnologias Envolvidas Arquitetura do Ciclo de Vida do Software Implementação de Princípios de Gerência de Qualidade ISO APLICADA AO SOFTWARE Uso da ISO FUTURA NORMA ISO/IEC (SPICE) Relatório Técnico ISO/IEC TR Categorias e Processo de Software Níveis de Capacidade Avaliação de Processos de Software UNIDADE 4 - MAPEAMENTO DO MERCADO BRASILEIRO DE SOFTWARE Profissionais do Setor Zero Qualidade dos Produtos de Software Qualidade dos Processos de Software

3 UNIDADE 1 - INTRODUÇÃO À QUALIDADE DE SOFTWARE Nesta unidade será mapeado todos os conceitos básicos que circundam à qualidade de um software. Procura-se aqui dar a noção necessária para que o estudo de normas e modelos como NBR s, CMM, ISO, SPICE possam ser compreendidos e pesquisados. 1.1 Qualidade no Contexto da Engenharia de Software Na literatura são encontradas várias definições para a palavra Qualidade, algumas delas são: Qualidade é a totalidade das características de um produto ou serviço que lhe confere a capacidade de satisfazer as necessidades implícitas ou explícitas [Norma ISO segundo Takashina, 1996]. Qualidade é a conformidade com os requisitos do consumidor. Não basta que o produto ou serviço satisfaça os padrões estatísticos de controle. O consumidor é a única referência válida para assegurar a adequação [Crosby,1991]. Qualidade consiste nas características do produto que vão ao encontro das necessidades dos clientes e dessa forma proporcionam a satisfação em relação ao produto [Juran,1991]. Considerando, Qualidade de Software, pode-se citar as seguintes definições: Qualidade é a totalidade das características de um produto de software que lhe confere a capacidade de satisfazer às necessidades explícitas e implícitas [NBR 13596, 1996]. Qualidade é o grau no qual um sistema, componente ou processo atinge os requisitos especificados [Fiorini, 1998]. É notável que a definição de qualidade para software não se difere muito da definição de qualidade para qualquer produto do mercado em geral. Contudo, em termos práticos, Qualidade em Software é algo muito mais complicado de ser alcançado, isto porque a mesma envolve a gerência e a sinergia de vários fatores. Considerando uma definição mais precisa e completa de Qualidade de Software pode-se perceber isto. [Norma NBR ISO/IEC 9126] Qualidade de Software é definida em função de seis características: funcionalidade, confiabilidade, usabilidade, eficiência, manutenibilidade e portabilidade. Cada uma dessas características pode ser definida em funções de sub-características conforme tabela a seguir: 3

4 Características Sub- Características Funcionalidade Confiabilidade Usabilidade Eficiência Adequação Acurácia Interoperabilidade Conformidade Segurança Acesso Maturidade Tolerância Falhas Recuperabilidade Inteligibilidade Apreensibilidade de Operacionalidade a Descrição Presença de conjunto de funções e sua apropriação para as tarefas. Geração de resultados ou efeitos corretos Capacidade de interagir com outros sistemas Capacidade de estar de acordo com normas, convenções e regulamentações Capacidade de evitar acesso não autorizado a programas e dados Freqüência de falhas Manutenção do nível de desempenho em caso de falha. Capacidade de se restabelecer a restaurar Facilidade de entendimento dos conceitos utilizados Facilidade de aprendizado Facilidade de operar e controlar a operação Comportamento Tempo de respota, de em relação ao processamento tempo Comportamento em relação a recursos Analisabilidade Manutenibilidade Modificabilidade Portabilidade Estabilidade Testabilidade Adaptabilidade Quantidade de recursos utilizados Facilidade de diagnosticar deficiências e causas de falhas Facilidade de modificação e remoção de defeitos Ausência de riscos de defeitos inesperados Facilidade de ser testado Capacidade de ser adaptado a ambientes diferentes 4

5 Capacidade ser instalado Conformidade Capacidade substituir de Facilidade de instalação para Acordo com padrões ou convenções de portabilidade Capacidade para substituição de outro software (aproveitamento de dados e informações) Exercício 1 - Para cada sub-item destacado na tabela, cite uma tecnologia (ferramenta, modelo, etc) que você utilizaria na prática do desenvolvimento de um software com o intuito de alcançar qualidade no mesmo. 1.2 Conceitos Fundamentais relacionados à Qualidade de Software Organização de Software Este é um termo bastante utilizado no Capability Maturity Model - CMM [SEI] e no SPIG - Software Improvement Guidebook [NASA,1996], porém sem uma conceituação precisa. No Brasil costuma-se utilizar tal expressão para significar o setor (área, serviço, departamento, empresa) responsável pela produção de software, seja para uso de uma empresa específica ou para venda no mercado Métricas Métrica é um método de determinar, quantitativamente, a extensão em que o projeto, o processo e o produto de software tem certos atributos [Fernandes, 1995]. São partes integrantes de uma métrica: a fórmula para determinar o valor da métrica, a forma de apresentação dos resultados e as diretrizes de utilização e interpretação dos resultados obtidos no contexto do ambiente de desenvolvimento de software. Métricas em software podem ser classificadas em três categorias: métricas do produto, métricas do processo e métricas de projeto [Humphrey,1989]. Métricas de produto são aquelas que descrevem as características do produto tais como tamanho, complexidade, desempenho e nível de qualidade. Exemplo: Quanto tempo será consumido para desenvolver o relatório X? Métricas de processo são aquelas que podem ser usadas para melhorar o processo de desenvolvimento e manutenção de software. Exemplo: Qual a eficiência no momento de remover defeitos durante o desenvolvimento? Métricas de projeto são aquelas que descrevem as características e execução de projeto. Exemplo: Número de desenvolvedores de software necessários? Quais devem ser os padrões para alocação de pessoal? Qual a programação das tarefas? 5

6 1.2.3 Garantia de Qualidade De acordo com Juran (1974) garantida de qualidade (Quality Assurance) é a atividade de prover, para todos os interessados, as evidências para estabelecer confiança de que a questão qualidade está sendo tratada adequadamente. A garantia de qualidade fornece aos gerentes visibilidade do processo em uso e dos produtos em construção. Isto proporciona aos gerentes em geral uma maior confiança nas informações relativas aos projetos. Garantida de Qualidade de Software - GQS: é a aplicação dos conceitos de garantia de qualidade à produção de software. GQS visa fornecer à gerência visibilidade do processo que está sendo utilizado pelo projeto de desenvolvimento de software e da qualidade dos artefatos que estão sendo criados. Na maioria das organizações a GQS só é obtida através de testes de programas. Esta visão acarreta os seguintes problemas: Em geral quem desenvolve o programa é quem testa - Sabe-se, a muito tempo, que as pessoas são ineficientes em encontrar seus próprios erros. Testes em programas só podem ser realizados efetivamente depois que o mesmo estiver pronto - A onde prejuízos já foram acumulados. Testes em programas avaliam somente a qualidade do produto - Deixa-se de considerar o processo pelo qual o produto foi desenvolvido. A GQS deve se preocupar com as seguintes questões [Yourdon, 1995]: Minimizar o número de defeitos no software entregue; Criar meios para controlar o desenvolvimento e a manutenção de software de forma que os prazos e os custos não sejam prejudicados; Certificar-se de que o produto possa ser utilizado no mercado visado e Melhorar a qualidade de futuras versões e futuros produtos. Segundo [Pressman, 1995] a GQS abrange métodos, ferramentas, revisões formais, estratégia de testes, controle de documentação de software e de mudanças, procedimentos para garantir a adequação aos padrões e mecanismos de medição e divulgação. UNIDADE 2 - QUALIDADE DE PRODUTO DE SOFTWARE Nesta unidade são apresentados todos os conceitos e normas relacionados à qualidade do produto de software. Por conseguinte esta unidade estará apresentando principalmente as normas brasileiras - NBR s derivadas das normas ISO para produto de software. A seguir, são apresentados: o modelo de qualidade de produtos de software; as métricas segundo a série de normas internacionais ISO/IEC 9126; o processo de avaliação de qualidade de produtos de software em conformidade com a série de normas internacionais ISO/IEC 14598; os requisitos de qualidade; e as instruções para testar software tipo pacote de acordo com a norma brasileira NBR ISO/IEC

7 O Comitê Técnico Conjunto da ISO/IEC vem trabalhando na elaboração de normas que permitam especificar e avaliar a qualidade dos produtos de software, a saber: Qualidade de Produto de Software o ISO/IEC : Modelo de Qualidade o ISO/IEC : Métricas Externas - Apoio para definição dos atributos de qualidade o ISO/IEC : Métricas Internas - Apoio para definição dos atributos de qualidade o ISO/IEC : Métricas de Qualidade em Uso Avaliação de Produtos de Software o ISO/IEC : Visão Geral o ISO/IEC : Planejamento e Gestão o ISO/IEC : Processo de Desenvolvedores o ISO/IEC : Processo para Adquirentes o ISO/IEC : Processo para Avaliadores o ISO/IEC : Documentação de Módulos de Avaliação Teste e Requisitos de Qualidade em Pacotes de Software o NRB ISO/IEC 12119: Pacotes de Software - Teste e requisitos de qualidade O relacionamento entre as normas das séries 9126 e deixa claro a abrangência da Norma ISO/IEC sobre todo o processo de avaliação, bem como a necessidade do uso da Norma ISO/IEC como referência na aplicação de métricas. 2.1 MODELO DE QUALIDADE DE PRODUTO DE SOFTWARE O modelo da qualidade definido na ISO/IEC , utilizada como referência para o processo de avaliação da qualidade de produto de software, está subdividida em duas partes: modelo para características externas e internas; e modelo para qualidade em uso Modelo para Características Externas e Internas Este modelo classifica os atributos de qualidade dos produtos de software em seis características (funcionalidade, confiabilidade, usabilidade, eficiência, 7

8 manutenibilidade e portabilidade). Estas características, por sua vez, são desdobradas em sub-características. As sub-características podem ser desdobradas em mais níveis, que caracterizam os atributos da qualidade. As métricas internas e externas aplicam-se, em geral, ao nível dos atributos da qualidade, ou seja, em um nível de detalhamento bem maior. A ISO/IEC conduz a um entendimento dos conceitos que definem as diversas características e sub-características da qualidade de produto de software; porém, na prática, ainda não facilita o suficiente a definição dos requisitos de qualidade a partir dela. As definições de características de qualidade permitem perceber um possível universo de requisitos que se enquadram no conceito apresentado, mas dificilmente permitiriam elaborar uma declaração de requisitos mais criteriosa, quanto às mesmas. Não faz sentido, por exemplo, uma declaração do tipo "o produto de software deve ter uma usabilidade de 0,5", pois esse número não teria qualquer significado (pelo menos no estado-da-arte em que se encontra o tema de medição da qualidade de produto de software). O primeiro desdobramento em sub-características serve para delimitar melhor o amplo universo contemplado pela característica. Introduz conceitos mais detalhados que facilitam a especificação de requisitos, ajudando a pensar na característica da qualidade a partir de seus componentes. Mas este desdobramento ainda não é suficiente para especificar os requisitos da qualidade. Uma declaração do tipo "A operacionalidade deve ser igual a 0,8", por exemplo, continua sem fazer sentido. Assim, o usuário da norma que necessite elaborar sua declaração de requisitos deve fazer o próximo nível de desdobramento, os atributos (que não estão presentes na ISO/IEC ), identificando aspectos relevantes ao produto de software e que se enquadrem nas características e sub-características citadas. Desta forma, uma declaração do tipo "O tempo de uso do produto de software até que se tenha domínio operacional do mesmo deverá ser inferior a 20 horas", por exemplo, é adequada como requisito da sub-característica operacionabilidade, que faz parte da característica usabilidade. Observe que foi necessário descer ao nível do atributo "tempo para se ter domínio operacional" para que o requisito pudesse ser declarado de forma objetiva e não ambígua. O documento ISO/IEC define exemplos de métricas externas que se associam a atributos de qualidade e que podem ser uma referência inicial, facilitando a tarefa de definir atributos. Visão Externa O modelo de qualidade da ISO/IEC privilegia a visão do usuário do produto de software que, em geral, atua a partir da operação do sistema do qual o produto de software faz parte. Esta é a visão de qualidade externa. Os usuários estão interessados principalmente no uso do software, no seu desempenho e nos efeitos do uso do software. Os usuários avaliam o software sem conhecer os seus aspectos internos ou como ele foi desenvolvido. As questões do usuário podem incluir: As funções requeridas estão disponíveis no software? Quão confiável é o software? Quão eficiente é o software? O software é fácil de usar? 8

9 Quão fácil é transferir o software para outro ambiente? Visão Interna - Equipe de Desenvolvimento Porém, o efeito externo percebido no uso do produto de software é decorrente de seus atributos internos, típicos de sua arquitetura, tais como o nível de modularização dos programas, a documentação gerada, o tipo de diálogo utilizado na interação com o usuário, entre outros. Esses atributos internos mantêm correlações com as características e subcaracterísticas externas do produto de software. Cada atributo interno pode influenciar uma ou mais características externas do produto de software. Cada atributo interno pode influenciar uma ou mais características e subcaracterísticas, sendo que a identificação das correlações existentes não é um trabalho simples, depende de cada organização que desenvolve software. Apesar disso, se a organização fizer este investimento, terá mais condições de garantir a qualidade de seus produtos pois será capaz de especificá-los e avaliá-los (através das característcas, subcaracterísticas e atributos externos) cada vez com mais precisão. Ou seja, esta visão do desenvolvedor, que envolve várias questões técnicas, constitui-se a visão interna. Visão de Gerente - Que também é parte constituinte da Visão Interna Existe ainda, o ponto de vista do gerente que provavelmente estará mais interessado na qualidade de forma geral do que em características (técnicas) específicas de qualidade e, por essa razão, ele necessitará atribuir pesos, refletindo os requisitos comerciais, para as características individuais. O gerente também pode ter que balancear os melhoramentos na qualidade com critérios gerenciais, tais como atraso de cronograma ou estouro de orçamento, porque ele deseja otimizar a qualidade dentro dos limites de custo, recursos humanos e prazos Detalhamento do Modelo para Características Externas e Internas - Características e Subcaracterísticas A. Funcionalidade - Conjunto de atributos que evidenciam a existência de um conjunto de funções e suas propriedades especificadas. As funções são as que satisfazem as necessidades explícitas ou implícitas. NOTAS: - Este conjunto de atributos caracteriza o que o software faz para satisfazer as necessidades, enquanto que os outros conjuntos caracterizam principalmente quando e como ele faz. - Em ambientes computacionais, as necessidades são especificadas, enquanto que em outros ambientes as necessidades implícitas devem ser identificadas e definidas. Adequação - Atributos do software que evidenciam a presença de um conjunto de funções e sua apropriação para as tarefas especificadas. Pergunta Chave: "Propõe-se a fazer o que é apropriado?". Acurácia - Atributos do software que evidenciam a geração de resultados ou efeitos corretos ou conforme acordados (por exemplo, um dos atributos pode ser o grau de precisão estabelecido para valores calculados). Pergunta Chave: "Faz o que foi proposto de forma correta?". Interoperabilidade - Atributos do software que evidenciam sua capacidade de interagir com sistemas especificados. Pergunta Chave: "Interage com os sistemas especificados?". Conformidade - Atributos do software que fazem com que ele esteja de acordo com as normas, convenções ou regulamentações previstas em leis e descrições similares, relacionadas à aplicação. Pergunta Chave: "Está de acordo com as normas, convenções e regulamentações?". 9

10 Segurança de Acesso - Atributos do software que evidenciam sua capacidade de evitar o acesso não autorizado, acidental ou deliberado, a programas e dados. Pergunta Chave: "Evita acesso não autorizado a programas e dados?". B. Confiabilidade - Conjunto de atributos que evidenciam a capacidade do software de manter seu nível de desempenho sob condições estabelecidas durante um período de tempo estabelecido. NOTA: Em software não ocorre desgate ou envelhecimento. As limitações em confiabilidade são decorrentes de defeitos na especificação dos requisitos, projeto ou implementação. As falhas decorrentes desses defeitos dependem de como o produto de software é usado e das opções de programa selecionadas, e não do tempo decorrido. Maturidade - Atributos do software que evidenciam a freqüência de falhas por defeitos no software. Pergunta Chave: "Com que freqüência apresenta falhas?". Tolerância a falhas - Atributos do software que evidenciam sua capacidade em manter um nível de desempenho especificado nos casos de falhas no software ou de violação nas interfaces especificadas. Na especificação no nível de desempenho, deverá estar incluida a capacidade de suportar falhas sem comprometer a segurança. Pergunta Chave: "Ocorrendo falhas, como ele reage?". Recuperabilidade - Atributos do software que evidenciam sua capacidade de restabelecer seu nível de desempenho e recuperar os dados diretamente afetados, em caso de falha, e no tempo e esforço necessário para tal. Pergunta Chave: "É capaz de recuperar dados após as falhas?". C. Usabilidade - Conjunto de atributos que evidenciam o esforço necessário para se poder utilizar o software, bem como o julgamento individual desse uso, por um conjunto explícito ou implícito de usuários. NOTA: Como "Usuários" podem ser incluídos operadores, usuário final e usuários indiretos, que estão sob a influência ou dependência do uso do software. Inteligibilidade - Atributos do software que evidenciam o esforço do usuário para reconhecer o conceito lógico e sua aplicabilidade. Pergunta Chave: "É fácil entender os conceitos?". Apreensibilidade - Atributos do software que evidenciam o esforço do usuário para aprender sua aplicação (por exemplo: controle de operação, entradas, saídas). Pergunta Chave: "É fácil aprender a usar?". Operacionalidade - Atributos do software que evidenciam o esforço do usuário para sua operação e controle da sua operação. Pergunta Chave: "É fácil operar e controlar?". D. Eficiência - Conjunto de atributos que evidenciam o relacionamento entre o nível de desempenho do software e a qualidade de recursos usados, sob condições estabelecidas. NOTA: Os recursos podem incluir outros produtos de software, hardware, materiais e serviços de operação, manutenção ou suporte. Comportamento em relação ao tempo - Atributos do software que evidenciam seu tempo de resposta, tempo de processamento e velocidade 10

11 na execução de suas funções. Pergunta Chave: "Qual é o tempo de resposta e processamento?". Comportamento em relação aos recursos - Atributos do software que evidenciam a quantidade de recursos usados e a duração de seu uso na execução de suas funções. Pergunta Chave: "Quanto recurso utiliza?". E. Manutenibilidade - Conjunto de atributos que evidenciem o esforço necessário para fazer modificações especificadas no software. NOTA: As modificações podem incluir correções, melhorias ou adaptações do software, devido a mudanças no ambiente ou nos seus requisitos. Analisabilidade - Atributos do software que evidenciam o esforço necessário para diagnosticar deficiências ou causas de falhas, ou para identificar partes a serem modificadas. Pergunta Chave: "É fácil encontrar uma falha quando esta ocorre?". Modificabilidade - Atributos do software que evidenciam o esforço necessário para modificá-lo, ou para remover seus defeitos ou para adaptá-lo a mudanças ambientais. Pergunta Chave: "É fácil modificar e remover defeitos?". Estabilidade - Atributos do software que evidenciem o risco de efeitos inesperados, ocasionados por modificações. Pergunta Chave: "A grande risco quando se faz alterações?". Testabilidade - Atributos do software que evidenciam o esforço necessário para validar o software modificado. Pergunta Chave: "É fácil testar quando se faz alterações?". F. Portabilidade - Conjunto de atributos que evidenciam a capacidade do software de ser transferido de um ambiente para o outro. NOTA: O ambiente pode incluir ambiente organizacional, de hardware ou de software. Adaptabilidade - Atributos do software que evidenciam sua capacidade de ser adpatado a ambientes diferentes especificados, sem a necessidade de aplicação de outras ações ou meios além daqueles fornecidos para essa finalidade pelo software considerado. Pergunta Chave: "É fácil adaptar a outros ambientes?". Capacidade para ser instalado - Atributos do software que evidenciam o esforço necessário para sua instalação em um ambiente especificado. Pergunta Chave: "É fácil de ser instalado em outros ambientes?". Conformidade - Atributos do software que o tornam consonante com padrões ou convenções relacionadas à portabilidade. Pergunta Chave: "Está de acordo com padrões ou convenções de portabilidade". Capacidade para substituir - Atributos do software que evidenciam sua capacidade e esforço necessário para substituir um outro software, no ambiente estabelecido para este software. Pergunta Chave: "É fácil substituir um outro software?" Diretrizes para o Uso das Características de Qualidade Esta norma é aplicável na definição dos requisitos de qualidade de software e na avaliação (medição, pontuação e julgamento) de produtos de software, incluindo: definição de requisitos de qualidade de um produto de software; 11

12 avaliação de especificação de software para verificar se ele irá satisfazer aos requisitos de qualidade durante o desenvolvimento; descrição de particularidades e atributos do software implementado (por exemplo: em manuais de usuário); avaliação de software desenvolvido antes da entrega; avaliação de software antes da aceitação. Atualmente existem poucas métricas de aceitação geral para as características descritas nesta Norma. Cada organização de normalização pode estabelecer seus próprios modelos de processos de avaliação e métodos para a criação e validação de métricas relacionadas com estas características, para cobrir as diversas áreas de aplicação e estágios do ciclo de vida. Nos casos em que não houver e não puderem ser desenvolvidas métricas apropriadas, algumas vezes podem ser usadas descrições verbais ou regras empíricas. Assim, tem-se que para se utilizar as características descritas nesta norma com propósito de definição e avaliação, é necessário estabelecer níveis de pontuação e critérios específicos para a organização ou para a aplicação, ou para ambas. No momento de se definir os critérios de avaliação da qualidade do produto de software, deve-se sempre considerar as características específicas do mesmo, isto porque, eficiência em software de tempo-real é muito mais importante a nível de avaliação de qualidade do que para um software comercial por exemplo Modelo para Qualidade em Uso Os atributos da qualidade em uso são classificados em quatro características: efetividade, produtividade, segurança e satisfação. A qualidade em uso é "a capacidade do produto de software de permitir à usuários específicos atingir metas especificadas com efetividade, produtividade, segurança e satisfação em um contexto de uso especificado". Ou seja, este modelo em conjunto com suas métricas associadas permitem avaliar o efeito causado pelo uso do produto de software dentro da organização. As métricas aqui irão refletir se o software contribuiu com a organização, isto em conformidade com que havia sido especificado. Efetividade: Refere-se à capacidade do produto de software em possibilitar aos usuários atingir metas especificadas com acurácia e completeza, num contexto de uso especificado. Produtividade: Refere-se à capacidade do produto de software em possibilitar aos usuários utilizar uma quantidade adequada de recursos em relação à efetividade alcançada, num contexto de uso especificado. Segurança: Refere-se à capacidade do produto de software em propriciar níveis aceitáveis de risco de danos a pessoas, negócios, software, propriedade ou ambiente, num contexto de uso especificado. Satisfação: Refere-se à capacidade do produto de software em satisfazer usuários, num contexto de uso especificado. A visão do modelo de qualidade levando em conta os resultados obtidos a partir do uso do software no ambiente especificado é uma inovação em relação ao modelo original da ISO/IEC 9126:1991. Esta visão pode ser usada como referência para a definição de requisitos da qualidade esperados para o ambiente de uso, assim como para a avaliação dos resultados obtidos. Quando o modelo de qualidade de uso for utilizado para a definição de requisitos, é necessário o estabelecimento das regras de derivação de atributos de características externas para o produto de software a partir das características da qualidade em uso. 12

13 2.2 AVALIAÇÃO DE PRODUTOS DE SOFTWARE O processo de avaliação de produtos de software está definido na série de normas ISO/IEC 14598, que deve ser utilizada em conjunto com a série ISO/IEC Basicamente a norma ISO/IEC tem seu foco nas métricas e no processo de aplicação destas sobre os atributos (características e subcaracterísticas) de qualidade definidos na ISO/IEC Assim uma define, de forma geral, o que deve ser medido e a outra como este processo de medida deve ser realizado. ISO/IEC : Visão Geral - Esta norma apresenta toda a estrutura de funcionamento da série de normas para avaliação da qualidade dos produtos de software, além de definir os termos técnicos utilizados nesse modelo. Fornece também os conceitos e o funcionamento do processo de avaliação da qualidade de qualquer tipo de software, para utilização por desenvolvedores, por adquirentes e por avaliadores de software independente. ISO/IEC : Planejamento e Gestão - Esta norma apresenta requisitos, recomendações e orientações para uma função de suporte ao processo de avaliação dos produtos de software. O suporte está relacionado ao planejamento e gerenciamento de um processo de avaliação de software e a tecnologia necessária dentro deste processo. ISO/IEC : Processo para Desenvolvedores - Esta norma destinase ao uso durante o processo de desenvolvimento e manutenção de software, enfocando a seleção e registro de indicadores que possam ser medidos e avaliados a partir dos produtos intermediários, obtidos nas fases de desenvolvimento de sistema, com o objetivo de prever a qualidade do produto final a ser desenvolvido. ISO/IEC : Processo para Adquirentes - Esta norma estabelece um processo sistemático para avaliação de: produtos de software tipo pacote (com equivalência à NBR ISO/IEC 12119), produtos de software sob encomenda, ou ainda modificações em produtos já existentes. O propósito da avaliação pode ser a comparação entre diversas alternativas de produtos existentes no mercado, ou a tentativa de garantir que um produto desenvolvido ou modificado sobre encomenda atenda aos requisitos inicialmente especificados. ISO/IEC : Processo para Avaliadores - Esta norma fornece orientações para a implementação prática de avaliação de produtos de software, quando diversas partes necessitam entender, aceitar e confiar em resultados de avaliação. O processo descrito define as atividades necessárias para analisar os requisitos de avaliação de modo a especificar, projetar e executar as atividades de avaliação e para se obter a conclusão sobre avaliação de qualquer tipo de produto de software. ISO/IEC : Documentação de Módulos de Avaliação - Esta norma define a estrutura e o conteúdo da documentação a ser usada da descrição dos Módulos de Avaliação. Explica como desenvolver módulos de avaliação e avaliá-los O Processo Avaliação de Produtos de Software ISO/IEC As etapas do processo de avaliação de produtos de software são descritas a seguir, isto de acordo com a norma ISO/IEC 14598: 13

14 Estabelecer Requisitos de Avaliação - Etapa composta pelas atividades: o Estabelecer o propósito da avaliação: defini-se sobre qual ótica será feita a avaliação: do ponto de vista do adquirente, do desenvolvedor ou de um avaliador. o Estabelecer o tipo de produto a ser avaliado: são produtos intermediários ou são produtos finais (antes da aceitação ou depois). o Especificar o modelo de qualidade: o modelo de qualidade (ISO/IEC 9126) serve como referência para a definição dos requisitos de qualidade para o produto de software. Neste estágio da avaliação, os requisitos são descritos para as características de qualidade mais relevantes, sendo priorizados de acordo com as necessidades dos usuários. Especificar a Avaliação - Estapa composta pelas atividades: o Selecionar Métricas - A especificação e medição quantitativa dos requisitos de qualidade do produto de software só podem ser feitas pelo uso de métricas associadas às características de qualidade esperadas. Métricas podem ser: (i) internas, associadas a arquitetura do produto de software e que permitem prever a qualidade do produto final; (ii) externas, mensuráveis quando o produto está em operação; e (iii) de qualidade de uso, que avaliam o efeito do uso do produto de software. o Estabelecer Níveis de Pontuação para as Métricas - Para cada métrica selecionada devem ser definidos os níveis de pontuação e a escala relacionada, onde poderá ser representado o nível requirido para o atributo a ser medido. o Estabelecer Critérios para Julgamento - Para julgar a qualidade do produto, convém que o avaliador prepare um procedimento para este fim, com critérios específicos para as diferentes características de qualidade, seja em termos de cada subcaracterísticas, ou através de uma combinação ponderada de subcaracterísticas. Basicamente é determinar qual subcaracterística tem maior peso (maior importância) no momento de avaliar a qualidade do produto. Projetar a Avaliação - Esta etapa define as atividades do plano de avaliação, descrevendo os métodos de avaliação e o cronograma de atividades do avaliador. Executar a Avaliação - Esta etapa é composta pelas atividades: o Obter as Medidas - As métricas selecionadas são aplicadas ao produto de software, resultando em valores nas escalas das métricas. o Comparar com Critérios - Os valores medidos então são comparados aos critérios estabelecidos na especificação da avaliação. 14

15 o Julgar os Resultados - É realizado um julgamento, um conjunto de valores pontuados é sintetizado e é feita uma declaração sobre quanto o produto de software atende aos requisitos de qualidade. Esta síntese é também comparada com outros aspectos como prazo e custo. Finalmente, através de critérios gerenciais, pode ser tomada uma decisão quanto à aceitação ou rejeição do produto de software, ou quanto à sua liberação ou não para uso. Os resultados da avaliação influenciam os próximos passos do ciclo de desenvolvimento do software, através de decisões como "convém que os requisitos sejam modificados, ou são necessários mais recursos para o processo de desenvolvimento?" ISO/IEC A própria norma ISO/IEC (NBR 13596) já apresenta o Modelo do Processo de Avaliação da forma como apresentado na figura a seguir: Esta figura apresenta os principais passos requiridos para a avaliação da qualidade de um produto de software, começando com as características de qualidade definidas nesta na própria norma. O processo é constituído de três estágios: Definição dos Requisitos de Qualidade, Preparação da Avaliação e Procedimento de Avaliação. Basicamente o modelo apresentado aqui é o mesmo descrito na norma ISO/IEC 14598, contudo o processo aqui é apresentado de forma mais abstrata, ocultando assim algumas atividades mais detalhadas. As particularidades (features) quantificáveis são medidas quantitativamente usando-se métricas de qualidade. O resultado, isto é, o valor medido, é mapeado em uma escala. Este valor sozinho não mostra o nível de satisfação, para isto as escalas são divididas em faixas correspondentes aos diversos graus de satisfação, como demonstrado a abaixo. 15

16 Exemplificando a avaliação de um atributo com relação a qualidade Considerando o atributo: O Tempo de uso do produto de software até que se tenha domínio operacional do mesmo deverá ser inferior a 20 horas pode-se ter: o A métrica selecionada é a seguinte: O percentual de módulos do produto de software que atendem o requisito, dividido por 10. o O nível de pontuação é definido de 0 a 10. o Critérios de julgamento são: - Intervalo fechado de 0 à 7 software não aceito. - Intervalo superior a 7 software aceito. 2.3 EXEMPLO PRÁTICO DE AVALIAÇÃO DE PRODUTO DE SOFTWARE Nesta seção são apresentadas todas as atividades relativas a avaliação de um produto de software. Esta avaliação está de acordo com as normas: ISO/IEC (NBR ISO/IEC Modelo de qualidade de produto de software), ISO/IEC (Métricas Internas) e ISO/IEC Nesta avaliação esta sendo considerada somenete a característica Manutenibilidade e suas sub-características. Esta é uma característica interna, logo não reflete uma visão que o usuário possui do produto de software mais sim uma visão do desenvolvedor Etapas para Realização de uma Avaliação Propósito da Avaliação Identificação do Tipo de Produto Especificação do Modelo de Qualidade - Atributos Métricas para os Atributos Níveis de Pontuação das Métricas Critérios de Julgamento Plano de Avaliação Obtenção das Medidas Comparação com Critérios Julgamento do Resultado 16

17 2.4 AVALIAÇÃO Propósito da Avaliação Esta avaliação visa determinar se um produto de software desenvolvido internamente na organização X é aceitável do ponto de vista do desenvolver, não do ponto de vista do usuário. A questão fundamental a ser avaliada é se o programa em questão está internamente bem organizado e bem projetado, contribuindo assim, para uma fácil manutenção do mesmo Identificação do Tipo de Produto O item a ser avaliado é um programa desenvolvido em Pascal para um problema interno do INSS - Instituto Nacional de Seguridade Social. O mesmo não se constitui um pacote de software. O programa tem com objetivo obter como entrada um conjunto de períodos de constribuição de uma pessoa ao INSS e a partir destes períodos calcular o número de dias de contribuição total da mesma. O programa em questão pode ser obtido através do link INSS.pas. Programa: INSS.pas Departamento Responsável: Dpto Desenvolvimento e Tecnologia Desenvolvido por: Franscisco A. S. Grossi - Programador Data: 15/08/2002 Versão: Especificação do Modelo de Qualidade - Atributos Modelo de Qualidade descrito a seguir está em conformidade com as normas: ISO/IEC (NBR ISO/IEC Modelo de qualidade de produto de software), ISO/IEC (Métricas Internas). Contudo este modelo é utilizado parcialmente, tendo como norte a questão da manutenibilidade. Com isso faz-se uso somente da característica Manutenibilidade e suas sub-características: Manutenibilidade o 1 - Analisabilidade (É fácil encontrar uma falha quando está ocorre?) Deve existir um projeto de arquitetura (diagrama de estrutura) que viabilize uma visão sistémica dos módulos do programa O nome de cada módulo deve ser definido com clareza e completude (no formato verbo no infinito + objeto da ação) Cada módulo deve possuir um controle de exceções com uma mensagem acoplada que identifica o tipo de erro, uma descrição do erro, o nome do módulo onde ocorreu o erro e os dados envolvidos na operação que gerou o erro Cada módulo deve realizar uma única atividade dentro de seu contexto - coesão funcional Cada módulo deve possuir no máximo 50 linhas de código cada. o 2 - Modificabilidade (É fácil modificar e remover defeitos?) 17

18 o o Módulos com coesão não funcional (fazem mais de uma atividade) não devem compartilhar código entre essas atividades Deve existir uma documentação breve para cada módulo afim de explicar seu objetivo e funcionamento Reaplicável Reaplicável Reaplicável. 3 - Estabilidade (A grandes riscos quando se faz alterações?) O acoplamento entre os módulos deve ser fraco para que erros em cascata não ocorram Não deve ser feito uso de várias globais (menos em casos onde o dado global é uma estrutura de dados que vem para substituir um arquivo ou tabela de dados) Reaplicável. 4 - Testabilidade (É fácil testar quando se faz alterações?) Reaplicável Reaplicável Reaplicável Reaplicável Métricas para os Atributos A seguir é listado cada um dos atributos seguido pela métrica adequada ao mesmo: Requisito Deve existir um projeto de arquitetura (diagrama de estrutura) que viabilize uma visão sistémica dos módulos do programa. Métrica Valor Situação Medido Existe um diagrama de estrutura completo 10 (módulos, acoplamento) e documentações. Existe um diagrama de estrutura completo 8 (módulos,acoplamento). Existe um diagrama de estrutura incompleto 5 (módulos). Existe um diagrama de estrutura parcialmente 3 atualizado. Não existe um diagrama de estrutura. 0 Requisito O nome de cada módulo deve ser definido com clareza e completude (no formato verbo no infinito + objeto da ação). Metrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito Cada módulo deve possuir um controle de exceções com uma mensagem acoplada que identifica o tipo de erro, uma descrição do erro, o nome do módulo onde ocorreu o erro e os dados envolvidos na operação que gerou o erro. Métrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito Cada módulo deve realizar uma única atividade dentro de seu contexto - coesão funcional. 18

19 Métrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito Cada módulo deve possuir no máximo 50 linhas de código cada. Métrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito Módulos com coesão não funcional (fazem mais de uma atividade) não devem compartilhar código entre essas atividades. Métrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito Deve existir uma documentação breve para cada módulo afim de explicar seu objetivo e funcionamento. Métrica: Percentual de Módulos que atendem o requisito dividido por 10. Requisito O acoplamento entre os módulos deve ser fraco para que erros em cascata não ocorram. Métrica: Percentual de Interface entre Módulos com Acomplamento Bom (Fraco) dividido por 10. Requisito Não deve ser feito uso de várias globais (menos em casos onde o dado global é uma estrutura de dados que vem para substituir um arquivo ou tabela de dados). Métrica Valor Situação Medido Nenhuma variável global é utilizada 10 São utilizadas variavéis globais de forma limitada (até 3 variáveis para cada 500 linhas de código). 6 É feito uso de várias variáveis globais de forma 0 errôner Níveis de Pontuação das Métricas - Escala A escala apresentada abaixo é a mesma para todos os atributos, por conseguinte, a mesma pode ser utilizada para aferir a qualidade e a aceitabilidade de cada um dos atributos de forma independente um do outro. Escala de Avaliação de Valor Medido Intervalos de Classificação Julgamento Valores 9-10 Ótimo Aceitável 7-8,9 Bom 5-6,9 Regular Não 3-4,9 Ruim Aceitável 0-2,9 Péssimo 19

20 2.4.6 Critérios de Julgamento do Produto de Software A média ponderada calculada na forma da expressão matemática listada abaixo, deve determinar o Valor Final da Avaliação (VFA) de qualidade do produto de software. A aceitação ou não do produto de software deve ser determinada avaliando a posição do VFA na escala definida no item (ou seja, aqui está-se usando a mesma escala definida para cada atributo também para o produto de software). VFA = (P1 * A1) + (P2 * A2) (Pn * An) / (P1 + P Pn) Considerações: Ax - refere-se ao valor medido para o atributo de número x. Px - refere-se ao peso que deve ser dado ao atributo de número x. Este peso é determinado pelo número de citações do atributo no "Modelo de Qualidade - Atributos" definido no item Por exemplo, o atributo (requisito) 1.1 foi citado no modelo por três vezes, logo seu peso é três Plano Avaliação Devem ser estabelecidas três equipes, onde cada equipe deverá ser responsável pelas tarefas de avaliação conforma esquema abaixo. Cada equipe deverá apresentar o valor medido para cada um dos requisitos e uma breve descrição apontando o nível de qualidade que o atributo (requisito) em questão possui. Equipe 1 - Avaliação de Características Gerais o Requisito Deve existir um projeto de arquitetura (diagrama de estrutura) que viabilize uma visão sistémica dos módulos do programa. o Requisito O nome de cada módulo deve ser definido com clareza e completude (no formato verbo no infinito + objeto da ação). o Requisito Cada módulo deve possuir um controle de exceções com uma mensagem acoplada que identifica o tipo de erro, uma descrição do erro, o nome do módulo onde ocorreu o erro e os dados envolvidos na operação que gerou o erro. o Requisito Deve existir uma documentação breve para cada módulo afim de explicar seu objetivo e funcionamento. Equipe 2 - Avaliação de Características Relacionadas a Arquitetura dos Módulos o Requisito Cada módulo deve realizar uma única atividade dentro de seu contexto - coesão funcional. o Requisito Cada módulo deve possuir no máximo 50 linhas de código cada. o Requisito Módulos com coesão não funcional (fazem mais de uma atividade) não devem compartilhar código entre essas atividades. Equipe 3 - Avaliação de Características Relacionadas aos Dados o Requisito O acoplamento entre os módulos deve ser fraco para que erros em cascata não ocorram. o Requisito Não deve ser feito uso de várias globais (menos em casos onde o dado global é uma estrutura de dados que vem para substituir um arquivo ou tabela de dados). 20

21 2.5 PACOTES DE SOFTWARE: TESTES E REQUISITOS DE QUALIDADE A NBR ISO/IEC estabelece requisitos de qualidade para software tipo pacote e fornece instruções de como testar o pacote de software em relação aos requisitos definidos. Seu escopo refere-se a pacote de software, na forma oferecida no mercado, e não aos processos de desenvolvimento e fornecimento de software. São exemplos de pacotes de software: processadores de textos, planilhas eletrônicas, bancos de dados, software gráfico, programas para funções técnicas ou científicas e programas utilitários. Um pacote de software é definido como "Conjunto completo e documentado de programas fornecido a diversos usuários para uma aplicação ou função genérica". Incluem-se como possíveis usuários desta Norma: Fornecedores que estejam: o especificando os requisitos para um pacote de software; o projetando um modelo para descrever produtos; o julgando seus próprios produtos; o emitindo declarações de conformidade (ABNT ISO/IEC Guia 22); o submetendo produtos a certificação ou à obtenção de marcas de conformidade (ABNT ISO/IEC Guia 23); Entidades de certificação que pretendam estabelecer um esquema de certificação por tercera parte; Laboratórios de teste, que terão de seguir as instruções de teste durante a execução de testes para certificação ou para emissão de marca de conformidade; Auditores quando julgam a competência de laboratórios de teste; Compradores que pretendam: o o o o comparar seus próprios requisitos com os descritos; comparar os requisitos necessários para executar uma determinada tarefa com a informação presente nas descrições de produto existentes; procurar por produtos certificados; verificar se os requisitos foram atendidos; O pacote de software a ser testado ou a ter sua qualidade avaliada deve dispor de: Descrição do Produto - Um documento que estabelece as propriedades do produto, com o propósito de orientar potenciais compradores na avaliação da adequabilidade do produto antes de comprá-lo. Caso o produto de software não disponha da descrição do produto, esta é considerada uma não-conformidade maior. Documentação do Usuário - O conjunto completo de documentos disponível em forma impressa ou não, que é fornecido ao usuário para a aplicação do produto de software e também como parte integral deste produto. Programas e Dados - O conjunto completo de programas de computador e dados fornecidos para a aplicação do produto de software e também como parte integral deste produto. 21

22 2.5.1 Requisitos de Qualidade de um Pacote de Software Nesta parte do documento é apresentado o conjunto de requisitos definidos pela norma NBR ISO/IEC para qualidade dos pacotes de software. São considerados aqui os seguintes aspectos: A. Descrição do Produto São requisitos que determinam que informações devem ser fornecidas sobre o pacote de software, ou seja, devem ser mantidas informações sobre a documentação de usuário, programas e, se existirem, sobre os dados (define o produto). Serve como base para a atividade de teste. A.1. Requisitos gerais sobre conteúdo da descrição Convém que a descrição de produto seja suficientemente inteligível, completa e possua boa organização e apresentação, a fim de auxiliar os compradores em potencial na avaliação da adequação do produto às suas necessidades, antes de comprá-lo. Cada declaração da descrição de produto deve ser correta e passível de erro. Cada termo deve ter um único significado. A.2. Identificação e indicações Este item especifica que a descrição de produto deve incluir ou convém que inclua os seguintes pontos: Identificação da descrição do produto Identificação do produto - Nome, versão e data do produto. Fornecedor - Nome, endereço e dados comerciais. Tarefa - Lista das tarefas que podem ser executadas utilizando-se o produto. Conformidade e documentos de requisitos - Referência aos documentos de requisitos com os quais o produto está em conformidade. Requisitos de hardware e software - Unidades de processamento e coprocessadores, tamanho da memória principal, tipos e tamanhos dos periféricos de armazenamento, placas de expansão, equipamentos de entrada e saída, ambiente de rede, software de sistema e outros software. Interface com outros produtos Itens a serem entregues - Programas, documentos, etc. Instalação - Explicação sobre a forma da instalação (o usuário pode ou instalar o produto) Suporte - Declaração sobre a existência ou não de formas de suporte ao produto. Manutenção - Declaração se a manutenção sobre o produto é oferecida ou não, e se existir a forma como isto ocorre. A.3. Declarações sobre funcionabilidade Este item declara vários requisitos com relação a funcionalidade do produto de software: Visão geral das funções - é uma descriação da cada função do sistema especificando se a função é parte do: produto, de uma extensão do produto integralmente apresentada na descrição do produto; de uma extensão do produto referida na descrição do produto; de um suplemento sem garantia. 22

23 Valores limites - se o produto é limitado por valores-limite específicos estes devem ser especificados (valores máximos ou mínimos para dados, comprimento de chaves, número máximo de registros em arquivos, etc). Segurança de acesso - especificação das maneiras (se existirem) para evitar acessos indesejáveis as funções. A.4. Declarações sobre confiabilidade A descrição do produto deve incluir informações sobre procedimentos para preservação de dados. Isto inclui procedimentos para backup, para recuperação de dados e formas de utilizar o produto de software de forma a garantir esta consistência dos dados. A.5. Declarações sobre usabilidade Devem descrever os seguintes itens do pacote de software: Interface com usuário - deve ser especificado o tipo de interface com o usuário. Conhecimento requerido - devem ser especificados todos os tipos de conhecimentos requiridos para utilizar o produto de software (área técnica, sistema operaciona, idiomas). Adaptação às necessidades do usuário - ferramentas para esta adaptação devem ser especificadas. Proteção contra infrações e direitos autorais - se algum tipo de proteção dificulta a usabilidade então esta deve ser especificada. Eficiência de uso e satisfação do usuário A.6. Declarações sobre eficiência A descrição do produto pode incluir dados sobre o comportamento do produto em relação ao tempo, tais como tempo de resposta para uma dada função sob condições estabelacidas. A.7. Declarações sobre manutenibilidade Este item é opcional para pacotes de software. A.8. Declarações sobre portabilidade Este item é opcinal para pacotes de software. B. Documentação do Usuário São requisitos que determinam que informações devem estar contidas na documentação do usuário, bem como este deve estar planejado e organizado. São considerados os seguintes aspectos aqui: B.1 Completude O manual do usuário (documentação do usuário) deve comtemplar os seguintes itens: todas as informações sobre uso e configuração (adaptabilidade) do produto, 23