Técnica de decomposição: Estimativa Baseada em Problema

Como uma estimativa de projeto é tão boa quanto a estimativa do tamanho do trabalho a ser realizado, o dimensionamento representa o primeiro grande desafio do planejador de projeto. Para a determinação do tamanho do produto a ser construído, as abordagens mais utilizadas são:

• abordagem direta (medido em LOC – Lines of Code, por exemplo);
• abordagem indireta (medido em FP– Function Points, por exemplo).

De acordo com Pressman e Maxim (2016, p. 734), dados de LOC e FP são usados de duas maneiras distintas durante a estimativa do projeto de software: 1) como variáveis de estimativa para dimensionar cada elemento do software e 2) como métricas de referência coletadas de projetos anteriores e usadas em conjunto com variáveis de estimativa para desenvolver projeções de custo e esforço.

Em relação às técnicas de estimativa baseadas em LOC e FP, elas diferem quanto ao nível de detalhe necessário para a decomposição:

• Estimativa LOC: a decomposição considera que todas as funções podem ser decompostas em subfunções semelhantes a entradas de uma base de dados histórica (quanto maior for o grau de particionamento, mais provável será que estimativas precisas de LOC possam ser desenvolvidas)
• Estimativa FP: em vez de focalizar a função, é estimada cada uma das características do domínio de informação (entradas, saídas, arquivos de dados, consultas, interfaces externas), bem como os 14 valores de ajuste de complexidade.

Como alternativa, o planejador pode escolher outros componentes para dimensionar, como classes, objetos, casos de uso, modificações ou processos do negócio afetados.

Métricas referenciais de produtividade (por exemplo, LOC/PM ou FP/PM, onde PM=Pessoa por Mês) são então aplicadas à variável de estimativa adequada e o custo ou esforço correspondente à função é derivado. Em seguida, as estimativas de função são combinadas para produzir uma estimativa global para todo o projeto.

A experiência mostra que, frequentemente, há uma variação nos valores das métricas de produtividade de uma organização. Portanto, o uso como referencial de um único valor obtido de uma dada métrica não é recomendável.

O ideal é que a média de cada métrica deva ser calculada por domínio de projeto. Os projetos devem ser agrupados por tamanho de equipe, área de aplicação, complexidade e outros parâmetros relevantes. Em seguida, médias locais dos domínios devem ser calculadas.

No caso de estimativas de um novo projeto, ele deve ser primeiro classificado em um domínio e depois a média da métrica do domínio adequado deve ser usada para gerar a estimativa.

Independentemente da variável de estimativa que é usada (LOC, FP, número de classes, número de casos de usoetc), o planejador começa estimando um intervalo de valores para cada função (LOC, por exemplo) ou o valor do domínio de informação (FP, por exemplo).

Usando dados históricos (ou intuição caso todo o resto falhar), são estimados um valor de tamanho otimista (Tot), um mais provável (Tmp)e um pessimista (Tpess)para cada função ou contagem para cada valor do domínio de informação. Isso possibilita o cálculo de um valor esperado para a variável de estimativa tamanho (T), para cada função (LOC) ou valor do domínio de informação (FP).

Um exemplo de cálculo de um valor esperado para T pode ser a média ponderada:

T = ( Tot + 4Tmp + Tpess ) / 6

Uma vez determinado o valor esperado para a variável de estimativa de tamanho T, os dados históricos de LOC ou PF são aplicados.

Planejamento do Projeto: Estimativas do projeto

As estimativas de custo e esforço envolvem muitas variáveis como fatores humanos, técnicos, ambientais e políticos, que podem afetar o custo final do projeto e o esforço necessário para desenvolvê-lo.

Pressman e Maxim (2016, p. 733) indicam as seguintes opções que ajudam na obtenção de estimativas de custo e esforço que sejam confiáveis:

1. Adie a estimativa até que o projeto esteja mais adiantado: quanto mais tarde você fizer a estimativa, maior a probabilidade de acertar.
2. Baseie as estimativas em projetos semelhantes que já foram concluídos.
3. Use técnicas de decomposição: essas técnicas utilizam uma abordagem do tipo “dividir para conquistar”, que seria decompor o projeto em suas funções principais e atividades relacionadas.
4. Use um ou mais modelos empíricos para estimativas de custo e esforço.

Infelizmente, apesar de atraente, a opção 1 não é prática pois, normalmente, o cliente exige estimativas de custo e prazo logo no início. Desta forma, o adiamento deve ser feito com muito bom senso. A opção 2 depende fundamentalmente dos dados históricos usados para alimentar a estimativa; mas ainda que existam, nem sempre a experiência passada funciona como um bom indicador de estimativas futuras.

Na maioria das vezes, o problema de desenvolver uma estimativa de custo e esforço para um determinado projeto é muito complexo para ser considerado como um todo. Devido a isso, as técnicas de decomposição indicadas na opção 3, que reduzem o problema em um conjunto de problemas menores, se mostram atrativas, pois se espera que, com essa divisão, se torne mais fácil chegar à solução.

A opção 4 indica o uso de modelos empíricos. Esses modelos podem ser usados para complementar as técnicas de decomposição e oferecer uma estratégia valiosa.

A precisão da estimativa de um projeto depende dos seguintes fatores:

• o grau com que o planejador estimou adequadamente o tamanho do produto a ser construído;
• a aptidão para traduzir a estimativa de tamanho em esforço humano, tempo transcorrido e dinheiro;
• o grau com que o plano de projeto reflete a capacidade da equipe de software; e
• a estabilidade dos requisitos do produto e do ambiente que apoiam o esforço de Engenharia de Software.

Ferramentas automáticas de estimativa implementam uma ou mais técnicas de decomposição ou modelos empíricos, fornecendo uma interessante alternativa.

Planejamento do Projeto: Recursos do projeto

Uma tarefa importante no planejamento é a estimativa de recursos necessários para o desenvolvimento do software. A figura ilustra as três principais categorias de recursos de Engenharia de Software com que devemos nos preocupar em um projeto: recursos humanos, softwares reutilizáveis e ambiente de desenvolvimento.

Recursos de Engenharia de Software para o planejamento de estimativas

 

Fonte: Pressman; Maxim (2016, p. 731).

• Recursos humanos: após a avaliação do escopo, é realizada a seleção de habilidades necessárias para a conclusão do desenvolvimento, que envolve a especificação de cargos (como gerente de projeto, engenheiro de software sênior etc.) e a especialização (como banco de dados, teste, arquitetura cliente-servidor etc). Caso o projeto seja grande, a equipe pode estar geograficamente dispersa, o que requer a especificação da localização de cada recurso humano.
• Recursos de software reutilizáveis: as práticas de engenharia de software baseadas em componentes enfatizam a capacidade de reutilização. Esses componentes devem ser catalogados, padronizados e validados, podendo ser agrupados em quatro categorias: de prateleira (software já existente adquirido de terceiros ou de um projeto anterior), completamente testados (especificações, projetos, códigos ou dados de testes já existentes e validados), parcialmente testados (idem ao anterior, mas que requerem modificação significativa para serem usados) e novos (construídos pela equipe especificamente para o projeto).
• Recursos do ambiente de desenvolvimento: o Software Engineering Environment – SEE incorpora hardware e software, ou seja, uma plataforma de hardware que suporta as ferramentas de software necessárias para produzir os artefatos que irão compor o produto em desenvolvimento. Cada elemento de hardware e software deve ser especificado como parte do planejamento.

Planejamento do Projeto: escopo e viabilidade do projeto

