Em meio a tantos dados que devem ser coletados para o desenvolvimento de um projeto, é imprescindível que se façam estimativas a fim de minimizar erros de planejamento e até mesmo analisar a viabilidade do projeto. Em qualquer método de estimativa é importante que possamos sempre avaliar tamanho, esforço, qualidade e cronograma.
.
.
O que se deve medir?
Existem 4 aspectos que fazem a diferença num projeto de software:
- O Tamanho final do produto é dado módulos, programas, interfaces, linhas de código, sub-rotinas ou classes.
- O Esforço do projeto deve estimar quantos homens/horas (medida do esforço para o desenvolvimento) são necessários para se construir o produto.
- A Qualidade do produto é medida em taxas de erros encontrados e solucionados.
- O Cronograma deve indicar quando cada atividade começa e termina.
Método Delphi
É baseado no princípio de que estimativas de um grupo estruturado de especialistas são mais precisas do que as estimativas derivadas de um grupo informal ou de indivíduos isolados. Os especialistas são cuidadosamente selecionados pela sua experiência e respondem a um questionário em um ou mais ciclos. O processo é encerrado quando a média do ciclo final estabelece o resultado final, ou seja, quando ocorre estabilidade nos resultados.
Análise de Pontos de Função (APF)
Análise de Pontos de Função é uma técnica para a medição de projetos de desenvolvimento de software, visando estabelecer uma medida de tamanho, em Pontos de Função (PF), considerando a funcionalidade implementada, sob o ponto de vista do usuário. Como medida de tamanho de software (semelhante a metros quadrados na construção civil), Pontos de Função apenas não são suficientes para compor um programa de medição de software, apenas medem o tamanho funcional do software.
Pontos por Função (PF) é uma unidade de medida de software reconhecida pela ISO para estimar o tamanho de um sistema de informação baseando-se na funcionalidade percebida pelo usuário do sistema, independentemente da tecnologia usada para implementá-lo.
Análise de Pontos por Caso de Uso (UCP)
O método trata de estimar o tamanho de um sistema de acordo com o modo como os usuários o utilizarão, a complexidade de ações requerida por cada tipo de usuário e uma análise em alto nível dos passos necessários para a realização de cada tarefa, em um nível muito mais abstrato que a técnica de Pontos de Função.
Modelo de Custo Construtivo (COCOMO)
O método COCOMO é um modelo de estimativa do tempo de desenvolvimento de um produto e é subdivido em três implementações:
- 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.
- 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.
- Avançado: São incorporadas características da versão intermediária com uma avaliação de impacto de custo em cada passo de todo o projeto.
Planning Poker
O Planning Poker é uma técnica estimativa utilizada em métodos ágeis para estimar esforço ou tamanho relativo das tarefas no desenvolvimento de software. Um time de desenvolvimento estima utilizando um baralho com cartas que normalmente são uma seqüência de Fibonacci e indicando o número de horas necessárias para executar a tarefa estimada. E as estimativas ocorrem da seguinte forma:
- É selecionado um item para discussão.
- Cada integrante da equipe escolhe uma carta que mais remete o “tamanho” do item selecionado. Essa decisão está condicionada ao conhecimento tácito e da experiência de cada integrante da equipe.
- Todos os membros mostram suas cartas ao mesmo tempo para não condicionar a opinião do outro.
- Muito provavelmente terá cartas com valores diferentes. As divergências e justificativas das estimativas serão colocadas na mesa. Todos os membros irão absorver isso e voltarão ao passo dois.
- A estimativa do item finaliza quando as cartas convergirem para um valor acordado e compartilhado em consenso pela equipe.
Para concluir lembro a frase de Tom de Marco: “Não se pode gerenciar o que não se pode medir.”
Por Autor Anderson Raymundo Souza
Artigo do Seminário de Engenharia de Software 2011-2
Revisão Thiarlei Macedo | Fonte Micreiros.com