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

24 descrição completa sobre todas as funções disponibilizadas pelo produto (mesmo aquelas não apresentadas na descrição do produto), dados sobre valores limites (devem ser repetidos aqui), informações necessárias para a instalação do produto, informações sobre aspectos de manutenção que possam ser realizadas pelo próprio usuário. B.2 Correção Todas as informações na documentação do usuário devem estar corretas. B.3 Consistência O documento do usuário não deve apresentar contradições internas. B.4 Inteligibilidade O documento de usuário deve ser escrito em conformidade com o tipo de usuário do produto. B.5 Visão geral Convém que a documentação de usuário seja apresentável e organizada. C. Programas e Dados Aqui são determinados os requisitos que o programa e os dados do pacote de software devem satisfazer. São considerados os seguintes aspectos aqui: C.1 Funcionalidade Os requisitos relacionados a funcionalidade estão organizados em: Instalação - Se puder ser realizada pelo usuário, deve ser possível que o mesmo faça a instalação somente com base nas informações contidas na documentação do usuário agregadas a requisitos de software e hardware. Após a instalação deve ser possível verificar se o programa está funcionando adequadamente seguindo um guia de teste fornecido. Presença de Funções - Todas as funções descritas no documento de usuário devem ser executáveis na forma nela descrita, com os correspondentes recursos, propriedades e dados, e dentro dos valores limites fornecidos. Correção e Consistência - Os programas e dados devem estar em conformidade com todas as declarações feitas na descrição do produto e não podem conter quaisquer constradições. C.2 Confiabilidade O sistema, compreendendo hardware e software, bem com os programas que pertencem ao produto, não deve entrar em um estado no qual o usuário não consiga controlá-lo, nem devem corromper ou perder dados. Isto deve ser válido ainda que: A capacidade seja explorada até os limites especificados; Deve ser feitas tentativas para explorar a capacidade além dos limites especificados; 24

25 Uma entrada incorreta seja feita pelo usuário ou por outros programas listados na descrição do produto; Instruções explícitas na documentação de usuário sejam violadas. Não estão devem ser inclusos nesta lista problemas ocasionados por hardware ou pelo sistema operacional. C.3 Usabilidade Devem ser considerados nesta seção os seguinets aspectos: Inteligibilidade - Convém que as perguntas, mensagens e resultados dos programas sejam inteligíveis, considerando: um seleção adequada de termos, uma correta representação gráfica; o fornecimento de informações básicas para o entendimento e pelas explicações dadas através de ajuda (help). Apresentação e Conformidade o Cada meio de armazenamento de dados deve apresentar a identificação do produto; o Deve ser sempre possível ao usuário, quando estiver trabalhando com os programas, descobrir qual função está sendo executada. o Convém que os programas apresentem sistemas de ajuda organizados e fácil leitura; o Convém que as mensagens possam ser diferenciadas pelo usuário (confirmação, solicitações, advertências, mensagens de erro); o Convém que os formatos de tela de entrada, de relatórios e de outras entradas e saídas sejam projetadas de forma clara e organizada (campos alfanuméricos alinhados pela esquerda, campos númerico alinhados pela direita, campos obrigatórios sejam reconhecidos, etc); Operacionaildade o o C.4 Eficiência A execução de funções que têm conseqüências graves devem ser reversíveis, ou o usuário deve ser claramente alertado sobre as conseqüências. Se um texto de documentação é exibido um um diálogo, convém que o usuário seja capaz de fazer acesso aos subitens do texto. Não há exigência. Entretanto, o produto deve estar em conformidade com as declarações de eficiência citadas em sua descrição. C.5 Manutenibilidade Não há exigência. Entretanto, o produto deve estar em conformidade com as declarações de eficiência citadas em sua descrição. C.6 Portabilidade Não há exigência. Entretanto, o produto deve estar em conformidade com as declarações de eficiência citadas em sua descrição Instruções para Teste de um Pacote de Software As instruções seguintes especificam como um produto deve ser testado em relação aos requisitos de qualidade. Elas incluem tanto o teste das propriedades 25

