Gestão de Riscos

Conceitos básicos sobre riscos em projetos de software

Estudos e a prática comprovam que uma série de fatores podem ameaçar o sucesso dos processos de desenvolvimento de software. Taxas relativamente altas de projetos atrasados, custos que ultrapassam as estimativas, implementações que não correspondem ao que foi exigido e projetos que são abortados antes da sua conclusão são problemas frequentemente encontrados na área de desenvolvimento de software.

De acordo com levantamento realizado pelo Standish Group, em 2015, dos projetos acompanhados, 29% foram completados com sucesso e 19% fracassaram. A tabela ilustra estes números desde 2011.

Resultados do Chaos Report do StandishGroup

	2011	2012	2013	2014	2015
Successful	29%	27%	31%	28%	29%
Challenged	49%	56%	50%	55%	52%
Failed	22%	17%	19%	17%	19%

Fonte: Hastie; Wojewoda (2015).

Estes números deixam claro que projetos de software envolvem riscos e são esses riscos que podem comprometer o projeto. Assim, é importante entender os riscos e tomar medidas para evitá-los ou administrá-los.

Mas o que se entende por risco?

Segundo Pethia et al. (2000, p. 45), “risco é a medida da probabilidade e severidade de efeitos adversos”.

Riscos de software

 

Fonte: Olivier Le Moal/Shutterstock

Ropponen; Lyytinen (2000, p. 100) definem variável de risco como “um estado ou propriedade de uma tarefa de desenvolvimento ou do ambiente que, uma vez ignorada, aumentará a probabilidade de falha do projeto”.

Pressman e Maxim (2016, p. 779) afirmam que, embora haja debate em relação à melhor definição de risco, há um consenso de que o risco

sempre envolve duas características: incerteza, pois o risco pode ou não ocorrer, ou seja, não existem riscos com 100% de probabilidade; e perda, pois se o risco se tornar realidade, consequências ou perdas indesejadas ocorrerão.

Os autores dizem que quando um risco for analisado, é importante que sejam quantificados tanto o nível de incerteza quanto o grau de perda associados. Para isso, devem ser consideradas as diferentes categorias de risco:

• Riscos de Projeto: identificam problemas potenciais orçamentários, de cronograma, de pessoal (quantidade e organização), de recursos, de clientes e de requisitos e seu impacto em um projeto de software. Ameaçam o plano do projeto.
• Riscos Técnicos: identificam problemas potenciais de implementação, de interface, de verificação e de manutenção. Ameaçam a qualidade e a data de entrega do software a ser produzido.
• Riscos do Negócio: ameaçam a viabilidade do software a ser construído. Os principais riscos do negócio são:
• Risco de Mercado: construir um produto ou sistema excelente que não interesse a ninguém.
• Risco Estratégico: construir um produto que não se encaixa mais na estratégia geral de negócios da empresa.
• Risco de Vendas: construir um produto que a equipe de vendas não sabe como vender.
• Risco Gerencial: perda de apoio da gerência superior por causa de modificação de enfoque ou de pessoal.
• Risco de Orçamento: perda de comprometimento orçamentário ou de pessoal.

Ainda segundo os autores, outra categorização possível de risco inclui os seguintes:

• Riscos Conhecidos: podem ser descobertos após a avaliação do plano de projeto, do ambiente técnico e comercial (prazo de entrega irreal, falta de documentação dos requisitos e/ou do escopo, ambiente de desenvolvimento ruim ou desfavorável etc.).
• Riscos Previsíveis: obtidos de experiência de projetos anteriores (rotatividade de pessoal, diluição do esforço de pessoal à medida que os pedidos de manutenção surgem).
• Riscos Imprevisíveis: extremamente difíceis de serem identificados antecipadamente.

Conciliação de Modelos de Estimativas

Normalmente, estimativas de projeto precisas usam pelo menos duas das técnicas de estimativas apresentadas anteriormente. Valores médios (conciliação) de estimativas são então calculados através dos valores de estimativa obtidos das técnicas consideradas.

A conciliação é realizada quando a variação máxima a partir da média obtida não ultrapassa 20%. Nesses casos, há forte razão para acreditar que as estimativas são confiáveis. Caso contrário, mais pesquisa e análise devem ser realizadas.

Pela comparação e conciliação das estimativas derivadas usando diferentes técnicas, é mais provável que o planejador consiga derivar uma estimativa precisa. Vale lembrar que a estimativa de projetos de software não é uma ciência exata. Mas, conforme vimos, dados históricos e técnicas sistemáticas podem melhorar a precisão da estimativa.

O que são Pontos por Caso de Uso (ou Use Case Points)?

Até o início da década de 1990 havia a falsa noção de que a APF não era adequada para medir sistemas orientados a objetos. Aqueles que compartilhavam desta noção, na prática, desconheciam a APF.

