Qualidade em Software. edson3@ig.com.br tentrindadevivas@esaex.mil.br

Qualidade em Software EDSON TRINDADE RESSUREIÇÃO HAMILTON TRINDADE VIVAS EsAEx Escola de Administração do Exército, R. Território do Amapá, Nº455, Pituba, Salvador BA, Brasil edson3@ig.com.br tentrindadevivas@esaex.mil.br Resumo: Este artigo tem como objetivo proporcionar ao leitor uma visão geral dos conceitos e os diferentes tipos de modelos de qualidade de software. Esta obra tem como público-alvo pessoas interessadas em conhecer as idéias básicas das diversas técnicas para melhorar a qualidade dos softwares e seus processos de elaboração, através do planejamento, implementação e controle de modelos de qualidade de software. Este artigo aborda os seguintes assuntos A Melhoria da Qualidade de Software; Produto e Processo; Requisitos de Software; Medição de Software; Padrões no desenvolvimento de software; Garantia da Qualidade de Software; Atividades de SQA (Software Quality Assurance); Qualidade de produto e a ISO/IEC 9126; As características da ISO/IEC 9126; Avaliação a partir da ISO/IEC 9126; ISO 9000-3 e ISO 9001; Uso da IS0 9001 para melhoria da qualidade; CMM: Capability Maturity Model e Características de uma empresa imatura. Palavras-chaves. qualidade em software, requisitos de sotware, modelos de software. Abstract: This article has as objective to provide to the reader a general vision of the concepts and the different types of models of quality of software. This workmanship has as public-target people interested in knowing the ideas basic of the diverse techniques to improve the quality of softwares and its processes of elaboration, through the planning, implementation and control of models of quality of software. This article approaches the following subjects The Improvement of the Quality of Software; Product and Process; Requirements of Software; Measurement of Software; Standards in the software development; Guarantee of the Quality of Software; Activities of SQA (Software Quality Assurance); Quality of product and ISO/IEC 9126; The characteristics of ISO/IEC 9126; Evaluation from ISO/IEC 9126; ISO 9000-3 and ISO 9001; Use of IS0 9001 for improvement of the quality; CMM: Capability Maturity Model and Characteristics of an immature company. Key words. quality of software, requirements of software, models of quality of software. 1. Introdução Há algumas décadas, a preocupação com a qualidade estava centrada diretamente no produto final. Esta abordagem parecia apropriada àquela época uma vez que estava mais próxima da percepção do usuário. Dentro deste espírito realizava-se o chamado controle da qualidade verificando-se a adequação do produto nos estágios finais no processo de produção. O setor de software, apesar de mais moderno teve um histórico semelhante. Inicialmente as atividades de teste procuravam auxiliar na depuração do produto, liberando-o de possíveis problemas de funcionamento, os bugs. Assim para que um produto de software fosse considerado de boa qualidade bastava garantir que ele não tinha problemas de funcionamento (bugs). Isto era feito tanto nos estágios finais da produção quanto em estágios intermediários (CÔRTES, 2001, pg.35). Alguns dos desenvolvedores de software continuam a acreditar que qualidade de software é algo com que você começa a se preocupar depois que o código foi gerado. Nada poderia estar mais longe da verdade. Garantia da qualidade de software (software quality assurance, SQA) é uma atividade que é aplicada ao longo do processo de software (PRESSMAN, 2002, pg.187). Segundo Pressman (PRESSMAN, 2002, pg. 193) qualidade de software pode ser definida como: Conformidade com os requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente. Analisando esta definição concluímos que a capacidade de um software atender a um propósito definido sob condições definidas é fundamental para

