Artigo Engenharia de Software 2 - Análise de pontos de função

Planejamento

Análise de pontos de função

Uma aplicação nas estimativas de tamanho de Projetos de Software

A indústria de software continua sentindo os efeitos da crise do software da década 80. Isto pode ser observado quando analisamos os três principais sintomas da crise do software apresentados por Pressman em 2006, a saber:

·         A produtividade não tem acompanhado a demanda por serviços;

·         A qualidade do software, em alguns sistemas, não é adequada;

·         As estimativas de prazo e custo são freqüentemente imprecisas.

Este último sintoma, que está associado a um dos principais problemas que a indústria de software tem enfrentado (a falta de previsibilidade de custo e prazo de projetos de software), pode levar a conseqüências desastrosas, tais como: conflitos entre o gerente do projeto e a equipe, baixa estima da equipe, entrega de software de baixa qualidade, perda de imagem da organização, e até mesmo o cancelamento do projeto. Assim, torna-se importante o investimento na implantação de um processo de estimativas efetivo, visando a melhoria da previsibilidade de custo, prazo e esforço.

Este artigo tem como propósito apresentar um processo de estimativas de projetos de software, aderente ao modelo CMMI, utilizando a métrica de Pontos de Função para estimar o tamanho funcional do projeto de software.

Processo de Estimativas de Projetos de Software

Esta seção apresenta uma visão geral de um processo de estimativas de projetos de software aderente à área de processo de Planejamento do Projeto do nível 2 do CMMI.

A Figura 1 ilustra um processo de Estimativas de Projetos de Software. Este processo é descrito nos parágrafos seguintes.

Figura 1. Processo de Estimativas de Projetos de Software

O principal insumo (artefato de entrada) para um processo de estimativas é o documento de requisitos. Como as estimativas devem ser realizadas no início do processo de desenvolvimento de software, então, o artefato utilizado é freqüentemente um documento inicial de requisitos (por exemplo: Documento de Visão) ou até mesmo um documento do próprio cliente (por exemplo: modelo de processo de negócios ou manual do usuário, no caso de redesenvolvimento). O responsável pelas estimativas deve analisar os requisitos para garantir a qualidade e então estimar o tamanho do projeto de software. O próximo passo é a derivação das estimativas de esforço, prazo (cronograma), custo (orçamento) com base na estimativa de tamanho e nos dados históricos de projetos concluídos da organização, assim como o estabelecimento da estimativa de recursos computacionais críticos. Neste ponto, as principais estimativas foram geradas, no entanto estas precisam ser documentadas. As premissas e suposições utilizadas na geração das estimativas também devem ser documentadas.

A análise das estimativas por um estimador independente, um profissional que não atue na equipe do projeto, constitui uma boa prática. O estimador independente poderá analisar a consistência das estimativas e a qualidade das suas documentações. No decorrer do processo de desenvolvimento, as estimativas devem ser acompanhadas conforme o refinamento dos requisitos. O projeto deve ser re-estimado se ocorrerem mudanças significativas nos requisitos funcionais ou não funcionais. Quando o projeto é concluído, deve-se documentar o tamanho, prazo, custo, esforço e recursos realizados, assim como outros atributos relevantes do projeto, visando a coleta de dados para a melhoria do processo de estimativas. As lições aprendidas também devem ser documentadas.

O foco deste artigo está na geração de estimativas de tamanho de projetos de software. Observe que a estimativa de tamanho é a primeira a ser gerada e a partir dela são derivadas as demais estimativas. Por isso, a importância desta estimativa. A literatura apresenta várias métricas de tamanho. Na indústria brasileira, pode-se destacar a utilização de três métricas: LOC (Line of Code), Pontos por Casos de Uso e Pontos de Função. A seção seguinte apresenta as vantagens e desvantagens da utilização destas métricas.

Métricas de Tamanho de Projetos de Software

A métrica Linhas de Código (LOC) é de fato a mais antiga. A principal vantagem é que a contagem de linhas de código pode ser automatizada por uma ferramenta. As desvantagens são as seguintes: muitas vezes, o significado de uma linha de código é subjetivo, por exemplo, contar ou não linhas de comentário no código fonte; a métrica não é adequada para ser um indicador de produtividade, por exemplo, o desenvolvedor que escrever mais linhas de código será mais produtivo do que o desenvolvedor que escrever um algoritmo mais elegante e mais eficiente com menos linhas de código. Além disso, torna-se bastante complicado e subjetivo aplicar esta métrica em um processo de estimativas cujo insumo é um documento inicial de requisitos. Portanto, não é recomendado o uso da métrica LOC como unidade de medida para as estimativas de tamanho.

A métrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner com o propósito de estimar recursos para projetos de software orientados a objeto, modelados por meio de especificação de Casos de Uso. A métrica é de fácil aplicação, não requer muito tempo de treinamento ou experiência prática. No entanto, o PCU somente pode ser aplicado em projetos de software cuja especificação tenha sido expressa em casos de uso. Além disso, como não existe um padrão único para a escrita de uma especificação de caso de uso, diferentes estilos na escrita do caso de uso ou na sua granularidade podem levar a resultados diferentes na medição por PCU. Assim, a métrica se torna subjetiva. E ainda, devido ao processo de medição do PCU ser baseado em casos de uso, o método não pode ser empregado antes de concluída a análise de requisitos do projeto. Na maioria das vezes existe a necessidade de se obter uma estimativa antes da finalização desta etapa. Então, esta métrica não é recomendada para utilização como unidade de medida das estimativas de tamanho de projetos de software.

A métrica Pontos de Função (PF), definida por Allan Albrecht em 1979, tem sido utilizada de forma crescente pela indústria de software. O IFPUG (International Function Point Users Group), criado em 1986, é responsável pela atualização das regras de Contagem de Pontos de Função, descritas no CPM (Counting Practices Manual), que se encontra na versão 4.2.1, publicada em 2005 no IFPUG. O IFPUG também é responsável pelo exame de certificação de especialistas em contagem de Pontos de Função, denominada CFPS (Certified Function Point Specialist). A métrica Pontos de Função é uma medida de tamanho funcional de projetos de software, considerando as funcionalidades implementadas, sob o ponto de vista do usuário. Tamanho funcional é definido como “tamanho do software derivado pela quantificação dos requisitos funcionais do usuário” (Dekkers, 2003).

A contagem de Pontos de Função é independentemente da metodologia de desenvolvimento e da plataforma utilizadas no desenvolvimento da aplicação. Assim, a autora recomenda a utilização da métrica Pontos de Função nas estimativas de tamanho de projetos de software. A autora tem utilizado a métrica para estimar os projetos dos clientes da organização Serviço Federal de Processamento de Dados (SERPRO) desde 2003, tendo obtido excelentes resultados.

A seção seguinte apresenta o método Contagem Estimativa de Pontos de Função (CEPF), utilizado para estimar o tamanho de projetos de software.

Contagem Estimativa de Pontos de Função

Antes de definir o método de estimativas CEPF, é importante destacar que “estimar significa utilizar o mínimo de tempo e esforço para se obter um valor aproximado dos Pontos de Função do projeto de software investigado” (Meli, 1999). Assim, para evitar confusão, é recomendável sempre fazer uma distinção entre os termos e conceitos: Contagem de Pontos de Função e Estimativa de Pontos de Função.

·         Contagem de Pontos de Função: significa medir o tamanho do software por meio do uso das regras de contagem do IFPUG (IFPUG, 2005);

·         Estimativa de Pontos de Função: significa fornecer uma avaliação aproximada do tamanho de um software utilizando métodos diferentes da Contagem de Pontos de Função do IFPUG.

Além do método Contagem indicativa de Pontos de Função, existem diversos métodos para estimar tamanho de projetos em Pontos de Função, descritos na literatura, dentre outros: Contagem Indicativa, Contagem Indicativa Inteligente, Estimativas Percentuais.

O método CEPF visa aferir o tamanho em PF de maneira simplificada, com base no conhecimento dos requisitos iniciais do projeto. Inicialmente, os requisitos funcionais iniciais documentados nas propostas comerciais, nos documentos de visão, ou em qualquer especificação inicial do sistema do usuário são mapeados nos tipos funcionais da Análise de Pontos de Função (APF): Arquivo Lógico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE) e Saída Externa (SE). Posteriormente, os Pontos de Função são associados a cada função identificada, baseando-se nas tabelas de complexidade e de contribuição funcional do CPM.

