21. Qualidade de Produto ou Qualidade de Processo de Software?

Transcrição

1 21. Qualidade de Produto ou Qualidade de Processo de Software? Qualidade de software é uma preocupação real e esforços têm sido realizados na busca pela qualidade dos processos envolvidos em seu desenvolvimento e manutenção. A mesma preocupação existe com o produto de software desenvolvido onde testes, normas e métodos são utilizados para verificar sua qualidade. No entanto, o software continua com sua qualidade comprometida. Um processo de qualidade não garante um produto de qualidade. Percebe-se, neste ponto, uma lacuna nos esforços que vêm sendo realizados na busca pela qualidade de software. O processo, que irá resultar no produto de software, concentra seus esforços na busca pela qualidade do modo de produção e manutenção do software, enquanto a qualidade do produto de software é focada no produto final, através da constatação de sua qualidade por avaliações no software já acabado. As iniciativas pela busca da qualidade de software descritas acima, denominadas abordagem de processo e abordagem de produto, respectivamente, são de grande valor e tratam seus objetivos de forma exemplar, mas agem de forma isolada. A qualidade do produto de software precisa fazer parte, de maneira mais intensa e formal, das preocupações do processo de desenvolvimento e manutenção. As características de qualidade de um produto de software precisam ser alocadas e verificadas nos produtos de software intermediários ao longo do processo e não apenas no produto já acabado. Este procedimento permite que os desvios no produto sejam detectados durante seu desenvolvimento e manutenção, promovendo assim o redirecionamento necessário ao processo para levá-lo à produção de um produto de software de qualidade. Uma solução simples para resolver esta lacuna é a prática simultânea das duas abordagens para qualidade de software (processo e produto) como, por exemplo, o modelo CMM (Capability Maturity Model for Software), que foca a qualidade do processo de software, e a Norma Brasileira NBR , que aborda as características de qualidade de um produto de software. Modelo de processo CMM O CMM, modelo de processo de software desenvolvido pelo SEI (Software Engineering Institute) a pedido do DoD (Departamento de Defesa dos EUA), descreve os elementos chave de um processo de software eficiente e eficaz, além de indicar uma maneira evolutiva de transformar um processo de software imaturo, onde se trabalha de forma ad hoc, em um processo de software maduro, disciplinado. Desta forma, este modelo pode ser utilizado tanto para definir o nível de maturidade de uma organização, quanto ao seu processo de software, como também para orientar um trabalho de melhoria de processo. São definidos cinco níveis de maturidade que são: 1 Inicial, 2 - Repetível, 3 Definido, 4 Gerenciado e 5 Otimizado. Cada um destes níveis atua como fundação para o nível seguinte e indica a capacidade do processo de software da organização. No Nível 1 de maturidade, o sucesso da organização depende do heroísmo das pessoas. O Nível 2 já possui um planejamento para novos projetos baseado em suas especificações e em experiências de projetos passados similares. A existência de um processo de software padrão para toda a organização é a principal característica de uma organização Nível 3 de maturidade. No Nível 4, a organização consegue um controle quantitativo da qualidade de seu processo de software e dos produtos gerados por ele. Uma organização Nível 5 de maturidade é aquela que consegue promover uma melhoria contínua de seu processo de software de forma organizada e sem prejudicar o bom andamento dos projetos que estão sendo executados.

