Requisitos para Ferramentas de Suporte à Garantia da Qualidade de Software

Transcrição

1 Requisitos para Ferramentas de Suporte à Garantia da Qualidade de Software Rodrigo Montenegro Possa 1 1 Departamento de Ciência da Computação Universidade Federal de Minas Gerais (UFMG) Av. Antônio Carlos, 6627 Pampulha Belo Horizonte - MG Abstract. Resumo. 1. Introdução rmpossa@gmail.com Atualmente, o software tem um papel muito importante para a sociedade. Há 50 anos, ele era utilizado somente em máquinas exclusivas de cálculo. Atualmente, produtos eletrônicos, bem como equipamentos críticos de segurança e atividades de diversas naturezas utilizam softwares [RUNESON98]. Logo, o sucesso da Engenharia de Software depende da entrega de produtos de alta qualidade. A qualidade de software pode ser vista sob vários aspectos. Para Phil Crosby, trata-se da conformidade com os requisitos do usuário [CROSBY79]. O critério Baldrige para a qualidade organizacional considera a satisfação do cliente como o item mais importante [NIST03]. Para Garvin, a qualidade pode ser vista sob as perspectivas transcendental, do usuário, do produto, de valor e da organização [GARVIN84]. Engenheiros de software (e acadêmicos) aplicam o termo qualidade tanto ao produto que está sendo desenvolvido quanto ao processo usado na construção do software [HILBURN00]. Um processo de desenvolvimento bem definido é um fator chave de sucesso para o alcance de softwares de alta qualidade. A melhoria do processo de software pode trazer ganhos em vários critérios de qualidade, tais como a verificabilidade, a eficiência, a portabilidade e a integridade, dependendo de qual metodologia for utilizada. [ASHARAFI03]. Um dos modelos de referência, que serve para avaliar a maturidade dos processos de uma organização [PAULA03], é o CMM [PAULK93]. Desde o seu aparecimento em 1991, este modelo despertou muito interesse em toda a comunidade de desenvolvimento de software. O CMM, divide as organizações desenvolvedoras de software em 5 níveis de maturidade, do inicial (nível 1) ao otimizante (nível 5), de acordo com as áreas chaves de processo que já foram implantadas. Este modelo de maturidade foi substituído recentemente pelo CMMI [CMMI02], que integrou os diversos modelos existentes (SW-CMM, SE-CMM, IPD-CMM e o SA-CMM) [PAULA03]. A Garantia da Qualidade de Software (GQS) é uma das áreas chaves de processo do CMM. De modo geral, a GQS é definida como um padrão planejado e sistemático

