Análise sobre métricas de estimativa de esforço de software
Arthur Gonçalves Silva, Carlos Eduardo Carvalho Dantas Instituto de Informática – Centro Universitário do Triângulo (UNITRI)
Caixa Postal 309 – 38.411-106 – Uberlândia – MG – Brasil
Arthurgs7@hotmail.com, carloseduardocarvalhodantas@gmail.com Resumo.
Este artigo tem como proposta trabalhar com a análise para melhoria das estimativas de esforço que será necessário em um projeto, visto que no mercado atual em constantes mudanças se torna cada vez mais complexo estimar o tempo e custos gastos no desenvolvimento de um sistema; com expectativas de resultados eficazes, os analistas empenham com ações de reinvenção contínua nas organizações, utilizando e propondo ferramentas como métricas que consiste em uma técnica para medir particularidades de produtos e processos, tem por objetivo aumentar o grau de gerenciamento de um projeto, nesse trabalho contemplaremos exemplo de análise por ponto de função e pontos por caso de uso.
Palavras Chave: Tempo. Métricas. Projeto. Estimativa. Análise.
1. Introdução
O desenvolvimento tecnológico trouxe para o cenário das organizações uma significativa relevância em seus processos, uma vez que sua contribuição permitiu a agilidade nos processos, a rapidez nas informações, a facilitação nos controles, a possibilidade de mensuração de resultados e o aprimoramento de técnicas de medição do tempo gasto no desenvolvimento de um projeto.
O autor Ralph Keeling traz o seguinte conceito acerca de um projeto: “Um esforço temporário empreendido para criar um produto ou serviço único”. (Keeling 2010); Um projeto pode ser desenvolvido acerca de um produto, serviço ou ainda um processo, estes possuem alguns requisitos básicos como: prazos, custos e recursos disponíveis.
Hoje em dia um dos principais problemas em um projeto é concluí-lo em concordância com o que foi estabelecido no contrato, pois, existem inúmeros fatores que contribuem com o atraso das etapas objetivadas podem-se destacar alguns erros nos cálculos utilizados para estimar o tempo de um projeto ou mesmo erro durante o desenvolvimento.
A métrica de software tem como princípios especificar as funções de coleta de dados de avaliação e desempenho, atribuir essas responsabilidades a toda a equipe envolvida no projeto, reunir dados de desempenho pertencentes à complementação do software, analisar os históricos dos projetos anteriores para determinar o efeito desses fatores e utilizar esses efeitos para pesar as previsões futuras.
2. Dificuldades encontradas para estimar o tempo de um projeto
Com o crescente avanço da tecnologia renovando-se a cada dia, com projetos cada vez mais ousados, uma série de dificuldades são encontradas na concepção de um projeto, ao estimar o tempo que virá a ser consumido na sua construção. Outro fator que implica em seu desenvolver está na concordância em apurar o que será medido em um software, analisar quais os critérios necessários, como definir padrões de avaliação, quantidade de recursos que serão disponíveis, ou seja, são inúmeros os fatores a serem levados em consideração para determinar com exatidão qual o tempo que um determinado projeto leva para concluir seu ciclo natural.
Diante das dificuldades encontradas no assunto abordado, o The Standish Group em seu relatório denominado CHAOS Report apontou que apenas 32% dos projetos são finalizados dentro do prazo e custos estimados, 44% dos projetos ultrapassam as estimativas atuais de prazo e custos e 24% dos projetos são cancelados antes de serem completados. [RUGGIERI, 2011]
De acordo com o relatório mencionado, as dificuldades encontradas dão-se pela má utilização dos recursos disponíveis, não acatando o que foi calculado e o não cumprimento dos prazos estipulados na análise do projeto a ser desenvolvido.
Métricas de software é um assunto que gera muita discussão em fóruns de tecnologia, abordado com frequência em reuniões por equipe de analistas de tecnologia de informação, sendo um assunto técnico e complexo, bastante comentado no mercado da engenharia de software, porém na prática é uma metodologia pouco utilizada em projetos de software.
Partindo do princípio que o ato de medir e estimar são de suma importância na execução de um projeto com sucesso, existem algumas variáveis que impedem que os analistas da área cumpram as etapas que programadas para o projeto.
O não cumprimento dos prazos estabelecidas no planejamento acarretará em maior custo, é necessário que haja controle e acompanhamento adequado, o gerenciamento de riscos na eventualidade de fatores que podem afetar as estimativas de tempo do projeto, torna-se necessário adequar o planejamento de risco com o planejamento de tempo.
A motivação como fator na execução prática do sistema onde comprometimento de todos os envolvidos como: desenvolvedores, usuários e gestores é fator crítico de sucesso para a obtenção de um processo ou produto com qualidade, dentro do prazo e com custo estabelecido.
Outra dificuldade entrada é a falta de maturidade dos profissionais da área, diante do desenvolvimento de um projeto, conhecer bem o processo de estimativas torna possível à realização de uma análise de forma mais precisa, conhecendo bem as particularidades requisitadas pelo cliente possibilitará uma margem menor de erros e melhores resultados obtidos.
3. Métricas
Segundo o autor Pressman
Na maioria dos empreendimentos técnicos, as medições e as métricas
produto, como também o próprio produto. O processo é medido, num esforço para melhorá-lo. O produto é medido, num esforço para aumentar sua qualidade. (1995 P.56)
De acordo com o autor as métricas são utilizadas no planejamento para auxiliar o analista a entender, avaliar, controlar e prever os processos que serão efetuados, para melhor desenvolve-los e conquistar melhor valor agregado aumentando sua qualidade. A utilização de métricas possibilita realizar uma das atividades primordiais do projeto, que é o planejamento, por meio dele é feita a identificação de esforço, custo e as etapas a serem executadas.
Planejamento representa um processo capaz de identificar os objetivos almejados, utilizando os meios estratégicos disponíveis. Na etapa que se refere ao planejamento é visto como um processo sistemático, pois envolve a integração de varias atividades, recursos e intervalos de tempo.
Métricas de Software é uma área de estudo que visa medir atributos de uma determinada entidade, consiste em uma técnica para medir propriedades ou características de produtos, processos ou recursos, sua utilização tem por objetivo aumentar o grau de gerenciamento de um projeto de software, tratando com maior exatidão previsões sobre custo e prazos do projeto, visando a identificação das necessidades de investimentos dentro da organização, valorizar o custo versus benefício e a possibilidade de redução de gastos e a melhoria nos prazos do projeto.
As Métricas de Software são de grande importância no projeto, porém em algumas situações são deixadas de lado, os analistas não compreendem sua real importância. No início do projeto deve haver a coleta de dados, pois através dessas informações é possível realizar a medição e o gerenciamento de custos, esforços e recursos, realizando uma gestão de projeto com qualidade.
As medições de um software são utilizadas para coletar dados quantitativos e qualitativos sobre as etapas de um projeto, uma vez que cada projeto possui suas particularidades, caberá ao desenvolvedor atender os requisitos solicitados pelo responsável pelo projeto e analisar as medições já efetuadas no conhecimento e na experiência vivenciada.
Nesse artigo iremos abordar duas métricas que são utilizadas para a medição de estimativas de esforço de um projeto de software, sendo elas Análise de Pontos por Função e Análise de Pontos por Caso de Uso.
3.1 Análise de Pontos por Função
A Análise de Pontos por Função (APF) incide em uma técnica que possibilita a medição de fatores de engenharia de software, apurando custo, tempo e esforço. A base é identificar os pontos onde as informações são modificadas, e quantificar tais informações em termos de complexidade, ou seja, o método de análise de ponto por função auxilia o analista na identificação do nível de complexidade e necessidades conforme o projeto solicitado.
Os cálculos dos pontos por função devem seguir as orientações sugeridas segundo o Manual de Práticas de Contagem do IFPUG (Internacional Function Point
Users Group), órgão que estabelece padrões e regras para a utilização da análise
A Análise de Ponto por Função não depende de tecnologia aplicada, é simples de ser usada e bastante compreensível por pessoas que não são da área, sendo uma ferramenta de auxilio gerencial, usada também para controle de qualidade e estimativas de custo e recursos para desenvolvimento e manutenção de softwares.
3.1.1 Fases de Contagem dos Pontos de Função
A contagem utilizando a técnica de pontos por função é executada com fundamento nos requisitos do projeto em análise, destaca-se as fases relacionadas à contagem.
A primeira fase nesse processo consiste na identificação dos componentes considerados sendo, arquivos lógicos internos (ALI); arquivos de interface externa (ALE), entrada externa (EE), consultas externa (CE) e saídas externas (SE). A segunda fase refere-se às etapas do processo de contagem trazendo os seguintes aspectos: identificação de complexidade e contribuição, pontos de função não ajustados e pontos de função ajustados. A última fase denominada aplicação da contagem que pode ser de um projeto de sistema, de alterações em sistemas ou de um sistema. De forma prática segue demonstração na figura 1 abaixo.
Figura 1. Tabela Processo de Contagem Ponto de Função
Para demonstração de forma técnica, será considerada a empresa X contratada para desenvolver um projeto cuja finalidade, seja a de gerar relatórios sobre o registro do cartão de ponto dos funcionários referente à entrada e saída. A empresa X constatou que o projeto necessita de dois arquivos lógicos internos (ALI), um arquivo de interface externa (ALE), a entrada externa será a inclusão das marcações de entrada e saída, o sistema terá quatro consultas externas e uma saída externa, a equipe de desenvolvimento da empresa X considerou que o projeto é de uma complexidade baixa.
Para calcular os pontos de funções não ajustados demonstrado na figura 1, é atribuído um peso de acordo com a complexidade do projeto para as funções do tipo de dados (ALI e AIE) e as funções do tipo de transação (Entrada Externa, Consulta Externa e Saída Externa). No modelo do projeto da empresa X segue o cálculo:
Pontos de Função não ajustados = ALI*7 + AIE*5 + EE*3 + SE*4 + CE*3 Pontos de Função não ajustados = 2*7 + 1*5 + 1*3 + 1*4 + 4*3
Pontos de Função não ajustados = 38
Concluído o cálculo de função não ajustado, o próximo passo é calcular o valor do fator de ajuste, representados pela soma dos quatorzes fatores denominados como características gerais do Sistema, sendo: Comunicação de Dados, Processamento Distribuído de Dados, Desempenho, Configuração Intensamente Utilizada, Taxa de Transação, Entrada de Dados On-line, Eficiência do Usuário Final, Atualização On-line, Processamento Complexo, Reutilização, Facilidade de Instalação, Facilidade de Operação, Múltiplas Localidades e Facilidade de Alteração, para esse projeto respectivamente será atribuído o nível de influência 4, 2, 3, 1, 4, 3, 2, 4, 1, 2, 3, 4 e 4, sendo o total do nível de influência igual a 37.
Para calcular o valor do fator de ajuste utiliza-se a seguinte fórmula: VFA = (Total do Nível de Influência * 0,01) + 0,65
VFA = (37 * 0,01) + 0,65 VFA = 0,37 + 0,65 VFA = 1,02
Para a contagem ajustada final de Ponto de Função é multiplicado os pontos de função não ajustados pelo valor do fator de ajuste.
Ponto de Função Ajustados = Pontos de Função não Ajustado * Valor do Fator de Ajuste
Ponto de Função Ajustados = 38 * 1,02 Ponto de Função Ajustados = 38,76
Para cada ponto de função ajustado a empresa X, através da utilização da métrica constatou que são necessário um esforço de 10 horas, para a empresa X a estimativa do projeto será de 388 horas/pessoa, tendo uma equipe em horário comercial de oito horas diárias composta de cinco pessoas, neste caso seria necessário nove dias e meio (388 horas totais / 5 pessoas * 8 horas) para conclusão do projeto.
3.2 Pontos por Caso de Uso
O método pontos por caso de uso representa um tipo de métrica que avalia o sistema por meio de análise das informações do próprio caso de uso, possibilitando o passo a passo das atividades que o sistema fornecerá ao usuário, a principal característica deste método é a capacidade de levantar os requisitos do projeto que servirá de base para cálculo da referida métrica.
3.2.1 Utilização do método Pontos por Caso de Uso
O método citado tem a finalidade de estimar o esforço que será consumido no projeto, através desse método é definido o UUCP (Unadjusted Use Case Point), ou seja, ponto por Caso de Uso não ajustado, TCF (Technical Complexity Factor), ou seja, os fatores técnicos e EFC(Environmental Factor), ou seja, os fatores não técnicos, que serão demonstrados a seguir, começando pelo UUCP que define o peso aos elementos
fundamentais do caso de uso, sendo os atores do caso de uso representados pelos usuários do sistema, cuja atuação é externa envolvendo pessoas, processo, sistemas e até mesmo hardwares disponíveis e o próprio caso de uso e suas particularidades definidas pelo analista.
Relação atores com nível de complexidade pode ser visto na figura 2. O Nível de complexidade dos atores demonstra uma relação atribuindo um valor simbólico representado por três pesos cuja finalidade é medir o grau de entretenimento.
Figura 2. Nível da complexidade dos atores.
Relação caso de uso com nível de complexidade pode ser visto na figura 3, esta passa a medir as possíveis transações do sistema, pontuando com grau de complexidade simples, médio ou complexo; de acordo com dados informados.
Figura 3. Nível da complexidade do caso de uso.
De modo prático o cálculo do UUCP (Unadjusted Use Case Point) é efetuado somando o peso dos atores vezes à quantidade de atores somados ao peso dos casos de uso multiplicados pela quantidade de casos de uso. Demonstrado na seguinte hipótese, onde um sistema será desenvolvido pela empresa X, através da análise da equipe
constatou que o projeto possui dois atores com nível de complexidade simples, um ator de médio e cinco atores de nível alto, composto por três casos de uso com complexidade simples, dois casos de uso médio e seis casos de uso complexo, podendo ser representado seguinte calculo:
UUCP = Atores (2*1+1*2+5*3=19) + Caso de Uso (3*5+2*10+6*15=125). UUCP = 144.
Seguindo o método, na próxima etapa será calculado o que se intitula TCF (Technical Complexity Factor) que nada mais é do que os fatores técnicos e sua complexidade. Para cada fator técnico é atribuído um nível que varia de 1 a 5 e um peso ou valor que varia dependendo de fator técnico analisado, vale resultar que cada um dos fatores possui relevância na estimativa do esforço, são considerados treze fatores técnicos citados na figura abaixo.
Figura 4. Fatores Técnicos.
Exemplificando a figura acima, cada um dos treze fatores técnicos recebeu um valor, e este é multiplicado por uma variável com o valor entre zero a cinco, onde zero representa que o fator é irrelevante para projeto e cinco que seria o valor máximo de impacto no desenvolvimento. No nosso exemplo da empresa X, os analistas da empresa X consideraram que o tempo de resposta, facilidade de uso, eficiência, recursos de segurança sejam primordiais, portanto a nota atribuída será 5; e que fatores como portabilidade, reutilização de código, acesso a código por terceiros não muito relevante, portanto receberão nota 0.8 e os demais receberão nota mediana igual a 3. Sendo assim, segue o cálculo do método TCF, onde FT significa fator técnico:
TCF = 0,6 + (0,01* Soma dos fatores (FT1=2*3 + FT2=2*5 + FT3=1*5 + FT4=1*3 + FT5=1*0,8 + FT6=0,5*3 + FT7=0,5*5 + FT8=2*0,8 + FT9=1*3 + FT10=1*3 + FT11=1*5 + FT12 = 1*0,8 + FT13 = 1*3 ))
TCF = 0,6 + (0,01* 45.2) TCF = 0,6 + 0,452
TCF = 1,052
O resultado do TCF pode variar entre 0.6 (que é quando os fatores técnicos não tem influência no sistema) e 1.35(seria o valor caso todos os fatores possuem nível de influência máximo), no caso da empresa X o resultado obtido foi de 1,052 onde os fatores técnicos influenciam no projeto de forma mediana, podendo desenvolver no projeto fatores técnicos classificados como importante, não tenham tanta relevância e vice-versa.
Dando sequência no método, será realizado o calculo do EFC (Environmental
Factor) explanando seria os fatores ambientais, podendo ser chamado também de
fatores não técnicos, como podem ser observados na figura abaixo.
Figura 5. Fatores Não Técnicos.
Para encontrar os fatores não técnicos (EFC) segue o raciocínio do método referente ao TFC, ou seja, a aplicação do método é similar ao cálculo dos fatores técnicos, levando em consideração os valores da figura 5, multiplica-se o nível de cada um dos fatores não técnicos pelo seu respectivo peso. De acordo com o analista da empresa X, o mesmo considerou que os fatores não técnicos como motivação, experiência com desenvolvimento, dificuldades na linguagem de programação são de suma importância para o projeto recebem nota cinco e os demais fatores considerados médios recebem a nota dois. Segue abaixo demonstração do cálculo, onde FN será a abreviação de fatores não técnicos:
EFC = 1.4 + (-0.03 * Soma dos Fatores (FN1= 1.5*2 + FN2= 0.5*5 + FN3= 1*2 + FN4= 0.5 * 2 + FN5=1*5 + FN6= 2*2 + FN7= -1*2 + FN8= 2*5 ))
EFC = 1.4 + (-0,03 * 25.5) EFC = 1.4 + (-0.765) EFC = 0.635
De acordo com o cálculo do EFC, o peso dos fatores não técnicos alcançou um resultado de 0.635 que é considerado baixo, pois o menor valor encontrado é 0,58 sendo assim os fatores não técnicos da empresa X não interferem em muito o desenvolvimento do projeto.
Para finalizar o cálculo do UCP basta multiplicar todos os resultados obtidos para encontrar a estimativa do projeto pelo esforço em horas, para tal utiliza-se a fórmula:
UCP = UUCP * TCF * ECF UCP = 144 * 1,052 * 0,635 UCP = 96.194
O valor encontrado do UCP foi de 96.194, porém para encontrar a estimava de homem/hora é multiplicado por 20 cada UCP, ou seja, caso esse projeto da empresa X ocorra conforme planejado o esforço homem/hora calculado será de 1923.88.
4. Estudo de Caso e Resultados Obtidos
Para o estudo de caso deste artigo será apresentado cinco casos de uso de um projeto realizado pela empresa Martins Comércio e Serviço de Distribuição - S/A, este consistiu em um sistema de vendas em Android especificamente para o Tablet Samsung Tab 7.0 P3100 para os representantes comerciais de vendas em todo o Brasil.
4.1 Apresentação dos Casos de Uso.
Pedido: O caso de uso consiste em um sistema de pedido, na qual o usuário seleciona o cliente, após a escolha o sistema mostra qual filial de faturamento, condição de pagamento, dando sequência é aberta a aba para escolha dos itens que farão parte do pedido, para concluir é aberta a aba das promoções caso os itens do pedido se encaixem em alguma promoção do pedido, a ultima aba do sistema é o caminhão onde ficam registrado os itens do pedido e a opção para fechar o pedido.
Cadastro de cliente: O caso de uso consiste em um sistema para cadastrar clientes, onde são mostrados todos os campos para informar os dados do cliente, após essa informações são validos se os campos possuem pontuação ou caracteres especiais, sendo salvo nos cadastros.
Incentivos de Vendas: O caso de uso consiste em um sistema que após selecionar o incentivo é mostrado às informações sobre o incentivo para vendas. Demonstrativo de Comissão: O caso de uso consiste em verificar as informações
referentes às vendas realizadas, selecionando algumas opções para verificação. Periféricos: O caso de uso da opção de periféricos consiste em duas ferramentas
para geração de pré-senha para acesso ao sistema de vendas online, atualização dos dados cadastrais.
4.2 Análise
A análise do Estudo de Caso da empresa Martins Comércio e Serviço de Distribuição -S/A, foi utilizada o método de análise por Ponto de Função, demonstrado seus resultados obtidos conforme as figuras 6 e 7 abaixo:
Figura 6. Análise ponto de função não ajustado.
Como demonstrado na figura acima, pode-se observar que o sistema foi composto por uma ALI que representa a base de dados, da seguinte forma: duas entradas externas como sendo a construção do pedido e inclusão de dados no cadastro de um novo cliente, oito consultas externas, sendo consultas em informação, referente ao demonstrativo de comissão e incentivo de vendas e, para finalizar as três saídas externas que seriam o envio para o servidor de todas as atualizações cadastrais, pedido e cadastro de cliente, totalizando 63 pontos de funções não ajustados.
Figura 7. Análise valor do fator de ajuste.
Na figura 7 pode ser observado o nível de influência de cada uma das características gerais do Sistema, sendo o valor do fator de ajuste igual a 1,1.
O valor do fator de ajuste calculado multiplicando o ponto de função não ajustado pelo valor do fator de ajuste, conforme análise realizada e demonstrada utilizando o indicador em questão:
Ponto de Função Ajustado = Ponto de Função não-Ajustado * Valor de Fator de Ajuste
Ponto de Função Ajustado = 63 * 1,1 Ponto de Função Ajustado = 69,3
De acordo com a análise feita pelo analista do projeto, o mesmo definiu que cada ponto de função estimaria a quantidade de 8 horas, sendo assim, o projeto seria concluído resultando em 554,4 horas/homens.
Figura 8. Análise pontos por Caso de Uso.
Conforme demonstrada na figura acima, pode-se observar que usuário do sistema é de complexidade alta, pois interage diretamente com a interface do sistema, salientado que o caso de uso do pedido foi bastante complexo por possuir diversos recursos disponíveis.
Figura 9. Análise dos Fatores Técnicos.
Na figura acima foram listados os fatores técnicos do projeto e seus respectivos pesos em relação ao sistema em desenvolvimento, visando à eficiência como ponto chave para a elaboração do sistema.
Figura 10. Análise dos Fatores Não Técnicos.
Na figura acima foram listados os fatores não técnicos, salientando que a capacidade de liderança foi de suma importância para o desenvolvimento do projeto, mesmo não tendo um peso elevado em relação aos requisitos estáveis e as dificuldades na linguagem de programação.
Conforme a análise aplicada, o método pontos por caso de uso visto nas figuras acima, ao multiplicar os fatores não técnicos, fatores técnicos e os ponto por caso de uso não ajustados, de forma prática chegou-se ao seguinte resultado:
Ponto por Caso de Uso = Pontos de Caso de Uso não Ajustados * Fatores Técnicos * Fatores não Técnicos
Ponto por Caso de Uso = 45 * 1,1275 * 0,515 Ponto por Caso de Uso = 26,12*20
Ponto por Caso de Uso = 522,60
Foi concluído e estimado um esforço de 522,60 horas/homens. 5. Conclusão
O aprimoramento de técnicas para medição do tempo e custo gastos no desenvolvimento de um projeto tem cooperado com estes profissionais, como por exemplo, a utilização de métricas possibilita realizar umas das atividades primordiais do projeto, que é o planejamento, por meio dele é feita a identificação quantitativa de esforço, custo e as etapas a serem trabalhadas.
Métricas de Software possuem a propriedade de medir atributos de uma determinada entidade, uma técnica para medir particularidades ou características de produtos ou processos, possibilita a melhoria no gerenciamento de um projeto de software. Cabendo ao desenvolvedor coletar dados quantitativos sobre as etapas do projeto, atendendo aos requisitos solicitados pelo responsável do projeto e analisar as medições já efetuadas.
Análise de Pontos por Função tem sido empregada como fonte de indicadores na formulação de estimativas dos prazos e custos necessários no projeto, diante ao desafio de compreender e alcançar a expectativa do usuário, facilitando o gerenciamento das fases e o cumprimento do que foi estabelecido no contrato; o uso de métricas
fundamenta as ações por meio de indicadores obtidos pela Análise de Pontos por Função.
O método Pontos por Caso de Uso possui uma finalidade de estimar o esforço que será gasto no projeto apresentando as particularidades mediante requisitos do software, traduzem os objetivos de uma análise orientada a produto, serviço ou processo.
No estudo de caso apresentado foram utilizadas as duas métricas de estimativas abordadas no artigo, possibilitando aplicação de cada uma no projeto, chegando ao resultado de que a análise por ponto de função apresentou-se a mais assertiva para o estudo de caso proposto no sistema de vendas do grupo Martins que teve uma duração de aproximadamente 570 horas/homens, porém para saber qual métrica é melhor seria necessário avaliar mais projetos de software, a melhor métrica a ser utilizada pela equipe que estará desenvolvendo o projeto é a que se tem um domínio maior por parte grupo responsável pela análise, ambas tem suas características e fatores a serem observados.
Na verdade não existe um modelo ideal para desenvolvimento utilizando metodologias ágeis, devido ao desenvolvimento ser feito em partes e no mercado atual o cliente deseja conhecer prematuramente o valor do projeto a ser desenvolvido, é proposto para trabalhos futuros uma análise mais profunda abordando a análise tanto de ponto de função, quanto ponto por caso em metodologias ágeis.
Referências
AGUIAR, Maurício. Pontos de Função ou Pontos por Caso de Uso? Como Estimar Projetos Orientad os a Objetos. Disponível em: <
http://www.bfpug.com.br/Artigos/UCP/Aguiar-Pontos_de_Funcao_ou_Pontos_por_Caso_de_Uso.pdf> Acesso em: 06 mai. 2013. DEKKERS, Carol. Pontos de Função e Medidas, O que é um Ponto de Função?.
Disponível em: < http://www.bfpug.com.br/Artigos/Dekkers-PontosDeFuncaoEMedidas.htm> Acesso em: 06 mai. 2013.
DOS SANTOS, G. REIS. Existem métricas eficientes para estimar desenvolvimento OO? Mundo Java, São Paulo, edição 38, p.13-17, Nov.2009.
KEELLING, Ralph. “Gestão De Projetos: Uma Abordagem Global”. Primeira Edição Setíma Tiragem. São Paulo: Ed Saraiva, 2010. P. 03.
MACHADO, Joice Basílio. Métricas Para Qualidade de Software: Um estudo de Caso Comparando Análise De Pontos Por Função e Pontos de Caso de Uso. Disponível em: < http://www.ic.ufmt.br:8080/c/document_library/get_file? p_I_id=58070&folderId=59706&name=DLFE-2194.pdf> Acesso em: 29 mai. 2013. PRESSMAN, Roger S. “Engenharia de Software”. Primeira Edição. São Paulo: Ed
Brasil, 1995. P. 56.
RUGGIERI, Ruggero. Problemas que ocorrem quando não existe um padrão na
elaboração de requisitos. Disponível em:
<http://www.tiespecialistas.com.br/2012/06/problemas-que-ocorrem-quando-nao-existe-um-padrao-na-elaboracao-de-requisitos/#.UZ1nfbWsiSo> Acesso em: 22 mai. 2013.