O estimador deve realizar uma leitura no documento inicial de requisitos, buscando informações relevantes para a identificação de processos elementares. O processo elementar é definido como a menor unidade de atividade significativa para o usuário (IFPUG, 2005). O processo elementar deve ser completo em si mesmo, independente e deixar a aplicação em um estado consistente (IFPUG, 2005). Uma vez identificado o processo elementar, o estimador deve buscar o entendimento deste para classificá-lo em Entrada Externa, Consulta Externa ou Saída Externa. Adicionalmente, o estimador deve descobrir os dados associados ao processo elementar, visando a determinação da complexidade funcional da função identificada. Caso não seja possível a identificação da complexidade da funcionalidade em questão, recomenda-se a utilização da complexidade Média. Na análise do processo elementar também são identificados, os grupos de dados lógicos da aplicação, que são classificados como Arquivos Lógicos Internos ou Arquivos de Interface Externa. Caso não seja possível a identificação da complexidade da função de dados em questão, recomenda-se a utilização da complexidade Simples.

A seguir são apresentadas dicas para ajudar no mapeamento dos requisitos funcionais da aplicação nos tipos funcionais da APF.

As necessidades e funcionalidades especificadas para o projeto, contidas no documento inicial de requisitos, devem ser enquadradas em uma das seguintes tabelas:

Tabela 1 - Contagem dos Arquivos Lógicos Internos (ALIs): Banco de Dados Lógico da Aplicação (tabelas e arquivos mantidos pela aplicação).

Considerações: Identifique os grupos de dados lógicos de aplicação nos modelos de dados ou diagrama de classes ou a partir dos requisitos funcionais, descritos nos documentos de requisitos (Documento de Visão, Relação de Casos de Uso, etc.). Não considere arquivos físicos, arquivos de índices, arquivos de trabalho e tabelas de relacionamento sem atributos próprios (tabelas que existem para quebrar o relacionamento nxn e apenas transportam as chaves estrangeiras). As entidades fracas também não são consideradas um ALI.

Se possível, tente descobrir os atributos lógicos, campos reconhecidos pelo usuário, e subgrupos de dados existentes para obter a complexidade funcional, segundo as regras de contagem do CPM (IFPUG, 2005). Caso não seja possível, a experiência tem mostrado que a maioria dos ALIs dos sistemas são de complexidade Simples.

Tabela 1. Identificação dos Arquivos Lógicos Internos da Aplicação

Tabela 2 - Contagem de Arquivos de Interface Externa (AIEs): Banco de Dados de outras Aplicações, apenas referenciados pela aplicação que está sendo estimada (tabelas e arquivos mantidos por outra aplicação).

Considerações: Identifique os grupos de dados lógicos de outras aplicações referenciados pela aplicação que está sendo estimada. Freqüentemente, o referenciamento de dados ocorre para a validação de informações em cadastros ou consultas. Algumas vezes, relatórios ou consultas referenciam dados externos de outras aplicações, também considerados AIEs. Não são considerados arquivos físicos, arquivos de índice, arquivos de trabalho, tabelas de relacionamento sem atributos próprios e entidades fracas.

A experiência tem mostrado que praticamente 100% dos AIEs dos sistemas são Simples. Porque, segundo o CPM (IFPUG, 2005), são considerados para a determinação da complexidade funcional do AIE apenas os atributos referenciados pela aplicação que está sendo contada.

Tabela 2. Identificação dos Arquivos de Interface Externa da Aplicação

Tabela 3 - Contagem de Entradas Externas (EEs): Funcionalidades que mantêm os Arquivos Lógicos Internos (ALIs) ou alteram o comportamento da aplicação.

Considerações: Identifique as funcionalidades de inclusão, alteração e exclusões de dados. Conte separadamente as inclusões, alterações e exclusões de dados, isto é, cada função independente de inclusão ou alteração ou exclusão deve ser contada separadamente. A aplicação possui funções de entrada de dados que alteram o comportamento dela, por exemplo: processamentos batch, ou processamento de informações de controle? Caso positivo, estas funções também devem ser identificadas como Entradas Externas.

Se você não possui conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Entradas Externas identificadas com complexidade Média.

Tabela 3. Identificação das Entradas Externas da Aplicação