Com a disseminação da construção e projeto de sistemas orientados a objetos, houve também uma mudança na forma de se especificar e modelar os sistemas. A UML e os casos de uso rapidamente tornaram-se padrão na indústria de software.

Dentro deste contexto, em 1993 Gustav Karner propôs em um trabalho acadêmico: a metodologia dos Pontos por Caso de Uso (baseado na Análise de Pontos de Função) com o intuito de estimar recursos para projetos de software orientados a objeto desenvolvidos utilizando o processo Objectory.

Fonte: <fattocs>

Estimativa com Pontos de Caso de Uso ou Use Case Points (UCPs)

Conforme já dissemos, os UCs podem ser utilizados na estimativa do tamanho planejado de um projeto de software. Embora não seja fácil utilizá-los, é possível calcular os Pontos de Caso de Uso ou Use Case Points (UCPs). Pressman e Maxim (2016, p. 741) descrevem os passos para o cálculo de UCPs como apresentado a seguir.

• Passo 1: Cada UC é avaliado para determinar sua complexidade relativa, podendo ser classificado como:
• UC Simples: possui fator de ponderação 5 e corresponde a uma interface de usuário simples, um único banco de dados com 3 ou menos transações e 5 ou menos implementações de classe.
• UC Médio: possui fator de ponderação 10 e corresponde a uma interface de usuário mais elaborada, 2 ou 3 banco de dados com 4 a 7 transações e 6 a 10 implementações de classe.
• UC Complexo: possui fator de ponderação 15 e corresponde a uma interface complexa, vários banco de dados com 8 ou mais transações e 11 ou mais implementações de classe.
• Deste passo resulta o Unadjusted Use Case Weight – UUCW, que é a soma de todas as contagens de UCs multiplicadas pelos correspondentes fatores de ponderação.

• Passo 2: cada ator é avaliado,podendo ser classificado como:
• Ator Simples: possui fator de ponderação 1 e corresponde a autômatos (outros sistemas, máquinas ou dispositivos) que se comunicam por meio de uma API.
• Ator Médio: possui fator de ponderação 2 e corresponde a autômatos que se comunicam por meio de um protocolo ou depósito de dados.
• Ator Complexo: possui fator de ponderação 3 e corresponde a seres humanos que se comunicam por meio de uma interface gráfica ou outra interface envolvendo pessoas.
• Deste passo resulta o Unadjusted Actor Weight – UAW, que é a soma de todas as contagens de atores multiplicadas pelos correspondentes fatores de ponderação.

• Passo 3: os fatores não ajustados UUCW e UAW são modificados considerando-se fatores de complexidade técnica ou Technical Complexity Factors – TCFs e fatores de complexidade ambiental ou Environmental Complexity Factors – ECFs. Uma vez determinados estes fatores, o valor final do UCP é calculado de acordo com a fórmula:

UCP = (UUCW + UAW) x TCP x ECF

Modelo COCOMO II

De acordo com Pressman e Maxim (2016, p. 745), COCOMO –COnstructive COst MOdel (Modelo Construtivo de Custo) é uma hierarquia de modelos de estimativa de software proposto por Barry Boehm em 1981. Este modelo evoluiu para um modelo mais abrangente denominado COCOMO II.

O modelo COCOMO II foi derivado dos dados de produtividade coletados de milhares de projetos de software e, com base nestes dados, foi derivado um modelo de estimativa E representado pela equação:

Onde:

E= esforço em pessoas-mês ou pessoas-ano

t = duração do projeto em meses ou anos

B = fator de habilidades especiais (para programas pequenos em torno de 5 a 15 KLOC, B= 0.16 e para programas grandes maiores que 70 KLOC B= 0.39)

P = parâmetro de produtividade (valores típicos podem ser P=2mil para software embarcado ou de tempo real, P= 10mil para softwares de telecomunicações e sistemas e P=28mil para aplicações comerciais).

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.

Exemplos de Estimativas Baseadas em LOC (parte 2)

Exemplo 2:

A tabela 1 apresenta as estimativas de tamanho otimista, mais provável e pessimista para cada uma das funções a serem implementadas no software CAD do exemplo 1. Considerando que a empresa de software responsável em desenvolver o projeto produz 400 LOC/por mês, com um valor bruto de mão de obra de R$ 3000,00 por pessoa-mês, podemos, com base nesses dados, obter a estimativa de custo e esforço necessários para construir o software usando a técnica de estimativa baseada em LOC.

Tabela 1 – Estimativas de Tamanho Otimista, Mais Provável e Pessimista (em LOC)

Função	Otimista(Tot)	Mais Provável(Tmp)	Pessimista(Tpess)
Recursos de Visualização	3000	4400	6000
Recursos de Análise 2D	5000	5500	6500
Recursos de Análise 3D	6400	7000	6900
Recursos de Controle e Interface com o usuário	3300	2500	2300
Administração da Base de Dados	6000	4100	2600
Recursos de Controle de Periféricos	1000	2800	4200
Recursos de Análise de Projetos	7700	7900	8200

