DOUTRINA

Como evitar armadilhas em Doutrina contratos de fbricas de software

Claudia Hazan
1 Introduo

A Tecnologia da Informao tem sido utilizada em vrios segmentos do mercado na automatizao de processos, visando o aumento da eficincia e eficcia dos processos organizacionais. Pode-se observar o aumento da demanda de desenvolvimento de novos sistemas e de manuteno dos sistemas existentes para que estes se adaptem s novas necessidades dos seus usurios. Nesse contexto, as reas de Tecnologia da Informao de muitas organizaes governamentais precisam contratar servios de desenvolvimento e manuteno de sistemas externamente para suprir a demanda das reas de negcios do rgo. Os principais tipos de contratos de prestao de servios de desenvolvimento ou manuteno de sistemas so os seguintes: Contrato por Preo Fechado, Contrato por homem-hora, Contrato baseado em Mtricas de Tamanho Funcional, descritos nos pargrafos seguintes. O Contrato por Preo Fechado consiste no contrato de um produto, por exemplo um Sistema de Recursos Humanos, com um preo definido para sua construo. Esse tipo de contrato pode ser prejudicial para a empresa contratada que precisa definir um preo para um sistema que est em fase inicial de especificao. Algumas vezes, as empresas que participam de uma licitao para este tipo contrato superestimam o do tamanho do projeto, fornecendo um preo elevado para o produto e gerando um nus enorme para o contratante, prejudicando a economicidade do contrato.
Claudia Hazan funcionria do Servio Federal de Processamento de Dados (SERPRO). Graduada em Informtica pela Universidade do Estado do Rio de Janeiro (UERJ), mestre em Engenharia de Sistemas e Computao/ Qualidade de Software pelo Instituto Militar de Engenharia (IME), especialista em Anlise de Pontos de Funo com Certificao CFPS desde 2001.

O Contrato por homem-hora foi bastante utilizado pelos rgos Pblicos. Nesse tipo de contrato, o pagamento realizado pela hora de trabalho do profissional contratado. Assim, o rgo Pblico estima uma quantidade de horas para o desenvolvimento ou manuteno de sistemas e as empresas que participam da licitao fornecem o
jan/ abr 2010 [ 47

DOUTRINA

preo da hora. Na verdade, trata-se de um contrato de terceirizao de mo de obra e no de Fbrica de software, trazendo muitos riscos gerenciais e trabalhistas da empresa contratada para o rgo Pblico contratante. Observe que se a empresa contratada alocar ao projeto de desenvolvimento de um Sistema de Recursos Humanos programadores improdutivos, que estejam aprendendo a linguagem de programao do sistema em questo, o nus do sistema no ficar pronto ser do contratante. Deve-se ressaltar que a Instruo Normativa IN04, associada ao processo de contratao de servios de Tecnologia da Informao pela Administrao Pblica Federal direta, autrquica e fundacional, publicada pela Secretaria de Logstica e Tecnologia da Informao (SLTI) do Ministrio do Planejamento Oramento e Gesto (MPOG) em 2008, preconiza a utilizao de mtricas em contratos de fbrica de software, e ainda destaca que a aferio de esforo por meio da mtrica homem-hora apenas poder ser utilizada mediante justificativa e sempre vinculada entrega de produtos de acordo com prazos e qualidade previamente definidos. O tipo de contrato de desenvolvimento e manuteno de sistemas baseado em mtricas de tamanho funcional tem sido utilizado por organizaes governamentais desde a dcada de 90. Nesse tipo de contratao, o pagamento da empresa contratada realizado por meio do dimensionamento do produto entregue, utilizando a mtrica estabelecida no contrato. As mtricas de tamanho mais utilizadas nos contratos so: Pontos por Casos de Uso, Pontos por Casos de Uso Ajustados, Pontos de Funo Ajustados e Pontos de Funo No Ajustados. A mtrica Pontos por Casos de Uso (PCU) foi proposta por Gustav Karner (1993) com o propsito de estimar recursos para projetos de software orientados a objeto, modelados por meio de especificao de Casos de Uso. A mtrica de fcil aplicao, no requer muito tempo de treinamento ou experincia prtica. No entanto, o PCU somente pode ser aplicado em projetos de software cuja especificao tenha sido documentada em casos de uso. Alm disso, como no existe um padro nico para a escrita de uma especificao de caso de uso, diferentes estilos na escrita do caso de uso ou na sua granularidade podem levar a resultados diferentes na
48 ] REVISTA DO TCU 117