Tabela 4 - Contagem de Consultas Externas (CEs): funcionalidades que apresentam informações para o usuário sem a utilização de cálculos ou algoritmos. São os processos elementares do tipo “lê - imprime”, “lê - apresenta dados”, incluindo consultas, relatórios, geração de disquetes ou CDs, downloads, entre outros.

Considerações: Você está desenvolvendo uma função para apresentar informações para o usuário: uma consulta, relatório, browse, listbox, download, geração de um arquivo, geração de CD ou de disquete? Esta função não possui cálculos ou algoritmos para derivação dos dados referenciados nem altera um Arquivo Lógico Interno, nem muda o comportamento do sistema? Caso positivo, estas funções devem ser identificadas como Consultas Externas.

Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Consultas Externas com complexidade Média.

Tabela 4. Identificação das Consultas Externas da Aplicação

Tabela 5 - Contagem de Saídas Externas (SEs): Funcionalidades que apresentam informações para o usuário com utilização de cálculos ou algoritmos para derivação de dados ou atualização de Arquivos Lógicos Internos ou mudança de comportamento da aplicação. São as consultas ou relatórios com totalização de dados, relatórios estatísticos, gráficos, geração de disquetes com atualização log, downloads com cálculo de percentual, entre outros.

Considerações: Você está desenvolvendo uma funcionalidade para apresentar informações para o usuário: uma consulta ou relatório com totalização de dados, etiquetas de código de barras, gráficos, relatórios estatísticos, download com percentual calculado, geração de arquivo com atualização de log? Caso positivo, estas funções devem ser identificadas como Saídas Externas. Observe que esta função deve ter cálculos ou algoritmos para processar os dados referenciados nos arquivos lógicos ou atualizar campos (normalmente indicadores) nos arquivos ou mudar o comportamento da aplicação.

Caso não haja conhecimento da aplicação de APF ou sobre o processo elementar (funcionalidade analisada), considere as Saídas Externas com complexidade Média.

Tabela 5. Identificação dos Saídas Externas da Aplicação

A Estimativa de tamanho do projeto em PFs deve ser gerada totalizando-se os PFs obtidos nas Tabelas 1, 2, 3, 4, e 5.

Uma aplicação da Contagem Estimativa de Pontos de Função

Esta seção tem como propósito apresentar um exemplo utilizando o método CEPF, bem como a derivação das estimativas de esforço e prazo, a partir da estimativa de tamanho do projeto em PF. No exemplo apresentado, é descrito um sistema hipotético, parte de um sistema real, visando apresentar uma visão geral de um procedimento de estimativas de maneira prática.

Suponha que o setor de treinamento de uma empresa solicitou um sistema, denominado STREINA, para apoiar as atividades de planejamento e acompanhamento das atividades de capacitação dos funcionários. A Tabela 6 apresenta as necessidades e funcionalidades do STREINA, retiradas do Documento de Visão do projeto. Além das funcionalidades apresentadas na Tabela 6, deve-se considerar os requisitos de cadastro de usuários e controle de acesso da aplicação. Estas funcionalidades estarão disponíveis para o perfil administrador do sistema.

Para facilitar o entendimento da aplicação da CEPF, a Tabela 7 mostra a contribuição para a contagem de PFs não ajustados dos tipos funcionais da APF. A complexidade funcional das funcionalidades identificadas é inferida em uma contagem estimativa, quando não se possui informação suficiente do projeto para aplicar as regras de contagem do CPM. Conforme mencionado, recomenda-se utilizar a complexidade Simples para os Arquivos Lógicos (ALI e AIE) e a complexidade Média para as Funções Transacionais (EE, CE, SE).

Tabela 6. Funcionalidades do Sistema de Treinamentos (STREINA)

Tabela 7. Contribuição para Contagem de PF dos Tipos Funcionais da APF

Aplicando-se o método Contagem Estimativa de Pontos de Função, tem-se o resultado apresentado na Tabela 8.

Tabela 8. Estimativa de Tamanho do Sistema de Treinamentos (STREINA)

Totalizando o tamanho em PFs das funcionalidades descritas na Tabela 8, tem-se 170 PFs não ajustados. Suponha que o fator de ajuste da contagem seja de 1,10. O fator de ajuste da contagem de PF é determinado com base na avaliação das 14 Características Gerais dos Sistemas, que descrevem as funcionalidades gerais das aplicações, por exemplo: performance, reuso, usabilidade, etc. O manual de práticas de contagem (CPM) apresenta a descrição das características e de suas ponderações, denominadas níveis de influência. O cálculo do PF Ajustado é obtido multiplicando-se os PFs Não Ajustados pelo Fator de Ajuste.  Assim, temos 187 Pontos de Função Ajustados estimados.