a atender os requisitos da qualidade. A crescente utilização de sistemas baseados em computação em praticamente todas as áreas da atividade humana provoca uma crescente demanda por qualidade e produtividade, tanto do ponto de vista do processo de produção como do ponto de vista dos produtos de software gerados. Nessa perspectiva, atividades agregadas sob o nome de Garantia de Qualidade de Software têm sido introduzidas ao longo de todo o processo de desenvolvimento de software. Este artigo tem como proposta apresentar os conceitos de Qualidade de Software adequando o nível de profundidade dos assuntos abordados aos objetivos deste trabalho. Serão discutidos conceitos de normalização, medição e certificação baseadas nos modelos mais utilizados e difundidos pelo mercado suas inter-relações, limitações, perspectivas iniciando pela apresentação de algumas idéias e abordagens de qualidade de software que tiveram importância histórica no aparecimento dos modelos atuais. 2. Qualidade de Software Hoje em dia muita gente fala em qualidade de software, mas nem sempre as pessoas têm uma noção clara desse conceito. Pode-se considerar qualidade sob diferentes pontos de vista e, portanto, pode-se ter diferentes definições sendo algumas das mais comuns listadas a seguir. - Software sem defeitos. - Software adequado ao uso (conforme a definição de qualidade de Juran). - Software que atente as especificações (conforme a definição de qualidade de Crosby). - Software produzido por um empresa que possui o certificado ISO 9000 para seu sistema de qualidade. - Software que possui confiabilidade / usabilidade / manutenibilidade. Pessoas com diferentes interesses sobre um produto têm visões diferentes sobre o conceito de qualidade. Por exemplo, clientes (mercado) usualmente consideram que o software tem qualidade se possui características que atendam suas necessidades. Desenvolvedores usualmente vêem a qualidade através das medidas de suas propriedades que são comparadas com indicadores de qualidade que são preestabelecidos. Para o setor de software um produto de qualidade é aquele com custo mínimo associado ao retrabalho durante o desenvolvimento e após a entrega do produto. Não tem sentido produzir um grande sistema de software se ele não funciona, não faz exatamente o que o cliente espera, não fica pronto no prazo ou se não puder merecer confiança, ou ainda, se não puder ser modificado ou mantido. O software é desenvolvido a um custo cada vez maior, com menor produtividade e com menos qualidade. Equipes individuais de projeto tentam ser mais produtivas mas, no contexto de uma empresa que não se preocupa com a qualidade, tais esforços no nível de projeto provavelmente não trarão resultados expressivos, visto que na maioria dessas empressas vários projetos de desenvolvimento de sistemas são cancelados antes de serem concluídos. Isto significa que iniciativas individuais de programadores e analistas de sistemas para melhoria de qualidade dificilmente mudarão a cultura da empresa onde os sistemas são desenvolvidos. Mais importantes são as iniciativas no nível corporativo (CÔRTES, 2001, pg.28). Mesmo o mais exausto desenvolvedor de software vai concordar que software de alta qualidade é uma meta importante. Muitas definições de qualidade de software têm sido propostas na literatura. Para os objetivos deste artigo poderemos definir a qualidade de software como: Conformidade com requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente. 3. A Melhoria da Qualidade de Software Quando uma empresa diz que é a favor da qualidade sem tomar nenhuma atitude nesse sentido, nada acontecerá. Usar chavões do tipo qualidade é prioridade número um não exerce impacto real sobre o trabalho que está sendo executado, a menos que isso esteja combinado com alguma ação real de melhoria de qualidade. Até mesmo uma ênfase maior aos testes deve causar pouco efeito na qualidade do software, pois, como se sabe, a maioria das técnicas de teste tem eficiência abaixo de 30% para descobrir defeitos. A maioria das empresas tem como alvo a entrega do software no prazo. Infelizmente isso, em geral, significa que o cliente recebe um produto defeituoso no prazo. Hoje em dia por causa da concorrência é necessário baixar o custo do software, o que quase sempre acaba implicando redução de qualidade, o que leva à insatisfação do cliente com a baixa qualidade do produto, que teve um custo inicial baixo, mas um custo total alto. É possível construir software com alta qualidade, no prazo e a baixo custo, mas não da forma caótica como é frequentemente feito hoje. Quando um problema ocorre, a reação é corrigir o problema seja ele importante ou não. O gerenciamento da qualidade permite que a empresa como um todo aprenda, com a correção de problemas, mais rapidamente e eficazmente. O controle de qualidade permite que corrijam os sintomas observáveis do problema. Devese reunir esforços para resolver a raiz da causa do problema no produto. A cultura da empresa deve mudar para aplicar com sucesso abordagens de prevenção dos defeitos e de melhoria dos processos. Não basta criar uma equipe formal de garantia da qualidade de software (CÔRTES, 2001, p.29). 4. Produto e Processo

Pode-se dizer que o produto de software é não diretamente observável à medida que ele só pode ser percebido indiretamente, por meio de alguma forma de visualização. Atualmente existe um número muito grande de ferramentas que permitem a visibilidade do produto de software. São elas: listadores-fonte, listagens de referência cruzada, diagrama de fluxo de dados, diagrama de modelo de dados, formato de entrada de dados, formato de entrada de dados, formato das saídas e muitos outros (CÔRTES, 2001, pg.29). A cada dez anos, avançando ou recuando cinco, a comunidade de software redefine o problema mudando o foco, de aspectos do produto para aspectos do processo. Assim, adotamos linguagens de programação estruturada (produto), seguidas por métodos de análise estruturada (processo), seguidos de encapsulamento dos dados (produto), seguido pela ênfase atual no Modelo de Maturidade de Capacidade de Desenvolvimento de Software do Instituto de Engenharia de Software (SEI) (processo). Toda a atividade humana pode ser um processo, mas cada um de nós obtém um senso de autovalor daquelas atividades que resultam numa representação ou instância, que pode ser usada ou apreciada por mais de uma pessoa, utilizada repetidamente, ou empregada em algum outro contexto não considerado. Isto é, obtemos um sentimento de satisfação pelo reuso de nossos produtos, por nós mesmos ou por outros (DAVIS, 1995). 5. Requisitos de Software Em engenharia de software a palavra especificação pode ser usada em vários contextos com diferentes significados e em diferentes níveis de abstração, desde a especificação de requisitos de software propriamente dita, acordada entre o adquirente e a empresa de desenvolvimento, até a especificação de implementação de um módulo isolado. A Norma ISO 8402 [ISO8402] define Qualidade como a totalidade de características de uma entidade que lhe confere a capacidade de satisfazer as necessidades explícitas e implícitas (PUCRS, 2003). Necessidades explícitas são aquelas expressas na definição de requisitos propostos pelo produtor. Esses requisitos definem as condições em que o produto deve ser utilizado, seus objetivos, funções e o desempenho esperado. As necessidades implícitas são aquelas que, embora não expressas nos documentos do produtor, são necessárias para o usuário. Estão englobados nesta classe tanto requisitos que não precisem ser declarados por serem óbvios (ex: a caneta escreve ) como aqueles requisitos que não são percebidos como necessários no momento em que o produto foi desenvolvido, mas que pela gravidade de suas conseqüências devem ser atendidos (ex: mesmo em condições não previstas, de erro ou má operação, um sistema de administração hospitalar não pode provocar a morte de pacientes) (TSUKUMO, 1997). Em um ambiente onde várias equipes (algumas geograficamente separadas) se ocupam com diferentes etapas do processo de desenvolvimento de software, a importância da especificação cresce sobremaneira, uma vez que serve de guia ao longo de todas as etapas do processo. Independente do nível de abstração de uma especificação, sua principal característica é o fato de que uma especificação deve dizer o que deve ser feito e não como deve ser feito. A fronteira entre o que e como pode ser, por vezes, meio nebulosa, principalmente nos casos em que uma determinada solução é um dos requisitos do sistema. Ex: o banco de dados deve ser Oracle. De qualquer maneira, sempre que possível, a especificação deve evitar detalhes da solução do problema. Outra particularidade de uma especificação é que dificilmente ela será imutável. Novas necessidades podem ser detectadas, e a própria experiência adquirida ao longo do desenvolvimento do sistema pode levar a alterações tanto no projeto como na especificação originais (além disso, as empresas costumam ter departamentos de marketing...). Por esta razão a especificação de requisitos deve ser preparada levando-se em conta esta característica. A partir destas considerações pode-se definir o conjunto de características de uma boa especificação de software: - Não ambígua - Consistente - Completa - Modular Embora dizer que uma especificação não deve ser ambígua pareça uma obviedade, de fato esta questão não é tão simples quando se usa língua natural para especificar requisitos. O que pode ser natural para alguém pode não o ser para outro. Uma solução aparentemente simples para este problema é usar especificação formal. Este tipo de solução, porém, costuma esbarrar na falta tanto de profissionais preparados para gerar tais especificações como para ler as mesmas. Um pouco de cuidado e o uso de ferramentas simples, tais como português estruturado e máquinas de estado podem minimizar os problemas. Inconsistências em especificações dizem respeito a declarações contraditórias de maneira que nenhuma implementação poderá satisfazer tal especificação. A probabilidade de se inserirem inconsistências aumenta na medida em que aumenta o tamanho e a complexidade dos documentos. Uma especificação deve ser completa em dois sentidos: Internamente completa: todos os termos ou conceitos novos devem estar definidos. Completa em relação aos requisitos: todas as necessidades devem estar cobertas. Por fim uma especificação deve ser modular, com