medio por PCU. Assim, a mtrica se torna subjetiva, a empresa contratada pode modelar um sistema com muitos casos de uso para maximizar a contagem de PCU, onerando o custo do projeto para a organizao contratante. O Fator de Ajuste dessa mtrica tambm bastante subjetivo, no existindo critrios objetivos para a pontuao das caractersticas do projeto que impactam no Fator de Ajuste. Assim, a mtrica PCU no recomendada como unidade de medida para o estabelecimento de contratos de fbrica de software. A mtrica Pontos de Funo (PF) uma medida de tamanho funcional de projetos de software , considerando as funcionalidades implementadas, sob o ponto de vista do usurio. Tamanho funcional definido como tamanho do software derivado pela quantificao dos requisitos funcionais do usurio (Dekkers, 2003). A mtrica independente da metodologia e tecnologia utilizadas, levando em considerao a viso do usurio. O Fator de Ajuste da mtrica PF possui critrios objetivos de pontuao. No entanto, as caractersticas do projeto utilizadas na determinao do Fator de Ajuste, constituem requisitos no funcionais do projeto de software, alm disso a ISO/ IEC 20926 reconheceu Pontos de Funo No Ajustados como mtrica de tamanho funcional (Dekkers, 2003). Em 2009, foi publicada a verso 4.3 do Manual de Prticas de Contagem (CPM) considerando os Pontos de Funo No Ajustados como a mtrica padro do IFPUG (International Function Point Users Group) (2009). Portanto, a autora recomenda o uso da mtrica Pontos de Funo No Ajustados como unidade de medida nos contratos de fbrica de software. importante destacar que o Tribunal de Contas da Unio (TCU) tambm tem recomendado, por meio da publicao de Acrdos, a utilizao de Pontos de Funo No Ajustados em contratos. Devido ao cenrio apresentado acima, atualmente, a maioria dos rgos Pblicos est utilizando a mtrica de Pontos de Funo No Ajustados em seus Editais para contratao de Fbrica de software. Sem dvida, uma grande evoluo em relao dcada de 90, onde a maioria dos contratos era de terceirizao de mo de obra por meio de homemhora, e muitas vezes os custos dos sistemas eram muito altos em relao aos resultados obtidos. No entanto, mesmo estabelecendo contratos utilizando a mtrica Pontos de Funo No Ajustados,

DOUTRINA

ainda existem muitos problemas associados aos contratos de fbrica de software. Esse artigo tem como propsito recomendar o uso da mtrica de Pontos de Funo No Ajustados em contratos de software e apresentar dicas para as organizaes que desejam estabelecer contratos com Fbricas de Software externas evitar armadilhas no processo de contratao. Este trabalho encontra-se organizado da seguinte maneira: a Seo 1 descreve o cenrio de contratao de servios de fbrica de software e o objetivo deste artigo; a Seo 2 apresenta uma viso geral da Anlise de Pontos de Funo; a Seo 3 identifica os principais problemas e solues de contratos de software baseados na mtrica PF; Finalmente, a Seo 4 conclui o artigo.
2 Uma Viso Geral da Anlise de Pontos de Funo