2 O CMM abrange práticas de planejamento, gerenciamento, desenvolvimento e manutenção de software. Quando estas práticas são realizadas, a organização aumenta sua possibilidade de atingir metas de custo, cronograma, eficiência e qualidade do produto final. Ou seja, uma organização de software imatura pode se transformar em uma organização madura através da execução das práticas deste modelo. Em uma organização de software imatura, o processo geralmente é improvisado e, mesmo quando o processo é especificado, nem sempre é seguido. Esta organização é reativa e os gerentes estão normalmente focados em resolver crises constantes. Quando prazos rígidos são impostos para a entrega do software, normalmente as funcionalidades, assim como a qualidade do produto como um todo, ficam absolutamente comprometidas. Por outro lado, uma empresa madura possui seu processo de software bem definido e institucionalizado por toda a organização. O processo é atualizado e melhorias são desenvolvidas através de testes e/ ou análises da relação custo/benefício. A estrutura do CMM é baseada na definição dos cinco níveis de maturidade onde KPAs (Key Process Areas) são apresentadas como fundamentais para uma empresa de certo nível de maturidade. A KPA possui um conjunto de práticas consideradas chave para que seu propósito seja cumprido na organização. Estas práticas chave são agrupadas de acordo com seu objetivo em relação à KPA, que pode ser: responsabilidades, habilidades, atividades, medições e análises e verificações. Norma NBR A Norma NBR Tecnologia da Informação Avaliação de produto de software: características de qualidade e diretrizes para o seu uso, que foi editada pela ABNT em 1998, é a versão brasileira da Norma ISO/IEC Information Technology Software product evaluation: quality characteristics and guidelines for their use, de O trabalho de elaboração da Norma NBR envolveu em torno de duas dezenas de profissionais especializados de empresas, universidades e centros de pesquisa, que já aplicavam os conceitos em suas atividades profissionais, antes mesmo do texto final ser aprovado como projeto de norma. Um dos motivos que levou a Comissão de Estudo de Qualidade de Software a elaborar a Norma NBR através da tradução do texto base da ISO/IEC 9.126, e não o de criar uma nova norma, foi a crescente integração da economia mundial que clama pela uniformização dos conceitos de qualidade exigindo o uso de textos normativos comuns a todos os países. A NBR estabelece seis características de qualidade que um produto de software deve ter; além de definir um modelo de qualidade de produto de software e apresenta os momentos onde a Norma pode ser aplicada. O modelo de qualidade de produto de software foi definido para apoiar o objetivo de aplicar as características de qualidade numa avaliação de produto de software e, é baseado na definição das características de qualidade de software através de subcaracterísticas. Sua utilização não é obrigatória. O importante, segundo a própria Norma, é perceber a necessidade de se seguir um modelo numa avaliação. As seis características e as subcaracterísticas que as definem, segundo a NBR , são as seguintes:

3 1.Funcionalidade: Adequação Presença de um conjunto de funções e sua apropriação para as tarefas especificadas. Acurácia Geração de resultados ou efeitos corretos. Interoperabilidade Capacidade de interagir com outros sistemas especificados. Conformidade Estar de acordo com normas, convenções e regulamentações. Segurança de acesso Capacidade de evitar acesso não autorizado a programas e dados. 2.Confiabilidade: Maturidade Freqüência de falhas. Tolerância a falhas Capacidade de manter nível de desempenho em caso de falha ou violação nas interfaces. Recuperabilidade Capacidade de restabelecer seu desempenho e restaurar dados após falha. 3.Usabilidade: Inteligibilidade Atributos do software que evidenciam o esforço feito pelo usuário para reconhecer o conceito lógico e sua aplicabilidade. Apreensibilidade Atributos do software que evidenciam o esforço do usuário para aprender sua aplicação. Operacionalidade Atributos do software que evidenciam o esforço do usuário para realizar sua operação e o controle da sua operação. 4.Eficiência: Comportamento em relação ao tempo Tempo de resposta, de processamento e de velocidade na execução de funções. Comportamento em relação aos recursos Quantidade de recursos utilizados. 5.Manutenibilidade: Analisabilidade Esforço necessário para diagnosticar aonde está a deficiência e causas de falhas. Modificabilidade Esforço necessário para realizar as modificações e a remoção de defeitos. Estabilidade Ausência de riscos de efeitos inesperados ocasionados por algumas modificações. Testabilidade Facilidade de ser testado.