Você construiria uma casa sem saber quanto iria gastar, que tarefas precisariam ser feitas e quais seriam os prazos para executá-las? Faço a mesma pergunta a você. Certamente sua resposta seria: não. Como a maioria dos sistemas e produtos de software pode custar consideravelmente mais do que construir uma casa, é muito razoável fazer uma estimativa antes de se começar a criar software.

A primeira atividade de planejamento do projeto de software é a determinação do escopo. O escopo do software descreve as funções e características que devem ser ofertadas aos usuários, o conjunto de dados de entrada e saída, o desempenho, as restrições, as interfaces e a confiabilidade que limitam o sistema. O escopo geralmente é definido por meio de:

• uma descrição narrativa do escopo do software após a comunicação com todos os stakeholders (partes interessadas); e
• um conjunto de casos de uso desenvolvido com a participação dos usuários (clientes).

Em ambos os caminhos é necessária uma intensa comunicação entre desenvolvedores e clientes. A técnica mais utilizada para isso é conduzir uma reunião preliminar ou uma entrevista, mas existem técnicas mais avançadas que visam facilitar essa comunicação. Como exemplo, podemos citar o FAST- Facilitated Application Specification Technique que é uma abordagem que visa encorajar a criação de uma equipe de clientes e desenvolvedores que trabalham juntos para identificar o problema, propor elementos de solução, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos.

A figura mostra as atividades relacionadas ao processo “Definir o escopo” de acordo com o guia PMI/PMBoK 5ª edição.

Atividades do processo Definir o Escopo

 

Fonte: PMI/PMBoK (2013, p. 120).

Uma vez entendido o escopo, é importante determinar a viabilidade do projeto dentro das dimensões delimitadas de: tecnologia, orçamento, tempo e recursos. Isso é importante para evitar dedicar esforço e dinheiro em um projeto que pode estar condenado ao fracasso desde o início.

Estimativas de Software e Planejamento de Projeto

Quando estamos envolvidos em um projeto de software, antes mesmo de começarmos a realizá-lo, precisamos lidar com alguns aspectos decisivos para o seu sucesso ou fracasso. Alguns destes aspectos, relacionados ao gerenciamento de projetos, são: escopo, custo, recursos e cronograma. Mas, de uma maneira mais geral, podemos dizer que o planejamento de um projeto de software envolve atividades como: Estimativa, Cronograma, Análise e gestão de risco, Planejamento da gestão da qualidade e Planejamento da gestão de mudanças.

Planejamento do Projeto

 

Fonte: dizain/Shutterstock

A estimativa é imprescindível para que sejam determinados a demanda de custos, esforço, recursos e tempo necessários para a criação do sistema ou artefato de software. Portanto, torna-se necessária grande dedicação a este assunto.

A estimativa de software é vista tanto como arte quanto como ciência e o desenvolvedor conta com várias técnicas úteis para auxiliá-lo. As métricas de processo e projeto coletadas ao longo de projetos anteriores fornecem uma base importante para a geração de estimativas quantitativas. Mas é importante ressaltar que a experiência do pessoal envolvido pode ajudar imensamente na medida em que as estimativas são desenvolvidas e revistas.

O planejamento de projeto fornece um guia para a Engenharia de Software bem sucedida. A estimativa é importante porque estabelece uma base para todas as outras atividades de planejamento de projeto.

Normalmente, as estimativas são feitas dentro de um período de tempo limitado no início do projeto e devem ser atualizadas regularmente à medida que o projeto avança. As abordagens modernas de Engenharia de Software, como os modelos evolucionários e modelos ágeis, assumem uma visão iterativa do desenvolvimento de software. Em tais abordagens, é possível revisitar a estimativa à medida que mais informações são conhecidas, permitindo, assim, revisá-la quando o cliente solicita modificações nos requisitos.

A estimativa de recursos, de custo e de cronograma exige experiência, acesso às informações históricas consistentes e empenho nas previsões quantitativas, quando informação qualitativa, em alguns casos, é tudo o que há disponível.