A mtrica Pontos de Funo foi criada por Allan Albrecht (1979) visando minimizar as dificuldades associadas ao uso da mtrica Linhas de Cdigo (LOC) como unidade de medida de tamanho de software e suportar a previso do esforo de desenvolvimento do projeto de software (Albrecht, 2003). Em 1986, uma Pesquisa do Quality Assurance Institute mostrou que PF a melhor mtrica para o estabelecimento de medies de qualidade e produtividade de projetos de software (Perry, 1986). Em 1993, PF se tornou a mtrica mais utilizada e estudada na Engenharia de Software (Jones, 1994). Atualmente, a mtrica de PF continua sendo a mais utilizada na indstria de software, como mtrica padro na definio de indicadores, como insumo para derivao de estimativas de prazo, custo e esforo e no estabelecimento de contratos de software. Esta seo tem como propsito apresentar uma viso geral da contagem de Pontos de Funo, baseando-se nas regras de contagem do Counting Practices Manual (CPM) 4.3 (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009). Os principais objetivos da Anlise de Pontos de Funo so os seguintes: Medir a funcionalidade requisitada e recebida pelo usurio; Medir projetos de desenvolvimento e de manuteno evolutiva de software independentemente da tecnologia utilizada na implementao. A Contagem de Pontos de Funo No Ajustados consiste no mapeamento dos requisitos funcionais do projeto de software nos cinco tipos funcionais da Anlise de Pontos de Funo: Arquivo Lgico Interno (ALI), Arquivo de Interface Externa (AIE), Entrada Externa (EE), Consulta Externa (CE), Sada Externa (SE), conforme ilustrado na Figura 1. O Arquivo Lgico Interno um grupo lgico de dados, mantido dentro da fronteira da aplicao, por meio de um ou mais processos elementares. O Arquivo de Interface Externa um grupo lgico de
jan/ abr 2010 [ 49

DOUTRINA

dados, referenciado por um ou mais processos elementares da aplicao. Contudo, eles so mantidos dentro da fronteira de outra aplicao. Uma Entrada Externa um processo elementar que processa dados ou informao de controle que vem de fora da fronteira da aplicao. O objetivo principal de uma EE manter um ou mais ALIs ou alterar o comportamento da aplicao. Uma Sada Externa um processo elementar que envia dados ou informao de controle para fora da fronteira da aplicao. O objetivo principal de uma SE apresentar informaes para o usurio por meio de um processamento lgico que deve conter: clculos ou criar dados derivados ou manter ALIs ou alterar o comportamento da aplicao. Uma Consulta Externa um processo elementar que envia dados ou informao de controle para fora da fronteira da aplicao. O objetivo principal de uma CE apresentar informao para o usurio por meio apenas de uma recuperao de dados ou informao de controle de um ALI ou AIE.
Identificao das Funes Documentos de Requisitos

Viso Geral da Contagem de PF

Funo de Dados (Internos)

Contagem PF

Pontos de Funo no Ajustados

Funes Transacionais
Consulta Externa (CE)

Funo de Dados (Externos)

Aplicao
Entrdas Externas (EE) Arquivos Lgicos Internos (ALI) Arquivos de Interface Externa (AIE)

Sada Externa (SE)

Figura 1: Os Cinco Tipos Funcionais da Anlise de Pontos de Funo [Hazan, 2008]

Cada funo identificada possui uma complexidade associada: Simples, Mdia ou Complexa e uma contribuio para a contagem de Pontos de Funo No Ajustados, baseada na sua complexidade (Tabela 1). A determinao da complexidade e da contribuio funcional no subjetiva, sendo baseada nas regras de contagem do CPM (INTERNATIONAL FUNCTION POINT USERS GROUP, 2009).Tabela 1: Contribuio Funcional dos Tipos de Funo [IFPUG, 2009]
Tipo de Funo Arquivo Lgico Interno (ALI) Arquivo de Interface Externa (AIE) Entrada Externa (EE) Sada Externa (SE) Consulta Externa (CE) Simples
7 5 3 4 3

Mdia
10 7 4 5 4

Complexa

15 10 6 7 6

A utilizao do procedimento de contagem de Pontos de Funo, descrito no CPM [IFPUG, 2009], implica na existncia do projeto lgico da aplicao.
50 ] REVISTA DO TCU 117

DOUTRINA

Nas fases iniciais do processo de desenvolvimento de software, os Pontos de Funo no podem ser medidos e sim estimados. Sugere-se a utilizao do mtodo Contagem Estimativa de Pontos de Funo (CEPF) nas estimativas de tamanho dos projetos de software para o estabelecimento de contratos ou elaborao de Editais [Hazan, 2005a].
3 Problemas e Solues de Contratos de Fbricas de Software

enquanto ele est estimando o projeto, sem custo ou esforo adicional, conforme demonstrado por Hazan (2005a). Considerando as revises e auditorias em Contagem de Pontos de Funo dos projetos contratados, importante que o documento de requisitos e o documento de contagem de PF ou estimativas estejam consistentes.
3.2 Estabelea Regras para o Tratamento das Mudanas de Requisitos

De fato, a mtrica PF tem sido muito utilizada como unidade monetria (R$/PF) nos contratos de desenvolvimento e manuteno de sistemas pelas organizaes governamentais brasileiras. Este tipo de contrato permite o melhor balanceamento de riscos entre contratante e contratada (Aguiar, 2000), sendo recomendado pela Instruo Normativa - IN04 e pelos rgos de Controle do Governo Brasileiro. Esta seo tem como propsito apresentar algumas dicas para as organizaes contratantes evitarem armadilhas em contratos de fbrica de software baseados em preo fixo por PF.
3.1 Obtenha um Documento de Requisitos deQualidade