módulos coesos e fracamente acoplados, da mesma forma que um software. A razão para tanto é a necessidade freqüente de alterações que devem, na medida do possível, se refletir no menor número de alterações no documento (PUCRS, 2003). 6. Medição de Software Medições no mundo físico podem ser categorizadas de dois modos: medidas direta (p. ex., o comprimento de um parafuso) e medidas indiretas (p. ex. a qualidade dos parafusos produzidos, medida pela contagem dos refugos). Métricas de software podem ser categorizados analogamente. Medidas diretas do processo de engenharia de software incluem custo e esforço aplicados. Medidas diretas do produto incluem linhas de código (linus of code, LOC) produzidas, velocidade de execução, tamanho de memória e defeitos relatados durante um certo período. Medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade e muitas outras habilidades. O custo e esforço necessários para construir software, o número de linhas de código produzidas e outras medidas diretas são relativamente fáceis de coletar, desde que conveções específicas para a medição sejam estabelecidas antecipadamente. Todavia, a qualidade e a funcionalidade do software, ou a sua eficiência, ou manutenibilidade são mais difíceis de avaliar e podem ser medidas apenas indiretamente. Podemos particionar o domínio das métricas de software em métricas de processo, de projeto e de produto. Também podemos disser que as métricas de produto, que são privadas para um indivíduo, são freqüentemente combinadas para desenvolver métricas de projeto, que são públicas para uma equipe de software. Métricas de projeto são então consolidadas para criar métricas de processo, que são públicas para toda a organização de software. Mas como uma organização combina métricas originárias de diferentes indivíduos ou projetos? Para ilustrar, podemos considerar um exemplo simples. Indivíduos em duas diferentes equipes de projeto registram e categorizam todos os erros que encontram durante o processo de software. Medidas individuais são então combinadas para desenvolver medidas da equipe. A equipe A encontrou 184 erros. Sendo todas as outras coisas iguais, qual equipe é mais efetiva na descoberta de erros ao longo do processo? Como não sabemos o tamanho ou a complexidade dos projetos, não podemos responder a essa questão. Todavia, se as medidas são normalizadas, é possível criar métricas de software que permitem comparação com médias organizacionais mais amplas (PRESSMAN, 2002, pg. 83). 7. Padrões no desenvolvimento de software O desenvolvimento de software produz uma seqüência de produtos relacionados: requisitos, projeto, codificação, teste e manutenção. O produto final deve atender ao usuário final do sistema. Além disso, produtos intermediários são gerados nas etapas dos vários processos de produção como insumos de entrada para a etapa seguinte (CÔRTES, 2001, pg.29). O American Heritage Dictionary define qualidade com uma característica ou atributo de alguma coisa. Como atributo de um item, a qualidade se refere a características mensuráveis coisas que nós podemos comparar com padrões conhecidos tais como comprimento, cor, propriedades elétricas e maleabilidade. Todavia, o software, que é essencialmente uma entidade intelectual, é mais difícil de caracterizar do que objetos físicos. No entanto, existem medidas das características de um programa. Essas propriedades incluem a complexidade ciclomática, a coesão, o número de pontos por função, linhas de código e muitas outras propriedades. Quando examinamos um item baseado em suas características mensuráveis, duas espécies de qualidade podem ser encontradas: qualidade de projeto e qualidade de conformidade. Qualidade de projeto refere-se a características que os projetistas especificam para um certo item. A gradação dos materiais, as tolerâncias e as especificações de desempenho todas contribuem para a qualidade do produto. À medida que materiais de alta gradação são usados, tolerâncias mais estritas e níveis de desempenho maiores são especificados, a qualidade do produto aumenta, se o produto é manufaturado de acordo com as especificações. Qualidade de conformidade é o grau com que as especificações de projeto são seguidas durante a fabricação. Outra vez, quanto maior o grau de conformidade, maior é o nível da qualidade de conformidade. No desenvolvimento de software, a qualidade do projeto abrange os requisitos, as especificações e o projeto do sistema. A qualidade da conformidade é um assunto concernente, principalmente à implementação. Se a implementação segue o projeto e o sistema resultante satisfaz os requisitos e metas de desempenho, a qualidade de conformidade é alta (PRESSMAN, 2002, pg.189). Padrões de projeto de software fornecem definições básicas do que deve ser produzido em cada estágio de desenvolvimento. Esses padrões descrevem em detalhes o que é para ser incluído em cada produto intermediário e como isto deve aparecer. Padrões de software fornecem critérios específicos para se medir a qualidade e avaliar a aceitabilidade dos produtos de software. Eles definem formato, estrutura e conteúdo de cada produto intermediário e asseguram a compatibilidade do produto com aqueles produtos que têm interface com outros produtos, ou são usados em fases subsequentes do desenvolvimento, ou com produtos de documentação.

