MÉTRICAS DE TAMANHO DE SOFTWARE

Segundo Freire (2008), avaliar o tamanho do software que será construído tem sido uma preocupação constante no contexto do desenvolvimento de software.

Pressman (2006) explica que determinar o tamanho do software é algumas vezes uma forma de encontrar um indicador para a complexidade do sistema que será projetado e quase sempre uma forma de encontrar um indicador para o aumento do esforço de codificação, integração e teste.

Para solucionar o problema de produzir estimativas com precisão, os engenheiros de software têm desenvolvido técnicas para compreender a relação que existe entre todos os fatores que afetam o esforço, o custo e o tempo no desenvolvimento de um projeto. (PFLEEGER, 2007 apud FREIRE, 2008, p. 37).

A seguir, serão apresentados alguns dos tipos de métricas mais utilizadas para calcular as estimativas de tamanho de software.

4.1.1 Linhas de Código - LOC

Segundo Peters e Pedrycz (2001), a técnica de mensuração por linhas de código (LOC - Lines of Code), ou de forma mais prática, milhares de linhas de código (KLOC), é a forma mais conhecida de medida de software, levando em consideração àquelas que são orientadas a tamanho.

A técnica LOC consiste na contagem do número de linhas de código fonte de um determinado programa de software. (MISIC; TESIC, apud FREIRE, 2008, p. 38).

Simon (2000 apud FREIRE, 2008, p. 38) explica que como a quantidade de linhas de código fonte é conhecida somente no final de um projeto de software, a estimativa deve ser feita, levando em consideração dados históricos de projetos anteriores.

De acordo com Pressman (2006), os defensores da técnica LOC alegam que as linhas de código estão presentes em qualquer projeto de software e podem ser facilmente contadas, além de existir um grande número de literatura as respeito do assunto. Por outro lado, os opositores argumentam que a técnica depende da linguagem de programação, que não

acomodam linguagens não procedimentais e que o seu uso na estimativa exige um nível de detalhamento que pode ser difícil de alcançar nas fases iniciais de um projeto de software.

4.1.2 Análise de Pontos de Função - APF

Segundo Freire (2008), a técnica de Análise de Pontos de Função (APF) foi desenvolvida por Allan Albrecht, em 1979, com a intenção de mapear as questões referentes à estimativa e à produtividade no desenvolvimento de softwares em ambientes heterogêneos.

A técnica AFP tem como objetivo medir o tamanho do software por meio da quantificação das funções implementadas sob o ponto de vista do usuário. (LONGSTREET, 2002 apud FREIRE, 2008, p. 39).

Pressman (2006) explica que o ponto de função é derivado a partir de uma relação empírica entre as medidas de contagem direta de domínio da informação e a avaliação de complexidade do software. Os valores de domínio da informação são definidos com base no número de arquivos, interfaces, entradas, saídas e consultas do sistema. Para cada um desses valores são atribuídos pesos para serem utilizados no cálculo do ponto de função.

O autor comenta que os defensores do ponto de função afirmam que a técnica é independente de linguagem de programação, e que é baseada em dados que são mais prováveis de serem conhecidos logo que o projeto começa a evoluir. Já, os opositores alegam que a técnica não é confiável pelo fato de que o cálculo é baseado em dados subjetivos.

4.1.3 COCOMO e COCOMO II

O modelo COCOMO (Constructive Cost Model) foi desenvolvido a partir de uma análise de banco de dados com 63 projetos de software, sendo que ele fornece fórmulas detalhadas para determinar o cronograma de um projeto, além do esforço de desenvolvimento e manutenção. (PETERS; PEDRYCZ, 2001).

Segundo Freire (2008), o COCOMO pode ser aplicado em várias fases do ciclo de desenvolvimento, fornecendo melhores resultados em estágios mais avançados do projeto. O autor explica que o modelo está dividido em três níveis de detalhe:

 Básico: O esforço e o custo são calculados em função do tamanho do programa estimado em linhas de código.

 Intermediário: Calcula o esforço de desenvolvimento levando em conta o tamanho do programa e os custos com equipe, hardware e atributos do projeto.

 Detalhado: Este nível utiliza todas as características do nível intermediário juntamente com o impacto do custo em cada fase do projeto de software. Segundo Sommerville (2003), o modelo COCOMO II foi criado para substituir o COCOMO, que acabou ficando obsoleto por estar muito ligado ao processo clássico de desenvolvimento de software, sem considerar as possíveis mudanças que podem ocorrer durante um projeto.

Valença (2007) explica que o COCOMO II suporta projetos de software que utilizam modelos de desenvolvimento em espiral, incremental e orientado a objetos.

Sommerville (2003) divide o COCOMO II em três níveis:

 Nível inicial de prototipação: Estimativas com base em pontos por objeto são utilizadas para estimar o esforço requerido.

 Nível inicial de projeto: Neste nível, os requisitos do sistema são concluídos e estimativas realizadas com base em pontos de função.

 Nível pós-arquitetura: Após a conclusão da arquitetura do projeto, é realizada uma estimativa do tamanho total do software.

4.1.4 Pontos de Caso de Uso - UCP

A UCP (User Case Points) é uma técnica de estimativa usada para determinar o tamanho de um projeto de software orientado a objetos baseada no conceito de casos de uso. (FREIRE, 2008).

Segundo Pressman (2006), os casos de uso têm a função de descrever as características visíveis do usuário que são requisitos básicos para um sistema. O caso de uso

não depende de linguagem de programação e é diretamente proporcional ao tamanho da aplicação em LOC e ao número de casos de teste que deverá ser executado no projeto.

Monteiro (2005 apud FREIRE, 2008, p. 46) explica que a eficácia da técnica UCP depende da padronização dos casos de uso de uma instituição, pois para obter as métricas é necessário contar o número de transações por caso de uso. As transações correspondem as atividades identificadas nos fluxos de eventos dos casos de uso.

A UCP tem ajudado a diminuir algumas dificuldades encontradas pelo mercado, no que diz respeito à adoção de técnicas de estimativas, porque é uma técnica simples e fácil de aplicar. (DAMODARAN; WASHINGTON, 2003 apud FREIRE, 2008, p. 46).