26 necessárias a todos os produtos de mesmo tipo, quanto o teste das propriedades especificadas na descrição do produto. Também estão incluídos o teste por inspeção dos documentos e o teste caixa-preta. Estas instruções descrevem o teste funcional (teste da caixa-preta). O teste estrutural não está incluído porque requer a disponibilidade de código-fonte. A. Pré-requisitos do Teste Presença dos itens do produto de software (software, hardware, documentações) Presença do hardware e software necessários (ambiente de funcionamento) Treinamento - Se for mencionado da descrição do produto, o responsável pelo teste deve ter acesso ao material e ao programa de treinamento disponibilizado ao usuário. B. Atividades do Teste Os três itens seguintes devem estar em conformidade com os requisitos de qualidade listados na norma NBR ISO/IEC Descrição do Produto Documentação do usuário Programas e dados (programas e dados devem ser testados em todos os ambientes de hardware e software especificados na descrição do produto). Os programas e seus respectivos dados devem ser testados utilizando guias de teste construídos com base na descrição do produto e na documentação de usuário. Os guias de teste devem ser contruídos de maneira metódica e sistematicamente. Guais de teste disponibilizados pelo fornecedor do pacote de software podem ser utilizados, mas os testes não devem se restringir a estes exemplos. Os guias de teste devem cobrir: Todas as variantes possíveis relativas ao processo de instalação do software. Deve ser possível verificar se a instalação ocorreu de forma correta. Devem cobrir todas as funções descritas na descrição de produto e na documentação de usuário e devem considerar as combinações que são representativas para a tarefa. Entradas e comandos desaprovados na documentação devem ser testados. C. Registros do Teste Os registros para cada teste devem conter informação suficiente para permitir a repetição do teste. Eles devem incluir: um plano de teste ou especificação de teste contendo guias de teste; todos os resultados associados com os guias de teste, incluindo todas as falhas que ocorreram; a identificação do pessoal envolvido no teste. D. Relatórios do Teste 26

27 Os objetos e resultados do teste (como relatório nos registros de teste) devem ser resumidos em um relatório de teste, que deve ter a seguinte estrutura: Identificação completa do produto de software; Configuração de hardware e software utilizada na avaliação dos programas e dados; Documentos usados (com suas identificações); Resultados da avaliação da descrição do produto, da documentação do usuário e dos programas e dados; Listar conformidades e não conformidades quanto a requisitos; Listar conformidades e não conformidades quanto a recomendações; Local e data da conclusão da avaliação; Nome completo e assinatura do pessoal envolvido na avaliação. O relatório de teste deve incluir: Uma declaração indicando que os resultados de teste se referem somente aos itens testados; Uma declaração de que o relatório de teste não deve ser parcialmente reproduzido, a menos que haja a aprovação por escrito do laboratório de teste. UNIDADE 3 - QUALIDADE DOS PROCESSOS DE SOFTWARE A seguir, são apresentados os processos de software segundo a Norma Brasileira NBR ISO / IEC 12207, as normas série ISO 9000, o CMM (Capability Maturity Model) e a futura norma ISO / IEC TR (SPICE - Software Process Improvement and Capability determination). Além destas, existem outras abordagens para melhoria da qualidade dos processos de software, todas com vantagens e desvantagens umas em relação às outras [THO97 e ZAH97]. 27

28 3.1 PROCESSOS DO CICLO DE VIDA DO SOFTWARE A Norma ISO/IEC foi publicada internacionalmente em 1995; a Norma Brasileira NBR ISO/IEC 12207, em O seu principal objetivo é estabelecer uma estrutura comum de processos de software, que seja utilizada como referência na contratação de produtos e serviços de software, bem como descrever as melhores práticas de engenharia e gerenciamento de software. A Norma faz de uso de uma terminologia bem definida e sua estrutura é composta de processos, atividades e tarefas, a serem aplicados em operações que envolvam software de alguma forma, seja na aquisição, fornecimento, desenvolvimento, operação e manutenção. Esta estrutura também permite estabelecer ligações claras com o ambiente da engenharia de sistemas, ou seja, aquele que inclui software, hardware, pessoal e práticas de negócios. Na norma ISO/IEC 12207, os processos do ciclo de vida do software são agrupados em três classes: processos fundamentais, processos de apoio e processos organizacionais. Cada processo é definido em termos de suas próprias atividades e cada atividade é definida em termos de suas tarefas. Uma tarefa é expressa através do verbo que a descreve: um requisito (deve), uma declaração de objetivos ou intenção (deverá), uma recomendação (deveria) ou uma ação permissível (pode). 28