2 de todas as ações necessárias para prover a confiança adequada de que um item ou um produto atendam aos requisitos técnicos estabelecidos [RUNESON98]. Por sua vez, o CMM define a GQS como um conjunto das atividades utilizadas na verificação da aderência dos projetos ao processo de desenvolvimento de software. No CMMI, esta área chave foi substituída pela Garantia da Qualidade do Produto e do Processo (GQPP), que se diferencia da GQS nos seguintes aspectos: maior objetividade nas revisões; identificação de lições aprendidas que visam à melhoria do processo a partir das revisões de Garantia da Qualidade; e análise das nãoconformidades para verificar a existência de tendências que possam ser identificadas e tratadas [VILLASBOAS05]. Nos dois modelos (CMM e CMMI), a Garantia da Qualidade envolve diversos papéis e grupos, tais como Equipes de Qualidade, Equipes de Desenvolvimento, Grupo de Engenharia de Processo, Líderes de projeto e Gerente sênior. Todos estes papéis participam de um conjunto extenso de atividades. Portanto, é muito grande a utilidade de um sistema de informação que auxilie na realização das atividades de GQS. Este artigo apresenta um catálogo de requisitos, da mesma forma que Hoffmann o fez [HOFFMANN04], para uma ferramenta de suporte às atividades de GQS. Os principais interessados neste trabalho são: empresas de desenvolvimento de software que executam atividades relacionadas à GQS em seu processo, como, por exemplo, o Serviço Federal de Processamento de Dados [TAVARES02]; e empresas desenvolvedoras de soluções de apoio aos processos. Embora a expressão Garantia da Qualidade de Software tenha sido utilizada no título deste artigo, o catálogo é baseado nas práticas de GQPP, já que esta é mais abrangente do que a área chave de processo GQS pertencente ao modelo CMM [VILLASBOAS05]. 2. Modelos e Características da GQS 2.1 Garantia da Qualidade de Software (GQS) O SWEBOK (Software Engineering Body of Knowledgement), Corpo de Conhecimento de Engenharia de Software, definiu a Garantia da Qualidade de Software como processos que fornecem a garantia de que os produtos e os processos de software no ciclo de vida de um projeto obedecem aos seus requisitos específicos [SWEBOK04]. A partir da definição acima, várias interpretações podem ser dadas para o termo GQS. O trabalho de Runeson e Isacsson [RUNESON98] apresenta duas interpretações. A primeira interpretação é dada pelo modelo de maturidade CMM, bem como por seu substituto, o CMMI. Neste modelo, a GQS é uma área chave de processo (no CMMI, a área de processo é a GQPP, Garantia da Qualidade do Produto e do Processo) que mapeia as atividades independentes de garantia da qualidade, em particular a verificação da aderência do projeto ao processo definido [RUNESON98]. A segunda interpretação apresentada por Runeson e Isacsson é dada pelo modelo ISO 9001 [ISO94]. Neste caso, os testes e as inspeções de código também fazem parte da GQS [RUNESON98]. Este artigo aborda apenas a interpretação do modelo CMMI para o termo GQS. O CMMI agrupa as inspeções e os testes em outras áreas chaves de processo, tais como

3 Verificação e Validação. Alguns aspectos do modelo são apresentados na próxima seção. 2.2 CMMI (Capability Maturity Model Integrated) - Modelo de Maturidade e Capacidade Integrado O CMMI é um modelo de maturidade desenvolvido pelo SEI, Software Engineering Institute, que se baseia em um conjunto de capacidades da Engenharia de Software presentes à medida que a organização alcança diferentes níveis de maturidade [PRESSMAN02, pag. 22]. A maturidade de uma organização é definida pelos níveis de 1 (caótico) a 5 (otimizante) no intuito de descrever recomendações evolutivas para a organização que pretende melhorar os processos e manter os seus produtos e serviços [PIMENTEL05]. As áreas de processo (PA, Process Area) são organizadas por níveis de maturidade. Com a representação em estágios, a cada avaliação da empresa geralmente é possível mensurar os resultados nítidos de estabilização da organização dentro do nível de maturidade. A figura 1 mostra os cinco níveis da maturidade. Segundo Chrissis, cada nível é a base para o nível superior, ou seja, uma escala gradativa de nivelamento [CHRISSIS03]. Figura 1 Níveis de maturidade [PIMENTEL05] Neste modelo, a Garantia da Qualidade de Software é tratada pela área de processo Garantia da Qualidade do Produto e do Processo. A GQPP faz parte do nível 2 de maturidade, o Gerenciado, que foca na área gerencial da engenharia de software.

