• Nenhum resultado encontrado

Capítulo 3 – Rastreamento de Requisitos

3.1 Importância do Rastreamento de Requisitos

Durante nossa pesquisa identificamos vários fatores que justificam o estudo e importância do rastreamento de requisitos. A seguir identificamos alguns dos fatores: Qualidade de software; Melhoria contínua de um processo; Análise de impacto e implementação de uma proposta de mudança; Manutenção de software e Melhoria do acompanhamento do progresso de um projeto.

A seguir explicaremos cada um dos fatores:

• Qualidade de software: A área de qualidade de software tem-se caracterizado pelo estudo e proposta de normas [ISO97] e modelos de qualidade (CMM [PAU93]), que, se aplicadas corretamente, poderiam contribuir para obter um software com maior qualidade. De fato, o rastreamento de requisitos é uma das atividades exigidas no nível dois do Capability Maturity Model for Software (CMM).

• Melhoria contínua de um processo: Entende-se por melhoria contínua de um processo o feedback contínuo da utilização de um processo durante o desenvolvimento do software e conseqüente melhoria do processo através desse feedback. Considerando-se o conjunto de relacionamentos estabelecidos entre diferentes artefatos do processo de software é possível responder algumas perguntas que contribuiriam para a melhoria de um processo de software. Por exemplo, considerando que foram estabelecidos relacionamentos entre as tarefas do cronograma do projeto, documento de requisitos e documentação do projeto, então algumas das seguintes perguntas poderiam ser respondidas:

◊ Por que um projeto foi bem sucedido ou mal sucedido? A inspeção dos relacionamentos entre requisitos e tarefas pode indicar como os requisitos dos clientes foram distribuídos no decorrer de um projeto.

Capítulo 3 – Rastreamento de Requisitos

◊ Quais foram os artefatos produzidos por cada programador? Uma alocação de uma tarefa para um ou mais recursos humanos pode ser enriquecida com o estabelecimento de relacionamentos entre pessoas e artefatos. Desta forma, identificaremos as pessoas responsáveis por cada um dos artefatos. Essa informação é importante para selecionar a pessoa mais apropriada para dar manutenção a um sistema.

◊ Quem foi o responsável por um determinado subsistema? De forma análoga ao item anterior, relacionamentos entre pessoas e artefatos ajudam a selecionar as pessoas mais apropriadas para dar manutenção a um subsistema.

◊ Quais foram os requisitos alocados nos diferentes subsistemas? Se forem estabelecidos relacionamentos entre requisitos e subsistemas, então uma inspeção desses relacionamentos pode identificar os subsistemas que implementam os requisitos do projeto. Isto será útil quando desejarmos reusar um subsistema no desenvolvimento de um outro sistema.

Estas e outras perguntas podem ser formuladas no momento em que os profissionais que participaram de um projeto já não mais trabalham na organização. Portanto, se o rastreamento não for realizado, maior tempo e recursos serão gastos na manutenção. Tradicionalmente, determinar os efeitos colaterais das mudanças no software tem sido realizado através de uma inspeção do código fonte e revisão da documentação. Contudo tal estratégia, embora possa funcionar de forma eficiente para pequenos sistemas, não é adequada para sistemas grandes e complexos.

• Análise de impacto e implementação de uma proposta de mudança: É sabido que no decorrer do processo de desenvolvimento, os clientes do sistema compreendem melhor alguns dos benefícios do sistema desejado. Isto os leva a formular ou reformular requisitos através das propostas de mudança. O uso do rastreamento em um projeto pode contribuir para conhecer e argumentar a decisão de aceitar ou rejeitar uma proposta de mudança. Por exemplo, uma proposta de mudança pode propor a inclusão de novos campos de informação para o gerenciamento dos clientes, mas a análise de impacto pode determinar que diagramas, programas, relatórios, interface, tabelas e código SQL

Capítulo 3 – Rastreamento de Requisitos

30 (Structure Query Language) precisam ser modificados. Com base na análise de impacto, o gerente poderá fazer uma estimativa de tempo e custo mais confiável e realista;

• Manutenção de software: Se um erro numa determinada funcionalidade (requisito) é detectado durante sua execução no sistema, este erro deveria ser identificado, resolvido, e as razões das suas causas, elucidadas. Se o rastreamento de requisitos estabeleceu relacionamentos entre requisitos e programas, podemos identificar e corrigir o erro mais eficientemente, pois saberemos de acordo com os relacionamentos qual programa implementa o requisito que apresenta problemas. Como afirmado por [PAL97], um dos benefícios do rastreamento de requisitos é reduzir o tempo e custo da manutenção e um sistema;

• Melhoria do acompanhamento do progresso de um projeto: Se o profissional do rastreamento de requisitos acompanha e registra os relacionamentos das tarefas com os artefatos e os requisitos do sistema, então existe uma grande probabilidade de se obter informações mais realistas do progresso do sistema.

Diante dos fatores que justificam o estudo e importância do rastreamento de requisitos, é possível afirmar que o rastreamento é um fator crucial para várias atividades do processo de desenvolvimento de software, pois fornece um conjunto de relacionamentos entre requisitos e artefatos que facilitam o trabalho de outras atividades. A manutenção de um sistema poderia realizar-se sem empregar rastreamento, porém, o custo para identificar os artefatos afetados pela introdução de uma mudança pode ser alto.

Uma organização que deseja empregar boas práticas de engenharia de software deve considerar a possibilidade de incluir a atividade do rastreamento de requisitos dentro das suas atividades de desenvolvimento. Para isso, é necessário que o rastreamento seja visto como uma atividade tão importante como as outras atividades do desenvolvimento, mesmo que o custo do investimento no rastreamento de requisitos seja alto e talvez não tenha um retorno tão imediato. O recomendável será sempre rastrear durante o processo de desenvolvimento, e não depois, ou apenas quando existir um problema ou proposta de mudança.

Capítulo 3 – Rastreamento de Requisitos