Conforme mencionado, a mtrica PF mede a funcionalidade requisitada e recebida pelo usurio. O documento de requisitos constitui um acordo comum entre as empresas contratantes e contratadas. Assim, fundamental a existncia de um Termo de Aceite associado aos documentos de requisitos, assinado pelo gestor do sistema ou gestor do contrato do rgo contratante. Alm disso, o contratante deve garantir a qualidade do documento de requisitos encaminhado para a fbrica de software contratada. Observe que se o contratante fornece um documento de requisitos com um requisito incompleto, a Fbrica entregar o produto sem a funcionalidade esperada e a organizao contratante ter que pagar por isso. A Engenharia de Requisitos apresenta vrias tcnicas para suportar as atividades de verificao e validao de Documentos de Requisitos, no entanto estas tcnicas so muito custosas. Sugere-se a utilizao do mtodo Contagem Estimativa de Pontos de Funo, alm de apoiar nas estimativas do projeto, o mtodo suporta a deteco de defeitos em documentos de requisitos pelo estimador,

A Engenharia de Requisitos e a indstria reconhecem que os requisitos no permanecem congelados at a concluso do projeto de software. Os requisitos evoluem desde a sua concepo at mesmo aps o sistema entrar em produo, devido a diversos fatores descritos por Kotonya (1998). Assim, fundamental que o contrato de software estabelea clusulas para tratamento das mudanas de requisitos. Este trabalho sugere o estabelecimento no contrato de um percentual para cada atividade do processo de software, por exemplo: requisitos: 20%, projeto e arquitetura: 10%, implementao: 50%, Testes: 15%, implantao: 5%. Estes percentuais so hipotticos, cada organizao deve definir estes valores com base no esforo consumido em cada atividade de seu processo de desenvolvimento de software. Alm disso, o gestor do projeto contratado deve acompanhar semanalmente o progresso de cada requisito funcional identificado no documento de requisitos do projeto de software. Assim, quando um requisito for modificado, deve-se identificar no Relatrio de Acompanhamento do projeto quais atividades do ciclo de vida foram realizadas para o requisito em questo. O prximo passo obter a contagem de Pontos de Funo do requisito original para aplicar o percentual das atividades do processo concludas para este requisito. Por exemplo, suponha uma mudana em um clculo no Relatrio de Empregados, identificado como uma Sada Externa Mdia 5 PF e que este requisito se encontre no fim da fase de requisitos. Ento, a contagem de PF do projeto para remunerao da empresa contratada deve considerar: o novo requisito modificado, SE Mdia 5 PF, e 20% do requisito original (1 PF), totalizando 6 PFs. Deve-se ressaltar que o gestor do contrato deve evitar encaminhar para a contratada os requisitos de negcio que estejam em fase de
jan/ abr 2010 [ 51

DOUTRINA

definio, seno podero emergir muitas mudanas em requisitos elevando o custo do projeto em questo. Recomenda-se a implantao de processos de gerenciamento de projetos e gerenciamento de requisitos pelos contratantes, aderentes s melhores prticas de modelos da Qualidade de Software , visando uma gesto efetiva dos projetos contratados.
3.3 Estabelea Clusulas de Garantia da Qualidade

Conforme mencionado, a mtrica PF considera a funcionalidade requisitada e recebida pelo usurio. Portanto, a remunerao da empresa contratada deve considerar as funcionalidades entregues, somente se estas no apresentam defeitos. Contudo, o seguinte cenrio pode ocorrer: a empresa contratada entrega as funcionalidades requisitadas com defeitos; o gestor do contrato reclama, a empresa contratada corrige os erros da funcionalidade em questo; a contratante recebe o sistema de volta com outros defeitos que surgiram com a correo do erro relatado. Esse tipo de problema comum em fbricas de software com um processo de testes inexistente ou inadequado. Observe que essa situao pode gerar um grande atraso no recebimento do sistema, podendo gerar atritos entre a rea de TI da empresa contratante e os gestores do sistema que esto aguardando a entrega do sistema funcionando. Assim, recomenda-se o estabelecimento de clusulas contratuais para garantir a entrega de um projeto de desenvolvimento ou manuteno de sistemas com qualidade. Sugere-se incluir no contrato uma clusula de multa associada qualidade do produto entregue, considerando o indicador defeitos/PF. Por exemplo, pode-se estabelecer que no aceitvel a entrega de mais de 0,3 defeitos/PF. importante definir no contrato os tipos de defeitos, a saber: bugs, defeitos na documentao, cdigo fonte no estruturado, etc. Pode-se estabelecer tambm nveis de severidade de defeitos.
3.4 Estabelea Clusulas Contratuais de Prazo e Taxa de Entrega

casos, a empresa contratante pede para a contratada relatar a taxa de produtividade. Esta prtica no adequada. A produtividade uma informao estratgica de uma empresa e ela no pode ser obrigada a divulgar estas informaes. Alm disso, deve-se ressaltar que em um contrato baseado em PF, o controle da produtividade da empresa contratada no faz sentido. De fato, as empresas contratantes empregam esta prtica para resolver o problema de demandas recebidas com atraso de cronograma. A soluo estabelecer no contrato o mtodo de estimativa de prazo a ser utilizado. Recomenda-se que este mtodo utilize o tamanho em PF estimado do sistema na derivao da estimativa de prazo. Alm disso, deve-se incluir clusulas de multa considerando o atraso da entrega do projeto. Para as organizaes que no possuem um processo de estimativas definido, sugere-se a utilizao da Frmula de Capers Jones (2007). Esta frmula simples de automatizar em uma planilha de clculo, consistindo em elevar o tamanho do projeto em PF a um expoente t, definido de acordo com o tipo do projeto a ser estimado. Hazan (2005b) apresenta dicas para identificar o expoente t. importante ressaltar que a frmula adequada apenas para projetos maiores que 100 PF. Em relao aos projetos pequenos, o contrato deve fixar prazos de acordo com o tamanho do projeto. Por exemplo, para projetos at 5 PF o prazo de entrega de 10 dias teis. Outro cenrio a ser considerado o seguinte: a empresa contratada ganha um prego fornecendo um preo muito baixo por PF e ao ganhar o contrato ela busca forar o aumento do preo do PF contratado, definindo regras prprias para a contagem de PF. Como os rgos pblicos esto se capacitando em contagem de Pontos de Funo, o gestor do contrato no aceita a contagem de PF majorada. Ento, a empresa contratada aloca apenas um recurso para atendimento daquele contrato, ressaltando que os demais recursos esto trabalhando em contratos mais lucrativos. E as demandas de manuteno crticas do contratante ficam pendentes no atendimento. Portanto, visando evitar este problema, importante definir clusulas contratuais estabelecendo uma taxa de entrega mnima de PF/ms, por exemplo, 200 PF/ms. Deve-se incluir uma clusula de multa tratando essa questo. O estabelecimento de uma taxa de entrega mensal mxima e mnima tambm

Algumas organizaes contratantes estabelecem clusulas contratuais associadas produtividade. Por exemplo, a fbrica de software contratada deve ter uma produtividade de 15 HH/PF em JAVA. Em alguns
52 ] REVISTA DO TCU 117