Chama-se produtibilidade a facilidade de se estabelecer um processo de produção eficiente e eficaz. Essa característica pode ser esperada da transformação do produto da fase de projeto para a codificação, do produto da codificação para a fase de teste e do produto do teste para a manutenção. A rastreabilidade possibilita que sejam verificados os objetivos funcionais e de desempenho (requisitos) do sistema de software. Se de forma geral a conformidade com os padrões não promove a qualidade, ela assegura um produto correto ou um processo eficiente. Padrões sozinhos não podem previnir erros técnicos. Para controlar e melhorar a qualidade deve-se estabelecer medidas de forma que ações apropriadas possam ser tomadas quando os valores medidos não estão dentro dos esperados (CÔRTES, 2001, pg.30). 8. Garantia da Qualidade de Software A garantia da qualidade é uma atividade essencial para qualquer negócio que faz produtos para serem usados por outros. Antes do século vinte, a garantia da qualidade era de responsabilidade tão somente do artesão que construía um produto. Hoje, toda empresa tem mecanismos para garantir a qualidade de seus produtos. Na realidade, declarações explícitas da preocupação da empresa com a qualidade tornaram-se estratégia de mercado durante as últimas décadas (PRESSMAN, 2002, pg.194). Muitas definições de qualidade de software têm sido propostas, mas para efeito de estudo vamos considerar a seguinte: Conformidade com requisitos funcionais e de desempenho explicitamente declarados, padrões de desenvolvimento explicitamente documentados e características implícitas, que são esperadas em todo software desenvolvido profissionalmente. Existe pouca dúvida de que essa definição poderia ser modificada ou estendida. De fato, uma definição de qualidade de software poderia ser debatida indefinidamente. Para a finalidade deste artigo, a definição serve para enfatizar três pontos importantes: 1) Os requisitos de software são a fundação a partir da qual a qualidade é medida. A falta de conformidade com os requisitos é falta de qualidade. 2) Os padrões especificados definem um conjunto de critérios de desenvolvimento que guia o modo pelo qual o software é submetido à engenharia. Se os critérios não são seguidos, irá ocorrer, quase certamente, a falta de qualidade. 3) Um conjunto de requisitos implícitos freqüentemente não é mencionado (p. ex., o desejo de facilidade de uso e boa manutenibilidade). Se software satisfaz seus requisitos explícitos mas deixa de satisfazer os requisitos implícitos, a qualidade do software é suspeita (PRESSMAN, 2002, pg.500). 9. Atividades de SQA (Software Quality Assurance) A garantia da qualidade de software é composta de uma variedade de tarefas associadas a duas partes diferentes os engenheiros de software que fazem o trabalho técnico e um grupo de SQA, que tem responsabilidade pelo planejamento, supervisão, registro, análise e relato da garantia da qualidade. Os engenheiros de software buscam a qualidade (e desenvolvem atividades de garantia da qualidade e de controle de qualidade) aplicando métodos e medidas técnicas sólidas, conduzindo revisões técnicas formais e efetuando teste de software bemplanejado. A missão do grupo de SQA é ajudar a equipe de software a conseguir um produto final de alta qualidade. O software Engineering Institute recomenda um conjunto de atividades de SQA que trata do planejamento, supervisão, registro, análises e relato da garantia da qualidade. Essas atividades são executadas (ou facilitadas) por um grupo independente de SQA que: Prepara um plano SQA para um projeto. O plano é desenvolvido durante o planejamento do projeto e é revisado por todas as partes interessadas. As atividades de garantia da qualidade, realizadas pela equipe de engenharia de software e pelo grupo de SQA, são regidas pelo plano. O plano identifica: - avaliações a serem realizadas. - auditorias e revisões a serem realizadas. - padrões que são aplicáveis ao projeto. - procedimentos para relato e acompanhamento de erros. - documentos a serem produzidos pelo grupo de SQA. - quantidade de realimentação fornecida à equipe de projeto do software. Participa no desenvolvimento da descrição do processo de software para verificar a satisfação do processo de software definido. O grupo de SQA identifica, documenta e acompanha desvios, verifica se as correções são feitas. Audita os produtos do trabalho de software encomendado para verificar a satisfação do que foi definido como parte do processo de software. O grupo de SQA revê produtos selecionados do trabalho, identifica, documenta e acompanha desvios, verifica se as correções são feitas e periodicamente relata os resultados do seu trabalho ao gerente de projeto. Garante que os desvios do trabalho de software e dos produtos do trabalho são documentados e manipulados de acordo com um procedimento documentado. Os desvios podem ser encontrados no plano de projeto, na descrição do processo, nos padrões aplicáveis ou nos produtos do trabalho técnico. Registra qualquer eventual não satisfação e a relata à gerência superior. Os itens que não atendem ao padrão são acompanhados até que sejam resolvidos (PRESSMAN, 2002, pg.194).