4 Junto com Medição e Análise e Gerência de Configuração, a GQPP possui foco no apoio às outras áreas de processos, não deixando de possuir importância fundamental para a organização e para o software que está sendo desenvolvido [PIMENTEL05]. A figura 2 mostra a interação da GQPP (em inglês, PPQA) com as outras áreas de processo do modelo CMMI. Figura 2 Suporte básico em áreas de processos [PIMENTEL05] Na próxima seção, alguns detalhes da área de processo GQPP são apresentados. 2.3 A área de processo Garantia da Qualidade do Produto e do Processo Em estudos recentes, a qualidade está relacionada ao processo de desenvolvimento do software em que o conjunto de atividades, métodos e práticas estão reunidos com o objetivo de medir a qualidade pelos requisitos, os padrões e os requisitos implícitos [ROCHA01]. A área de processo GQPP tem como objetivo fornecer à equipe e à gerência uma visão objetiva dos processos e produtos de trabalhos associados. A seguir são apresentadas as quatro metas da área de processo GQPP que ajudaram na elaboração do catálogo de requisitos apresentado neste artigo[pimentel05]: A primeira meta a ser atingida para GQPP é Avaliar Objetivamente Processos e Produtos de Trabalho. Envolve verificar a aderência do processo executado e dos produtos e serviços associados às descrições, padrões e procedimentos dos processos dentro da organização. É necessário realizar a avaliação objetiva a fim de identificar não-conformidades (desvios) e gerar documentação que podem ser relatórios de avaliações e ações corretivas. A segunda meta é Fornecer um Entendimento Objetivo. As questões de nãoconformidade são rastreadas e divulgadas de forma objetiva. Neste caso, o responsável pela área de processo assegura a resolução destas questões. A terceira meta é Institucionalizar um Processo Gerenciado. Em desenvolvimento... A quarta meta é Institucionalizar um Processo Definido. Em desenvolvimento...

5 2.4 Partes Interessadas Na introdução deste artigo, as empresas desenvolvedoras de software foram citadas como interessadas no catálogo de requisitos, visto que elas devem executar atividades relacionadas à Garantia da Qualidade de Software para desenvolverem produtos de alta qualidade. Dentro destas empresas existem papéis diretamente relacionados à área de processo GQPP, e que, portanto, são partes interessadas neste catálogo de requisitos. São eles [RUNESON98]: - Consultor de GQS: Papel que irá agendar, executar e reportar as revisões, garantindo, em seguida, que todas as não-conformidades sejam devidamente tratadas; - Líder de Projeto: Responsável pelo projeto revisado. Tomará ciência do resultado das revisões realizadas em seus projetos. Deve providenciar a regularização das nãoconformidades encontradas nestas revisões; - Gerente Sênior: Nível hierárquico e estratégico mais alto da organização, sendo envolvido em todos os projetos, em nível mais alto de abstração. Deve tratar as nãoconformidades não solucionadas no âmbito do projeto. - Grupo de Engenharia de Processo: Responsável pela manutenção e melhoria dos processos da organização. Recebe e avalia as propostas de melhoria dos processos registradas durante as revisões de qualidade. 3 Requisitos O trabalho de Villas-Boas apresenta a implantação da área de processo GQPP na empresa CPqD [VILLASBOAS05], que desenvolve soluções para a área de telecomunicações. O artigo em questão mostra como foi a implementação de cada prática que visa ao atendimento das metas citadas na seção 2.3. Com base na implementação das práticas de GQPP [VILLASBOAS05] e nas necessidades das partes interessadas identificadas na seção 2.4, é possível fundamentar o enunciado e a enumeração dos requisitos de uma ferramenta de suporte à Garantia da Qualidade de Software. Os requisitos estão agrupados por cada um dos papéis envolvidos no processo de GQPP e identificados na seção 2.4, Partes Interessadas. 3.1 Requisitos dos Consultores de GQS - CGQS Plano de Garantia da Qualidade de Software A ferramenta deve permitir o registro do planejamento de GQS para os projetos. O plano de GQS deve conter o agendamento das revisões de qualidade, os critérios a serem utilizados na avaliação dos processos, produtos de trabalhos e serviços. - O plano de GQS deve conter as datas estimadas para início e fim da revisão, bem como o esforço previsto para a execução da mesma; - Deve ser possível o agendamento de revisões periódicas ou por marco;

