Use Case Point: Estimativas de Projeto – Parte 2

Artigo no estilo: Curso

A técnica de pontos por caso de uso (UCP) surgiu como uma adaptação para os pontos de função. Contudo, não houve grande repercussão do método nessa época.

As empresas que utilizam os casos de uso como forma de traduzir os requisitos do cliente conseguem definir as ações que o sistema deve realizar no início do projeto, assim como no decorrer do desenvolvimento do sistema.

O UCP permite que as estimativas sejam realizadas durante o levantamento de requisitos, e nas fases de análise e implementação do projeto.

Estimativas geradas no início do projeto permitem ao gestor o levantamento de dados imediatos para calcular o custo do produto. O CoCoMo é dependente da tecnologia aplicada, pois gera as métricas a partir de linhas de código.

A Análise de Pontos de Função permite a medição independente da linguagem de programação utilizada, contudo deve ter as funcionalidades do sistema definidas para que os cálculos sejam implementados. O UCP, por outro lado, contabiliza as realizações dos componentes no diagrama de caso de uso.

Outro ponto importante a ser esclarecido é que os casos de uso são de simples entendimento pelo usuário, tornando, portanto, as suas métricas facilmente evidenciadas e justificadas. Os clientes e os usuários finais têm interesse nesse tipo de modelagem, pois ela representa toda a funcionalidade do sistema e descreve como ele será usado; sua participação durante a modelagem é fundamental, uma vez que um analista de sistema será um agente que transcreverá aquilo que entender sobre a realidade exposta pelos clientes/usuários e suas necessidades, em especificações técnicas que devem retratar tal realidade.

Dessa forma, as estimativas também poderão ser entendidas pelo cliente, que estará capacitado a negociar com o seu fornecedor o custo em razão da complexidade do produto.

Situações em que há modificações na especificação são previstas para essa medição, pois os requisitos, desde que previamente acordados entre fornecedor e cliente, são passiveis de adaptação. Existem quatro razões principais no projeto que levam os requisitos a serem readaptados:

· Mudanças funcionais nos requisitos que não foram especificadas nos casos de uso: as necessidades do cliente/usuário evoluem, refletindo no sistema em desenvolvimento. Essas modificações devem, antes de tudo, estar documentadas nos casos de uso, impedindo que haja desvios das métricas com o projeto;

· A evolução dos requisitos não funcionais também deve aparecer na diagramação dos casos de uso, evitando que elementos importantes do desempenho do sistema deixem de constar para as estimativas;

· Os sistemas são suscetíveis a mudanças corretivas, caso apresentem alguma alteração com o que foi especificado nos requisitos, desse modo os defeitos localizados devem estar documentados no diagrama de casos de uso;

· Algumas alterações não são solicitadas pelo cliente, contudo o gerente de projetos pode solicitar à sua equipe alterações quanto ao produto em desenvolvimento, a fim de evitar futuros problemas de incompatibilidade do software ou mesmo para adequá-lo às exigências do mercado.

Um dos problemas a ser enfrentado pelo Use Case Point é a atenção ao nível de detalhamento do diagrama de casos de uso. Quanto mais casos de uso, atores e relacionamentos a especificação tiver, mais precisa será a medição, principalmente se o diagrama respeitar a quantidade certa ou pelo menos aproximada de ações requeridas para o sistema.

Modelagem de Casos de Uso

Os diagramas de casos de uso são um dos principais diagramas utilizados na ...