Resumo:
Um Processo de Software para Rapid Application
Development (RAD)
A quality software process for rapid application
development
Gerry Coleman and Renaat Verbruggen
Grupo 5
Christian Reis
Pedro M. S. Eleutério
Ricardo J. M. Ribeiro
Wagner S. Bila
Ramon Chiara
Resumo:
Processos de software podem melhorar significativamente a qualidade dos
produtos de uma empresa produtora de software, e com eles é possível
medir a avaliar o desempenho dos setores ligados ao desenvolvimento.
Este artigo[
1] defende que a maior parte dos processos
consolidados é inapropriado para empresas pequenas, onde o prazo tem
importância mais elevada, e sugere a adoção dos métodos
DSDM
1 e
PSP
2 para empresas que vivem este
contexto.
O uso de um processo de software é largamente apontado como um fator
para sucesso de uma empresa de desenvolvimento de software. O Software
Engineering Institute (SEI), após anos avaliando e aprimorando processos
de software em empresas, consolidou uma série de práticas no modelo
Capability Maturity Model (CMM).
O CMM é direcionado a grandes corporações. Pequenas empresas que
trabalham desenvolvendo software, no entanto, também necessitam de um
processo de software. O artigo propõe a adoção dos métodos DSDM e PSM
por estas empresas.
O termo Rapid Application Development (RAD) se aplica a projetos
que têm prazos curtos, e que em geral envolvem o uso de prototipagem e
ferramentas de desenvolvimento de alto nível. O RAD existe para facilitar o
desenvolvimento de aplicações com esta característica, mas sofre de
problemas semelhantes a outras formas de desenvolvimento rápido: a
falta de prazo pode implicar em qualidade reduzida, e há necessidade de
habilidade maior dos desenvolvedores, e suporte maior da gerência e dos
clientes.
O DSDM é um método aplicado a RAD que aplica prototipagem extensivamente
para garantir entrega contínua e qualidade elevada para os produtos
gerados. A entrega dos produtos intermediários é determinada por
faixas fixas de tempo. Os princípios do DSDM seguem:
- Envolvimento ativo do Usuário
- Poder de decisão da equipe DSDM
- Entrega frequente
- O critério mais importante para aceitação é adequação à
tarefa requisitada
- Teste integrado ao ciclo de vida
O ciclo de vida DSDM se divide em cinco fases:
- Estudo de Viabilidade
Esta fase determina de o projeto é factível ou não, e se o DSDM é o
método adequado.
- Estudo do Negócio
Nesta etapa são determinados os requisitos primários.
- Iteração para o Modelo Funcional, e
- Iteração para Desenvolvimento
Nestas fases ocorre o desenvolvimento em si, sendo que na primeira é
aprimorado o levantamento de requisitos, e na segunda, assegurada a
qualidade dos protótipos gerados.
- Implementação
Esta fase engloba a entrega do produto e as atividades relacionadas.
A literatura que descreve o DSDM especifica o uso intensivo de testes
para garantir qualidade em todos os estágios do processo. No entanto,
embora haja literatura extensiva defendendo o uso de técnicas
alternativas para a Garantia de Qualidade, o DSDM não inclui indicações
para o uso destas técnicas durante o processo.
O PSP tem como objetivo oferecer um modelo de Qualidade de Software
adequado a projetos pequenos. O trabalho envolve principalmente os
desenvolvedores, que trabalham verificando a qualidade dos módulos sob
sua responsabilidade. O PSP é em essência um conjunto de formulários e
procedimentos que compõem um processo definido.
O PSP possui quatro níveis principais:
- PSP0 (Baseline)
Oferece uma infraestrutura para coleta de dados de um processo.
- PSP1 (Planejamento, Escalonamento e Estimativa)
Nesta fase é dado apoio ao planejamento do projeto, e assistência à
estimativa do tamanho do projeto.
- PSP2 (Gerência da Qualidade do Software)
Neste nível são aplicados métodos de verificação e revisão para garantir
qualidade do processo e do produto.
- PSP3 (Desenvolvimento Cíclico)
Neste nível sistemas grandes são decompostos para se adequar melhor ao
PSP.
Uma quantidade significativa de empresas têm implementado algumas
disciplinas do PSP com grandes vantagens: o uso de inspeções e revisões
auxilia a descoberta de problemas nas fases iniciais do desenvolvimento, e
a aplicação de métricas é essencial para a avaliação do processo sendo
utilizado em cada empresa.
No trabalho realizado pelos autores, foi feito um levantamento e
avaliação subsequente dos processos em uma empresa pequena, aplicando
questionários e, posteriormente, uma análise detalhada do processo. Os
problemas que se mostraram aparentes seguem:
- Ausência de um documento padrão de requisitos
- Ausência de um documento padrão para projeto
- Ausência de padrões para programação
- Ausência de planos dos programadores para testes de unidade
- Ausência de teste independente dos módulos
- Ausência de documentação formal de erros
- Ausência de documentação de solicitações de correções de
erro e alterações
A proposta do artigo é aplicar uma combinação de técnicas do DSDM e do
PSP para enfrentar os problemas levantados na seção anterior. Durante a
avaliação se concluiu que o uso de ambos os métodos favoreceriam a
empresa em diversos pontos: DSDM é bem-adequado a RAD, mas faltam ao
método técnicas e métricas para avaliação de qualidade; o PSP endereça
estes pontos de uma forma satisfatória.
O DSDM tem uma semelhança maior com o nível PSP3, e a implementação de
cada combinação importante está detalhada abaixo:
- Uso de proxies
Para medir quanto do produto estará pronto para uma faixa de tempo do
DSDM, utiliza-se a estimativa PSP através de proxies, que são
substitutos para o código -- Pontos funcionais (Function Points,
ou FP), Linhas de Código (Lines of Code, ou LOC), Interfaces,
etc -- que sejam mais fáceis de aproximar aos requisitos.
- Teste
O DSDM advoga o uso de analisadores de código automatizados para
verificar erros no produto; no entanto, estes analisadores podem levar
algum tempo para serem desenvolvidos para um grau de satisfação mínimo.
Ouso de revisões e inspeções sugerido pelo PSP oferece um suporte melhor
à avaliação de erros até a implementação completa dos analisadores.
- Plano de Qualidade
O uso dos documentos do PSP para compor o Plano de Qualidade do DSDM é
sugerido. Estes documentos deveriam ser agregados a outros que servem
especificamente às particularidades do RAD.
- Métricas
Como o DSDM não oferece um guia específico para métricas, seria
interessante adotar um conjunto que permitisse avaliar quantitativamente
o progresso do desenvolvimento. As métricas sugeridas no artigo são:
- Métricas para tamanho e erros, baseados em LOC ou FP
- Métricas para produtividade, também apoiadas em LOC ou FP
- Métricas para tempo e cronograma
- Métricas auxiliares, que dão uma idéia do progresso do projeto
e na qualidade do processo
- Manutenção
Aplicar uma métrica para determinar quantos defeitos em produção foram
encontrados, e quanto tempo levaram para ser reparados podem dar uma
idéia melhor da efetividade do processo implantado.
- Reuso de Software
É sugerido fazer uma avaliação real das vantagens do reuso, apoiado no
histórico de métricas recolhido e no impacto possível da adaptação dos
componentes -- se a empresa não tem pessoal disponível para trabalhar
na manutenção e gerenciamento destes componentes, em geral não é
interessante aplicar o reuso.
O estudo revelou que o DSDM pode ser um caminho para a adequação ao
Nível 2 do CMM, oferecendo amparo para uma entrega rápida do software. A
aplicação de conceitos do PSP pode auxiliar na verificação da qualidade
do produto, além de apoiar as estimativas feitas e na documentação
requerida pelo DSDM.
Os autores sugerem simplificar os meios de registrar os dados sendo
medidos para reduzir o impacto do uso das técnicas PSP, e a aplicação de
automação para assistir o processo de avaliação e inspeção do código.
Ambas as sugestões são feitas para adequar melhor o PSP às necessidades
de prazo que um projeto RAD possui.
- 1
- Gerry Coleman and Renaat Verbruggen.
A quality software process for rapid application development,
Software Quality Journal 7, pp. 107-122, 1998.
Christian Reis
2000-08-15