GUIMARÃES, Valéria Aparecida [1]
LARA, Alexander Prado [2]
PUTTINI, Ricardo Staciarini [3]
GUIMARÃES, Valéria Aparecida; LARA, Alexander Prado; PUTTINI, Ricardo Staciarini. Aplicação de Análise de Pontos por Função em Projetos SOA. Revista Científica Multidisciplinar Núcleo do Conhecimento. Edição 08. Ano 02, Vol. 01. pp 88-102, Novembro de 2017. ISSN:2448-0959
Resumo
Estimar o tamanho de um software a ser desenvolvimento é indispensável para se obter uma estimativa confiável de custos e prazos. Uma das técnicas de medição mais utilizadas e documentadas para a obtenção do tamanho de um software é a Análise de Pontos de Função (APF), que, no entanto, tem sua aplicabilidade para projetos que utilizam a abordagem da Arquitetura Orientada a Serviços (SOA) frequentemente questionada. Este trabalho apresenta o resultado da aplicação da APF em um sistema desenvolvido integralmente utilizando-se a abordagem SOA, o que permitiu posterior comparação das estimativas produzidas pela APF com esforço, prazo e custos reais do projeto.
Palavras-Chave: Estimativa de Software, Medição de Software, APF, SOA.
1. Introdução
Estimar o tamanho de um software a ser desenvolvido é indispensável para se obter uma estimativa confiável de custos e prazos (WILKIE, 2011), mas realizar adequadamente esse tipo de estimativa é apontado pela literatura como um dos maiores desafios enfrentados por gestores dessa área (PRESSMAN,2011; WILKIE, 2011; KAUR, 2016). É o que mostra, por exemplo, Roetzheim (2000), que conduziu, durante 18 anos, uma extensa pesquisa, que concluiu que a as maiores causas de fracassos de projetos de software estão relacionadas a uma pobre estimativa de custos e cronograma de execução, e não a problemas técnicos, políticos ou de desenvolvimento da equipe.
Apesar de não ser uma ciência exata, devido a influência de variáveis humanas, técnicas, ambientais e políticas (SOARES,2013), técnicas de medição (e métricas) de software podem contribuir, significativamente, com a geração de estimativas mais assertivas, o que diminui a discrepância entre o que foi estimado e o que foi realizado, bem como permite detectar tendências e antecipar problemas, proporcionando um controle de custo mais eficiente, reduzindo riscos, melhorando a qualidade e garantindo que os objetivos de negócio sejam alcançados (FLORAC,1997; PRESSMAN,2008; TICHENOR,2013; SOARES,2013).
Uma das técnicas de medição mais utilizadas e documentadas para a obtenção do tamanho funcional de um software é APF (da sigla em inglês FPA, Function Point Analysis) (IFPUG,2010; WILKIE, 2011; SOARES,2013). Este método foi publicado pela primeira vez em meados da década de 70 por Allan Albrecht (ALBRECHT,1984) e aprimorado pelo International Function Point Users Group (IFPUG), e já se encontra consolidado e amplamente utilizado em todo o mundo (IFPUG,2010; CALAZANS,2011; SISP,2015). O método utiliza Pontos de Função (PF) como unidade de medida (IFPUG,2010).
Apesar da consolidação da APF como técnica para dimensionamento do tamanho funcional de softwares (LINDSKOOG,2009; IFPUG,2010) e do esforço continuo para aprimoramento e evolução do método, há cenários que em que sua adoção não é direta. Projetos de software que seguem a abordagem Arquitetura Orientada a Serviço (SOA) – arquitetura para desenvolvimento de software cujo princípio fundamental é a construção de serviços reutilizáveis e interoperáveis (ERL,2005), faz parte da lista de contextos onde a aplicação da APF é questionada.
Discussões acerca da aplicabilidade do método para projetos SOA têm sido constantes e muitos desafios ainda precisam ser vencidos para sua adoção. (GENCEL, 2008; LINDSKOOG,2009; GOMES,2012). Esta dificuldade decorre de diversos fatores, dentro os quais se destacam o fato de que, em projetos SOA, muitas funcionalidades são projetadas para o reuso, o que torna comum que o escopo de um projeto extrapole o escopo funcional da aplicação que está sendo desenvolvida (ERL, 2005). Além disso, em SOA, sistemas complexos precisam ser decompostos em serviços e boa parte do esforço de análise e projeto está vinculado justamente ao processo de decomposição e posterior recomposição dos serviços. Esse processo requer a aplicação explícita de métodos e princípios para obtenção de baixo acoplamento, capacidade de composição, padronização e mediação de transações, entre outros, que não estão presentes no desenvolvimento de software convencional (ERL, 2008). Desse modo, as métricas e benchmarks de estimativa de esforço utilizadas para o desenvolvimento tradicional não poderiam ser aplicadas diretamente em projetos SOA (LINDSKOOG,2009; FARRAG,2015).
Dentro deste contexto, esse artigo apresenta resultados de um estudo de caso que envolveu a medição, através da APF, de um software desenvolvido integralmente utilizando a abordagem SOA para posterior comparação com o esforço, prazo e custos reais dispensados na implementação do software. O trabalho foi desenvolvido a partir de dados coletados de um projeto real, do qual os autores tiveram acesso irrestrito.
Este artigo está organizado da seguinte maneira: a seção 2 apresenta sucintamente os conceitos básicos relacionados à Análise de PF e à abordagem SOA, bem como os principais trabalhos científicos que nortearam a proposta. A seção 3 Apresenta a Metodologia de Trabalho adotada, enquanto a seção 4 apresenta resultados obtidos. Por fim, a seção 5 traz as principais conclusões e comentários finais.
2. Conceitos
2.1 Análise de Pontos de Função (APF)
Conforme já mencionado, a APF é uma técnica para a medição de softwares ou de projetos de desenvolvimento/manutenção de softwares, mantida pelo International Function Point Users Group (IFPUG), e que tem por objetivo a obtenção do tamanho funcional em “Pontos de Função” (PF), considerando o ponto de vista do usuário (IFPUG,2010). O IFPUG publica e mantém atualizado o Manual de Práticas de Contagem (CPM – Counting Practices Manual), que contém as regras e o processo que devem ser seguidos para garantir resultados mais consistentes na aplicação da APF (IFPUG,2010).
As organizações podem aplicar esse padrão internacional para medir o tamanho de um software com o intuito de: (i) estimar esforço, custo e prazo requeridos para o desenvolvimento, manutenção e melhoria do software; (ii) fornecer suporte à análise de qualidade e produtividade; (iii) fornecer um fator de normalização para a comparação de softwares (IFPUG,2010). Sua utilização apresenta diversos benefícios dos quais destacam-se: regras de contagem objetivas, independência da solução tecnológica e linguagem de programação e possibilidade de geração de estimativa já nas fases iniciais do ciclo de vida do software (SISP,2015).
A aplicação do método envolve a realização das seguintes etapas, detalhadas no CPM (2010): (i) obter a documentação disponível; (ii) identificar o propósito e o tipo de contagem, determinar o escopo da contagem e a fronteira da aplicação; (iii) medir as funções de dados, que são os requisitos funcionais do usuário no que se refere a armazenamento e/ou recuperação de dados e são classificadas em Arquivos Lógicos Internos (ALI) – grupos lógicos de dados mantidos dentro da fronteira da aplicação, e Arquivos de Interface Externa (AIE) – são apenas referenciados pela aplicação sendo medida; (iv) medir as funções transacionais, que são funcionalidades providas ao usuário para o processamento de dados por uma aplicação e são classificadas em (a) Entradas Externas (EE) – responsáveis pelo processamento de dados ou informações de controle que têm sua origem fora da fronteira da aplicação; (b) Consultas Externas (CE) – responsáveis pelo envio de dados ou informações de controle que saem para fora da fronteira da aplicação; (c) Saídas Externas (SE) – responsáveis pelo envio de dados ou informações de controle que saem para fora da fronteira da aplicação, incluindo lógica de processamento adicional, além do identificado em uma Consulta Externa; (v) calcular o tamanho funcional; (vi) documentar e reportar a contagem. Ou seja, a partir da documentação de projeto ou do software e sob o ponto de vista do usuário (requisitos funcionais) são derivados os PF em termos de funcionalidades oferecidas e dados envolvidos. De posse da quantidade de PF e com base em modelos, como o Modelo Simplificado de Estimativas (Vazquez,2012) ou o Modelo COCOMO II (Boehm,2009), são derivados o esforço, prazo e custo de um projeto.
2.2 Arquitetura Orientada a Serviços (SOA)
SOA é uma abordagem de arquitetura para desenvolvimento de software cujo princípio fundamental é a construção de serviços reutilizáveis e interoperáveis (ERL,2005). De acordo com ERL (2005), Serviço é unidade fundamental da lógica orientada a serviço (lógica da solução), ou seja, as funcionalidades da aplicação são disponibilizadas na forma de serviço.
Uma lógica é considerada orientada a serviço quando alguns princípios, conhecidos como princípios SOA, são aplicados em uma extensão significativa da solução (ERL, 2005). De acordo com ERL (2008) são oito estes princípios: (I) padronização de contrato; (II) baixo acoplamento de serviços; (III) abstração de serviço; (IV) capacidade de reuso de serviço; (V) autonomia de serviço; (VI) independência de estado de serviço; (VII) visibilidade de serviço (capacidade de descoberta); e (VIII) capacidade de composição de serviço.
SOA busca, por meio da aplicação dos princípios: aumentar o alinhamento entre negócio e TI; a federalização (o acesso aos serviços é padronizado de forma a unificar a visão dos seus consumidores); a diversidade de fornecedores; o retorno do investimento (ROI); e a agilidade organizacional; bem como reduzir o peso da TI na organização (ERL,2008). Desta forma, SOA permite construir aplicações que respondam mais rapidamente às demandas de negócio, uma vez que serviços são construídos de maneira padronizada, sendo capazes de interoperar (comunicar) uns com os outros de maneira padrão e transparente, independentemente de plataforma, fornecedores ou tecnologias que em foram construídos ou são executados.
Apesar de já existir há algum tempo, SOA ganhou relevância apenas a partir de meados dos anos 2000 (ERL, 2005). Segundo pesquisa realizada recentemente (WinterGreen, 2014), o mercado de SOA está crescendo rapidamente. O relatório da pesquisa indica que o mercado SOA atingiu US $ 5,7 bilhões em 2013 e pode chegar a US $ 16,4 bilhões até 2020. De acordo com a pesquisa, este crescimento significativo se deve ao fato de SOA oferecer processos automatizados mais eficientes e proporcionar à TI a possibilidade de investir uma maior parte do orçamento no crescimento do negócio. Além disso, com soluções de software desacopladas (independentes), os serviços SOA podem ser reutilizados de maneira eficiente.
3. Apresentação da Metodologia de Trabalho Adotada
A medição por meio da utilização de PF para obtenção do tamanho funcional do PROJETO DE REFERÊNCIA, realizada através da aplicação das regras de contagem definidas no CPM (IFPUG,2010), teve por objetivo identificar, através de uma análise comparativa, qual seria o custo, prazo e esforço reais dispensados na realização do projeto e resultado obtido a partir da aplicação da APF. Desta forma, foi possível, avaliar se a utilização da APF seria adequada para a medição do projeto (desenvolvido sob a abordagem SOA).
3.1 Escolha do Projeto
A escolha do projeto a ser utilizado ocorreu de forma natural, uma vez que a empresa onde os autores trabalham foi contratada para estruturar a adoção de SOA por uma organização que, por razões de sigilo de informações, será denominada contratante no decorrer deste artigo .O projeto teve por objetivo, de maneira geral, a estruturação da adoção de SOA pela contratante. Foram desenvolvidas atividades para a estruturação, desenvolvimento, implantação e monitoramento do programa de adoção SOA, por meio da execução de atividades que incluiu, entres outras, a criação de um sistema desenvolvido integralmente utilizando a abordagem SOA e que será denominado PROJETO DE REFERENCIA no decorrer deste artigo.
3.2 Medição do PROJETO DE REFERÊNCIA
A medição do PROJETO DE REFERÊNCIA por meio da utilização de PF foi realizada após concluída implementação e implantação do software. Deste modo, optamos por realizar uma contagem detalhada, que considera além da quantidade de funções transacionais, à complexidade funcional (Baixa, Média, Alta) de cada função individualmente. Foram utilizados como insumos para medição, além dos artefatos produzidos durante o desenvolvimento do projeto, o acesso ao software em funcionamento. Contamos, ainda, com a opinião especializada dos membros da equipe do projeto.
3.3 Estimativa de Esforço de Projetos de Software
Diversos modelos para estimar esforço de projetos de software, baseados em PF, estão disponíveis atualmente, sendo o Modelo Simplificado de Estimativas (Vazquez (2012)) e o Modelo COCOMO II (Boehm,2009) os mais utilizados (SISP ,2015). Neste trabalho, utilizamos o Modelo simplificado de estimativas, o mesmo utilizado pelo SISP (2015).
4. Resultados Experimentais
4.1 PROJETO DE REFERÊNCIA
Nesta seção são apresentados os resultados reais obtidos a partir da execução do PROJETO DE REFERÊNCIA, que inclui informações sobre a equipe de projeto, esforço, prazo e custos do projeto.
4.1.1 Equipe de Projeto
O Quadro 1 apresenta a equipe alocada para o desenvolvimento da solução. São apresentadas informações a respeito da quantidade de pessoas que participaram do projeto por tipo de recurso/papel, o papel exercido pelo recurso alocado na equipe com sua respectiva porcentam de particação e à dedicação relativa, em percentuais, de um recurso/papel específico ao longo de todo o projeto.
4.1.2 Prazo e Esforço Realizados
O PROJETO DE REFERÊNCIA teve uma duração de 6 meses e o esforço real foi medido através do registro de horas no JIRA, uma ferramenta que possibilita o acompanhamento de projetos através do registro de atividades e geração de relatórios. O Quadro 2 apresenta o esforço dispensado na realização de cada etapa do desenvolvimento do projeto.
Quadro 2: Esforço Realizado PROJETO DE REFERÊNCIA
| Fase Projeto | Horas |
| Modelagem de Negócio e Analise | 1076 |
| Implementação | 826 |
| Teses e Implantação | 268 |
| Total Horas | 2170 |
4.1.3 Custo Realizado
O custo foi calculado através da conversão de horas para UST (Unidade de Serviço Técnico), que é a unidade de medica utilizada para quantificar o trabalho. Ou seja, a quantidade de homem-hora é convertida em UST conforme definição contratual para derivação de custos. O cálculo de UST leva em consideração a complexidade da atividade executada (baixa, média e alta). O Quadro 3 apresenta o resultado da conversão de horas/UST para cada fase do projeto.
Quadro 3: Custo Realizado PROJETO DE REFERÊNCIA
| Fase Projeto | Horas | UST |
| Modelagem e Análise | 1076 | 1765 |
| Implementação | 826 | 894 |
| Teses e Implantação | 268 | 304 |
| Total Horas | 2170 | 2963 |
Considerando o valor de UST contratado de R$247,50, o projeto teve um custo total no valor de R$733.342,50
4.1.4 Resultado Geral
A Quadro 4 apresenta o sumário de esforço, prazo e custo dispensados na realização do projeto de referência, o qual servirão de base para análise comparativa com o resultado da medição do tamanho funcional do software por meio da utilização PF.
Quadro 4: Resultado Geral
| PROJETO REFERÊNCIA | |
| Esforço (horas): | 2170 |
| Prazo (meses): | 6 |
| Custo (R$): | R$733.342,50 |
4.2 Medição do tamanho do Funcional – IFPUG
A medição funcional do tamanho do software por meio da utilização de PF considerou a aplicação como um todo, com a visão funcional do ponto de vista do usuário, conforme preconiza a APF padrão do IFPUG (IFPUG,2010). O Quadro 5 apresenta o propósito (objetivo ou finalidade da medição) e escopo de Medição (conjunto ou subconjunto de aplicações que serão medidas). O Quadro 6 apresenta, resumidamente, o resultado da contagem, que corresponde ao valor do tamanho funcional do PROJETO DE REFERÊNCIA. A derivação de Prazo, Esforço, Equipe e Custo foram determinados com base no modelo de Estimativas Simplificado, o qual é apresentado no Quadro 7.
Quadro 5: Cenário Funcional Medição PROJETO REFERÊNCIA
| Cenário Funcional | |||
| Propósito da Medição | Medição do tamanho funcional (APF IFPUG) do projeto de referência desenvolvido como parte do programa de adoção de SOA da contratante. | ||
| Escopo da Medição | Aplicações do PROJETO DE REFERÊNCIA | ||
Técnica de Contagem: determina se a contagem será indicativa, estimada ou detalhada. A contagem indicativa baseia-se somente em informações a respeito das funções de dados, ou seja, na quantidade de arquivos lógicos existentes (ALIs e AIEs). A contagem estimada considera, além da quantidade de funções de dados, informações a respeito das funções de transação, de forma que forma que os requisitos dos usuários precisam estar mais detalhados. Já para contagem detalhada, além da quantidade de funções transacionais, é necessário determinar a complexidade funcional (Baixa, Média, Alta) de cada função individualmente (NESMA,2015).
Tipo de Contagem: são possíveis três tipos de contagem: (i) Desenvolvimento: medida da funcionalidade fornecida aos usuários considerando a primeira instalação do software. (ii) Melhoria/Manutenção: referente as modificações, o seja, funcionalidade incluída, alterada ou excluída, para um software já existente. (iii) Aplicação: medida da funcionalidade que uma aplicação oferece ao usuário. Uma Aplicação é conjunto coeso de procedimentos automatizados e dados, que tem por objetivo suportar um objetivo de negócio e é composta por um ou mais componentes, módulos ou subsistemas (IFPUG,2010).
Tamanho Funcional do Projeto: Refere-se ao valor do tamanho funcional do PROJETO DE REFERÊNCIA.
Produtividade Diária (horas): Refere-se à quantidade de horas produtivas de uma pessoa no dia. Neste trabalho, foi considerado 6 horas/dia, conforme recomendado pelo (SISP,2015).
Índice de Produtividade (horas/PF): Refere-se à quantidade de horas dedicadas a produção de 1 PF. A determinação do valor do índice de produtividade depende de diversos fatores, que podem incluir, entre outros, a plataforma tecnológica, segurança, desempenho, usabilidade e tamanho do projeto. Cada organização deverá possuir uma tabela de produtividade própria, considerando dados históricos de projetos anteriores.
Esforço (pessoa/hora): Refere-se à quantidade de horas a serem dispensadas na entrega do projeto, ou seja, na entrega do tamanho funcional determinado. É calculado com base no tamanho funcional do projeto e índice de produtividade (Tamanho (PF) x Índice de Produtividade (HH /PF)).
Ambiente: Refere-se ao expoente a ser utilizado na formula para determinação do prazo recomendado. A Tabela 1 apresenta as opções disponíveis. Neste foi selecionado o “Sistema OO – Sistema Orientado a Objetos”, o qual mais se aproxima das características de um projeto SOA.
Prazo Recomendado: É calculado de acordo com fórmula de Capers Jones [Jones,2007].
Carga de Trabalho Mensal (horas): Refere-se à quantidade de horas úteis trabalhadas em mês por pessoa.
Equipe: Refere-se à quantidade de recursos necessários para desenvolvimento do projeto e deve-se considerar os percentuais de alocação do recurso ao projeto. No resultado apresentado, a equipe de projeto de 6,2 recursos poderia corresponder, por exemplo, a uma equipe de 12 pessoas com 50% de alocação e um líder de projeto com 20% de alocação ao projeto.
Equipe Informada: Refere-se a equipe que efetivamente trabalhou no desenvolvimento do projeto. Tem por objetivo apoiar outras simulações de esforço e prazo e a distribuição dos recursos na equipe de acordo com a dedicação de cada um ao projeto.
Outras simulações de Estimativas: Foram geradas outras simulações de estimativas com base na equipe informada e considerando redução de prazo. O valor do ponto de função utilizado foi definido com base em referências históricas da empresa CONTRATANTE. Foram calculados os custos do projeto sem considerar a redução de prazo e considerando a redução de prazo.
5. Conclusões
5.1 Análise Crítica da Proposta
A partir da análise dos resultados obtidos por meio da aplicação da APF e execução do PROJETO DE REFERÊNCIA foi concluído que o custo real do projeto SOA e o obtido a partir da medição por meio de PF resultaram em valores significativamente diferentes (custo real: R$733.342,50 e custo estimado: R$349.600,00). Observou-se, ainda, uma diferença significativa entre o esforço necessário para desenvolvimento do projeto e esforço real (esforço real: 2170 horas e esforço estimado: 6992 horas). O custo real e estimado (custo real: R$733.342,50 versus custo estimado: R$593.620,00) somente apresentaram valores relativamente próximos quando método de estimativa para derivação de custo considera a redução de prazo para desenvolvimento do projeto em relação ao idealmente recomentado (prazo real: 6 meses versus prazo recomendado: 7,71 meses).
Desta forma, foi possível concluir que a APF apresentou resultados muito díspares em relação aos resultados reais obtidos, não sendo, portanto, adequada para a medição de projetos SOA. Soma-se, ainda, o fato de a APF não contabilizar em sua contagem os requisitos não‑funcionais, os quais são muitos frequentes em aplicações SOA, como por exemplo, o reuso e composição de serviços. Além de não permitir a medição fragmentada da solução, ou seja, a medição individualmente por serviço. Esta é uma característica bastante desejada quando se trata de medição de projetos SOA, que pode envolver a construção de uma solução completa ou apenas um subconjunto desses serviços, podendo, inclusive, envolver a construção de apenas um serviço específico.
5.2 Limitações e Trabalhos Futuros
O trabalho realizado limitou-se a medição de um projeto apenas. Além disso, foi utilizado apenas um método de estimativas para derivação de esforço, custo e prazo. Em trabalhos futuros, a aplicação da APF em uma diversidade maior de projetos e utilização de outros métodos de estimativas pode trazer benefícios na medida em que proporcionará maior confiabilidade nas conclusões obtidas. Será ainda de grande relevância a proposição de um método específico para medição do tamanho de softwares SOA, que busque seguir os conceitos mais puros do IFPUG com relação à medição funcional, mas considere também a necessidade de medição fragmentada da solução, bem como a medição dos requisitos não-funcionais.
Referências
ALBRECHT, Allan J. IBM CIS&A Guideline 313. AD/M Productivity, 1984.
BOEHM, B.W. Software Cost Estimation with COCOMO II. Prentice Hall, New Jersey, 2009.
CALAZANS Angelica; LISBOA Irina; OLIVEIRA Marcelo. Avaliação das Características Gerais de Sistemas na Análise por Pontos de Função – APF por meio da aplicação do GQM – Goal, Questions, Metrics. VII Simpósio Internacional de Melhoria de Processos de Software. São Paulo. Novembro de 2011.
ERL, Thomas. Service-Oriented Architecture: Concepts, Technology, and Design. Crawfordsville: Prentice Hall PTR, Aug. 2005.
ERL, Thomas. SOA Principles of Service Design. Prentice Hall, 2008.
FARRAG, Esraa A.; MOAWAD, Ramadan; IMAM, Ibrahim F. An Approach for Effort Estimation of Service Oriented Architecture (SOA) Projects. JSW, v. 11, n. 1, p. 44-63, 2016.
FLORAC, William A.; PARK, Robert E.; CARLETON, Anita D. Practical software measurement: Measuring for process management and improvement. CARNEGIE-MELLON UNIV PITTSBURGH PA SOFTWARE ENGINEERING INST, 1997.
GENCEL, Cigdem; DEMIRORS, Onur. Functional size measurement revisited. ACM Transactions on Software Engineering and Methodology (TOSEM), v. 17, n. 3, p. 15, 2008.
GOMES, Yuri Marx Pereira. Functional size, effort and cost of SOA projects with function points. no. LXVIII, November, 2012.
IFPUG – INTERNATIONAL FUNCTION POINT USER GROUP. Manual de Práticas de Contagem de Pontos de Função. Version 4.3.1, Janeiro 2010.
IFPUG – INTERNATIONAL FUNCTION POINT USER GROUP. Assessment Practices Manual. Version 2.3, Maio 2015.
JONES, C. Estimating Software Costs. Second Edition, Mc Graw Hill, 2007.
KAUR, Prabhjot. A Review of Software Metric and Measurement. International Journal of Computer Applications & Information Technology, v. 9, n. 2, p. 187, 2016.
LINDSKOOG Jeff. Applying Function Points Within a SOA Environment. EDS, An HP Company. 1401 E. Hoffer St. Kokomo, IN 46902. USA. September 2009.
NESMA – Netherlands Function Points Users. Análise de Pontos de Função Inicial. Julho 2015.
PRESSMAN, Roger S. Engenharia de software: uma abordagem profissional. 7ª Edição. Ed: McGraw Hill, 2011.
ROETZHEIM, William H. Estimating software costs. SOFTWARE DEVELOPMENT-SAN FRANCISCO-, v. 8, n. 10, p. 66-68, 2000.
SISP. Roteiro de Métricas de Software do SISP: versão 2.1, Ministério do Planejamento, Orçamento e Gestão. Secretaria de Logística e Tecnologia da Informação. Brasília: MP, 2015.
SOARES DOS REIS, Julio Cesar; BARBOSA, Marcelo Werneck. PROPOSTA DE UMA TÉCNICA DE ESTIMATIVA PARA REQUISITOS. Revista de Sistemas e Computação-RSC, v. 3, n. 1, 2013.
TICHENOR Charley, SNAP-Case Study 2 (vsn 1. 0): How to Use Function Points and SNAP to Improve a Software Acquisitions Contract. IFPUG. Junho de 2014.
VAZQUEZ, Carlos E.; SIMÕES, Guilherme Siqueira; ALBERT, Renato Machado. Análise de Pontos de Função: medição, estimativas e gerenciamento de projetos de software. 12ª Edição, Editora Érica Ltda, São Paulo, 2012.
WILKIE, F. George et al. The value of software sizing. Information and Software Technology, v. 53, n. 11, p. 1236-1249, 2011.
[1] Mestrando em Engenharia Elétrica – UnB
[2] Doutor em Engenharia e Gestão do Conhecimento.
[3] Doutor em Engenharia Elétrica pela Universidade de Brasília (2004), aonde leciona no Departamento de Engenharia Elétrica desde 1998. Realizou estágio doutoral na L’Ecole Supérieure d’Électricité (Supelec), Rennes/França (2001/2002) e estágio de pós-doutorado no Swedish Institute for Computer Science (SICS), em Estocolmo/Suécia (2011). Foi coordenador do Núcleo de Tecnologia da Informação (NTI) da UnB (2006-2008) e Diretor do Centro de Informática (CPD) da UnB (2007-2008). Atua em projetos de pesquisa, desenvolvimento tecnológico e inovação, e consultoria, em parceria com diversas empresas e entidades governamentais, em assuntos relacionados às TIC, onde atua na definição de estratégia, modelo de governança, prospecção tecnológica e transferência de tecnologia. Suas áreas de interesse atuais incluem: computação em nuvem, arquitetura orientada a serviço, gerenciamento de processos de negócio, sistemas distribuídos e aplicações de tecnologias da informação em ambientes governamentais.