29 3.1.1 Processos Fundamentais Atendem o início (contratação entre o adquirente e o fornecedor) e a execução do desenvolvimento, operação ou manutenção de produtos de software, durante o ciclo de vida do software. São eles: Processo de Aquisição. Define as atividades do adquirinte, organização que adquire um sistema ou produto de software. Inicia-se com a definição da necessidade de adquirir um sistema, um produto ou um serviço de software. O processo continua com a preparação e emissão do pedido de proposta, seleção de fornecedor e gerência do processo de aquisição através da aceitação do sistema, produto ou serviço de software. Processo de Fornecimento. Define as atividades do fornecedor, organização que provê o produto de software ao adquirente. O processo pode ser iniciado tanto por decisão de preparar uma proposta para responder a um pedido de proposta de um adquirente, quanto pela assinatura e celebração de um contrato com o adquirente para fornecer o sistema, produto ou serviço de software. O processo continua com a determinação dos procedimentos e recursos necessários para gerenciar e garantir o projeto, incluindo o desenvolvimento e a execução dos planos de projeto até a entrega do sistema, produto ou serviço de software para o adquirinte. Processo de Desenvolvimento. Define as atividades do desenvolvedor, organização que define e desenvolve o produto de software. O processo contém as atividades para análise de requisitos, projeto, codificação, 29

30 integração, testes, instalação e aceitação relacionadas aos produtos de software. Processo de Operação. Define as atividades do operador, organização que provê serviço de operação de um sistema computacional no seu ambiente de funcionamento para seus usuários. O processo cobre a operação do produto de software e o suporte operacional aos usuários. Processo de Manutenção. Define as atividades do mantenedor, organização que provê os serviços de manutenção do software, isto é, gerenciamento de modificações no software para mantê-lo atualizado e em perfeita operação. Este processo só é ativado quando o produto de software é submetido a modificações no código e na documentação associada devido a um problema, ou à necessidade de melhoria ou adaptação. O objetivo é modificar um produto de software existente, preservando a sua integridade Processos de Apoio Auxiliam e contribuem para o sucesso e qualidade do projeto de software. Um processo de apoio é empregado executado, quando necessário, por outro processo. São eles: Processo de Documentação. Define as atividades para registrar informações produzidas por um processo ou atividade do ciclo de vida. O processo contém o conjunto de atividades que planeja, projeta, desenvolve, produz, edita, distribui e mantém aqueles documentos necessários a todos os interessados, tais como gerentes, engenheiros e usuários do sistema ou produto de software. Processo de Gerência de Configuração. Define as atividades para a aplicação de procedimentos administrativos e técnicos, por todo o cliclo de vida do software, destinado a identificar e definir os itens de software em um sistema, e estabelecer suas linhas básicas (baseline); controlar as modificações e liberações dos itens; registrar a apresentar a situação dos itens e pedidos de modificação; e controlar o armazenamento, a manipulação e a distribuição dos itens de software. Processo de Garantia de Qualidade. Define as atividades para fornecer a garantia adequada de que os processos e produtos de softwaere, no ciclo de vida do projeto, estejam em conformidade em com seus requisitos especificados e sejam aderentes aos planos estabelecidos. A abrangência do processo inclui questões como garantia da qualidade do produto, do processo e do sistema de qualidade. Processo de Verificação. Define as atividades para verificação dos produtos de software. É um processo para determinar se os produtos de software de uma atividade atendem completamente os requisitos ou condições impostas a eles. Processo de Validação. Define as atividades para validação dos produtos produzidos pelo projeto de software. É um processo para determinar se os requisitos e o produto final (sistema ou software) atendem o uso específico proposto. Processo de Revisão Conjunta. Define as atividades para avaliar a situação e produtos de uma atividade de um projeto, se apropriado. As revisões conjuntas são feitas tanto nos níveis de gerenciamento do projeto como nos níveis técnicos e são executadas durante a vigência do contrato. Processo de Auditoria. Define as atividades para determinar adequação aos requisitos, planos e contrato, quando apropriado. Processo de Resolução de Problema. Define um processo para analisar e resolver os problemas (incluindo não-conformidades), de qualquer natureza ou fonte, que são descobertos durante a execução do desenvolvimento, 30