A tabela 2 apresenta o cálculo do tamanho de cada uma das funções (em LOC) utilizando a expressão apresentada anteriormente T=(Tot + 4Tmp + Tpess)/6.

Tabela 2 – Cálculo do tamanho de cada função

Função	Estimativa de LOC
Recursos de Visualização	T1 = ( Tot + 4Tmp + Tpess ) / 6 @4433
Recursos de Análise 2D	T2 = ( Tot + 4Tmp + Tpess ) / 6 @5583
Recursos de Análise 3D	T3 = ( Tot + 4Tmp + Tpess ) / 6 @6883
Recursos de Controle e Interface com o usuário	T4 = ( Tot + 4Tmp + Tpess ) / 6 @2600
Administração da Base de Dados	T5 = ( Tot + 4Tmp + Tpess ) / 6 @4167
Recursos de Controle de Periféricos	T6 = ( Tot + 4Tmp + Tpess ) / 6 @2733
Recursos de Análise de Projetos	T7 = ( Tot + 4Tmp + Tpess ) / 6 @7197
Estimativa das Linhas de Código (Total)	34317 LOC

Utilizando as estimativas de tamanho e os dados do valor bruto da mão de obra e produtividade fornecidos anteriormente, podemos calcular as estimativas de esforço e custo total conforme indicado a seguir.

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (34317 LOC)/(400 LOC/pessoas-mês)

@ 86 pessoas-mês

Custo por LOC = (valor bruto da mão de obra) / (produtividade média)

= (3000 reais/pessoas-mês) / (400 LOC/pessoas-mês)

= 7.50 reais/LOC

Custo total estimado do projeto=(Estimativa de LOC) * (Custo por LOC)

= (34317 LOC) * (7.50 reais/LOC)

@ 257400.00 reais

Exemplos de Estimativas Baseadas em LOC

Exemplo 1:

Suponha um determinado software que será desenvolvido. Este software é do tipo CAD – Computer-Aided Design, ou seja, tem uma aplicação científica. Após a análise do escopo do software, suas funções principais foram identificadas e são relacionadas na tabela.

Principais funções identificadas no software CAD

Função	Estimativa de LOC
Recursos de Visualização	3000
Recursos de Análise 2D	5000
Recursos de Análise 3D	6400
Recursos de Controle e Interface com o usuário	3300
Administração da Base de Dados	6000
Recursos de Controle de Periféricos	1000
Recursos de Análise de Projetos	7700
Estimativa das Linhas de Código (Total)	32400

Em seguida, um intervalo de estimativa de LOC é desenvolvido para cada função. Esse intervalo considera as estimativas como otimista, mais provável e pessimista.

Os valores das estimativas apresentados na tabela 3, para cada função, foram obtidos utilizando a expressão para T já apresentada (T =(Tot + 4Tmp + Tpess)/6).

Por exemplo, para a função “Recursos de Análise 3D”, foram obtidas: estimativa otimista Tot= 3800 LOC; mais provável Tmp= 6500 LOC; pessimista TPess= 8600 LOC. Estes valores, aplicados na equação T= (3800 + 4x6500 + 8600)/ 6, produzem um valor esperado de T= 6400 LOC.

Após o cálculo das estimativas de LOC para cada função, foi identificada uma estimativa de 32400 LOC para o sistema a ser desenvolvido.

Considerando que uma análise de dados históricos revelou que a produtividade organizacional média para sistemas desse tipo é de 500 LOC/pessoas-mês e que o valor bruto da mão de obra é de R$ 4000,00 por pessoa-mês, o custo por linha de código é de aproximadamente:

Custo por LOC = (valor bruto da mão de obra)/(produtividade média)

= (4000 reais/pessoas-mês)/(500 LOC/pessoas-mês)

= 8 reais/LOC

Portanto, o custo total estimado para o projeto é de:

Custo total estimado do projeto = (Estimativa de LOC)*(Custo por LOC)

= (32400 LOC) * (8 reais/LOC)

= 25920.00 reais/mês

O esforço necessário estimado para desenvolver o projeto é de:

Esforço necessário estimado=(Estimativa de LOC)/(produtividade média)

= (32400 LOC)/(500 LOC/pessoas-mês)

@ 65 pessoas-mês

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

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.

Métricas orientadas a classes: métricas CK – Chidamber e Kemerer

A classe é a unidade fundamental de um sistema OO e as métricas associadas a uma classe individual e às colaborações entre classes podem ajudar na avaliação da qualidade de um projeto OO. Chidamber e Kemerer propuseram um conjunto de métricas para sistemas OO, denominado CK metrics suite, que é bastante conhecido.

As 6 métricas CK, de acordo com Pressman e Maxim (2016, p. 667-669) são assim definidas:

• WWC – Weighted Methods per Class (métodos ponderados por classe): suponha que são definidos para uma classe C n métodos de complexidade c1, c2...cn. A métrica específica de complexidade escolhida (como complexidade ciclomática, por exemplo) deve ser normalizada de forma que a complexidade nominal para cada método assuma o valor 1.0.
• Podemos concluir que o WWC deve ser mantido o mais baixo possível, pois à medida que o número de métodos de uma classe cresce, ela tende a se tornar cada vez mais específica daquela aplicação, deixando seu potencial de reutilização muito baixo.
• DIT – Depth of the Inheritance Tree (profundidade da árvore de herança): essa métrica se refere ao comprimento máximo do nó até a raiz da árvore de hierarquia de classes. Na medida em que DIT cresce, é possível que classes de nível inferior herdem muitos métodos. Portanto, um DIT baixo mostra-se mais desejável. Um DIT alto leva a uma maior complexidade do projeto, mas por outro lado, pode implicar que haja muitos métodos que possam ser reutilizados. Na árvore de hierarquia de classes da figura, o DIT é 3.

Diagrama de classes: exemplo de árvore de hierarquia de classes

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

• NOC – Number of Children (número de filhas): as subclasses diretamente subordinadas a uma classe na hierarquia de classes são chamadas de filhas. Na figura 7 a classe Parede tem 3 subclasses SegmentoParede, Janela e Porta. Na medida em que o NOC aumenta, a quantidade de testes necessários para exercitar cada classe filha também aumenta.
• CBO – Coupling Between Object classes (acoplamento entre objetos de classes): o modelo CRC pode ser usado para determinar o valor do CBO, que se refere ao número de colaborações para uma classe. Na medida em que o CBO aumenta, as modificações e os testes resultantes destas modificações tornam-se mais complexos e a reutilização da classe pode ser reduzida.

Exemplo de Cartão CRC

 

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

• RFC - Response for a Class (resposta para uma classe): corresponde ao conjunto de métodos em potencial que podem ser executados em resposta a uma mensagem recebida por um objeto daquela classe. Na medida em que a RFC aumenta, tanto o trabalho de teste quanto a complexidade da classe também aumentam.
• LCOM – Lack of Cohesion Methods (falta de coesão em métodos): cada método em uma classe pode acessar um ou mais atributos. LCOM corresponde ao número de métodos que acessam um ou mais atributos em comum. Se nenhum método acessa os mesmos atributos, LCOM = 0. Para exemplificar, considere uma classe com 6 métodos: 4 dos métodos têm um ou mais atributos em comum; portanto, LCOM =4. Para manter a coesão alta, é desejável se manter LCOM baixo.

Cartão CRC - Class-Responsibility-Collaborations

Embora não faça parte de UML, uma técnica chamada Cartões CRC é muito usada para atribuir responsabilidades durante o projeto OO.

CRC cards foram inventados por Ward Cunningham e Kent Beck. Cartão CRC é um cartão pequeno (para só escrever o essencial) para cada classe. Escreve-se o nome da classe, suas responsabilidades e colaborações. Só se pensa nas responsabilidades de alto nível. Os cartões são desenvolvidos em pequenos grupos em que cada pessoa assume o papel (Role) de uma ou mais classes.

Exemplo de Cartão CRC

Fonte: <dsc>.

Baixo Acoplamento e Alta Coesão

Dentre estas características, as que mais se destacam são acoplamento e coesão. Uma boa aplicação OO deve seguir os princípios básicos de manter Baixo Acoplamento e Alta Coesão. Collares (2012) apresenta exemplos em Java que mostram soluções que corrigem erros para que estes princípios sejam mantidos:

“Elementos muito acoplados dependem muito uns dos outros, assim, se você altera um deverá alterar o outro.

Exemplo de Alto Acoplamento:

publicintgetIdade(){

    returnUtil.getFuncoes.getFuncoesData.calculaIdade(nascimento);

}

Correção para Baixo Acoplamento:

publicintgetIdade(){

    returnUtil.calculaIdade(nascimento);

}

Se uma classe faz mais do que ela deveria fazer, ela está com uma coesão baixa, e isso é ruim.

Exemplo de Baixa Coesão:

publicclass Aluno(){

    String nome;

    int[] notas;

        publicvoidsetNome(String nome){

            this.nome=nome;

}

        publicStringgetNome(){

            return nome;

}

        publicvoidsetNotas(int[] notas){

            this.notas=notas;

}

        publicdoublecalculaMedia(){

//código para calcular média

            return media;

}

}

Exemplo de Alta Coesão:

publicclass Aluno(){

    String nome;

        publicvoidsetNome(String nome){

            this.nome=nome;

}

        publicStringgetNome(){

            return nome;

}

}

        publicclass Notas{

    Aluno aluno;

    int[] notas;

        public Notas(Aluno aluno){

            this.aluno=aluno;

}

        publicvoidsetNotas(int[] notas){

            this.notas=notas;

}

        publicdoublecalculaMedia(){

//código para calcular média

            return media;

}

}