DOUTRINA

importante para a fbrica de software contratada dimensionar suas equipes para um melhor atendimento ao contrato.
3.5 Estabelea o CPM como a Base para as Contagens de PF ao invs de Converses

de software. As fbricas de software contratadas tambm devem ter seu escritrio de mtricas para revisar a contagem de PF da empresa contratante. Hazan (2008) apresenta os dez erros de contagem de Pontos de Funo mais observados.
3.6 Estabelecer Regras para Dimensionar

Algumas empresas contratantes estabelecem seus contratos com base na mtrica Pontos de Funo, no entanto no possuem capacitao adequada em contagem de Pontos de Funo. Em alguns casos, estas empresas delegam a contagem para a empresa contratada que estabelece roteiros de contagem com regras que podem majorar a contagem de PF. Algumas vezes, a dimensionamento do tamanho do projeto em PF realizado por meio de converses de horas alocadas em Pontos de Funo. Assim, estabelecido com a empresa contratada um ndice de converso, por exemplo, 8 horas de trabalho corresponde a 1 PF, e ento o pagamento da empresa contratada feito por meio das horas alocadas ao projeto em questo convertidas em PF. Observe que se o recurso de desenvolvimento est em uma fbrica de software externa a empresa contratante, esta no pode gerenciar a quantidade de horas alocada ao projeto. Se o analista da empresa contratada est realizando seu trabalho nas instalaes da contratante, isto um tipo de terceirizao de mo de obra. E ainda, se a contratada alocar um recurso com baixa produtividade, o custo do projeto ser muito alto. A prtica de converso de horas para PF simples, no entanto inadequada. Se o contrato baseado em Pontos de Funo, a empresa deve realizar as contagens seguindo as regras de contagem do manual CPM. Deve-se ressaltar que uma contagem de PF errnea pode levar a conseqncias desastrosas, tais como: pagamento incorreto do projeto contratado por PF, gerao de dados para indicadores de qualidade defeitos/PF e produtividade horas/PF incorretos, gerao de estimativas incorretas. fundamental que as organizaes que desejam estabelecer contratos de fbrica de software com base em Pontos de Funo criem seu Escritrio de Mtricas com profissionais especialistas em contagem de Pontos de Funo. recomendado que estes profissionais possuam Certificao CFPS ( Certified Function Point Specialist) e possuam experincia prtica em contagem de PF e mtodos de estimativas de projetos