31 operação, manutenção ou outros processos. O objetivo é prover os meios em tempo adequado e de forma responsável e documentada para garantir que todos os problemas encontrados sejam analisados e resolvidos e tendências sejam identificadas Processos Organizacionais São empregados por uma organização para estabelecer e implementar uma estrutura constituída de processos de ciclo de vida e pessoa associados, melhorando continuamente a estrutura e os processos. Eles são tipicamentes empregados fora do domínio de projetos e contratos específicos; entretanto, ensinamentos destes projetos e contratos contribuem para a melhoria da organização. São eles: Projeto de Gerência. Define as atividades genéricas que podem ser empregadas por quaisquer das partes que têm que gerencia seu(s) respecitivo(s) processo(s). O gerente é reponsável pelo gerenciamento de produto, gerenciamento de projeto e gerenciamento de tarefa do(s) processo(s) aplicável(eis), tais como aquisição, desenvolvimento, operação, manutenção ou processos de apoio. Processo de Infra-Estrutura. Define as atividades para estabelecer e manter a infra-estrutura necessária para qualquer outro processo. A infra-estrutura pode incluir hardware, software, ferramentas, técnicas, padrões e recursos para o desenvolvimento, operação e manutenção. Processo de Melhoria. Define atividades básicas que uma organização executa para estabelecer, avaliar, medir, controlar e melhorar um processo do ciclo de vida do software. Processo de Treinamento. Define as atividades para prover e manter pessoal treinado. A aquisição, o fornecimento, o desenvolvimento, a operação ou a manutenção de produtos de software é extremamente dependente de pessoal com conhecimento e qualificação. Portanto, é essencial que o treinamento de pessoal seja planejado e implementado com antecedência para que o pessoal treinado esteja disponível quando o produto de software for adquirido, fornecido, desenvolvido, operado ou mantido Processo de Adaptação O processo de adaptação define as atividades necessárias para executar a adaptação da Norma para sua aplicação na organização ou em projetos. A adaptação deve ser executada baseando-se em alguns fatores que diferenciam uma organização ou projeto de outros, dentre os quais, a estratégia de aquisição, modelos de ciclo de vida de projeto, características de sistemas e software e cultura organizacional. A experiência desse processo permite que a Norma seja adaptável a qualquer projeto, organização, modelo de ciclo de vida, cultura e técnica de desenvolvimento Tecnologias Envolvidas A Norma é flexível para as disciplinas de engenharia de software envolvidas, sendo utilizável com qualquer modelo de ciclo de vida (cascata, incremental, evolutivo, etc.); com qualquer método ou técnica de engenharia de software (projeto orientado a objetos, técnicas estruturadas, prototipação, etc); com quaisquer linguagens de programação (Java, Delphi, Cobol, etc). Estas questões são muito dependentes do projeto e do estado da arte da tecnologia, portanto estas escolhas são deixadas a critério dos usuários da Norma. 31

32 3.1.6 Arquitetura do Ciclo de Vida do Software A Norma estabelece uma arquitetura de alto nível do ciclo de vida do software, abrangendo desde a concepção até a descontinuação do software. Esta arquitetura é baseada em processos-chave e o inter-relacionamento entre eles, seguindo dois princípios básicos. Modularidade - os processos têm alta coesão e baixo acoplamento, ou seja, todas as partes de um processo são fortemente relacionadas e o número de interfaces entre os processos é mantido o mínimo. Responsabilidade - cada processo na Norma é de responsabilidade de uma "parte envolvida". Um "parte envolvida" pode ser uma organização ou parte dela. As partes envolvidas podem ser da mesma organização ou de organizações diferentes Implementação de Princípios de Gerência de Qualidade A Norma implementa os princípios da gerência de qualidade. Ela os executa em três passos básicos: Integração da Qualidade no Ciclo de Vida - A Norma provê os requisitos para um conjunto abrangente e integrado de processos dentro de todo o ciclo de vida, onde cada processo é construído de acordo com o ciclo PDCA (plan-docheck-act). Trata todas as atividades relacionadas à qualidade como uma parte integrante do ciclo de vida do software e também apropria estas atividades para cada processo no ciclo de vida. Processo de Garantia de Qualidade - O processo de garantia da qualidade é dedicado assumir a concordância dos produtos e serviços com seus requisitos contratuais. Pessoas responsáveis por este processo são providas com a necessária liberdade e autoridade organizacional. Processo de Melhoria - A Norma contém um processo de melhoria, em nível de organização e corporação, para gerenciamento da qualidade de seus próprios processos estabelecidos. 3.2 ISO APLICADA AO SOFTWARE A família ISO 9000 é composta de uma série de normas, mas somente as normas 9001, 9002 e 9003 podem ser utilizadas como requisitos entre clientes e fornecedores. As outras normas destinam-se a orientar a escolha da norma adequada a ser utilizada ou à sua implementação. A ISO 9003 só cobre as atividades de inspeção e ensaio final. A ISO 9002, as atividades de produção e serviços associados e a ISO 9001, todo o ciclo de vida de um produto ou serviço, iniciando no seu projeto ou desenvolvimento, passando pelas atividades de produção e serviços associados. As normas da série ISO 9000 foram expandidas com a edição das Normas Internacionais de série 10000, que complementam estas e fornecem diretrizes para planos de qualidade, auditorias internas, qualificação de auditores, comprovação metrológica e manuais de qualidade. Estima-se que existam certificações ISO em 150 países diferentes. A América do Sul / Central teve o maior crescimento de 1998 para 1999, em certificações, ficando com um crescimento de 72%. Em segundo lugar ficou a Austrália / Nova Zelândia com 51% de crescimento. As regiões com maior participação de certificados emitidos são: Europa: 55%; Extremo Oriente: 16%; 32