Métricas para projeto Orientado a Objetos-OO

Apesar de existirem muitas métricas que podem ser usadas como indicadores para orientar a forma pela qual um novo projeto deva evoluir, muitos engenheiros de software não as utilizam. Como veremos neste tópico, realizar um projeto sem medição é algo inaceitável!

Componentes de um projeto OO

 

Fonte: Bobicova Valeria/Shutterstock

De acordo com Pressman e Maxim (2016, p. 666), sistemas OO podem ser mensurados a partir das características:

• Tamanho: contabiliza as entidades OO como classes ou métodos acoplados à profundidade de uma árvore de herança.
• Complexidade: é definida pelas características estruturais do sistema OO, observando-se como as classes se inter-relacionam.
• Acoplamento: contabiliza as conexões físicas entre elementos do sistema OO como número de mensagens passadas entre objetos.
• Suficiência: responde a pergunta “que propriedades uma classe deve ter para ser útil?”, ou seja, se a classe possui as características dela requeridas.
• Totalidade: está relacionada com a suficiência, pois determina se a classe entrega o conjunto de propriedades que reflete totalmente as necessidades do domínio do problema.
• Coesão: é definida verificando se todos os métodos trabalham em conjunto para atingir uma finalidade única e bem definida.
• Originalidade: reflete o grau segundo o qual um método é atômico. Um método não pode ser construído por meio de uma sequência de outros métodos dentro de uma classe.
• Similaridade: reflete o grau em que duas ou mais classes são similares em relação à sua estrutura, função, comportamento ou finalidade.
• Volatilidade: mede a probabilidade da ocorrência de uma modificação em um componente de um sistema OO.

Tipos de Métricas de Software

Métricas para qualidade de especificação

De acordo com Pressman e Maxim (2016, p. 663), há uma lista de características que podem ser usadas para avaliar a qualidade do modelo de requisitos e as especificações de requisitos correspondentes, como: não ambiguidade, totalidade, exatidão, compreensibilidade, consistência interna e externa, disponibilidade, rastreabilidade, modificabilidade, entre outras. Cada uma delas pode ser representada usando uma ou mais métricas.

Suponha que há Nr requisitos em uma especificação, entre os quais há Nf requisitos funcionais e Nnf requisitos não funcionais, tal que:

Nr = Nf + Nnf

Para se determinar a não ambiguidade dos requisitos, pode ser utilizada uma métrica com base na interpretação de cada requisito pelos revisores. Se Nii representa o número de requisitos para os quais todos os revisores tiveram a mesma interpretação (ii = interpretação idêntica), temos:

Q1 = Nii / Nr

Quanto mais próximo de 1 for Q1, menos ambiguidades haverá na especificação dos requisitos.

Considerando que Nfu representa o número de requisitos funcionais únicos, Ne representa o número de entradas definidas pela especificação e Ns o número de estados especificados, a métrica da totalidade dos requisitos funcionais Q2 pode ser obtida por:

Q2 = Nfu / (Ne x Ns)

Métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE)

A métrica Eficiência na Remoção de Defeitos ou Defect Removal Efficiency (DRE), de acordo com Pressman e Maxim (2016, p. 718), “é uma medida da capacidade de filtragem das ações de garantia de qualidade e controle quando são aplicadas em todas as atividades da estruturas de processo”.

Sendo Ea= número de erros encontrados antes que o software seja entregue ao usuário final e Dd= número de defeitos encontrados depois que o software foi entregue ao usuário final, o DRE pode ser assim definido:

O valor ideal para DRE é 1, ou seja, nenhum defeito é encontrado no software. Mas de forma mais realista, Dd será maior que 0. À medida que Ea aumenta é provável que o valor final de Dd diminua (erros são removidos antes de se tornarem defeitos) e o valor global de DRE comece a se aproximar de 1.

Um dos objetivos desta métrica é incentivar a equipe de desenvolvedores a incorporar técnicas para que seja encontrado o maior número de erros possível antes da entrega do software.

Métricas orientadas a Casos de Uso ou Use Cases (UCs)

Os casos de uso ou Use Cases (UCs) são amplamente utilizados como método para descrever requisitos no nível dos clientes ou no domínio do negócio. De acordo com Pressman e Maxim (2016, p. 714), os UCs são definidos no início do processo de software, permitindo que sejam usados para estimativas antes de iniciar atividades de modelagem e construção.

O UC é independente da linguagem de programação e sua quantidade é diretamente proporcional ao tamanho do software em LOC e à quantidade de casos de teste que terão de ser projetados para exercitar o software.

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points) - parte 3

[3] Passo 3: neste passo, utiliza-se uma expressão empírica proposta pelo modelo para obtenção dos pontos de função:

Apenas para ilustrar, vamos apresentar a tabela completamente preenchida, para um determinado projeto de software, o que seria feito no passo 1.