10. Qualidade de produto e a ISO/IEC 9126 Com o passar do tempo dois fatores causaram mudanças na abordagem sobre a qualidade. Em primeiro lugar houve o fortalecimento do conceito de foco no cliente. Hoje em dia o cliente, ou o mercado, passou a ter um peso maior que o fabricante na definição das características desejáveis em um produto de software. Em segundo lugar, com a evolução da tecnologia, um grande número de recursos e características tornou-se disponível. Naturalmente estes atributos passaram também a ser importantes componentes na avaliação da qualidade do produto, além da simples correção do funcionamento. A evolução da tecnologia tem esta característica de elevar os padrões mínimos das expectativas dos clientes ( ou usuários ). Essa evolução de percepção pode ser constatada comparando-se os trechos seguintes das definições da ISO para confiabilidade em geral [ISO 8402] e para confiabilidade de software [ISO 9126]. Confiabilidade segundo a ISO 8402: A capacidade de um item desempenhar uma função requerida... Confiabilidade de software segundo a ISO/IEC 9126: Um conjunto de atributos que tem impacto na capacidade do software de manter seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo. Assim, pode-se ver que a definição de confiabilidade foi ampliada para acomodar dentro da expressão nível de desempenho outras características além da funcionalidade. Os atributos adicionais que foram aparecendo de acordo com a necessidade e a evolução da tecnologia foram sistematizados pela norma ISSO/IEC 9126 (versão brasileira [NBR ISSO 13596]). Esse modelo de qualidade de produto pode ser usado de diferentes maneiras por diferentes atores, sejam eles o usuário, o desenvolvedor e o gerente de desenvolvimento. Dentre os diversos usos da ISSO/IEC 9126, sem dúvida, o de maior visibilidade pública é o de modelar o processo de avaliação de produto de software, desde a seqüência de atividades empregadas até a discussão sobre as métricas mais apropriadas para a pontuação (CÔRTES, 2001, p.35). 11. As características da ISO/IEC 9126 Além da funcionalidade, a ISO/IEC 9126 incorporou cinco novas características passando a contar com seis, a saber: - Funcionalidade. Conjunto de funções especificadas e suas propriedades. As funções devem satisfazer as necessidades implícitas e explícitas do usuário. Este conjunto de atributos caracteriza o que o software faz para satisfazer as necessidades, enquanto as demais caracterizam como e quando ele faz. - Confiabilidade. Medida da capacidade do software de manter seu nível de desempenho dentro de condições estabelecidas por um dado período de tempo. - Usabilidade. Medida do esforço necessário ao uso do software por um usuário de perfil determinado explícita ou implicitamente. - Eficiência. Relação entre o nível de desempenho do software e a quantidade de recursos utilizada, sob condições de uso preestabelecidas. - Manutenibilidade. Medida do esforço necessário para fazer alterações no produto de software. - Portabilidade. Medida da facilidade do produto de software ser transferido para outro ambiente operacional. Diferentes atores podem ter diferentes visões e expectativas sobre o que seja um software de qualidade. A norma ISO/IEC 9126 apresenta três visões, a do usuário, a do desenvolvedor e a do gerente de desenvolvimento. Visão do usuário. O usuário está interessado na utilização do produto de software, no seu desempenho e nos efeitos do seu uso, quaisquer que sejam suas características construtivas. Pode-se dizer, nesse caso, que o usuário está interessado nas medidas externas da qualidade. A visão do desenvolvedor. O processo de desenvolvimento requer que o usuário e o desenvolvedor usem um conjunto de características da qualidade, uma vez que elas devem ser utilizadas nos requisitos e na aceitação do produto. Para produtos de prateleira o desenvolvedor deve procurar atender também aos requisitos implícitos da qualidade. Para alcançar com maior segurança os objetivos da qualidade do produto final, frequentemente o desenvolvedor verifica a qualidade de produtos intermediários e usa as chamadas medidas internas. O desenvolvedor deve incorporar as expectativas da qualidade das pessoas que posteriormente farão atividades de manutenção. A visão do gerente de desenvolvimento. O gerente de desenvolvimento pode estar mais interessado em uma medida da qualidade geral do que em uma característica específica e, por este motivo, pode ponderar cada uma delas para obter uma visão mais próxima dos objetivos do negócio da empresa. Certamente também procurará equilibrar as melhorias da qualidade do produto com outros critérios, tais como respeito aos cronogramas ou previsões de custo. Esta visão apresentada na ISO/IEC 9126 já é um prenúncio da necessidade de uma abordagem mais abrangente da questão da qualidade e já se aproxima mais do conceito da qualidade de processo, além da qualidade de produto (CÔRTES, 2001, pg.38 ). 12. Avaliação a partir da ISO/IEC 9126 A aplicação da ISO/IEC 9126 na avaliação da qualidade pode se dar nas seguintes situações: - Definição dos requisitos da qualidade de um produto de software.