6 - Se a revisão for agendada por marco, a ferramenta deve indicar quais tipos de artefatos podem ser revisados, permitindo que o CGQS selecione alguns deles. Por exemplo, se o agendamento for de uma revisão que será feita no final da fase de Elaboração, a ferramenta deve mostrar, entre outros, os artefatos da documentação dos requisitos e os do fluxo de Análise; - No planejamento de GQS deve ser possível criar critérios de amostragem para a seleção dos artefatos a serem avaliados, que devem ser obedecidos durante a execução das revisões. Por exemplo, durante o planejamento da revisão do marco de Elaboração, o CGQS define que, para o projeto, devem ser revisados pelo menos 20% das Especificações de Casos de Uso. Fundamentação: No CMMI, uma das sub-práticas necessárias para atender à meta Avaliar Objetivamente Processos e Produtos de Trabalho é Estabelecer e manter critérios claramente declarados para as avaliações [CMMI02]. O CPqD [VILLASBOAS05] implementa esta sub-prática através de dois tipos de revisão de GQS: periódica e por marco. Os itens a serem avaliados são planejados de acordo com a fase e o ciclo de vida do projeto. Os produtos de trabalho são avaliados de acordo com um critério de amostragem. No CPqD, as revisões periódicas são utilizadas para avaliar os processos de gestão (p. ex. planejamento, acompanhamento, gestão de risco, tomada de decisão), enquanto que as agendadas por marco são realizadas para avaliar processos de engenharia (p. ex. solução técnica, integração de produto, verificação, validação) nos marcos pré-estabelecidos do ciclo de vida dos projetos [VILLASBOAS05] Relatório de Avaliação A ferramenta deve ter uma funcionalidade que permita ao CGQS informar o resultado de sua revisão. Deve ser possível registrar a análise crítica da revisão, as nãoconformidades, as lições aprendidas para a melhoria do processo, bem como as datas e o esforço realizados. - Deve ser possível recuperar as datas e o esforço estimados para a revisão. Isto é importante para efetuar a análise crítica, na qual o CGQS justifica eventuais desvios de valores realizados em relação aos estimados; - Para cada não-conformidade identificada, deve ser possível informar o fluxo, a atividade e o artefato onde a mesma foi encontrada, bem como a descrição da nãoconformidade, as ações corretivas e o prazo para sua regularização; - Para cada lição aprendida para melhoria do processo, deve ser possível informar o fluxo, a atividade e o artefato focos da melhoria, bem como sua descrição. - A análise crítica pode ser registrada em um campo de texto livre; - Ao confirmar o registro do Relatório de Avaliação, este deve ser enviado ao Líder de Projeto e à equipe de desenvolvimento; - Cada não-conformidade deve ser enviada para o Líder de Projeto, que a encaminhará para o responsável pela correção;

7 - Caso alguma lição aprendida para melhoria do processo tenha sido encontrada, esta deve ser enviada para o Grupo de Engenharia de Processo, que aceitará ou não a sugestão de melhoria. Fundamentação: No CMMI, algumas das sub-práticas necessárias para atender à meta Avaliar Objetivamente Processos e Produtos de Trabalho são Identificar todas as não-conformidades encontradas durante a avaliação e Identificar lições aprendidas que poderão melhorar processos. Os produtos de trabalho gerados no atendimento a esta meta são: Relatório de Avaliação, Relatório de não-conformidades e Ações Corretivas. No enunciado deste requisito, os dois últimos produtos de trabalho foram considerados como partes do primeiro produto [CMMI02]. No CPqD, para a implementação das sub-práticas acima, as não-conformidades encontradas durante as avaliações são registradas em ferramenta para acompanhamento e designadas ao responsável. Além disso, quando aplicável, após cada avaliação são registradas lições aprendidas sobre os processos utilizados. Essa informação é utilizada para a melhoria de processos [VILLASBOAS05]. 3.2 Requisitos dos Líderes de Projeto Em desenvolvimento. 3.3 Requisitos do Gerente Sênior Em desenvolvimento. 3.4 Requisitos do Grupo de Engenharia de Processo Em desenvolvimento. 4 Aspectos práticos e operacionais Os seguintes aspectos práticos e operacionais relacionados ao catálogo de requisitos são indicados a seguir: - No plano de GQS e no relatório de avaliação, as datas da revisão e o esforço estimados/realizados devem ser registrados na unidade Homem-hora (HH); - O encaminhamento de não-conformidades, lições aprendidas, análises críticas e outros produtos de trabalho gerados pela ferramenta deve ser feito via ao papel destinatário; -... em desenvolvimento... 5 Conclusão Este artigo apresentou um catálogo de requisitos para ferramentas de suporte à Garantia da Qualidade de Software. O catálogo foi feito com base nas metas da área de processo Garantia da Qualidade do Produto e do Processo, nas necessidades das partes interessadas e na implantação da área de processo em uma empresa de telecomunicações [VILLASBOAS05]. As ferramentas construídas com base neste catálogo irão ajudar empresas desenvolvedoras de software a atenderem às metas da GQPP e a melhorarem a