De posse da estimativa de tamanho, procede-se com a geração da estimativa de esforço. Neste exemplo, utiliza-se o modelo simplificado de estimativas de esforço, descrito por Hazan em 2005. Para isto, deve-se obter um índice de produtividade por meio de análise do banco de dados de histórico de projetos da organização, observando-se os atributos do projeto em questão e o esforço realizado em projetos similares. Este projeto é pequeno (menos de 200 PFs) e será desenvolvido em JAVA por uma equipe com experiência intermediária na plataforma. Assim, o índice de produtividade hipotético utilizado é o de 12 horas/PF. Então, a estimativa de esforço é de: 187  12 = 2244 HH (homens_hora).

O próximo passo é a estimativa de prazo, aplicando-se a fórmula de Caper Jones (1998) de aproximação de Tempo Ótimo de Desenvolvimento (Td) com um expoente t = 0,34, tem-se: Td = 187^0,34 = 5,92 meses. Considerando-se o prazo estimado de 6 meses e o esforço estimado de 2244 HH, o próximo passo é a estimativa do tamanho da equipe de desenvolvimento ideal para atuar no projeto em questão. Segundo Jones (1997), a produtividade média diária no Brasil é de 6 horas/dia. E ainda, em média um mês possui 22 dias úteis. Então, tem-se: prazo = (esforço em HH) / (tamanho equipe * 6 * 22). Então, aplicando-se a fórmula, obtém-se o tamanho da equipe ideal para atuar no projeto, que deve ser constituída por três recursos, incluindo desenvolvimento e gestão.

O COCOMO II também possui fórmulas para o cálculo do Td, baseadas em parâmetros de calibragem e de mapeamento (Boehm, 2000). É importante destacar que as organizações devem ter ou construir um banco de dados histórico, contendo informações de projetos concluídos, com a finalidade de gerar as estimativas de prazo, custo e esforço com uma acurácia adequada.

Aplicando-se o COCOMO II para as estimativas de esforço e prazo do STREINA, tem-se o seguinte:

·         Fator de Produtividade Linear (Pessoas_Mês/KSLOC) para desenvolvimento WEB: 2,51 (Roetzheim, 2005);

·         Fator Exponencial para desenvolvimento WEB: 1,030 (Roetzheim, 2005)

·         1 PF = 33 SLOC em JAVA (Jons, 1997);

·         Esforço = Fator de Produtividade  KSLOC^{Fator Exponencial}   (Roetzheim, 2005);

·         Esforço = 2,51 [(33 170)/1000]^1,030 = 14,83 Pessoas_Mês. Note o que o insumo para o COCOMO é PF Não Ajustado, por isso considerou-se 170 PFs;

·         O COCOMO considera o dia com 7h e o mês com 22 dias úteis, então o esforço em HH é o seguinte: 14,83 * 7 * 22 = 2284 HH. Note que o cálculo do esforço estimado é próximo ao 2244 HH obtido pelo modelo simplificado;

·         Prazo (Td) = 2,5  (Esforço^0,32) = 5,9 meses (Aguiar, 1999);

·         Note que o prazo estimado pela fórmula de Caper Jones – 5,92 meses, ficou bastante próximo do prazo estimado pelo COCOMO.

Na prática, torna-se importante aplicar mais de um modelo de estimativas e analisar-se os resultados obtidos. Caso fosse utilizada a fórmula de esforço da ferramenta Cost Xpert, apresentada por Aguiar em 1999, o resultado seria o seguinte: E= 2,4 (V ^1,05) = 14,68 Pessoa_Mês, sendo V o tamanho do projeto em KSLOC. Note que este é bem próximo do esforço estimado, utilizando-se os parâmetros propostos por Roetzheim em 2005. Caso fosse utilizado o esforço de 14,68 como insumo para o cálculo do prazo, este continuaria sendo estimado em 5,9 meses.