- Avaliação das especificações do software durante o desenvolvimento para verificar se os requisitos da qualidade estão sendo atendidos. - Descrição das características e atributos do software implementado, por exemplo, nos manuais de usuário. - Avaliação do software desenvolvido antes da entrega do cliente. (CÔRTES, 2001, pg.39). O processo da avaliação da qualidade de produto de software, a partir das características da qualidade definidas pela ISO/IEC 9126 desenvolve-se em três estágios: definição dos requisitos da qualidade, preparação da avaliação e avaliação propriamente dita. - Preparação da avaliação Seleção das métricas da qualidade: Escolha dos critérios para associar quantificações numéricas para cada um dos atributos. Essas métricas podem variar ao longo do ciclo de desenvolvimento, sem deixar de lado a perspectiva de avaliação do usuário. Definição dos níveis de pontuação: Os resultados quantificados são mapeados em escala com regiões sugeridas pela norma, três para a pontuação satisfatório (excelente, bom e razoável) e uma para a pontuação insatisfatório. Definição dos critérios de avaliação: Definição dos critérios para fazer o mapeamento das características para valores numéricos. - Procedimento para avaliação Medida: Aplicação das métricas definidas ao produto de software. Pontuação: Determinação dos valores pontuação. Avaliação: Determinação do resultado final, em termos de aceitação ou não da qualidade do produto (CÔRTES, 2001, pg.40). 13. ISO 9000-3 e ISO 9001 Na sessão anterior foi apresentada a IS0 9126, que trata de atributos da qualidade do produto de software. Observou-se que houve avanço com relação à visão mais antiga que limitava a qualidade intríseca do produto, ou sua confiabilidade. No entanto, nas últimas décadas ganhou aceitação cada vez maior a aplicação de práticas da qualidade a todas as etapas de desenvolvimento e não somente ao produto final. Isto representa a preocupação com os processos envolvidos na produção ao invés de preocupação apenas com o produto. Além disso, com os conceitos da qualidade de processos, passaram a ser objeto de atenção todos os processos que tenham algum efeito na percepção do cliente sobre a qualidade do produto e não apenas os processos de produção. Exemplos de processos importantes não localizados diretamente na cadeia de produção são treinamento e aquisição. A IS0 elaborou norma de aplicação geral neste sentido, concebida inicialmente para o setor de manufatura mas em seguida estendida a todas as áreas de atividade econômica. Hoje essas normas são aplicáveis à indústria em geral e ao setor de serviços de todas as naturezas. Essas normas da série IS0 9000 e a sua aplicação são: a) IS0 9000 (NBR IS0 9000, versão brasileira da ABNT): Normas de gestão da qualidade e garantia da qualidade. Diretrizes para seleção e uso. Este documento auxilia a empresa na seleção da norma mais apropriada para o seu negócio e na sua utilização e é não normativo. b) IS0 9001 (NBR IS0 9001): Sistemas da qualidade. Modelo para garantia da qualidade em projeto, desenvolvimento, produção, instalação e assistência técnica. Esta é a norma mais geral da série e pode ser aplicável a qualquer empresa ou atividade. c) IS0 9002 (NBR IS0 9002): Sistemas da qualidade. Modelo para garantia da qualidade em produção e instalação. Esta norma aplica-se a empresas que não têm atividades de desenvolvimento como, por exemplo, serviços em geral (exceto os de projeto). d) IS0 9003 (NBR IS0 9003): Sistemas da qualidade. Modelo para garantia da qualidade em inspeção e ensaios finais. Esta norma é restrita à área de inspeção e testes. e) IS0 9004 (NBR IS0 9004): Gestão da qualidade e elementos do sistema da qualidade. Diretrizes. Este documento traz orientações gerais para a implantação de gestão da qualidade e não é normativo. Os documentos IS0 9000 e 9004 contêm apenas diretrizes e orientações e são não normativos. Os documentos normativos, e para os quais faz sentido falar em certificação de uma empresa, são apenas as normas IS0 9001, 9002 e 9003 (CÔRTES, 2001, pg.44 ). As normas da série IS0 9000 foram desenvolvidas para a aplicação em qualquer setor produtivo. Obviamente o setor de manufatura teve um peso importante na definição dos requisitos e isto pode ser percebido na redação da IS0 9001. Para facilitar a sua aplicação em desenvolvimento de software, a IS0 desenvolveu o guia IS0 9000-3: IS0 9000-3: diretrizes para a aplicação da IS0 9001 ao projeto, desenvolvimento, fornecimento, instalação e manutenção de software. A IS0 9000-3 é organizada de maneira que, para cada elemento da IS0 9001, é apresentada uma interpretação para as empresas de software. O texto original da IS0 9001, via de regra, traz requisitos obrigatórios (verbos deve ou shall em inglês). Já as interpretações da IS0 9000-3 têm mais o caráter de observações ou recomendações de são redigidas com os verbos should ou may ( deveriam ou podem ). Em outras normas da ABNT o verbo should e trazido como convém que, como uma recomendação. Outra norma da IS0 para a aplicação em desenvolvimento de software é a IS0 12207, que trata dos processos do ciclo de vida de software. Essa norma tem muitos pontos de contato com a IS0 9000-3. Pode-se definir auditoria da qualidade como o processo sistemático e independente usada para