33 América do Norte: 13%. A América do Sul participa somente com 2,6% do total de certificações. A seguir apresentamos o conjunto de requisitos gerais definidos pela norma ISO 9001:1994. Alguns desses requisitos são voltados para estruturação da empresa, outros como mecanismo de retroalimentação e melhoria discreta e os demais voltados para execução das atividades envolvidas diretamente com o ciclo de vida do produto ou serviço. Nr. do Requisito Título do Requisito da ISO 9001:1994 Tipo de Requisito 4.1 Responsabilidade pela administração E Análise crítica pela administração R 4.2 Sistema de qualidade E 4.3 Análise Crítica de Contrato P 4.4 Controle de Projeto P 4.5 Controle de documentos e dados E 4.6 Aquisição P 4.7 Produto fornecido pelo cliente E 4.8 Identificação e rastreabilidade P 4.9 Controle de Processo P 4.10 Inspeção e Ensaio P 4.11 Controle de equipamentos de inspeção, medição e ensaio 4.12 Situação da inspeção e ensaio P 4.13 Controle de produto não conforme E 4.14 Ação corretiva e preventiva R 4.15 Preservação, embalagem e entrega P armazenamento, P 4.16 Controle de registros da qualidade E 4.17 Auditoria interna R 4.18 Treinamento E 4.19 Serviços associados P 4.20 Técnicas estatísticas E E: Estrutural; P:Relacionado ao ciclo de vida do produto ou serviço; R: Retroalimentação / melhoria Uso da ISO 9000 A ISO reconhece que existem 4 diferentes categorias genéricas de produtos e publicou diretrizes para implementação de sistemas de qualidade para cada uma destas categorias: Produtos (hardware): ISO Serviços: ISO ; Materiais Processados: ISO ; Software: ISO