8 qualidade de seus produtos, mediante a execução correta de seus processos. Futuramente, podem ser adicionados requisitos originados a partir de outros modelos, como o ISO em desenvolvimento Referências [ASHARAFI03] Alsharafi, N. (2003) The impact of software process improvement on quality: in theory and practice, Information and Managemens Elsevier. [CHRISSIS03] Chrissis, M., Konrad, M., Shrum, S. (2003) CMMI: Guidelines for Process Integration and Product Improvement. Boston: Addison-Wesley. [CMMI02] SEI - CMMI Product Team. (2002) Capability Maturity Model Integration, v. 1.1, Carnegie Mellon University, Pittsburgh, EUA. [CROSBY98] Crosby, P. (1998) Quality Is Free, McGraw-Hill. [GARVIN84] Garvin, D. (1984) What product quality really mean?, Sloan Management Review, pp [GEORGIDAOU03] Georgidaou, E. (2003) GEQUAMO A Generic, Multilayered, Customisable, Software Quality Model, Software Quality Journal, November, pp [HILBURN00] Hilburn, T. e Towhidnejad, M. (2000) Software Quality: A Curriculum Postscript?, Proceedings of the Thirty-first SIGCSE Technical Symposium on Computer Science Education. [HOFFMANN04] Hoffmann, M., Kuhn, N., Weber, M. e Bittner, M. (2005) Requirements for requirements managment tools. Proceedings of the IEEE International Requirements Engineering Conference (RE 04), pp , Kyoto, Japão. [ISO94] International Standard 9001 (1994) Quality Systems - Model for Quality Assurance in Design, Development, Production, Installation and Servicing [NIST03] National Institute of Standards and Technology (2003) Baldrige National Quality Program, disponível em [PAULA03] Paula Filho, W. P. (2003) Engenharia de Software Fundamentos, Métodos e Padrões, Editora LTC, 2 a Edição. [PAULK93] Paulk, M., Curtis, B., Chrissis, M. B. e Weber, C. (1993) Capability Maturity Model for Software, versão 1.1. Software Engineering Institute, Pittsburgh. [PIMENTEL05] Pimentel, C. A., Silva, D. e Bezerra, I. (2005) Principais Objetivos da área de Garantia da Qualidade na Engenharia de Software e na Organização. [PRESSMAN02] Pressman, R S. (2002) Engenharia de Software. 5ª edição. Rio de Janeiro: McGraw-Hill. [ROCHA01] Rocha, A. R., Maldonado, J. C. e Weber, K. C. (2001) Qualidade de Software Teoria e Prática. Prentice Hall, São Paulo

9 [RUNESON98] Runeson, P. e Isacsson, P. (1998) Software Quality Assurance - Concepts and Misconceptions, Proceedings of the 24th EUROMICRO Conference. [SWEBOK04] SWEBOK (2004) Guide to the software engineering Body of Knowledge, disponível em [TAVARES02] Tavares, H. C., Paim, F. e Carvalho, A. E. (2002) Implantando CMM Nível 2: A Estratégia SERPRO, I Simpósio Brasileiro de Qualidade de Software. [VILLASBOAS05] Villas-Boas, A., Côrtes, M. L. e Lopes, S. (2005) Do SQA ao PPQA: a implementação CMMI do CPqD, VII Simpósio Internacional de Melhoria de Processos de Software.