Métricas de Software – Estimativa de esforço e prazo
COCOMO
O que é COCOMO?
COnstructive COst MOdel (COCOMO) é um algorítmico modelo de estimativa do custo do software criado por Barry Boehm.
O modelo usa uma fórmula básica de regressão, com parâmetros que são derivados dos dados históricos e das características atuais dos projetos.
O método COCOMO é um modelo de estimativa do tempo de desenvolvimento de um software e está baseado no estudo de 63 projetos, dos quais foram examinados de 2.000 a 100.000 linhas de código em linguagens de programação Assembly.
O COCOMO consiste em três implementações: básico, intermediário e avançado. Avance a tela e compreenda cada uma delas.
COCOMO básico
COCOMO básico é um modelo estático que calcula o esforço de desenvolvimento de software e seu custo em função do tamanho de linhas de códigos desenvolvidas. Aplica-se às seguintes classes de projetos do software:
- Orgânicos: são projetos relativamente pequenos, simples e com pouca inovação, com equipes de dimensão relativamente pequena. Exemplo: mala direta.
- Semidestacado ou difuso (em tamanho e complexidade): são projetos intermediários com características entre o modo orgânico e o embutido, em que as equipes de trabalho são heterogêneas em termo de experiência, como, por exemplo, um sistema de processamento de transações (folha de pagamento).
- Embutido ou restrito: aplicável no desenvolvimento de sistemas complexos embutidos em hardware, com muitas inovações, restrições severas e/ou requisitos muito voláteis e de confinamentos operacionais; exemplo: sistema de controle de telefonia.
O COCOMO básico é um modelo estático de valor simples, que calcula o esforço do desenvolvimento de software em função do tamanho deste software, expresso em linhas de código estimadas.
Exemplos de COCOMO básico
Uma vantagem do COCOMO básico é a sua rapidez em estimativas de custo de software; porém, sua exatidão é limitada devido à falta de fatores para explicar as diferenças entre:
- Ferramentas;
- Qualidade de pessoal e experiência;
- Uso de ferramentas modernas e técnicas;
- Outros atributos de projeto que influenciam nos custos de software.
Exemplo 1: Considere um software com 33,3 Kloc; usando o modelo semidestacado, temos:
Suponha que outro software tenha o Kloc igual a 45,3?
Logo, o número ideal de pessoas no projeto é:
N = E/D = 152/14,5 = 11 pessoas
Exemplo 2: Considere que, após uma análise de ponto de função, detectamos 236 PFs não ajustados e que, além disso, as fórmulas do COCOMO tenham sido construídas com Kloc. Se a linguagem utilizada for ACCESS, temos:
TAMANHO = 38 x 236 (PF) = 8968 LOC = 8,968 KLOC
Usando o COCOMO básico, o gerente considerou o projeto como orgânico. Sendo assim, vamos usar as fórmulas.
COCOMO intermediário
O método intermediário é uma extensão do método básico, porém, com mais categorias de controle, como: atributos do produto; atributos de hardware; atributos pessoais; atributos do projeto.
Atributos do produto
- Confiabilidade exigida do software;
- Tamanho do banco de dados;
- Complexidade do software.
Atributos de hardware
- Restrições de desempenho de run-time;
- Restrições de memória;
- Mudanças do ambiente de software;
- Tempo de resposta.
Atributos de pessoal
- Capacidade dos analistas;
- Capacidade dos programadores;
- Experiência na aplicação;
- Experiência no ambiente de hardware;
- Experiência com a linguagem de programação.
Atributos do projeto
- Uso de ferramenta de software;
- Técnicas modernas de programação;
- Prazo requerido para o desenvolvimento.
O COCOMO intermediário calcula o esforço de desenvolvimento de software em função do tamanho do programa, que inclui custo, avaliação subjetiva do produto, hardware, pessoal e atributos de projeto. Observe a fórmula:
Considere que, no exemplo 2 (COCOMO intermediário), o gerente considerou o projeto como orgânico; portanto, usaremos as fórmulas:
Cálculo do EAF: analisando os 15 direcionadores da tabela de multiplicadores de esforço (clique aqui para visualizá-la), o gerente alcançou os seguintes resultados:
- Complexidade do software: Alta
- Restrições quanto ao uso da memória: Alto
- Experiência com a linguagem de programação: Baixa
- Capacidade dos programadores: Baixa
Os outros atributos foram considerados normais.
Assim, podemos calcular o EAF:
COCOMO avançado
No COCOMO avançado, são incorporadas características da versão intermediária com uma avaliação de impacto de custo em cada passo do projeto.
Nele, pode ser empregado software interativo auxiliar para a estimativa de custos e prazos. A partir de um conjunto de atributos, premissas e modos de desenvolvimento, o COCOMO estima os prazos, custos e recursos necessários para cada etapa do ciclo de vida do produto.
COCOMO avançado: Spider-CoCoMo
O que é Spider-CoCoMo?
É uma ferramenta oriunda das pesquisas do projeto SPIDER da Universidade Federal do Pará (OLIVEIRA, 2010). http://www.spider.ufpa.br/
Esse projeto tem como objetivo a construção de uma suíte de ferramentas livres para dar suporte à implementação do modelo de qualidade MPS.BR – Melhoria de Processo de Software Brasileiro (SOFTEX, 2009).
Por que foi concebida?
Sua concepção ocorreu pela necessidade de uma forma sistematizada e simples para realizar estimativas de projetos de software, pois a maioria das empresas utilizam planilhas eletrônicas e, com elas, não é possível atender completamente às necessidades dos gerentes, tendo em vista que não é possível obter uma base histórica dos valores estimados nos projetos da organização.
O que é o MPS.BR?
O MPS.BR (SOFTEX, 2009) é um programa que busca avaliar processos de desenvolvimento de software por meio de um conjunto de boas práticas. Esse modelo se divide em sete níveis de maturidade, partindo do nível G, o mais baixo, até o nível A, o mais alto. À medida que se passa de um nível para o outro, o processo é entendido como mais maduro; cada nível possui um conjunto de atividades, denominados processos. Por fim, cada processo contido em um nível possui resultados esperados, que indicam que um determinado item do processo em questão foi alcançado. A avaliação se dá pela análise de cada resultado esperado dos processos.
A Spider-CoCoMo está inserida no contexto do processo Gerência de Projetos, auxiliando nas estimativas de custo, prazos e número de pessoas. A ferramenta está indiretamente ligada com o resultado esperado do GPR 2 e diretamente ligada com o GPR 4, dois dos resultados esperados desse processo.
GPR 2
Visa garantir que tarefas e produtos de trabalho sejam dimensionados por meio de métodos apropriados. A ferramenta necessita que o resultado esperado seja cumprido, pois ele serve de parâmetro para o cálculo do CoCoMo. Em particular para esse resultado esperado, o projeto SPIDER possui duas ferramentas para medir o tamanho de projeto baseado no método de análise de pontos por função e pontos por casos de uso, que são a Spider-APF e a Spider-UCP (BALDEZ, 2010).
Caso seja adotado qualquer outro tipo de método que não os citados anteriormente, o valor pode ser inserido manualmente na Spider-CoCoMo sem que haja perda nos resultados estimados.
GPR 4
Requer que o esforço e os custos sejam estimados. Esse resultado esperado é totalmente atendido com a utilização da Spider-CoCoMo tanto nos níveis G e F, tendo em vista que o método CoCoMo é utilizado para estimativas, como dito anteriormente, como nos níveis superiores ao F, pois os valores estimados são armazenados em banco de dados, sendo feito um histórico deles. Esse é o grande diferencial da Spider-CoCoMo sobre as planilhas eletrônicas.
COCOMO II
O que é COCOMO II?
O COCOMO II (segunda versão do COCOMO – COnstructive COst MOdel) é um modelo objetivo de custos para o planejamento e execução de projetos de software. Um modelo de custos fornece estrutura (framework) para a comunicação de decisões de negócio entre os envolvidos em um empreendimento baseado em software.
Além disso, oferece suporte a negociações contratuais, análises de melhoria de processo, aquisição de ferramentas, alterações na arquitetura, decisões entre desenvolvimento e aquisição de componentes, assim como diversas outras decisões sobre retorno do investimento, servindo de base a estimativas plenas de credibilidade.
Como se processa?
Embora a maioria das organizações inicie o processo de estimativa utilizando modelos lineares simples, o amadurecimento do processo de software leva à utilização de modelos mais sofisticados, capazes de melhor descrever os fatores que influenciam os projetos de software.
O COCOMO II é uma excelente escolha nesse sentido. Desenvolvido em uma universidade e fortemente apoiado pela indústria, oferece uma solução aberta, escalável e respeitada.
Quais são suas vantagens?
- O mesmo processo pode ser aplicado ao projeto inteiro ou apenas a um componente individual;
- O COCOMO pode calcular a programação da manutenção anual;
- O COCOMO pode examinar a vantagem de dados históricos e, com essas informações, criar uma constante da calibração que pode ser calculada para estimativas futuras.
Qual é a sua desvantagem?
Imprecisão: sua precisão pode ser prejudicada no início do projeto, pois o modelo depende fortemente de uma estimativa precisa da quantidade de linhas.
Método de Putnam
O método de Putnam considera múltiplas variáveis e o ciclo de desenvolvimento do projeto.
Com base em análise estatística, Putnam relacionou os comportamentos prazo e esforço.
Equação de Putnam
Complexidade ciclomática
O que é?
Em 1976, McCabe criou uma maneira de testar cada caminho independente de um programa, de forma que a quantidade de casos de teste será a complexidade ciclomática do programa.
Complexidade ciclomática ou complexidade condicional é uma métrica usada para indicar a complexidade do software; mede a quantidade de caminhos de execução independentes a partir do código fonte.
Como é Calculada?
É calculada a partir de um grafo de fluxo: os nós do grafo correspondem a grupos indivisíveis de comandos, e uma aresta conecta dois nós.
Em que pode ser aplicada?
A complexidade ciclomática também pode ser aplicada a funções, módulos, métodos ou classes individuais de um programa.
Vamos a um exemplo?
Veja como calcular a complexidade ciclomática para um artefato de software (VG).
V(G) = E – N + 2P
Para:
E = 8 P = 1
N = 7
V(G) = 8 – 7 + 2 = 3
V(G) = 3
V(G): Complexidade ciclomática;
G: Grafo (fluxograma);
E: Número de bordas (ligações);
N: Número de nós (instruções);
P: Número de componentes conectados ao gráfico (assumimos P = 1).
Conclusões
- Não existe um modelo único;
- Deve-se desenvolver o modelo mais adequado à empresa;
- O modelo deve ser periodicamente revisto;
- Deve-se validar por mais de um método;
- É um aspecto estratégico para a empresa.
Referências
Base: Pós em Engenharia de Software – Estácio (EAD), com várias adaptações e melhorias.
PADUA Filho, Wilson de. Engenharia de Software: fundamentos, métodos e padrões. 3. ed. Rio de Janeiro: Editora LTC, 2009.
PETERS, James F. Engenharia de Software. 3. ed. Campus, 2001.
PRESSMAN, Roger S. Engenharia de Software. 7. ed. McGraw Hill, 2011.
SOMMERVILLE, Ian. Engenharia de Software. 8. ed. McGraw Hill, 2007.
VAZQUEZ, C. E.; SIMÕES, G. S.; ALBERT, R. M. Análise de ponto de função medição, estimativa e gerenciamento de projetos de software. São Paulo: Editora Érica, 2009.
Exercícios de fixação