4 6.Portabilidade: Adaptabilidade Capacidade de ser adaptado a ambientes diferentes. Capacidade para ser instalado Esforço necessário para a instalação. Conformidade Consonância com padrões ou convenções de portabilidade. Capacidade para substituir Capacidade e esforço necessário para substituir outro software. Esta Norma pode ser aplicada, segundo ela própria, nos seguintes momentos: na definição dos requisitos de qualidade de um produto de software; na avaliação da especificação de software para verificar se ele irá satisfazer a todos os requisitos de qualidade durante o desenvolvimento; descrição de particularidades e atributos do software implementado como, por exemplo, em manuais de usuário; avaliação do software desenvolvido, antes da entrega; e avaliação do software desenvolvido e antes da aceitação. Integrando CMM e NBR A contribuição, promovida pela utilização simultânea de um modelo de processo e da Norma que descreve as características de qualidade de um produto de software, é proporcionar uma alternativa prática para que o desenvolvimento e manutenção de uma organização de software resulte num produto de qualidade, de acordo com os parâmetros que são reconhecidos internacionalmente. Uma estratégia que pode ser adotada é analisar instâncias de um modelo de processo de software com algum potencial para o uso da Norma NBR Apesar do modelo CMM v 1.1 estar sendo substituído, provavelmente ainda este ano, pelo CMMI (Capability Maturity Model Integration), ele ainda é o mais indicado para um trabalho desta natureza por ser bastante conhecido e utilizado em todo o mundo desde Isso faz com que uma aplicação prática em organizações de software seja viável de imediato, promovendo resultados a curto prazo. O grupo de atividades, que concentra práticas chave sugeridas pelo CMM, são de grande importância nesta análise porque descrevem o que deve ser feito para se estabelecer a capacidade do processo de software. A capacidade de todo o processo de software define os limites de resultados esperados quando se segue o processo de software em uso. Ao introduzir a NBR nas práticas chave das atividades, pretende-se expandir seu objetivo para que possam definir também o que deve ser feito para estabelecer a capacidade do produto. A forma de utilização dos conceitos da NBR em instâncias do modelo de processo CMM devem ser simples e de fácil implementação. Um exemplo pode ser extraído da KPA gerenciamento de requisitos definida para organizações de Nível 2 de maturidade. O propósito colocado pelo CMM para esta KPA é o entendimento comum, entre cliente e equipe do projeto de software, sobre os requisitos do cliente a serem implementados no software. Considerando a utilização da Norma NBR em instâncias cabíveis nesta KPA, é agregado valor ao CMM transformando seu propósito para: entendimento comum, entre cliente e equipe do projeto de software, sobre os requisitos do cliente incluindo as características de qualidade a serem implementadas no software.

5 Uma instância nesta KPA é a atividade de número um que diz: o grupo de engenharia de software revê os requisitos a serem alocados antes de incorporá-los ao projeto de software. O documento Especificação de Requisitos de Software deve descrever o comportamento do software esperado pelo cliente. Considerando o uso da NBR nesta atividade, o grupo de engenharia de software revê os requisitos a serem alocados antes de incorporá-los ao projeto de software, procurando garantir a presença das características de qualidade de produto de software, definidas na NBR , na Especificação de Requisitos de Software. As 18 KPAs, definidas pelo modelo de processo CMM, possuem instâncias que podem ser apontadas com oportunidade de envolver e usar os conceitos da Norma NBR Isto reflete que, independente do nível de maturidade da organização, a oportunidade de usar a Norma NBR no processo de software é sempre possível, aplicável e recomendada. Com esta iniciativa simples, o foco estará na qualidade do software e não mais no processo ou no produto final. Ou seja, deve-se executar as melhores práticas no processo para desenvolver e manter um produto que possua as características de qualidade reconhecidas internacionalmente promovendo, desta forma, a melhoria da qualidade do software como um todo. Bibliografia Carnegie Mellon University. SEI Software Enginnering Institute. The Capability Maturity Model: Guidelines for Improving the Software Process. 14. ed. EUA: Addison Wesley Longman, Associação Brasileira de Normas Técnicas. TI Avaliaçao de produto de software: Características de qualidade e diretrizes para o seu uso, NBR RJ. SEI (Software Enginnering Institute) Paulk, M. C.; et al. The Capability Maturity Model for Software. Pittsburgh: SEI Software Engineering Institute, ABNT (Associação Brasileira de Normas Técnicas) www. abnt.org.br. International Organization for Standarlization. Information technology Software product evaluation: Quality characteristics and guidelines for their use, ISO/IEC Genebra, Master, S. An Overview of Capability Maturity Model Integration (CMM ISM): version 1.0. In: SIMPROS 2000 Simpósio Internacional de Melhoria de Processo de Software, 2, 2000, SP. Anais do SIMPROS SP, Autor: Mary Lucy Sant'Ana & Ana Cervigni Guerra Biografia: Mary Lucy Sant'Ana ([email protected]) é analista de sistemas, matemática e mestranda em Gestão da Qualidade Total, na UNICAMP. Trabalha há 22 anos na área de qualidade. Ana C. Guerra ([email protected]) é doutora em Engenharia Mecânica pela UNICAMP. Atua na área de qualidade desde 1994 no CenPRA.