verificar a conformidade das práticas, produtos e procedimentos da empresa com relação às normas e regras estabelecidas (CÔRTES, 2001, p.44). As auditorias têm normalmente um ou mais dos seguintes objetivos: - determinar a conformidade ou não-conformidade dos elementos do sistema da qualidade com requisitos especificados. - determinar a eficácia do sistema da qualidade implementado no atendimento aos objetivos da qualidade especificados. - prover ao auditado uma oportunidade de melhorar o sistema da qualidade. - atender aos requisitos regulamentares. - permitir o cadastramento do sistema da qualidade da organização auditada em um registro. Geralmente as auditorias são realizadas por uma ou mais das seguintes razões: - avaliar inicialmente um fornecedor quando se pretende estabelecer uma relação comercial. - verificar se o sistema da qualidade da própria organização continua a atender aos requisitos especificados e se está sendo implementado. - Verificar, dentro de uma relação contratual, se o sistema da qualidade do fornecedor continua a atender aos requisitos especificados e se está sendo implementado. - avaliar o sistema da qualidade da própria organização frente a uma norma de sistema da qualidade. Estas auditorias podem ser de rotina ou provocadas por mudanças significativas no sistema da qualidade da organização, na qualidade do processo, produto ou serviço, ou pela necessidade de acompanhar uma ação corretiva (XAVIER, 2000). 14. Uso da IS0 9001 para melhoria da qualidade A aplicação de técnicas da qualidade nas empresas deve servir como instrumento para aumentar a efetividade do negócio, em termos de satisfação do cliente, participação no mercado, relacionamento com a comunidade e melhoria dos resultados econômicos. Infelizmente, muitas empresas têm encarado essas atividades como um investimento, porém visando unicamente dois possíveis retornos: a) satisfação de exigências dos clientes de certificação IS0 9000 para manutenção dos contratos de fornecimento; b) elemento de marketing ou imagem, visando diferenciar-se ou igualar-se aos concorrentes. Esses dois motivos são importantes, mas são muito menos do que um programa da qualidade pode oferecer. O sistema da qualidade deveria ser encarado como um instrumento para estabelecer um programa de melhoria contínua, sempre garantindo um alinhamento entre os objetivos de negócio e o real funcionamento da empresa (CÔRTES, 2001, pg.60). 15. CMM: Capability Maturity Model A assim chamada crise do software foi identificada há duas ou três décadas e tem se tornado cada vez mais grave em função da disseminação do uso do software em todas as atividades humanas, desde as industriais, de serviços e até de entretenimento. O Departamento da Defesa norte-americano, ao observar que a situação dos seus contratos de desenvolvimento tornara-se insustentável, patrocinou a fundação do Software Engineering Institute (SEI), em 1984, visando criar condições para a evolução das boas práticas de engenharia de software. O objetivo era de que fosse alcançado, nos projetos de desenvolvimento de software dos fornecedores do DoD(Department of Defense) norte-americano, o mesmo nível de repetibilidade e controle encontrado em outros setores da atividade industrial, tais como a manufatura e a construção civil. A Universidade de Carnegie Mellon em Pittsburgh, nos Estados Unidos, foi selecionada para administrar o recém criado SEI. Já em setembro de 1987 o SEI publicou uma descrição sumária do assim chamado modelo de maturidade de software. Esse estudo foi base para o livro que apresentou os fundamentos do modelo de maturidade de software, Managing the software process. Depois de quatro anos de experimentação o SEI publicou o Capability maturity model (CMM). O CMM propõe a: a) ser baseado em experência prática de empresas de software; b) refletir o melhor do estado da prática; c) atender as necessidades daqueles que realizam melhoria do processo de software e avaliação do processo de software; d) ser documentado e estar disponível publicamente (CÔRTES, 2001, pg.65). 16. Características de uma empresa imatura Para entender o tipo de benefício que uma empresa pode ter engajando-se em um programa de evolução de maturidade, é interessante observar as diferenças entre uma empresa madura e outra imatura. Em uma empresa imatura os processos de desenvolvimento são improvisados ou, se existem, não são seguidos sistematicamente. Algumas características de uma empresa imatura: a) o trabalho é feito em regime de emergência (apagar incêndio). b) dificilmente os compromissos de prazo e custo são cumpridos, c) não é costume fazer planejamento com base em estimativas realistas. d) como os processos não são bem definidos, eventuais iniciativas de melhoria não se sustentam e não se perpetuam.

e) quando o projeto é pressionado por prazo, características de qualidade e funcionamento do produto são sacrificadas. f) o sucesso de um projeto depende muito de alguns poucos especialistas (gurus) que resolvem todos os grandes problemas ou lançam mão freqüentemente de novas tecnologias como solução milagrosa. Usando uma metáfora adaptada de Humphrey, uma empresa imatura assemelha-se a uma equipe de futebol de várzea, onde alguns jogadores correm desordenadamente atrás da bola enquanto outros assistem apáticos e desinteressados. Não há estrutura orgânica nem espírito de equipe. Entretanto, vale a ressalva que empresas imaturas podem apresentar eventualmente produtos de boa qualidade. Mas o fazem mais como resultado da existência de jogadores excepcionais, ou um técnico excepcional, do que propriamente por mérito da equipe. Além disso os seus resultados são irregulares, imprevisíveis e normalmente têm custos fora do controle (CÔRTES, 2001, pg.66). O modelo CMM é construído a partir do conceito de processo. Um processo integra pessoas, ferramentas e métodos para executar uma seqüência de passos com o objetivo definido de transformar determinadas entradas em determinadas saídas. Na terminologia CMM um processo só pode assim ser chamado quando é executado. Uma definição (ou descrição) de um processo é apenas uma descrição, não é o processo. No tripé que constitui o processo, os três componentes são importantes. Em muitas empresas é colocada a ênfase em treinamento (pessoas) e ferramentas (Case). O benefício resultante dessa abordagem certamente cresce no início, mas satura-se rapidamente se nada for feito visando os métodos e o funcionamento harmônico dos três componentes. Uma premissa implícita do modelo CMM é que a qualidade de um produto é determinada em grande medida pela qualidade dos processos utilizados na sua produção e manutenção. Na medida em que a maturidade dos processos de software de uma empresa evolui. Os processos passam a ser mais bem definidos e mais institucionalizados nas organizações e com maior equilíbrio entre os seus três componentes. A capacidade de um processo de software descreve a faixa de resultados esperados dentro de uma margem de probabilidade. A maturidade do processo reflete em que medida ele pode ser definido, gerenciado, medido, controlado e executado de maneira eficaz. O modelo CMM nasceu sob influência das teorias e conceitos para a qualidade propostos por Shewhart (PDCA), Deming e Juran. Está baseado na crença, hoje confirmada, que possível estender todos esses conceitos e ferramentas da qualidade para o setor de software (CÔRTES, 2001, pg.67). 17. Conclusão Pelo estudado neste artigo, fica a interrogação: até que ponto a evolução das práticas de qualidade de software está realmente arraigada na indústria? A realidade do mercado, a forte concorrência entre os produtores de software e o crescente nível de exigência do mercado consumidor têm colocado desafios cada vez maiores para os produtores. Hoje em dia, também no setor de software, a qualidade passou a ser uma pré-condição, deixou de ser um diferencial competitivo. Os resultados e as experiências relatadas na literatura conduzem à conclusão que uma empresa de software com pretensões de ser bem sucedida no mercado não pode desconhecer e desprezar essas técnicas. Muitas empresas têm adotado programas de qualidade com o mero objetivo de projetar uma imagem positiva junto aos clientes. Mesmo considerando-se que esse tipo de resultado é realmente alcançado, essa atitude revela uma visão limitada do potencial de retorno que essas técnicas podem proporcionar. A simples adoção de uma postura focalizada no cliente já traz grandes benefícios em todo o ciclo de produção, desde o planejamento estratégico, marketing, até o desenvolvimento do produto propriamente dito e o fornecimento dos serviços de pós-venda. Além disto temos todos os outros benefícios, de redução de custos e prazos e melhoria da competitividade em termos gerais. Para uma empresa que quer iniciar-se nessas práticas pode ser um pouco frustrante a constatação de que não existe um único caminho, uma técnica ou um modelo que garanta o sucesso. Como primeiro passo, interessante pelo menos conhecer as alternativas e suas limitações. Em primeiro lugar, é necessário avaliar os modelos com relação aos seguintes aspectos: - Adequação: o modelo tem aplicação no tipo de negócio em questão? É de aplicação geral ou específica? Estabilidade e estado da prática: o modelo tem um número razoável de usuários? Ele está estabelecido ou está em desenvolvimento? - Suporte: existe auxílio disponível e experimentado no mercado para serviços de treinamento e consultoria? - Custo: o modelo é de propriedade de alguma empresa? Quais são os custos associados à sua aplicação? Em segundo lugar, é necessário analisar o modelo com relação ao tipo de empresa na qual pretende-se aplicá-lo: - Tamanho da organização. - Objetivos do negócio. - Tipo e escala de produção, produto de prateleira ou de desenvolvimento contratado (sob demanda)? - Tipo de mercado-alvo e cliente. - Quais são os fatores críticos para o