Tabela completa de Pontos de Função

Valor do domínio da informação	Contagem	Fator de Peso			Contagem x Fator de Peso
		Simples	Médio	Complexo
Nº de Entradas Externas (EIs)	3	3	4	6	9
Nº de Saídas Externas (EOs)	2	4	5	7	8
Nº de Consultas Externas (EQs)	2	3	4	6	6
Nº de ArqLóg Internos (ILFs)	1	7	10	15	7
Nº de ArqInterf Externos (EIFs)	4	5	7	10	20
Contagem Total →					50

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

Supondo que no passo 2 foi realizado o cálculo que resultou em

o valor que indica que o produto é moderadamente complexo.

No passo 3 calculamos o PF.

PF = 50 x [0.65+ (0.01 x 46)] = 55.5 => 56

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points) - parte 2

[2] Passo 2: para o cálculo dos pontos de função, você terá que avaliar as 14 questões apresentadas no quadro 1, também relacionadas às funcionalidades do software a ser desenvolvido. Para cada uma dessas perguntas, você terá que atribuir um fator de ajuste de valor ou Value Adjustment Factor – VAF, Fi (i = 1 a 14), obedecendo à escala proposta pelo modelo apresentado no quadro 2.

Quadro 1 – 14 perguntas relacionadas às funcionalidades

1. O sistema exige backup e recuperação confiáveis	8. Os arquivos são atualizados on-line?
2. É requerida comunicação de dados?	9. Entradas, saídas, arquivos e consultas são complexos?
3. Existem funções de processamento distribuído?	10. O processamento interno é complexo?
4. O desempenho é crítico?	11. O código é projetado para ser reusável?
5. O sistema funcionará num sistema operacional existente e intensamente utilizado?	12. A conversão e a instalação estão incluídas no projeto?
6. São requeridas entrada de dados on-line?	13. O sistema é projetado para múltiplas instalações em diferentes organizações?
7. As entradas on-line requerem que as transações de entrada sejam construídas com várias telas e operações?	14. A aplicação é projetada de forma a facilitar mudanças e o uso pelo usuário?

Fonte: baseado em Pressman; Maxim (2016, p. 661).

Quadro 2 – Escala de VAFs – Value Adjustment Factors

Fonte: baseado em Pressman; Maxim (2016, p. 661).

Para evitar o problema da subjetividade ao avaliar a influência de cada funcionalidade, o IFPUG desenvolveu recomendações a serem seguidas.

No final desse segundo passo, você terá a soma das influências de cada uma das 14 perguntas. O valor dessa soma variará de um mínimo de 0 (todas as 14 perguntas tendo valor 0) a um valor máximo de 70 (todas as perguntas tendo valor igual a 5).

Métricas orientadas a função - Pontos de Função (PF) ou FP (Function Points)

A métrica Ponto de Função (PF) ou Function Point (FP) pode ser utilizada como forma de medir a funcionalidade fornecida por um sistema. Pressman e Maxim (2016, p. 659) indicam que podem ser usadas para:

• estimar o custo ou trabalho necessário para projetar, codificar e testar o software;
• prever o número de erros que serão encontrados durantes os testes; e
• prever o número de componentes e/ou o número de linhas de código-fonte projetadas.

Os PFs são derivados de medidas calculáveis do domínio de informações do software com base em:

1. ExternalInputs-EIs (número de entradas externas): cada entrada externa tem origem em um usuário ou é transmitida de outra aplicação. Fornece dados distintos orientados à aplicação ou informações de controle.
2. External Outputs-EOs (número de saídas externas): cada saída externa é formada por dados derivados da aplicação e fornece informações para o usuário.
3. ExternalinQuiries-EQs (número de consultas externas): refere-se a uma entrada online que resulta na geração de alguma resposta imediata do software na forma de uma saída online.
4. InternalLogical Files-ILFs (número de arquivos lógicos internos): cada arquivo lógico interno é um conjunto de dados que fica dentro dos limites da aplicação e é mantido por meio de entradas externas.
5. External Interface Files-EIFs (número de arquivos de interface externos): cada arquivo de interface externo é um conjunto de dados que fica fora da aplicação, mas fornece dados que podem ser usados pela aplicação.

Para o cálculo de Pontos de Função, os passos descritos a seguir devem ser seguidos.

[1] Primeiro passo: preencher as colunas sombreadas da tabela. Note que nessa tabela você deve preencher apenas os dados da coluna Contagem e fazer o cálculo da coluna Contagem x Fator de Peso e totalizar a Contagem Total. As colunas Valor do domínio da informação e Fator de Pesos já estão preenchidas, pois são valores são propostos pelo modelo e, a princípio, são fixos. Então, nesse passo, você terá que estimar a quantidade de cada parâmetro previsto para o software a ser desenvolvido e atribuir um fator de peso para cada um deles.