Toda estimativa tem incerteza e isso acaba acarretando riscos ao projeto. Se o escopo do projeto é mal entendido ou se os requisitos estão sujeitos a mudanças frequentes, a incerteza e o risco podem se tornar perigosamente altos.

Para tratarmos as estimativas de software, precisamos considerar o conjunto de tarefas relacionadas ao Planejamento de Projeto. O planejamento do projeto de software objetiva proporcionar um framework para que o gerente de projetos possa fazer estimativas adequadas de recursos, custos e cronograma. De acordo com Pressman e Maxim (2016, p. 730) as tarefas associadas a um bom planejamento de projeto são:

1. Estabelecer o escopo do projeto.
2. Determinar a viabilidade do projeto.
3. Definir os recursos necessários (recursos humanos, softwares reutilizáveis, ambiente de desenvolvimento).
4. Realizar as estimativas do projeto.
5. Fazer a Gestão de Riscos.
6. Desenvolver o cronograma do projeto.

Métricas para Manutenção

De acordo com Pressman e Maxim (2016, p. 678), pode ser calculado um SMI – Software Maturity Index (índice de maturidade de software) que fornece a indicação da estabilidade de um produto de software com base nas alterações que ocorrem em cada versão deste produto. Para este cálculo, devem ser obtidas as seguintes medidas:

• MT = número de módulos da versão atual
• Fc = número de módulos da versão atual que foram alterados
• Fa = número de módulos da versão atual que foram acrescentados
• Fd = número de módulos da versão anterior que foram excluídos da versão atual

SMI = [MT – (Fc + Fa + Fd)] / MT

Métricas Halstead Aplicadas ao Teste

O trabalho de testes, de acordo com Pressman e Maxim (2016, p. 676), pode ser baseado com base nas métricas de Halstead, podendo ser obtidas as métricas:

PL = 1/ Dou 1 / [(n1/2) x (N2/n2)]

e = V / PL ou (N1 + N2) x log2 (n1 + n2)/PL

A porcentagem de trabalho de teste global a ser dispensado a um determinado módulo k pode ser estimada com base na seguinte equação, na qual o denominador é a soma do trabalho de Halstead por todos os módulos do sistema:

Porcentagem de trabalho de teste (k) = e (k) / Ʃ e(i)

Complexidade Ciclomática

A complexidade ciclomática mede a complexidade de um determinado módulo (classe, método, função etc), com base na contagem do número de caminhos independentes que ele pode executar até o seu fim. Um caminho independente é o que apresenta pelo menos um desvio de fluxo ou um novo conjunto de comandos a serem executados.

Essa métrica parte do princípio de que, medindo a complexidade do programa, é possível saber quantos caminhos lógicos devem ser testados. Pode ser representada por um grafo de fluxo de controle, no qual os nós representam uma ou mais instruções sequenciais e os arcos orientados indicam o sentido do fluxo de controle entre as instruções. Sendo e (edges) o número de arestas e n (nodes) o número de nós, a complexidade ciclomática v(G) de um grafo pode ser calculada através da fórmula:

v(G) = e - n + 2

Um exemplo de um trecho de programa (procedimento) em pseudocódigo e seu correspondente grafo de fluxo é mostrado na figura.

Um trecho de programa e seu grafo de fluxo

Fonte: <treinaweb>.

No grafo da figura acima há 17 arestas e 13 nós. O cálculo da complexidade ciclomática é:

v(G) = e - n + 2 = 17 – 13 + 2 = 6

Mas há outra forma de fazer o cálculo da complexidade ciclomática, que implica o mesmo resultado. Considerando que R seja o número de regiões do grafo de fluxo:

v(G) = R

Observe a figura a seguir. O grafo de fluxo da figura foi demarcado com as regiões. Como são 6 regiões, v(G) continua sendo 6, como no cálculo anterior.

Grafo de fluxo com regiões do trecho de programa da figura 12

Fonte: <treinaweb>.