Projetos de Manuteno

Muitas organizaes estabelecem em seus contratos de fbrica de software a prestao de servios de desenvolvimento e manuteno de sistemas com base na mtrica Pontos de Funo. No entanto, o manual de prticas de contagem (CPM) trata apenas os projetos de desenvolvimento e de manuteno evolutiva. Assim, torna-se importante a definio de mtricas para os demais projetos de manuteno. Pode-se contratar tais projetos em homem-hora, no entanto, conforme mencionado a IN 04 preconiza evitar a contratao de fbrica de software por meio da mtrica homem-hora. Assim, recomenda-se a utilizao de mtricas baseadas nas regras de contagem de Pontos de Funo para dimensionar os projetos de manuteno no contemplados no manual CPM. O primeiro passo a identificao de todos os tipos de projetos de manuteno que podem ser contratados pela organizao. Posteriormente, deve-se definir mtricas para dimensionar tais projetos. Sugere-se utilizar um percentual da contagem de Pontos de Funo das funcionalidades impactadas pelo projeto de manuteno em questo, conforme descrito a seguir: a) Manuteno Evolutiva: A manuteno evolutiva, tambm denominada de projeto de melhoria funcional ou simplesmente projeto de melhoria (enhancement), est associada s mudanas em requisitos funcionais da aplicao, ou seja, a incluso de novas funcionalidades, alterao ou excluso de funcionalidades em aplicaes implantadas. Segundo o padro IEEE Std 1229 [INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS COMPUTER SOCIETY, 1998], esta manuteno um tipo de manuteno adaptativa, definida como: modificao de um produto de software concludo aps a entrega para mant-lo
jan/ abr 2010 [ 53

DOUTRINA

funcionando adequadamente em um ambiente com mudanas. A contagem de Pontos de Funo desses projetos realizada segundo a frmula abaixo (INTERNATIONAL FUNCTION POINT USERS GROUP , 2009).
PF = PF INCLUIDO + PF ALTERADO + PF CONVERSO + PF EXCLUIDO

Onde:
PF INCLUDO PF ALTERADO PF EXCLUDO
= Pontos de Funo associados s novas funcionalidades que faro parte da aplicao. = Pontos de Funo associados s funcionalidades existentes na aplicao que sero alteradas no projeto de manuteno. = Pontos de Funo associados s funcionalidades existentes na aplicao que sero excludas no projeto de manuteno. converso de dados dos projetos de manuteno evolutiva (Enhancement). Exemplos de funes de converso incluem: migrao ou carga inicial de dados para popular as novas tabelas criadas e relatrios associados migrao de dados.

PF CONVERSO = Pontos de Funo associados s funcionalidades de

b) Manuteno Corretiva: A manuteno corretiva altera o software para correo de defeitos. Encontra-se nesta categoria, as demandas de correo de erros em funcionalidades em sistemas em produo. Quando o sistema em produo for desenvolvido pela contratada, a manuteno corretiva ser do tipo Garantia, no sendo cobrada do cliente. As clusulas de Garantia devem ser estabelecidas em contratos. Nestes casos, a aferio do tamanho em Pontos de Funo das funcionalidades corrigidas considera 60% a 80% do PF ALTERADO. Este percentual definido de acordo com a existncia de documentao atualizada do sistema em questo. Por exemplo, para um sistema com documentao desatualizada ou sem documentao, onde no solicitada a atualizao da documentao do projeto, utiliza-se a frmula abaixo:
PF = PF ALTERADO X 0,70

c) Verificao de Erros: So demandas referentes a um comportamento anormal ou indevido apontado pelo contratante em sistemas em produo. Neste caso, a fbrica de software contratada se mobilizar para encontrar a causa do problema. Se for constatado erro de sistema, a demanda ser atendida como manuteno corretiva. Entretanto, uma vez no constatado o problema ou o mesmo for decorrente de regras de negcio implementadas ou utilizao incorreta das funcionalidades, deve ser realizada a aferio do tamanho em PF das funcionalidades verificadas, considerando-se 25%, segundo a frmula abaixo.