Uma grande questão que surge é como minimizar a subjetividade na atribuição desses fatores de ponderação, porque isso pode variar de pessoa para pessoa. O IFPUG – International Function Points Users Group – disponibiliza uma série de recomendações visando minimizar essa subjetividade.

Uma vez preenchida a tabela, você terá o valor de Contagem Total, o qual será utilizado no terceiro passo do cálculo.

Tabela para Pontos de Função

Valor do domínio da informação	Contagem	Fator de Peso			Contagem x Fator de Peso
		Simples	Médio	Complexo
Nº de Entradas Externas (EIs)		3	4	6
Nº de Saídas Externas (EOs)		4	5	7
Nº de Consultas Externas (EQs)		3	4	6
Nº de ArqLóg Internos (ILFs)		7	10	15
Nº de ArqInterf Externos (EIFs)		5	7	10
Contagem Total →

Fonte: baseada em Pressman; Maxim (2016, p. 660).

Métricas de Qualidade e Métricas para o Modelo de Requisitos

O desenvolvimento de um projeto inicia-se com a criação do modelo de requisitos e é nesta fase que os requisitos são formulados e a base do projeto é estabelecida. Desta forma, as métricas de produto que fornecem informação sobre a qualidade do modelo de análise são bastante desejáveis.

Software Metric

 

Fonte: Profit_Image/Shutterstock

A qualidade de um sistema, aplicação ou produto é tão melhor quanto melhor estejam descritos os requisitos que o descrevem, o projeto que modela sua solução, o código que o implementa e os testes que o exercitam para descobrir defeitos e erros.

Desta forma, métricas como erros por ponto de função, erros descobertos por horas de revisão, erros descobertos por horas de teste e eficiência na remoção de defeitos proporcionam informações relevantes que ajudam no controle de qualidade do software.

Considerações sobre Métricas

Há um grande número de métricas de software, que normalmente são aplicadas de forma isolada e consideradas insatisfatórias por grande parte dos desenvolvedores.

No passado, várias métricas e uma série de processos foram propostos, mas a maioria não possuía uma base teórica suficiente e/ou uma significativa validação experimental. Várias delas foram definidas e, em seguida, testadas e utilizadas em apenas um ambiente limitado. Apesar de, em alguns casos, existirem relatos de validação ou de aplicação dessas métricas, testes ou uso em ambientes diferentes produziram resultados não esperados. Essas diferenças acabam por não serem surpreendentes, uma vez que faltam definições claras e hipóteses de testes bem definidas.

Assim, existe um grande número de métricas que podem ser utilizadas, mas devemos observar quais delas têm sido mais amplamente utilizadas ou aceitas, pois certamente apresentam resultados mais efetivos.

Se o desenvolvedor construir uma aplicação apoiada por métricas escolhidas de forma criteriosa, elas poderão produzir resultados úteis se forem utilizadas de acordo com o ambiente especificado.

Independentemente das métricas adotadas. é muito importante para as organizações a coleta efetiva dessas métricas e o registro histórico dos projetos, formando uma base de conhecimento que auxilie nos processos de análise, melhoria e tomada de decisão.

Muitos fatores devem ser levados em consideração para a escolha das métricas. Recomendamos que você identifique qual a necessidade de medição do projeto (qualidade, produtividade, erros, falhas etc.) para, em seguida, adotar mecanismos que permitam uma medição mais significativa e efetiva.

Métricas de Processo e Projeto

De acordo com Pressman e Maxim (2016, p. 703), métricas de processo e de projeto de software são medidas quantitativas que permitem aos engenheiros de software vislumbrar a eficácia tanto do processo quanto dos projetos que são conduzidos usando este processo como framework. As medições permitem que julgamentos deixem de ser subjetivos e tendências possam ser detectadas de forma que estimativas possam ser feitas e aperfeiçoamentos buscados.

Métricas: busca pelo aperfeiçoamento

 

Fonte: G7 Stock/Shutterstock

As métricas de processo têm finalidade estratégica e objetivam fornecer um conjunto de indicadores de processo visando o seu aperfeiçoamento no longo prazo. As métricas de projeto têm finalidade tática e permitem ao gerente de projeto avaliar o estado de um projeto em desenvolvimento, acompanhar riscos em potencial, descobrir setores que apresentam problemas antes que se tornem críticos, ajustar o fluxo de trabalho e ainda avaliar a capacidade da equipe para controlar a qualidade do produto e dos artefatos de software.

As medidas que são coletadas com base em dados de qualidade e produtividade são convertidas em métricas e analisadas e comparadas com métricas anteriores. Essas métricas podem ser usadas durante o projeto para detectar problemas ocorridos no desenvolvimento e serem transmitidas para quem tem responsabilidade sobre o aperfeiçoamento do processo de software. Desta forma, muitas métricas são usadas tanto no domínio do processo quanto do projeto.

