Ferramenta de apoio ao processo de desenvolvimento de software em pequenas empresas

Clayton Vieira Fraga Filho

Matriz de Rastreabilidade (Traceability Matrix)

No gerenciamento de projetos de software as alterações e a avaliação do impacto da mudança durante o ciclo de desenvolvimento é essencial e crítico.

É importante assegurar que, os requisitos possam ser relacionados aos Casos de Uso propostos para o sistema, pois os Casos de Uso esclarecem a implementação proposta do sistema a partir da visão de um usuário. É importante definir um projeto claro para os analistas, portanto se a alteração é proposta enquanto o sistema está em desenvolvimento, o impacto da alteração envolve verificar como a alteração afeta os requisitos, o projeto do sistema e sua implementação.

A matriz de rastreabilidade oferece como grande facilitador a visualização global dos Casos de Uso e requisitos do sistema em uma tabela de forma gráfica, dando suporte ao analista para tomar decisões e descobrir problemas e sua solução de forma mais rápida, muitas vezes antes do fase de implementação. Os artefatos modificados no Controla são sinalizados, oferecendo suporte visual ao analista na identificação de potenciais focos de problemas.
Além da matriz de rastreabilidade de projeto, é possível relacionar requisitos, implementação, liberações, testes e erros.

Abaixo na figura 2 é exibia a matriz de Rastreabilidade de projeto (Casos de Uso X Requisitos).

Durante a operação das matrizes de rastreabilidade, o cadastro de cada artefato de software é atualizado de acordo com a matriz que está sendo atualizada. Como exemplo podemos citar o relacionamento de Casos de Uso com Casos de Teste. O analista pode desejar após ter realizado um relacionamento nesta matriz, que os requisitos e casos de uso associados tenham o estado Verificado definido para eles. Neste momento o Controla realiza uma validação com o objetivo de consultar se o estado anterior do requisito e casos de uso da relação está definido como Implementado, seguindo o fluxo definido, eliminando do analista a responsabilidade de realizar este processo manualmente.

Método de priorização de requisitos baseada em valor, custo e risco

Durante o desenvolvimento de um software, os stakeholders podem chegar a um acordo informal quanto à prioridade dos requisitos. Projetos de software exigem uma abordagem mais estruturada que elimine sentimentalismos, políticas e suposições do processo de priorização. Algumas técnicas analíticas e matemáticas envolvem a estimativa do valor e custo relativo de cada requisito (Karl Wiegers 2003). Os requisitos de mais alta prioridade são aqueles que fornecem a maior fração do valor total do produto e a menor fração do custo total (Karlsson and Ryan 1997; Jung 1998 apud Karl Wiegers 2003). Estimar subjetivamente o custo e o valor comparando dois a dois todos os requisitos é impraticável para uma grande quantidade de requisitos.

Outra alternativa é a “Quality Function Deployment” (QFD), um método para relacionar o valor que o cliente atribui às características propostas para o produto (Zultner 1993; Cohen 1995). Uma terceira abordagem, importada da Gerência de Qualidade Total (TQM), classifica cada requisito de acordo com vários critérios de sucessos do projeto e calcula uma pontuação para classificar a prioridade dos requisitos. Entretanto, poucas empresas de software parecem estas dispostas a assumir o rigor do QFD e do TQM.

O modelo proposto por Karl Wigers para auxiliar na estimatva das prioridades relativas para um conjunto de requisitos funcionais, adota conceitos do QFD em basear o valor que o cliente atribui para o benefício fornecido ao cliente caso um requisito específica seja incorporado, e uma penalidade caso o requisito esteja ausente. A importância de um requisito é diretamente proporcional ao valor que ele agrega e inversamente proporcional ao seu custo e riscos associados à sua implementação. Esta abordagem distribui um conjunto de prioridades estimadas de forma contínua ao invés de simplesmente agrupá-las em um conjunto discreto de poucos níveis de prioridade.

Uma vez identificados os requisitos essenciais ao produto a ser entregue, o modelo proposto pode ser usado para classificar a importância relativa dos requisitos restantes. Quem deve ser considerado no processo de priorização:

• O gerente do projeto, que conduz o processo, resolve conflitos e ajusta as entradas de outros participantes se necessário;
• Clientes representativos, tais como patrocinadores do produto ou pessoal de marketing, que podem fornecer os valores de benefícios e penalidades;
• Representantes da equipe de desenvolvimento tais como líderes de equipes que podem fornecer os valores de custos e riscos.

Os passos a seguir representam a seqüência para a utilização do modelo de priorização:

1. Os requisitos que devem ser analisados precisam ser incluídos na lista. Todos os ítens devem ser do mesmo nível de abstração – não é permitido comparar requisitos funcionais com Casos de Uso do produto, portanto no–Controla–são incluídos apenas os Requisitos Funcionais. Se certos requisito estão logicamente associadas (por exemplo, você só pode implementar o requisito B somente se o requisito A for incluído), são listados somente requisitos principais (driving feature) na análise.
2. O stakeholder deve estimar o benefício relativo de cada requisito a ser fornecida para o cliente ou negócios numa escala de 1 a 9. O valor 1 indica que ninguém considera o requisito útil e 9 significa que ele é extramente importante. Estes valores de benefícios indicam um alinhamento dos requisitos com as regras de negócios do produto.
3. Deve ser estimada a penalidade relativa que o cliente ou o negócio sofrerá caso o requisito não seja incluído. Novamente, é necessário utilizar a escala de 1 a 9, onde o valor 1 indica que nada será afetado se o requisito for excluído, e 9 indica um sério problema caso contrário. Requisitos que possuam baixo benefício e baixa penalidade adicionam custo ao projeto, mas agregam pouco valor. Quando os valores de penalidade forem atribuídos, é necessário que se considere o quão infeliz um cliente seria se um requisito específico não fosse incluído. É importante fazer as seguintes perguntas:
   1. Seu produto perderia pontos em comparação com outro produto que contém tal funcionalidade?
   2. Haveria alguma conseqüência contratual ou legal?
   3. Estaria violando algum padrão do governo ou das regras de negócio?
   4. Os usuários seriam incapazes de executar alguma função necessária?
   5. Quais problemas surgiriam devido a promessas do pessoal de marketing com relação a uma funcionalide que no final fosse omitida?
4. O modelo calcula o valor total de cada requisito como a soma de seus benefícios e penalidades. Por padrão, benefício e penalidades recebem o mesmo peso. Como um refinamento é permitido alterar os pesos relativos para estes dois fatores.
5. Depois que os desenvolvedores estimarem o custo relativo de implementação de cada requisito, novamente a escala de 1 (fácil e rápido) a 9 (caro e demorado), o modelo calcula o percentual do custo total que cada requisito fornece no modelo. Os desenvolvedores estimam os custos baseados na complexidade, interface, possibilidade de reuso, quantidade de testes, documentação necessária, dentre outros.
6. Similarmente, os desenvolvedores devem estimar o risco relativo de cada requisito na escala de 1 a 9. Requisitos mal-definidos que podem demandar re-trabalho são de alto risco. A planilha calcula o percentual do risco total derivado de cada requisito.

No modelo padrão, o benefício, penalidade, custo e risco são mais pesados, mas no Controla é possível ajustar todos os quatro pesos. A precisão desta técnica está limitada à capacidade da equipe em estimar benefícios, penalidades, custos e riscos de cada item.

É importante observar que há pequenas diferenças nas prioridades calculadas. O método não tem formalismo matemático rigoroso. O ideal é agrupar requisitos que tem prioridades similares.
Diferentes usuários freqüentemente têm pensamentos distintos a respeito da importância de um requisito específico ou sobre a penalidade de omití-lo.

É importante tirar os requisitos da teoria para um nível no qual avaliações realistas possam ser feitas. Isto dará ao processo maior chance de construir produtos que agregam o máximo de valor ao negócio.

Na Figura 3 abaixo pode-se ver a exportação de cenários.