54 ] REVISTA DO TCU 117

DOUTRINA

PF = PF NO AJUSTADO X 0,25

d) Manuteno Cosmtica Adaptao de Interface: So consideradas manutenes cosmticas as demandas associadas s alteraes de interface, por exemplo, fonte de letra, cores de telas, logotipos, mudana de botes na tela. Nestes casos, a aferio do tamanho em Pontos de Funo das funcionalidades corrigidas considera 10% do PF_ALTERADO. No ser contemplada a redocumentao das funcionalidades da aplicao impactadas pela manuteno nas demandas desta categoria.
PF = PF ALTERADO X 0,10

aplicao. Estes projetos so dimensionados seguindo a frmula de manuteno evolutiva do CPM, onde as funcionalidades de atualizao de dados ou gerao de relatrios so consideradas PF_INCLUDOS. De um modo geral, a atualizao de dados de sistemas em produo ser contada como Entrada Externa e a gerao de relatrios ou arquivos ser contada como Consulta Externa ou Sada Externa. Outros tipos de projetos de manuteno podem ser identificados nas organizaes e descritos nos contratos. Algumas organizaes contratam a documentao de sistemas legados, nesses casos, pode-se considerar 20% do tamanho do projeto em PF, caso seja requisitada apenas a documentao dos requisitos. Caso a demanda seja a gerao de artefatos de documentao de todas as fases do processo de desenvolvimento, deve-se considerar um percentual de 30% a 50%, dependendo dos artefatos a serem gerados.

e) Manuteno Adaptativa: So consideradas manutenes adaptativas as mudanas em requisitos no funcionais da aplicao. As demandas de manuteno adaptativa so dos seguintes tipos: Redesenvolvimento de projetos em outra plataforma, Atualizao de plataforma, Adequao de funcionalidades s mudanas de negcio. Freqentemente, o redesenvolvimento de um sistema em outra plataforma tratado como um novo projeto de desenvolvimento. No caso de atualizao de plataforma, por exemplo, realizar uma manuteno em um Portal para que este suporte mais um browser ou uma verso mais atual de um browser, deve-se estabelecer um ndice percentual redutor para a contagem de Pontos de Funo, considerando cada tipo de atualizao de plataforma. As mudanas em requisitos no funcionais podem ser diversas, por exemplo otimizao de algoritmos para melhora de performance, etc. Nesses casos, deve-se estabelecer em contrato o percentual para cada tipo de manuteno adaptativa. f) Apurao Especial: So funcionalidades executadas apenas uma vez para: corrigir problemas de dados incorretos na base dados das aplicaes ou atualizar dados em bases de dados de aplicaes; ou gerar um relatrio especfico ou arquivo para o usurio por meio de recuperao de informaes nas bases da

4 Concluso

De fato, a utilizao da mtrica Pontos de Funo No Ajustados como unidade de medida de tamanho funcional em contratos de prestao de servios de desenvolvimento e manuteno de sistemas uma excelente prtica. Alm da existncia de regras de contagem de Pontos de Funo bem definidas e publicadas no manual de prticas de contagem (CPM), pode-se ressaltar os seguintes benefcios na utilizao da mtrica, dentre outros: independncia da tecnologia e metodologia utilizadas, baseada na viso do usurio, facilidade de estimativa nas fases iniciais do ciclo de vida do software, a utilizao da mtrica como dado padro para a definio de indicadores da qualidade de software e apoio na avaliao dos benefcios de aquisio de pacotes de software (anlise make or buy). importante ressaltar que em um processo de contratao de fbrica de software , alm da estimativa de tamanho do projeto em Pontos de Funo, outros aspectos devem ser considerados, a saber: definio do processo de desenvolvimento