Ainda de acordo com Pressman e Maxim, o processo situa-se no centro de um triângulo (conforme ilustra a figura) que liga três fatores que influenciam significativamente tanto a qualidade de software quanto o desempenho da organização:

• Pessoas: a capacidade e a motivação das pessoas reúnem os fatores individuais que mais influenciam a qualidade e o desempenho.
• Produto: a complexidade do produto pode ter um forte impacto sobre a qualidade e o desempenho das pessoas que formam a equipe.
• Tecnologia: os métodos e as ferramentas de engenharia de software são fundamentais, pois impactam o processo.

Além destes fatores, o triângulo do processo encontra-se dentro de um círculo que inclui o ambiente de desenvolvimento (exemplo: ferramentas CASE), condições de negócios (exemplo: prazos e regras de negócio) e características do cliente (exemplo: facilidade de comunicação).

Triângulo de fatores que impactam o processo

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

A eficácia de um processo pode ser medida pelas saídas dele derivadas como: medidas dos erros descobertos antes da entrega do produto, defeitos relatados pelos usuários finais, produtividade da equipe, esforço humano dispendido, tempo gasto, cumprimento do cronograma, entre outras. Desta forma, as métricas de processo podem fornecer benefícios significativos na medida em que a organização trabalha para corrigir e melhorar seus problemas, buscando maior maturidade de processo. Em um nível mais avançado, a organização pode adotar a abordagem SSPI – Statistical Software Process Improvement, que usa a análise de falhas de software para coletar informação sobre erros e defeitos encontrados no produto em operação.

As métricas de projeto são usadas por um gerente de projeto para adaptar o fluxo de trabalho e sua primeira aplicação ocorre, geralmente, durante a estimativa. Métricas usadas em projetos anteriores podem ser usadas como base. O gerente utiliza medidas de esforço e tempo dispendidos comparadas com as estimativas previstas no cronograma para monitorar e controlar o progresso do projeto.

Na medida em que o trabalho técnico prossegue, outras métricas de projeto são utilizadas, como taxa de produção, horas de revisão, pontos por função, linhas de código entregues etc. Além disso, os erros descobertos são registrados e outras métricas técnicas são utilizadas para avaliar a qualidade do projeto, o que irá influenciar a abordagem de testes.

As métricas de projeto são usadas tanto para minimizar o tempo do cronograma, buscando evitar atrasos e diminuir riscos, quanto para avaliar a qualidade do produto. Na medida em que a qualidade é melhorada, os defeitos são reduzidos e a quantidade de retrabalho também é minimizada, levando à redução do custo do projeto.

Classificação das Métricas de Software

Existem muitas classificações para métricas de software. Um software pode ser medido orientado ao tamanho, a funções, aos objetos, aos recursos humanos envolvidos, a qualidade e pela produtividade, entre outras medições.

Apresentamos algumas classificações de métricas a seguir, com base no trabalho de Meirelles (2008).

• Classificação quanto ao objeto
• Métricas de produto: são relacionadas à complexidade, tamanho, qualidade (confiabilidade, manutenibilidade etc.) do software produzido.
• Métricas de processo: referem-se ao processo de concepção e desenvolvimento do software, medindo por exemplo, o processo de desenvolvimento, o tipo de metodologia usada e o tempo de desenvolvimento.
• Classificação quanto ao critério utilizado na sua determinação
• Métricas objetivas: são obtidas através de regras bem definidas, sendo a melhor forma de possibilitar comparações posteriores consistentes. Nessa categoria, os valores obtidos devem ser sempre os mesmos, independentemente do instante, condições ou indivíduos que os determinam. A determinação dessas métricas é passível de automatização (por exemplo, número de linhas de código).
• Métricas subjetivas: podem partir de valores, mas dependem de um julgamento, que também é um dado de entrada, para serem levantadas (por exemplo, o modelo de estimativa de custo, que depende da classificação do tipo de software).
• Classificação quanto ao método de obtenção
• Métricas primitivas: são aquelas que podem ser observadas diretamente em uma única medida (por exemplo, o número de linhas de código, erros indicados em um teste de unidade ou ainda o total de tempo de desenvolvimento de um projeto).
• Métricas compostas: são as combinações de uma ou mais medidas (por exemplo, o número de erros encontrados a cada mil linhas de código ou ainda o número de linhas de teste por linha de código).

Existem outras classificações, como métricas privadas e públicas.

As métricas privadas se aplicam ao indivíduo e as informações e resultados são de divulgação restrita. Os dados coletados com base individual devem ser privados e servir como indicadores apenas para o indivíduo. Servem para ajudar o engenheiro de software a aperfeiçoar seu trabalho individual. Algumas métricas são privadas de uma determinada equipe (por exemplo, proporção de defeitos por indivíduo).

As métricas públicas têm origem privada, mas acabam por serem divulgadas para toda a equipe. Elas permitem que as organizações realizem mudanças estratégicas para melhorar o processo de desenvolvimento do software.