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>.

Métricas de Halstead

Maurice Halstead, em sua teoria da Ciência do Software, propôs leis quantitativas para o desenvolvimento de software usando um conjunto de medidas, assim definidas de acordo com Pressman e Maxim (2016, p. 675):

• n1 = número de operadores distintos que há em um programa
• n2 = número de operandos distintos que há em um programa
• N1 = número total de ocorrências de n1 (operadores)
• N2 = número total de ocorrências de n2 (operandos)

Com base nestas medidas, podem ser calculados:

n = n1 + n2(vocabulário do programa)

N = n1 log2n1 + n2 log2n2(tamanho do programa)

V = (N1 + N2) x log2(n1 + n2)(volume do programa)

D = n1/2 x N2/n2 (dificuldade do programa)

Exemplo de aplicação das métricas de Halstead

main() {

int a, b, c, med;

scanf("%d %d %d", &a, &b, &c);

med = (a + b + c) / 3;

printf("med = %d", med);

}

n1 (operadores únicos)= 12 main, (), {}, int, scanf, &, =, +, /, printf, " , ;

n2 (operandos únicos)= 7 a, b, c, med, "%d %d %d", 3, "med = %d"

N1= 30

N2= 15

n =n1 + n2 = 19(vocabulário do programa)

N =n1 log2n1 + n2 log2n2= 12x log212 + 7xlog27

=12x3.58 + 7x2.81 = 42.96 + 19.67 = 62.63(tamanho do programa)

V =(N1 + N2) x log2 (n1 + n2) = 45 x log219 =45 x 4.25 = 191.25(volume do programa)

D =n1/2 x N2/n2=12/2 x 15/7 = 12.85 (dificuldade do programa)

Modelos de Estimativa Empíricos

Alguns modelos de estimativa para software usam fórmulas empíricas. Essas fórmulas são derivadas usando análise de regressão de dados coletados de projetos anteriores. Normalmente usa-se uma amostra limitada de dados de projetos.

Cada modelo de estimativa é adequado para um determinado conjunto de classes de software e ambientes de desenvolvimento, ou seja, são dependentes dos dados dos projetos que foram usados para obtê-los. Devido a isso, geralmente esses modelos de estimativa devem ser adaptados para as condições locais da organização.

É claro que, antes de serem usados na sua empresa, esses modelos devem ser testados usando resultados de projetos finalizados. Os dados estimados pelo modelo devem ser comparados aos resultados reais e a eficácia do modelo deve ser analisada para as condições locais.

De acordo com Pressman e Maxim (2016, p. 744), a estrutura geral dos modelos empíricos tem a forma:

E = A + B x (ev)c

Onde:

A, B, c são constantes derivadas empiricamente

E esforço em pessoas-mês

ev variável de estimativa (LOC ou PF)

A maioria dos modelos de estimativa tem alguma forma de fator de ajuste ao projeto. Isso permite que a variável E seja ajustada por características específicas do projeto, tais como complexidade do problema, experiência da equipe e ambiente de desenvolvimento.

A seguir, apresentamos alguns exemplos de modelos empíricos orientados a FP para esforço (E):

E = -13.39 + 0.0545 x (PF) (modelo de Albrecht e Gaffney)

E = 60.62 + 7.728 x 10-8 x (PF)3 (modelo de Kemerer)

E = 587.7 + 15.12 x (PF) (modelo de Matson, Barnett e Mellichamp)

E agora, alguns exemplos de modelos empíricos orientados a LOC para esforço (E):

E = 5.2 x (KLOC)0,91 (modelo de Walston-Felix)

E = 5.5 + 0.73 x (KLOC)1,16 (modelo de Bailey-Basili)

E = 3.2 x (KLOC)1,05 (modelo de Boehm simples)

E = 5.288 x (KLOC)1,047 (modelo de Doty para KLOC > 9)

É importante ressaltar que para os mesmos valores de FP ou LOC, os modelos vão gerar resultados diferentes (porque foram gerados, cada qual, em alguns domínios de aplicação específicos). Portanto, para utilizar esses modelos, eles devem ser adaptados para as necessidades locais.

Métricas para Medição de Software

As métricas de software podem ser classificadas como diretas e indiretas. As medidas diretas do produto incluem linhas de código (Lines of Code – LOC) produzidas, velocidade de execução, tamanho da memória e defeitos relatados em certo período de tempo. As medidas indiretas do produto incluem funcionalidade, qualidade, complexidade, eficiência, confiabilidade, manutenibilidade, entre outras.

Métricas orientadas a tamanho – Lines of Code (LOC)

De acordo com Pressman e Maxim (2016, p. 709), medidas de software orientadas a tamanho são criadas pela normalização das medidas de qualidade e/ou produtividade, considerando-se o tamanho do software produzido.

Linhas de Código (Lines of Code – LOC)

Fonte: Iurii Stepanov/Shutterstock

As linhas de código podem ser escolhidas como valor de normalização, pois são a medida mais utilizada para medir o tamanho de um programa. São de fácil definição e precisão, devendo ser usadas como um indicador. A partir da medição de LOC ou KLOC (mil linhas de código), as métricas podem fornecer:

• erros por KLOC;
• defeitos por KLOC;
• custo por KLOC; e
• páginas de documentação por KLOC.

A partir delas, outras métricas podem ser derivadas, como:

• erros por pessoa-mês;
• KLOC por pessoa-mês; e
• custo por página de documentação.

Porém vale lembrar que a qualidade do código-fonte não pode ser medida pela quantidade de linhas de código e sim pela organização de tais linhas visando a manutenção e o reúso. Além disso, essas métricas não são a melhor maneira de medir os processos de software.