desenvolvimento: qualidade intríseca, custo ou prazo? Existem desafios técnicos significativos? Em terceiro lugar, é necessário considerar o tipo de produto em desenvolvimento: - Tamanho e complexidade do software; tamanho da equipe de desenvolvimento. - Domínio da aplicação: aplicação de tempo real, controle, missão crítica, software para entretenimento e educação, etc. (certamente as preocupações com confiabilidade serão muito mais severas em aplicações de missão crítica do que em software para entretenimento). Mesmo com todas essas considerações, é importante ressaltar que todos os modelos descritos e disponíveis na literatura guardam muitas semelhanças entre si e há grande intersecção entre eles. Duas posturas extremamente negativas ao se enfrentar o problema da escolha de um modelo são: paralisia devido à indefinição sobre qual é o melhor modelo; falta de constância na implementação de programas de qualidade com mudanças freqüentes de linhas de ação. O importante é escolher um dos modelos, com os devidos cuidados é claro, mas aplicá-los com determinação e firmeza de propósitos. Referências (CÔRTES, 2001) CÔRTES, Mario Lúcio. Modelos de qualidade de software / Mario Lúcio Côrtes, Thelma C. S. Chiossi Campinas, SP: Editora da Unicamp, Instituto de Computação, 2001. (BARTIÉ, 2002) BARTIÉ, Alexandre Adquirindo Maturidade Organizacional Editora Campus, 2002. Engenharia de Software / Pressman, Roger S. 5.ed Rio de Janeiro, RJ: McGraw-Hill, 2002. (PUCRS, 2003) Pontifícia Universidade Católica do Rio Grande do Sul, Faculdade de Informática - Tópicos Especiais em Engenharia de Software I : Teste de Software Rio Grande do Sul, RS Disponível em http://www.inf.pucrs.br/~flavio/teste/unidade02/aula 04_CaracteristicasDeUmaEspecificacoesDeRequisito s.html Acesso em: 17/07/2003 (TSUKUMO, 1997) TSUKUMO, Alfredo N. Qualidade de Software: Visão de Produtos e Processos de Software / TSUKUMO, Alfredo N., REGO, Claudete M., SALVIANO Clenio F., AZEVEDO Gláucia F.,MENEGHETTI, Luciano K., COSTA, Márcia C., CARVALHO, Mario Bento, COLOMBO, Regina M. T. Disponível em http://www.psphome.hpg.ig.com.br/downloads/proce ssos_produtos.pdf Acesso em: 17/07/2003 (XAVIER, 2000) XAVIER, Sidney José Nogueira Formação de Auditores Internos em Sistemas Normalizados (Ênfase em IS0 9000) / Sidney José Nogueira Xavier, Roberto Ricardo Machado de Andrade, Ricardo Perrone de Mesquita Belo Horizonte, MG: Editora de Desenvolvimento Gerencial, 2000 ( Série ISSO 9000, Vol. 3 ). (DAVIS, 1995) DAVIS, M. J.. Process and Product: Dichotomy or Duality/ ACM Press, vol 20, n 2, April 1995 transcrito do (PRESSMAN, 2002). (MAXIMIANO, 1995) MAXIMIANO, Antonio Cesar Amaru. Introdução à Administração / Antonio Cesar Amaru Maximiano 4.ed. rev. e ampl. São Paulo, SP: Atlas, 1995. (MCT, 2003) Ministério da Ciência e Tecnologia MCT. Evolução da Qualidade no Setor de Software Brasileiro: Quatro Biênios Medindo e Acompanhando Indicadores de Gestão Brasília, DF Disponível em http://www.mct.gov.br/sepin/dsi/qualidad/artigos.ht m Acesso em: 11/05/2003 (PRESSMAN, 2002) PRESSMAN, Roger S.