jan/ abr 2010 [ 55

DOUTRINA

a ser seguido pela contratada com detalhamento dos artefatos a serem entregues, cronograma do projeto, definio dos acordos de nvel de servio, definio com clareza do objeto a ser contratado, considerando os requisitos funcionais e os requisitos no funcionais do projeto. Observe que os requisitos no funcionais (performance, segurana, padro de interface...) no contam Pontos de Funo, no entanto impactam nas estimativas de esforo, custo e prazo do projeto. Este artigo apresentou os principais problemas observados em contratos de fbrica de software baseados em Pontos de Funo e sugestes de soluo para os mesmos. O principal problema observado a falta de maturidade das empresas na utilizao da mtrica PF levando s contagens de PF erradas e atritos entre contratantes e contratadas. Portanto, recomenda-se a criao de um Escritrio de Mtricas nas empresas contratantes e contratadas sob a coordenao de um consultor de mtricas com experincia terica e prtica, visando assegurar a qualidade das contagens de Pontos de Funo dos projetos contratados.
5 Referncias

DEKKERS, C. Measuring the logical or functional size of software projects and software application. ISO Bulletin, May, 2003, p. 10-13. Disponvel em: <http://www.bfpug.com.br/ Artigos/ISO-0926_Article.pdf>. Acesso em: 27 ago. 2010. HAZAN, C.; BERRY, D.M.; LEITE, J.S.P. possvel substituir processos de engenharia de requisitos por contagem de pontos de funo? In: INTERNATIONAL WORKSHOP ON REQUIREMENTS ENGINEERING (WER), 8th, 2005, Porto, Portugal. Anais [Porto: s.n., 2005?]. p. 197-208. Disponvel em: <http://wer.inf.puc-rio.br/WERpapers/artigos/artigos_ WER05/claudia_hazan.pdf>. Acesso em: 27 ago. 2010. [2005a]. HAZAN, C.; OLIVEIRA, E.A.; BLASCHEK, J.R. How to avoid traps in contracts for software factory based on function point metric. In: INTERNATIONAL SOFTWARE MEASUREMENT & ANALYSIS CONFERENCE, 3rd, 2008, Washington, USA. Track presentation abstracts. [Resumo] disponvel em: <http://www.ifpug.org/conferences/2008/ trackPresentationAbstracts.htm>. Acesso em: 27 ago. 2010. HAZAN C.; VON STAA, A. Anlise e melhoria de um processo de estimativas de tamanho de projetos de software. Monografias em Cincia da Computao, Rio de Janeiro, n. 4, 2005. (MCC 04/05). ISSN 0103-9741. [Resumo] disponvel em: <http://bib-di.inf.puc-rio.br/techreports/2005.htm>. Acesso em: 27 ago. 2010. [2005b]. INSTITUTE OF ELECTRICAL AND ELECTRONICS ENGINEERS COMPUTER SOCIETY (IEEE). IEEE standard for software maintenance. [New York], 1998. (IEEE Std 1219, 1998.). ISBN 0-7381-0336-5. INTERNATIONAL FUNCTION POINT USERS GROUP (IFPUG). Counting practices manual. Version 4.3. [Princeton, NJ], 2009. JONES,C. Estimating software costs: bringing realism to estimating. 2nd ed. New York: Mc Graw Hill, 2007. JONES, C. Function points. Computer, v. 27, n. 8, p. 66-67, Aug. 1994. KARNER, G. Resource estimation for objectory projects. 1993. Disponvel em: <http://www.bfpug.com.br/Artigos/ UCP/Karner%20-%20Resource%20Estimation%20for%20 Objectory%20Projects.doc>. Acesso em: 27 ago. 2010. KOTONYA, G.; SOMMERVILLE, I. Requirements engineering: processes and techniques. New York : J. Wiley, 1998. PERRY, W.E. The best measures for measuring data processing quality and productivity. Quality Assurance Institute Technical Report. 1986.

AGUIAR, M. Contratando o desenvolvimento com base em mtricas. In: PROJECT MANAGEMENT INSTITUTE, 2000, Rio de Janeiro. Reunio. Disponvel em: <http://www.bfpug. com.br/Artigos/PMI-RIO-27-11-2000.htm>. Acesso em: 27 ago. 2010. ALBRECHT, A. J. Measuring application development productivity. In: JOINT SHARE/GUIDE/IBM Application Development Symposium, 1979, California. Proceedings [S.l. : s.n., 1979?], p. 83-92. Disponvel em: <http://www.bfpug.com.br/Artigos/Albrecht/ MeasuringApplicationDevelopmentProductivity.pdf>. Acesso em: 27 ago. 2010. ALBRECHT, A.; GAFFNEY, J. Software function, source lines of code, and development effort prediction: a software science validation. IEEE Transactions on Software Engineering, Piscataway, NJ, USA, v. 9, n. 6, p. 639-648, 1983. Disponvel em: <http://www.computer.org/portal/ web/csdl/doi/10.1109/TSE.1983.235271>. Acesso em: 27 ago. 2010.

56 ] REVISTA DO TCU 117