34 Outra norma importante, juntamente com a ISO , na implantação do sistema da qualidade em software é a ISO / IEC 12207, que trata dos processos que compõem o ciclo de vida do software. No Brasil, cerca de 150 certificações ISO 9000 no setor de software estão sendo esperadas para o final de Isto se deve à percepção dos benefícios, pressão de clientes, maior quatidade de profissionais que conhecem o modelo e, também, aos grupos "Ruma à ISO 9000" apoiados por Agentes SOFTEX - (consulte De acordo com as últimas revisões da ISO 9000, a norma ISO voltada para software foi excluída. Contudo, existe uma grande pressão das empresas de TI para que a mesma seja revisada alinhada à ISO 9001 versão 2000, mas este futuro ainda é incerto. 3.3 FUTURA NORMA ISO/IEC (SPICE) ISO / IEC designa uma futura norma internacional para Avaliação de Processos de Software, que está sendo desenvolvida pelo Projeto ISO SPICE (Software Process Improvement and Capability determination). Este desenvolvimento foi iniciado em 1993, após a realização de um estudo pela ISO sobre as necessidades e os requisitos de um padrão para avaliação de processos de software. Este estudo concluiu que havia consenso internacional sobre a necessidade e requisitos para este padrão e que deveria ser adotada uma forma de desenvolvimento na qual resultados pudessem ser utilizados o mais breve possível, garantindo que o padrão elaborado atendesse completamente aos seus requisitos. Foi criado então o projeto SPICE, com uma equipe de especialistas internacionais para produzir as versões iniciais da futura norma e coordenar a utilização destas versões pela comunidade internacional Relatório Técnico ISO/IEC TR A versão atual da futura norma internacional é um relatório técnico publicado pela ISO em 1998, denominado ISO/IEC TR 15504: Information Technology - Software Process Assessment (Tecnologia da Informação - Avaliação de Processos de Software), composto por nove partes: : Conceitos e guia introdutório; : Um modelo de referência para processos e capacidade de processo; : Executando uma avaliação; : Guia para execução de uma avaliação; : Um modelo de avaliação e guia de indicadores; : Guia de competência dos avaliadores; : Guia para utilização em melhoria de processos; : Guia para utilização em determinar a capacidade de processo de fornecedor; : Vocabulário. Enquanto as partes 2 e 3 são normativas, as outras são apenas informativas. Segundo a 15504, uma avaliação de processo de software é uma avaliação disciplinada de processos de uma unidade organizacional em relação a um modelo compatível com o modelo de referência da Os requisitos e orientações para a realização de uma avaliação estão descritos respectivamente nas partes 3 e 4. O 34

35 Modelo de Referência e os requisitos para um modelo compatível estão descritos na parte 2. Um exemplo de um modelo compatível está descrito na parte 5. Orientações para a competência que um avaliador deve ter para realizar uma avaliação estão descritas na parte 6. Uma avaliação pode ser realizada no contexto de uma melhoria contínua ou para a determinação da capacidade. Para a melhoria contínua, uma avaliação tem como objetivo entender o estado dos processos de uma organização, enquanto que para a determinação da capacidade, uma avaliação tem como objetivo determinar a adequação dos processos de uma organização a um requisito particular, uma classe de requisitos, um determinado contrato ou para uma classe de contratos. Orientações para a utilização de uma avaliação nestes dois contextos estão descritas nas partes 7 e 8. Finalmente, a parte 1 contém uma introdução geral à e a parte 9 contém uma relações de termos e respecitivas definições. Para executar uma avaliação uma organização deve escolher um avaliador capacitado, um modelo de processo compatível, como por exemplo o modelo descrito na , e um método de avaliação compatível. [figura 1.12 página 21] A futura norma foi baseado nos principais modelos existentes (como o CMM, TRILLIUM e BOOTSTRAP), tendo entre objetivos básicos realizar uma harmonização destes diversos modelos e prover um framework para estes modelos e outros que possam criados. Esta prevista para este ano o lançamento da Norma ISO/IEC definitiva, para isto várias revisões estão sendo feitas para se alcançar um modelo aceitável. As principais mudanças que devem ocorrer são: combinação do conteúdo das nove partes atuais em apenas cinco, inclusão de um exemplo de processo de avaliação compatível e substituição da dimensão de processo do Modelo de Referência por requisitos para a definição de processo. Deste modo, a futura norma poderá ser utilizada para avaliar (e melhorar) processos em qualquer domínio, não apenas processos de software. Por exemplo, a nova versão do CMM, chamada de CMMI (Capability Maturity Model Integrated), que integra os domínios do software, sistema e projeto integrado de produto, está sendo desenvolvida como um modelo em consistente com a [SEI, Capability Maturity Model Integrated, 2000]. Já foram realizadas mais de 600 avaliações utilizando as várias versões evolutivas do SPICE, inclusive duas no Brasil (publicadas na SBES ) Categorias e Processo de Software O modelo de referência descrito na parte 2 identifica e descreve um conjunto de processos da Engenharia de Software considerados universais e fundamentais para a boa prática da Engenharia de Software. Quarenta processos e componentes de processos são descritos e organizados em cinco categorias de processo: Cliente- Fornecedor, Engenharia, Suporte, Gerência e Organização. Estes processos são um superconjunto dos processos definidos na ISO / IEC Cada processo é descrito na parte 2 basicamente por um nome, o propósito e como reconhecer uma implementação de sucesso. A parte 5, como um exemplo de modelo compatível, 35

36 detalha a descrição de cada processo, incluindo práticas-base e possíveis produtos de entrada e saída Níveis de Capacidade Cada um destes processos pode estar sendo executado em uma determinada organização em diferentes níveis de capacidade. A define seis níveis seqüênciais e cumulativos que podem ser utilizados como uma métrica para avaliar como uma organização está executando um determinado processo e também podem ser utilizados como uma guia para a melhoria da execução. Cada nível de capacidade é descrito na parte 2 basicamente por um nome, definição e atributos. A parte 5, como um exemplo de um modelo compatível, detalha a descrição de cada nível, incluindo práticas gerenciais e outros indicadores para cada atributo. Os seis níveis de capacidade e suas respectivas características são: Nível 0 - Incompleto: Existe uma falha geral na satisfação do propósito do processo. Existem poucos, ou difíceis de serem identificados, produtos de trabalho ou resultados dos processos. Nível 1 - Executado: O propósito do processo é geralmente alcançado. Isto talvez não seja rigorosamente planejado e acompanhado. As pessoas da organização reconhecem que uma ação deve ser executada, e existe uma concordância geral e informal que esta ação deve ser executada e quanto isto deve ser feito. Existem produtos de trabalho para o processo e estes produtos evidenciam a satisfação do propósito do processo. Nível 2 - Gerenciado: O processo produz produto de trabalho de acordo com procedimentos específicos e é planejado e acompanhado. Os produtos de trabalho são conforme os padrões e requisitos especificados. A principal distinção deste nível em relação ao Nível Executado é que a execução do processo passa a construir produtos de trabalho que satisfazem os requisitos de qualidade especificados, dentro do cronograma de tempo e dos recursos necessários. Nível 3 - Estabelecido: O processo é executado e gerenciado utilizando um processo definido baseado em princípios de uma boa engenharia de software. A implantação de um processo usa uma versão customizada e aprovada de um processo padrão documentado para satisfazer os resultados definidos do processo. Os recursos necessários para estabelecer a definição do processo são disponibilizados. A principal distinção deste nível em relação ao Nível Gerenciado é que o processo utiliza um processo padrão que é capaz de atingir seus resultados definidos. Nível 4 - Previsível: O processo definido é executado consistentemente na prática dentro de limites de controle definidos, para atingir as metas definidas do processo. Medições detalhadas de desempenho são coletadas e analisadas, levando a um entendimento quantitativo da capacidade do processo e uma melhora na habilidade para prever e gerenciar a execução. A execução é gerenciada quantitativamente. A qualidade dos produtos de trabalho é conhecida de forma quantitativa. A principal distinção deste nível em relação ao Nível Estabelecido é que o processo passa a ser executado consistentemente dentro de limites definidos para atingir seus resultados. Nível 5 - Otimizado: O desempenho do processo é continuamente melhorado para satisfazer objetivos correntes e futuros do negócio, com o processo permitindo repetibilidade em atingir suas metas de negócio definidas. Objetivos quantitativos de eficiência e eficácia para o desempenho do processo são estabelecidos, baseados nos objetivos do negócio da organização. Um acompanhamento contínuo do processo em relação a estes objetivos é estabelecido pela obtenção de realimentações quantitativas e a melhoria é obtida a partir da análise dos resultados. A otimização do 36

37 processo envolve experiências de idéias e tecnologia e a mudança de processos não efetivos para satisfazer metas e objetivos definidos. A principal distinção deste nível em relação ao Nível Previsível é que o processo-padrão passa a ser alterado e adaptado para atingir de forma efetiva os objetivos correntes e futuros do negócio Avaliação de Processos de Software Para executar uma avaliação, uma organização deve escolher um avaliador capacitado, um modelo de processo compatível, como por exemplo o modelo descrito na , e um processo de avaliação. Entre outras decisões, também deve ser selecionado um subconjunto dos processos e seus respectivos níveis de capacidade, alinhado com os objetivos do negócio da organização. Dentro do contexto de melhoria de processos, a avaliação significa a caracterização das práticas correntes de uma unidade organizacional em termos de capacidade dos processos selecionados. A análise dos resultados é feita em relação às necessidades do negócio da organização, identificando os aspectos e negativos, e os riscos associados aos processos. Isto leva a determinar se os processos estão atingindo efetivamente seus objetivos e identificar causas da baixa qualidade, alto custo ou tempo excessivo, indicando a priorização na melhoria dos processos. O desenvolvimento da tem reunido os melhores especialistas internacionais em avaliação de processos de software e, por meio da sinergia deste grupo, tem causado avanços significativos no estado da arte e na base teórica para avaliação de processos. O impacto geral deste trabalho tem ajudado a melhoria das práticas internacionais da engenharia de software. UNIDADE 4 - MAPEAMENTO DO MERCADO BRASILEIRO DE SOFTWARE 4.1 Profissionais do Setor O capital humano, que abrange as capacidades individuais, conhecimentos, habilidades e experiências dos empregados de uma empresa, aliado ao capital estrutural constituem o capital intelectual das organizações. Um dos indicadores medidos para acompanhar a qualificação profissional do setor diz respeito à formação acadêmica formal das pessoas ocupadas nas empresas em nível de pós-graduação e foi levantado a partir de Nota-se pela tabela a existência de pelo menos um profissional pós-graduado em mais de 40% das empresas das amostras. Faixas de 1995 Dez/1996 Dez/1998 Profissionais Nº % Nº % Nº % Zero , , ,4 1 a , , ,3 3 a ,5 43 7,3 42 9,4 6 a ,6 21 3,6 19 4,3 37

38 11 a ,3 2 0,3 6 1,4 21 ou mais 7 1,6 8 1,4 10 2,2 Base Desde 1995, há em aproximadamente um quarto das empresas pelo menos um profissional certificado em qualidade, considerando para efeito da pesquisa aquele que obteve a certificação oferecida pela American Society for Quality - ASQ, é um Lead Assessor ou pós-graduado lato sensu ou stricto sensu em gestão de qualidade, num total de 823 profissionais certificados em Faixas de 1995 Dez/1996 Dez/1998 Profissionais Nº % Nº % Nº % , , ,2 Zero 1 a , , ,3 3 a ,5 23 3,9 26 5,8 6 a ,9 11 1,9 10 2,2 11 a ,7 3 0,5 6 1,4 21 ou mais 5 1,2 1 0,2 5 1,1 Base A ASQ, entidade que congrega profissionais interessados na engenharia da qualidade e na gestão da qualidade, oferece diversas certificações profissionais, entre as quais a de engenheiro de qualidade (Certified Quality Engineer - CQE), engenheiro de confiabilidade (Certified Reliability Engineer - CRE), auditor da qualidade (Certified Quality Auditor - CQA), administrador da qualidade (Certified Quality Manager - CQM) e engenheiro da qualidade em software (Certified Sofware Quality Engineer - CSQE). No Brasil, os exames para certificação são aplicados pela Associação Brasileira de Controle de Qualidade - ABCQ. A certificação do Lead Assessor qualifica um auditor a atuar na avaliação de empresas segundo as normas ISO Qualidade dos Produtos de Software A qualidade dos produtos de software, propriamente dita, não é medida na âmbito das pesquisas aqui analisadas. O acompanhamento, relacionado a este ponto, é conduzido a partir de questões relativas a Normas Internacionais como ISO/IEC 9126 e ISO/IEC Em 1997, 26% das empresas conheciam as Normas ISO/IEC 9126 ou ISO/IEC 12119, sendo que 7% as utilizavam sistematicamente ou estavam começando a usá-las. Em 1999 estes percentuais se elevaram para 36% e 9% respectivamente. Categorias ISO/IEC 9126 e ISO/IEC 9126 (NBR ISO/IEC ) Nº % Nº % Nº % Conhece e 43 7,3 42 9,4 27 6,1 usa Conhece e , , ,6 não usa Não , , ,3 38

39 conhece Base Qualidade dos Processos de Software A qualidade dos processos de software nas empresas brasileiras tem sido acompanhada a partir de questões realicionadas à certificação ISO 9000 e ao conhecimento e uso do modelo CMM - Capabibity Maturity Model, Projeto SPICE - Software Process Improvement and Capability determination (Tecchinal Report ISO/IEC 15504) e Norma Internacional ISO/IEC Categorias Certificação ISO Certificação ISO SW explicitado no - escopo Empresas certificadas Os agentes de software brasileiros, responsáveis pela formulação e execução da Política de Software Paías, vêm disseminando a cultura da qualidade nas empresas e já promovem treinamento para milhares de profissionais. A sociedade SOFTEX tem conduzido a divulgação do CMM junto a suas empresas associadas, contribuindo para a mundança do perfil de conhecimento inicialmente encontrado. CMM Conhece e Usa Conhece, mas Não Usa Não Conhece