Quem é responsável pela gestão de um projeto de desenvolvimento de software sempre se depara com perguntas como “qual será o custo?” e “quanto tempo vai levar?”. Neste artigo, você vai saber como medir o tamanho do software e as principais técnicas usadas para estimar o esforço em desenvolver um novo produto ou modificar um sistema.
Medir o tamanho do software é como analisar as plantas antes de construir uma casa. Afinal, antes de construir, será preciso demonstrar a necessidade de recursos para a sua conclusão ou fazer uma reforma.
Mas é preciso reconhecer que esta tarefa é desafiadora, mesmo para líderes experientes. Por isso, reunimos neste artigo algumas das principais métricas utilizadas para medir o tamanho do software e mostramos a sua importância para o gerenciamento de projetos de desenvolvimento. Confira!
Leia também:
As 7 melhores empresas de desenvolvimento de software
Por que é tão importante medir o tamanho do software?
Antes de tudo, calcular o esforço para criar um sistema pode variar bastante, mas é uma etapa importante, pois sem ela o projeto pode nem sair do papel. Vale ressaltar também que esse cálculo pode ser feito por time ativo e entregas. É o caso da alocação por projeto, por exemplo.
“Muitas vezes os sistemas podem ser criados sem de fato mensurar o esforço, simplesmente com alocação de time e definição de tarefas e planejamentos em fases curtas (sprints). Nesses casos, há apenas o custo mensal atribuído ao projeto”, explica Rafael Sapata, CEO da UDS Tecnologia.
Assim como levam em conta o esforço humano, tais custos também se referem às ferramentas e à infraestrutura que são necessárias para a produção.
Mas além disso, o software é medido para:
- Estabelecer a qualidade do produto ou processo atual.
- Para prever melhorias futuras do produto ou processo.
- Melhorar as funcionalidades de um produto ou processo.
As principais maneiras de estimar o tamanho de um projeto de software são:
1) Por meio da medição das características do produto, através de uma metodologia e de métricas para converter a medida em uma estimativa de tamanho.
2) Por analogia, em que as estimativas de tamanho do projeto atual são baseadas em outras já realizadas em projetos similares. Ou seja, empresas e desenvolvedores maduros conseguem fazer estimativas mais assertivas baseadas em experiências anteriores.
No entanto, há diferenças entre medição e métrica:
A medição: indicação do tamanho, quantidade ou determinação de um atributo específico de um produto ou processo. Por exemplo, o número de erros em um sistema é uma medida.
A métrica: medida do grau em que qualquer atributo pertence a um sistema, produto ou processo. Por exemplo, o número de erros por pessoa/hora seria uma métrica.
É assim que a medição de software dá origem a métricas de software.
As métricas se relacionam a quatro funções de gerenciamento:
- Planejamento
- Organização
- Controle
- Melhorias
Porém, um software não é “uma coisa” concreta. Você pode medir tudo o que pode ser visto e tocado. Já o software é intangível, ou seja, não é tocável e nem visualizável (sem levar em consideração a codificação e processos que lhe dão funções visíveis e significado). Por isso, as métricas de software são, por assim dizer, um tema sobretudo matemático, quase filosófico.
Mas na prática, todo projeto tem que demonstrar a quem financia a necessidade de recursos para a sua conclusão. Caso essa primeira etapa não seja satisfatória, o projeto pode nem começar.
Só a partir da mensuração podemos ter ideia da quantidade de recursos que o software vai demandar.
Functional Size Measurement (FSM) é a técnica para medir um software em termos da funcionalidade que ele oferece pela quantidade de Requisitos Funcionais do Usuário.
Quais as principais métricas para medir o tamanho do software?
A resposta é complexa, pois existem dezenas de técnicas sendo desenvolvidas desde os anos 50 e nenhuma delas é 100% exata. Por que? Porque o tamanho funcional não é uma entidade absoluta. Calma, vamos por partes.
O que é o tamanho funcional do software?
O tamanho funcional é usado principalmente no estágio de planejamento para os cálculos de estimativa de recursos do projeto (custo, esforço e cronograma).
O FSM é usado também na conclusão de um projeto, para comparar o desempenho em termos de custo-benefício e eficiência das equipes de desenvolvimento e suporte.
O que são os requisitos funcionais do software?
Um requisito funcional é a designação de como um sistema deve se comportar (ou não). Ou seja, é o que o sistema deve fazer para atender às necessidades ou expectativas do usuário.
Por exemplo, pense no botão “adicionar ao carrinho de compras”. O comportamento é como o sistema faz isso (calcular o preço total da compra de cada produto e aceitar o pagamento por cartão de crédito). De fato, esse é um exemplo bem simples de um requisito funcional.
Dito isso, já podemos passar para um resumo sobre as métricas de medição do software com padrão ISO.
Métodos de medição de tamanho funcional comuns
Os métodos de medição de tamanho funcional (FSM) mais comumente usados são Pontos de Função, Pontos de Função IFPUG (International Function Point Users’ Group) e COSMIC (Common Software Measurement International Consortium).
Além destas duas técnicas, há outros FSMs comuns, como:
- NESMA
- FISMA
- Mark II
Para fins práticos e objetivos deste artigo são consideradas apenas 5 principais métricas para medir o tamanho do software: Pontos de Função, IFPUG, COCOMO, Planning Poker e PERT.
Análise de Pontos de Função (APF)
O conceito de Pontos de Função foi criado por Allan Albrecht, da IBM, em 1979. Um ponto de função é uma unidade de medida usada para expressar a quantidade de funcionalidade que um sistema de informação (como um produto) fornece a um usuário.
Os pontos de função são usados para calcular uma medição de tamanho funcional (FSM) do software. O custo (em moeda ou horas) de uma única unidade é chamado de produtividade e é calculado com base em projetos anteriores.
A partir do tamanho funcional, podem ser derivadas estimativas adicionais, como tempo e custo.
Posteriormente, a APF foi aprimorada pelo consórcio IFPUG, mas ainda é amplamente utilizada.
O método IFPUG
O IFPUG é uma organização fundada em 1986, sem fins lucrativos, que promove a utilização da técnica de Análise de Pontos de Função para estimar o tamanho de um software. Essa técnica se baseia na contagem de pontos, padronizados pelo CPM (Counting Practices Manual) e tem 7 etapas. A contagem inclui projeto de desenvolvimento, de manutenção ou de aplicação.
O IFPUG refinou a técnica de Pontos de Função original para levar em conta mais do que o processamento de dados relacionado a processos. Seu mérito reside na abordagem das funções e características de um sistema sob o ponto de vista do que ele faz para o usuário com base nos requisitos funcionais, e não nos técnicos.
Isso significa que é uma técnica de contagem que independe do hardware e da tecnologia de desenvolvimento.
Em 1998, foi constituído o BFPUG – Brazilian Function Point Users Group – o representante do IFPUG no Brasil.
COCOMO (Constructive Cost Model)
Esta técnica estima o esforço necessário (desenvolvimento, prazos e tamanho da equipe) para construir o software com base no tamanho do código.
Para isso, utiliza equações complexas para prever o número de programadores/mês e o tempo de desenvolvimento. O COCOMO aceita medidas de linhas de código ou Pontos de Função.
No entanto, diferente do IFPUG, é preciso ajustar as equações para que representem as influências sobre os atributos de hardware e software durante o ciclo de vida do projeto.
Story Points: Planning Poker
Depois do “chute”, essa métrica interativa talvez seja a estratégia mais utilizada e mais fácil para estimar o tamanho relativo de um projeto de software.
O Planning Poker utiliza como medida o conceito de Story Point, que nada mais é do que uma estimativa baseada em incertezas. Parece louco?
Imagine que você precisa comprar uma camiseta. Na loja, seleciona modelos de diversos tamanhos (P, M, G, etc.). Ao experimentar, você conclui que a camiseta da marca X de tamanho M serviu. Na próxima compra, você já vai saber que a marca X veste bem com o M e vai acertar o tamanho da camiseta sem experimentar.
Ou seja, esse processo foi baseado em incerteza, comparação e determinação da estimativa.
No Planning Poker, o dimensionamento relativo é usado para fornecer uma medida adequada para as equipes estimarem o trabalho.
Este método tem esse nome por sua origem na Metodologia Ágil Scrum (Planning) e pelo formato de jogo de baralho (Poker).
Leia também:
Dicas para acelerar o tempo de desenvolvimento de software
4 razões para usar testes automatizados no seus projetos
Como se calcula a estimativa com Planning Poker?
As cartas levam os números da sequência de Fibonacci como escala inicial para comparar itens (cada número é a soma dos dois números anteriores: 0, 1, 2, 3, 5, 8, 13, 21, e assim por diante).
Com os itens priorizados por um Product Owner, os membros do time precisam definir qual o menor item selecionado para a planning. Será a partir desse menor item que o time começará a sua comparação.
Quanto maior o número, mais complexo e incerto o trabalho será, assim como provavelmente será maior a quantidade de esforço necessária para ser concluído. Portanto, quanto mais complexo o item, mais ele deverá ser dividido para que seja o mais “relativamente mensurável” possível.
Como no exemplo da camiseta, se um item selecionado já foi desenvolvido pelo time em uma sprint passada, ele pode ser usado como referência de comparação e estimativa.
Esse processo de estimativa se torna dinâmico e divertido, envolvendo toda a equipe nas “apostas”, e é considerado um sucesso para medir o esforço de projetos ágeis de software.
PERT
Criada pela NASA em 1958, a técnica PERT consiste em descobrir a duração de uma atividade com base em três estimativas possíveis: Otimista (O), Pessimista (P) e Mais Provável (MP). Cada estimativa demonstra o nível de risco e incertezas inerentes a cada etapa, o que permite o cálculo de esforço, tempo e recursos necessários para concluir um projeto da seguinte forma:
- Otimista: é o cenário perfeito, onde tudo dá certo;
- Pessimista: é o pior cenário, onde tudo vai dar errado;
- Mais provável: é um cenário razoável, sem grandes surpresas (nem boas nem ruins).
A partir daí, o projeto é segmentado em uma série de funções e tarefas para a equipe:
- Quais as lideranças que vão participar do projeto;
- Quem será o responsável por acompanhar o projeto;
- Quais as etapas para a implementação do projeto;
- Qual a estimativa de duração do projeto, em cada uma de suas etapas;
Depois disso, e conforme a complexidade do projeto, é possível partir para o chamado de Método do Caminho Crítico (CPM/PERT). Entenda a seguir.
Método CPM – Critical Path Method
Considerado uma extensão da técnica PERT, o CPM é utilizado no gerenciamento de projetos mais complexos e extensos. Contudo, também pode ser aplicado em projetos simples.
Resumidamente, pode-se dizer que o CPM é um modelo gráfico, um diagrama em que são organizadas tarefas/atividades que permite mostrar a ligação entre cada uma das etapas e suas respectivas dependências que devem ser superadas para a realização total de um projeto.
Assim, o método CPM auxilia na identificação de gargalos, recursos e mão-de-obra necessária e possíveis problemas no projeto, dando uma visão mais ampla da sequência lógica do planejamento.
Fórmula do cálculo PERT
Na fórmula PERT, dá-se o peso maior para a estimativa Mais Provável, sem deixar de considerar as estimativas Pessimista e Otimista.
É possível alterar os pesos entre as estimativas conforme a realidade do projeto, mas os pesos não podem ultrapassar a soma total de 6.
Por exemplo, as estimativas:
- Otimista = 20 dias
- Pessimista = 35 dias
- Mais Provável = 25 dias
PERT = (35 + 4 x 25 + 20) / 6 = 25,83 dias.
Logo, a estimativa PERT calculada para a atividade é de 25,83 dias.
Depois de estipulada a PERT das atividades, e a sequência e dependência entre elas, é possível chegar à duração do projeto. Pode-se calcular também o desvio padrão, cujos cálculos fogem ao objetivo do artigo.
O importante aqui é que a técnica PERT melhora os resultados dos projetos e facilita a tomada de decisão.
Leia também:
Sustentação de software: vantagens e como ter sucesso
A importância dos Design Patterns no desenvolvimento de software
Como poupar tempo e dinheiro no desenvolvimento de aplicativos?
Gerencie o seu projeto de software de forma eficaz
Sem dúvida, a estimativa de tamanho do software é uma atividade crítica, pois impacta tanto na solução técnica quanto no gerenciamento do projeto de software, na manutenção e na qualidade do produto.
Assim, é recomendável medir o tamanho do software não somente no início, mas durante todo o ciclo de vida do projeto.
Também vale destacar que as técnicas e métricas para medir o tamanho do software são fundamentais para o levantamento de requisitos.
Mas apesar de toda a sua influência vital no desenvolvimento de software, incluindo aplicativos, diversas empresas brasileiras ainda mostram imaturidade na aquisição, monitoramento e uso inteligente de ferramentas de medição de seus projetos de software.
Segundo pesquisa do Ministério da Ciência e Tecnologia, apenas cerca de 29% das empresas brasileiras realizam estimativas de tamanho de software.
Sem dimensionar o software, é praticamente impossível esclarecer se os recursos do projeto estão sendo utilizados de maneira eficiente e se, de fato, os prazos serão alcançados.
A consequência é um alto grau de risco e de imprevisibilidade no andamento do projeto, e não é raro que isso leve à perda de prazos e dinheiro ou até mesmo inviabilize o produto digital.
Por fim, é importante ressaltar que as técnicas descritas aqui muito resumidamente são apenas algumas dentre as muitas existentes e não existe apenas uma que seja completa por si só.
Portanto, é recomendável que se escolha a técnica mais adequada para medir o tamanho do software ou associar mais de uma técnica, conforme o projeto e o que se pretende calcular.
A UDS sabe que a exigência dos usuários aumenta a cada dia. Por isso, fornecemos rapidamente uma estimativa detalhada, precisa e confiável, além de acompanhamento de performance e produtividade em tempo real. Fale com a gente para avaliar e conduzir seus projetos de software de forma segura.
