Proposta de método de Validação e Verificação, integrado a gestão da melhoria de qualidade do processo de software
Jorge Luiz Risco Becerra (Prof. Dr. da POLI-USP) - jorge.becerra@poli.usp.br
Rubens Sales (Prof. Ms do Centro Universitário Fundação Santo André) - prof.rubens.sales@gmail.com
Carlos Roberto L. de Matos (Centro Universitário Fundação Santo André) - crlmatos@yahoo.com.br
Empresas de desenvolvimento de software a fim de alcançarem suas metas, visam à diminuição de seu retrabalho e melhoria de sua produtividade e rentabilidade. Assim, investem na melhoria continua de seus processos de produção de software. Modelos como o CMMI, que melhoram continuamente o processo de produção e manutenção de softwares são cada vez mais estudados e implantados, em organizações de software. Este artigo, desenvolvido a partir da compilação de resenhas literárias, artigos e estudos de casos, apresenta um método de validação & verificação, denominado método VV, que aplicado ao longo da execução do processo, visa garantir a qualidade do processo de software e dos produtos gerados, através do controle da qualidade realizado nos produtos de cada fase do processo. Utilizando-se de um conjunto de checklists, o método possui um processo onde os erros encontrados são armazenados em um repositório de dados para posteriormente serem recuperados e compilados por um processo de geração de indicadores, cujo objetivo é, identificar a evolução da melhoria do processo, assim como a geração de Planos de Ações para melhoria permanente do processo pelo qual o software é desenvolvido.
Palavras-Chaves: processo de software, qualidade, verificação e validação, CMMI
1. Introdução
A garantia do produto de software está diretamente relacionada ao seu processo de construção, porém na maioria dos casos a avaliação da qualidade de software, no sentido de identificar suas deficiências e limitações em sua aplicabilidade é feita comumente na fase de teste do processo, ou seja, na última fase antes da implantação. (HUMPHREY,1990)
Estudo feito pela IBM, que mostra que este tipo de controle agrega custo adicional ao projeto, pois considerando que a remoção de um erro descoberto durante o projeto custe uma unidade monetária para ser corrigido, este mesmo erro descoberto imediatamente antes da fase de teste nos custará seis unidades monetárias e meia, durante os testes quinze unidades monetárias e depois da entrega entre sessenta e cem unidades monetárias .( PRESSMAN, 1995)
2º Contecsi – Congresso Internacional de Gestão da Tecnologia e Sistemas de Informação / Internacional Conference on Information Systems and Technology Management
No entanto estudos e pesquisas mostram que uma organização com bom desempenho gasta 80% de seu esforço na prevenção de problemas, enquanto uma de baixo desempenho gasta 90% de seu tempo corrigindo sintomas em vez de causas de problemas, além disso, os testes só podem detectar 70% dos defeitos latentes no código e que inspeções periódicas durante o processo podem detectar 80 a 90% dos erros antes dos testes, portanto faz-se necessário técnicas de controle de qualidade que venham de encontro com os testes, minimizando a quantidade de erros nesta fase, diminuindo o tempo gasto na depuração dos erros e mitigando a possibilidade do software ser implantado ainda com erros. (ROCHA,2000)
Para que o controle de qualidade tenha sucesso são necessários alguns procedimentos: (WEINBERG, 1997)
x Construir um banco de dados comum, que armazene os resultados das avaliações realizadas, formando assim, um histórico para possíveis comparações e referências;
x Proporcionar um conjunto básico de ferramentas para facilitar as atividades de coleta de dados;
x Definir um conjunto de requisitos, documentando os conceitos de qualidade para o projeto em desenvolvimento, no contexto da organização;
x Elaborar um sistema consistente de revisões. (FREEDMAN; WEINBERG, 1997) As revisões são técnicas importantes para a garantia da qualidade do software, evitando que engenheiros de software gastem tempo e recursos projetando o produto errado, ou seja, as inspeções podem identificar defeitos e promover uma correção a baixo custo. (FREEDMAN; WEINBERG, 1997)
O método VV baseia-se no ciclo PDCA (Plan – Do – Check – Action), desenvolvido por DEMING (1985), com o objetivo de obter um aperfeiçoamento constante dos processos de planejamento de projetos, desenvolvimento de software, gestão de produto e pessoas, onde os planos de ação para melhoria são implementados, avaliados e institucionalizados.
A figura1 apresenta o ciclo PDCA para melhoria continua.
x Plan é o primeiro passo do ciclo de Deming, onde é feito o planejamento da melhoria de acordo com a geração e análise dos indicadores, estabelecimento de novas metas;
x Do nesta fase as ações para problemas são desenvolvidas e implementadas, ou seja são desenvolvidos os planos de ação, as melhorias no processo, tomadas decisões gerenciais;
x Check é a verificação dos resultados da implementação das ações, aqui é feita a avaliação das últimas soluções implementadas através de comparações feitas antes e depois das implementações, podendo inclusive fazer uso de ferramentas como carta de tendência, o gráfico de dispersão e o gráfico de controle;
x Action atingido os resultados esperados, parte-se para a padronização do processo conforme as melhorias implementadas e, principalmente sustentação da melhoria, ou seja a institucionalização das medidas implementadas.
A medida que algumas fases do processo são melhoradas e passam a produzir com mais qualidade e eficiência, outras fases se tornarão o gargalo do processo necessitando de melhorias. Desta forma o método se mantém em constante avaliação num ciclo de melhoria continua.
A seguir é apresentado o MÉTODO VV, aderente ao ciclo PDCA e a PA (Process Area) de Análise de Medição do Nível 2 do CMMI.
2. O Método VV (Matos, Zanardi, 2004)
O método VV, visa garantir a qualidade através de validações e verificações nos produtos gerados em cada fase do processo de software. Dessa forma, pretende-se garantir a qualidade do produto desde o início de sua produção.
A utilização do método VV visa não só a garantia de um produto 100% conforme suas especificações, mas a melhoria contínua do processo de produção do software, implementando na organização os conceitos apresentados pelo PDCA (Plan, Do, Check e Action), através da implantação dos seguintes processos do método de acordo com a figura 2:
P1 – Processo de investigação
- Aplicação de checklists para cada produto e fase do processo de software; - Armazenamento de não conformidades em um repositório de não conformidades;
P2 – Processo Análise de problemas
- Geração de indicadores do processo de produção de software; ( Número de não conformidades por especificação técnica, maiores ocorrências de erros por tipo de erro e outros);
- Utilização de Gráficos de Pareto e diagrama de causa efeito (Ishikawa);
P3 – Processo Planejar ações
- Geração de planos de ação para correção do produto; - Geração de planos para melhorias no processo de software.
P4 – Processo Executar ações
- Acompanhar a execução dos Planos de ações;
P5 – Processo Realimentar método;
- Aplicar processo P1 e comparar resultados esperados contra resultados Obtidos.
Figura 2 – Processos do método VV
Uma meta do método VV, é mitigar a propagação do erro de uma fase para outra, proporcionando a redução dos custos na eliminação dos defeitos, pois conforme Agnaldo A. Fernandes (1995), em citação a David Card , “... 81% dos defeitos introduzidos em um software são oriundos da fase de projeto...” (Fernandes, 1995: 124).
2.1. Apresentação dos Elementos do Método VV
Figura 3 – Elementos do método VV P1 Processo de investigaçã P2 Processo Análise de problemas P3 Processo Planejar Ações P5 Processo Realimentar método P4 Processo Executar Ações
A Figura 3 fornece uma visão geral do Método VV, seus elementos, seu fluxo e processo, assim o método é composto em:
x Fase do Processo é fase do processo de construção de software na qual o artefato de entrada foi gerado, e onde ele será corrigido se necessário;
x Artefato de entrada é o artefato gerado pelo processo de software o qual será avaliado pelo Método VV;
x Checklist é o elemento do Método VV que possui o objetivo de controlar a qualidade dos artefatos de entrada. É a lista de itens pelo qual o artefato é avaliado.
x Repositório de dados é o conjunto de informações armazenados com informações provenientes da aplicação dos checklists previstos no Método VV;
x Avaliação são informações compiladas através de:
o Indicadores informações elaboradas através da recuperação de dados armazenados no repositório de não-conformidades, e que são utilizados como parâmetro para análise dos problemas existentes nos produtos e no processo de software. Alguns indicadores propostos são:
Num de defeitos por produto;
Atividade com maior incidência de não-conformidades; Indicador de defeito mais comum;
Num de horas de retrabalho por produto e fase;
Produtos com maior incidência de não-conformidades;
E outros, inclusive propostos pela organização a ser implantado o método.
o Gráfico de Pareto e Diagrama de Ishikawa Ferramentas da qualidade utilizadas para identificação das causas dos problemas encontrados;
o 5w2h ferramenta de auxilio para elaboração do plano de ação;
x Plano de Ação Estratégia formal, desenvolvida a partir do resultado das análises das informações compiladas pelas ferramentas da qualidade;
x Lista de problemas é o documento com a relação de todos os problemas e não conformidades encontradas no artefato avaliado pelo MÉTODO VV; x Artefato de Saída homônimo ao Doc com Qualidade é o documento
homologado pela aplicação dos checklists do MÉTODO VV; que será utilizado nas próximas fases do processo de software;
x Artefatos de apoio artefatos que colaboram com MÉTODO VV a avaliação do produto a ser validado.
2.2. Fluxo de Trabalho do MÉTODO VV Fase do Processo de
Software
Fig. 4 – Diagrama de atividade do MÉTODO VV Aplica Checklist
Não encontrou defeitos
Armazena não-conformidades
Gera Artefato do Processo Artefato de apoio
Lista de problemas
Produto homologado
Aplicar Ferramentas da qualidade
O método VV tem como ponto de partida artefatos de entrada, documentos a serem homologados pelo método, e artefatos de apoio, que auxiliam a avaliação do artefato de entrada.
Entretanto o MÉTODO VV tem dispositivos de controle e gestão do processo, ou seja, um repositório de informações, que compiladas geram indicadores possibilitando uma visão da qualidade do processo atual.
A aplicação do checklist é feita aos produtos gerados em cada fase do processo de software, com o objetivo de garantir a qualidade do software desde o início de sua construção e mitigar a possibilidade de um erro se propagar por todo o processo.
2.3. Fluxo dos Processos do método VV.
No processo de Investigação a verificação dos produtos é realizada baseada em checklists, caso seja encontrados erros e não conformidades, o artefato analisado é devolvido à fase responsável para as devidas correções. Os erros encontrados são armazenados em um repositório de não-conformidades. Os checklists são formados por questões referentes ao produto e questões relativas ao cumprimento das atividades do processo de produção do produto em análise.
O processo de Análise de problemas recupera os dados armazenados no repositório de não-conformidades e gera indicadores com informações estatísticas para análise da qualidade dos tipos de produtos que foram avaliados. Para que se possa identificar as causas são aplicados Gráficos de Pareto e diagrama de causa efeito (Ishikawa).
O Processo Planejar ações avalia os resultados das análises e elabora planos de ação para correção do produto, e planos para melhorias no processo de software. Esse processo gera um cronograma de execução dessas ações.
O Processo Executar ações acompanha a execução dos planos de acordo com o cronograma de melhoria do processo de software. Os resultados obtidos são avaliados e comparados aos resultados esperados nos Planos pelo Processo Realimentar método.
Com o processo realimentado inicia-se uma nova iteração do método, com o objetivo de dar continuidade ao processo de melhoria contínua da produção de software.
3. Aderência do Método VV a PA de Análise e Medição do N 2 do CMMI
No nível de maturidade 2, os projetos da organização asseguram que necessidades são administradas e que processos são planejados, realizados, avaliados e controlados. As disciplinas de processo refletem que o nível de maturidade assegura que práticas atuais são mantidas durante tempos de pressão. (CMU/SEI-2002-TR-029, ESC-TR-2002-029, 2004)
As necessidades, processos, resultado dos trabalhos e atividades são gerenciados. A posição do resultado dos artefatos e das atividades é visível para o gerenciamento em pontos definidos.
Comprometimentos são estabelecidos no meio de stakeholders apropriados e são revisados quando necessário. Artefatos são revistos com stakeholders e são controlados, satisfazendo suas necessidades específicas, padrões e objetivos.
A PA de Análise e Medição, é um dos grupos de práticas relacionadas a ser executada em conjunto com outras PA’s satisfazendo o conjunto de objetivos considerados importantes para a certificação nível 2, e tem por objetivo desenvolver e manter a capacidade de medição possibilitando o levantamento de informações necessárias para a tomada de decisões gerenciais.
A cada PA são estabelecidas Metas Especificas (SG – Specific Goal), Metas Gerais (GG – Generic Goal), Práticas Específicas (SP – Specific Practice) e Características Comuns (Common Features), esta ultima subdividida em:
9Compromisso de Execução (CO) 9Capacidade de Execução (AB) 9Dirigindo Implementação (DI)
A Tabela 1 demonstra a aderência do método proposto às metas especificas e gerais da PA de Análise e Medição.
PA de Análise e Medição CMMI Método VV SG 1 Alinhe Atividades de Análise e
Medição
Avaliação de indicadores e aplicação de Diagrama de Ishikawa e Pareto, em
informações armazenadas nos repositório de dados.
SP 1.1 Estabeleça objetivos de medição
A garantia da qualidade de cada produto gerado pelo processo de software, e obtenção de informações para determinação de metas de melhoria do processo e produto de software SP 1.2 especifique Método de
medição
O ciclo definido pelo método é aplicado como método de medição
SP 1.3 Especifique a coleta de dados e procedimento para armazenamento
Os erros encontrados a cada aplicação de cheklist são armazenados em um repositório de dados, conforme procedimentos descritos no método.
SP 1.4 Especifique procedimentos de analise
As informações armazenadas no repositório são compiladas em forma de indicadores, gráfico de pareto e ishikawa, conforme rege o método.
SG 2 Forneça os Resultados da Medição
Os resultados são apresentados para a equipe de desenvolvimento nas reuniões de ponto de controle dos projetos
SP 2.1 Colete os dados de Medição
Os dados são coletados a partir da aplicação dos cheklists e armazenados no repositório de não-conformidades
SP 2.2 Analise os dados de medição Aplicação do P2 - Processo de Análise de problemas
SP 2.3 Armazene Dados e resultados Geração de histórico através dos dados armazenados no repositório de dados
SP 2.4 Comunique os Resultados Apresentação dos resultados aos Stakeholders GG 2 Institucionalize um processo
gerenciado
Implantação e treinamento das equipes da organização, no método VV
GG 3 Institucionalize um processo definido
Implantação e treinamento das equipes da organização, no método VV, como parte integrante do processo de software definido para a Organização
Tabela 1 – Aderência do MÉTODO VV a PA de Análise e Medição do Nível 2 CMMI.
5. Conclusão
Por estar aderente a ciclo de Deming, o método VV deve ser aplicado em organizações que desejem implantar um processo de melhoria continua de seus processos de software; Políticas criadas pela alta gestão da organização devem nortear a aplicação do método.
O conjunto de checklists a serem aplicados não foi apresentado neste artigo, pois estes checklists, podem ser adaptados a realidade da organização onde o método será aplicado, assim como os indicadores, os quais existe um conjunto padrão definido pelo método, que, porém, podem sofrer adaptações sugeridas pela organização.
Assim, pode-se observar que o método possui um processo padrão bem definido, o que facilita as adaptações necessárias à sua aplicação em diversas organizações de software, o que faz o método bastante flexível.
O método VV procura atacar um problema típico nos diversos sites de desenvolvimento de softwares, “a qualidade do produto” e a “melhoria do processo de software”, a implantação do método induz a organização a praticar o ciclo de melhoria contínua proposto por Deming e colabora para a implantação da Área de Processo Medição e Análise do nível 2 do Modelo CMMI.
Com relação a aderência do método ao CMMI, pode-se concluir que apesar de colaborar com a implantação da PA de medição de análise, o método ainda carece de melhorias para ser evoluído e complementado com o objetivo de atender as demais PA´s do nível 2, tornando-se ferramenta completa para o alcance dos objetivos propostos deste nível, agilizando inclusive sua certificação.
REFERÊNCIA BIBLIOGRÁFICA
CMU/SEI-2002-TR-029, ESC-TR-2002-029 – Capability Maturity Model Integration (CMMISM), Versão 1.1, CMMISM for Software Engineering (CMMI-SW, V1.1), Staged Representation; 2002
Site do SEI: http:\\www.sei.cmu.edu;
FERNANDES, Aguinaldo Aragon. Gerência Efetiva de Software Através de Métricas. São Paulo. Atlas, 1995.
FREEDMAN, D.P.; WEINBERG, G.M. Manual de Walkthroughs: inspeções e revisões
técnicas de especificações de sistemas e programas. McGraw-Hill, São Paulo,1993.
HUMPHREY,Watts. Managing the Software Process. Addison-Wesley Reading,MA,1990.
MATOS, Carlos R.L.; ZANARDI, Edcleisson M. Qualidade e Garantia do Produto de
Software. 2004. 88 f. Trabalho de Conclusão do Curso (Bacharelado em Sistemas de
Informação) – Faculdade de Ciências, Filosofia e Letras, Centro Universitário Fundação Santo André. Santo André, 2004.
PRESSMAN, Roger S. Engenharia de Software. Editora MAKRON Books, 1995.
ROCHA, Ana Regina. Programa de Engenharia de Sistemas e Computação, COPPE/UFRJ, 2000.