A estimativa de custo deve considerar o valor da hora da equipe alocada ao projeto (custo de pessoal), bem como outros custos de ambiente, ferramentas, deslocamentos, consultoria, etc. Algumas empresas possuem dados históricos de custo por PF de projetos concluídos, possibilitando a derivação direta da estimativa de custo a partir da estimativa de volume em Pontos de Função.

A estimativa de recursos computacionais críticos em um projeto WEB deve considerar, dentre outros, a disponibilidade dos servidores utilizados para desenvolvimento, homologação e produção do sistema e outros recursos de hardware relevantes.

É importante ressaltar que após a geração das estimativas, deve-se adicionar um percentual, prevendo uma evolução natural dos requisitos do projeto. Este percentual deve ser obtido por meio de dados de históricos de um indicador de estabilidade de requisitos de projetos concluídos da organização.

As ferramentas de estimativas também trabalham desta forma, solicitando que o usuário (estimador) forneça tal percentual. No entanto, devido à ausência de dados históricos analisados para tal indicador, a autora tem se baseado em análise de publicações e sua experiência profissional. A autora tem utilizado um percentual de 20% a 35% para os projetos com Documento de Visão. Esta variação de percentual é diretamente proporcional ao detalhamento do Documento de Visão e conhecimento dos requisitos do projeto pelo analista de negócios.

Para alguns projetos estimados, baseados apenas em atas de reunião ou documentos menos detalhados, foi utilizado o percentual de 40%. Em projetos pequenos com documentos de requisitos com um detalhamento adequado, o percentual varia de 10% a 25%.

A CEPF deve ser refinada, conforme o conhecimento dos requisitos do projeto evolui, em marcos definidos no plano do projeto. Assim, não há retrabalho no processo de estimativas, as estimativas de PF anteriores não são descartadas e sim refinadas, conforme os requisitos do projeto evoluem.

Conclusão

A indústria tem demonstrado dificuldade na previsibilidade de prazo e custo dos projetos de software. No entanto, muitas organizações ainda estimam projetos, sem a utilização de processo, de maneira “artesanal”, baseando-se apenas na opinião dos líderes ou gerentes do projeto. De fato, o método de estimar projetos baseando-se na opinião de especialistas é bastante eficaz. O problema é quando a equipe não possui especialistas no domínio do projeto em questão.

Este trabalho apresentou um processo para as organizações nas estimativas de projetos de software, utilizando métodos aderentes às melhores práticas do CMMI nível 2. Espera-se que com a utilização de processos, o cenário caótico em relação à previsibilidade de projetos seja melhorado.

O método Contagem Estimativa de Pontos de Função tem sido utilizado com sucesso pela autora, além deste apoiar nas estimativas dos projetos, este também tem se mostrado bastante eficaz no suporte ao processo de engenharia de requisitos.

Referências

AGUIAR, M. Estimativas Confiáveis de Prazos para Gerentes de Projetos. Developer’s Magazine, Maio 1999, pp. 30-32.

AGARWAL, R. et al. Estimating Software Projects. ACM SIGSOFT, Software Engineering Notes vol 26 nº4, July 2001, pp.60-67.

BOEHM, B.W. Software Cost Estimation With COCOMO II. Prentice Hall, New Jersey, 2000.

DEKKERS, C. Measuring the “logical” or “functional” Size of Software Projects and Software Application. Spotlight Software, ISO Bulletin May 2003 pp10-13.

HAZAN C.; STAA, A. v. Análise e Melhoria de um Processo de Estimativas de Tamanho de Projetos de Software. Monografias em Ciências da Computação nº 04/05, Departamento de Informática PUC-Rio, ISSN 0103-9741, Fevereiro 2005.

IFPUG. Counting Practices Manual. Version 4.2.1, January, 2005.

JONES, C. Applied Software Measurement: Assuring Productivity and Quality. Prentice Hall, Second Edition, 1997.

JONES, C. Estimating Software Costs. McGraw-Hill, 1998.

MELI, R.; SANTILLO, L. Function Point Estimation Methods: A Comparative Overview. Proceedings of FESMA 99, Amsterdam, Netherlands, October 1999, pp. 271-286.

PRESSMAN, R. S. Engenharia de Software, 6ª edição, MC Graw Hill, São Paulo, 2006.

ROETZHEIM, W. Estimating and Managing Project Scope for New Development. Crosstalk –The Journal of Defense Software Engineering, April 2005, pp. 4 -7.