Você está na página 1de 21

Medio de Pontos por Funo a Partir da Especificao

de Requisitos
Helena Cristina A. B. Tavares, Ana Elizabete S. Carvalho, Jaelson F. B. Castro
Serpro Empresa do Ministrio da Fazenda, Universidade Federal de Pernambuco
helena-sristina.tavares@serpro.gov.br, ana-elizabete.carvalho@serpro.gov.br, jbc@cin.ufpe.br

Abstract. Neste trabalho apresentaremos uma proposta para medio de Pontos por
Funo a partir da especificao de requisitos expressa em casos de uso, notao
UML (Unified Modeling Language). Com esta medio torna-se disponvel uma
mtrica confivel na fase de especificao de requisitos do processo de
desenvolvimento de software. Esta proposta visa enfatizar a importncia da
especificao de requisitos para o trabalho de medio de sistemas, minimizando o
esforo dos lderes de projeto, obtendo uma compreenso intuitiva do porte do
projeto em termos de Pontos por Funo de maneira simples e dinmica. Verifica-se
que caso de uso e pontos por funo podem ser usados juntos efetivamente para
alcanar sucesso no gerenciamento dos requisitos e do projeto.

Introduo

Com a globalizao da economia e maior competitividade no mercado, as empresas


tornam-se mais dependentes dos seus sistemas de informao. Construir esses sistemas
em tempo hbil para serem teis aos negcios e com qualidade adequada o desafio que
as organizaes que desenvolvem software esto enfrentando.
Como Empresa de Tecnologia da Informao, o SERPRO atua num mercado em
permanente ebulio, por isso iniciou um processo para identificao e implantao das
melhores prticas para elevar o estgio de maturidade do processo de desenvolvimento de
software.
Impulsionando este processo est a meta de atingir o nvel 2 de maturidade segundo o
modelo CMM (Capability Maturity Model) do SEI at o final de 2002, com a avaliao
prevista para novembro, conforme descrito em [2]. E, os trabalhos iniciais verificaram que
a falta de uma efetiva gerncia de requisitos era um dos principais problemas a serem
superados.
Dando incio estruturao interna de uma gerncia de requisitos, o SERPRO
participou do projeto Plataforma Tecnolgica em Engenharia de Requisitos - Estratgias
para o Aumento da Qualidade no Desenvolvimento de Sistemas [3], o qual teve como
objetivo estabelecer bases para o aumento da qualidade dos processos de produo de

Medio de Pontos por Funo a Partir de Especificao de Requisitos 279

software, por meio da cooperao entre universidades e empresas, com nfase na


utilizao da Engenharia de Requisitos. A plataforma foi extremamente importante para
um melhor conhecimento dos problemas enfrentados pelas organizaes que participaram
do projeto e da possibilidade da cooperao com as instituies de pesquisa para minorar
esses problemas [4].
Identificados os problemas, os processos descritos em [5] foram executados para a
implantao da Gerncia de Requisitos no SERPRO tendo em vista a melhoria do
processo preconizada para o Nvel 2 do CMM. Com a efetiva utilizao e nfase dada aos
requisitos durante a fase inicial do processo de desenvolvimento de software, vislumbrouse a oportunidade e a necessidade de extrair mtricas de tamanho de software a partir dos
requisitos descritos em casos de uso [6], o que serviria de subsdios para as demais reas
chaves de processo do CMM.
Concentrando esforos para descrever requisitos de software com caso de uso e
medindo os requisitos utilizando a mtrica Pontos por Funo, projetos podem ser melhor
gerenciados e controlados. O dimensionamento de projeto na fase de requisitos um
tpico que vem sendo bastante considerado quando o enfoque Qualidade do Processo de
Desenvolvimento de Sistemas. Com base no tamanho de um projeto, pode-se derivar uma
srie de indicadores gerenciais que proporcione uma postura pr-ativa dos gestores de
desenvolvimento sob diversos aspectos.
Nos idos de 1979, em busca de uma mtrica melhor, A. J. Albrecht (IBM) considerou a
utilizao dos aspectos externos visveis de um software para gerar uma nova mtrica,
conhecida como Pontos de Funo e que foi um dos primeiros mtodos a medir e prever o
desenvolvimento de software com alguma preciso [7].
Considerando esses tpicos, [6] props a medio de Pontos por Funo a partir da
especificao de requisitos baseada em casos de uso. Esta proposta visa antecipar o
trabalho de medio de sistemas minimizando o esforo dos lderes de projeto, obtendo
uma compreenso intuitiva do porte do projeto em termos de Pontos por Funo a partir
dos requisitos elicitados.
Na prxima Seo, so descritos trabalhos relacionados. Na Seo 3, faremos um
resumo da Mtrica Anlise de Pontos por Funo. Na Seo 4, apresentaremos uma
proposta de medio de Pontos por Funo a partir da descrio dos requisitos expressos
em notao UML e um estudo de caso para facilitar o entendimento da proposta. E,
finalmente, a Seo 5 composta das concluses e trabalhos futuros.

Trabalhos Relacionados

Recentemente, tem surgido grande nmero de extenses para o modelo de pontos por
funo. Vrios autores tm proposto mtricas para adaptar pontos de funo a software
orientado a objetos. Em [10] classes so tratadas como objeto, e servios fornecidos a
clientes como transaes, enquanto em [11] cada classe considerada como um arquivo
interno, e mensagens enviadas atravs da fronteira do sistema so tratadas como

280 WER 2002

transaes. Sneed [12] props pontos de objeto como medidas para estimar tamanho de
software OO. Pontos de objeto so derivados da estrutura de classes, de mensagens e de
processos ou casos de uso e ponderados pelos fatores de ajuste.
Vrios trabalhos esto sendo publicados mostrando a utilizao da mtrica Anlise de
Pontos por Funo na fase de Requisitos em projetos orientados a objetos. Entre eles,
destacam-se: Function Point Usage in Object Oriented Environments [13], Use Cases and
Function Points [14], Estimating Software Development Effort Based on Use CasesExperiences frorm Industry [23] e Function Point Measurement from Java Programs [24].
Toro relata a futura utilizao de mtrica de tamanho de Software a partir dos requisitos
utilizando a tcnica de Pontos de Caso de Uso na ferramenta descrita em [15],
confirmando assim a importncia da extrao das mtricas de tamanho de software a
partir dos requisitos.
Uma proposta inicial do IFPUG [16] trata classes como arquivos e mtodos como
transaes. Fetcke [17] define regras para mapear um modelo de casos de uso [18] para os
conceitos do manual de Prticas de contagem do IFPUG, mas nenhuma tentativa foi feita
para relacionar os resultados a outras mtricas, tais como, pontos de funo tradicionais,
linhas de cdigo ou esforo [19].
Nos ambientes de desenvolvimento de software, atualmente, temos uma enumervel
quantidade de mtodos de desenvolvimento, tecnologias, plataformas, configurao e
acesso centralizado/descentralizado. Indiferente a metodologias e ambientes, no entanto,
os pr-requisitos chave para o desenvolvimento de sistema de qualidade so entender,
documentar e priorizar os requisitos do sistema [1].
A mtrica de Anlise de Pontos por Funo mede o tamanho do software pela
quantificao de sua funcionalidade externa, baseada no projeto lgico ou a partir do
modelo de dados; abrange a funcionalidade especfica requerida pelo usurio. Essa
funcionalidade diz o que ser entregue ao usurio.
A abordagem de casos de uso captura requisitos da perspectivas de como o usurio
realmente utilizar o sistema ao invs da perspectivas das caractersticas que o sistema
deve incorporar. Isto significa que o mesmo documento pode ser utilizado para contar
Pontos por Funo (ou para medir o projeto). Uma vez que o mesmo documento
utilizado, ento assegurado um maior nvel de preciso. muito melhor comunicar
gerncia que um projeto teve um crescimento de 300 a 900 FPs que declarar que o
projeto teve muito crescimento.
Casos de uso esto se tornando um mtodo largamente utilizado para descrever os
requisitos aparentemente visveis de uma aplicao de software. Pontos por funo um
mtodo para medir software a partir de uma perspectiva de requisitos e casos de uso um
mtodo para desenvolver requisitos. Ambos, pontos por funo e casos de uso, tentam ser
independentes da tecnologia utilizada para implementar a soluo de software. Casos de
uso so utilizados para validar um design proposto e para garantir que est de acordo
com todos os requisitos. Novamente, um benefcio de um caso de uso tentar definir
requisitos bem no incio do ciclo de vida. Se casos de uso so definidos no incio e pontos
por funo so aplicados, ento as estimativas do projeto so muito mais precisas. Uma

Medio de Pontos por Funo a Partir de Especificao de Requisitos 281

vez que Pontos por Funo possuem grandes bases histricas, possvel comparar a
produtividade de utilizar mtodos de casos de uso com outros mtodos.
Ao saber o tamanho do projeto no incio do ciclo de vida, melhores estimativas de
tempo e custo podem ser desenvolvidas. Os casos de uso so mantidos atualizados, os
Pontos por Funo so mantidos atualizados, as estimativas do projeto podem ser
facilmente atualizadas e os desacordos explicados.
O aumento do foco nos requisitos resulta em um software de maior qualidade. Casos de
Uso e Pontos por Funo podem ser usados juntos efetivamente para alcanar sucesso no
gerenciamento dos requisitos e do projeto [8].
O principal aspecto deste trabalho a utilizao das informaes contidas nos casos de
uso para as regras de contagem de pontos por funo tradicionais, o que permitiu a
comparao de tamanho com os sistemas pontuados anteriormente que foram definidos a
partir da especificao estruturada.

Anlise de Pontos por Funo (APF)

De acordo com a tcnica Anlise de Pontos por Funo, uma aplicao de software, vista
sob a tica do usurio, um conjunto de funes ou atividades do negcio que o
beneficiam na realizao de suas tarefas [20]. O manual do IFPUG classifica os seguintes
tipos de elementos funcionais[21]:
1. Entrada Externa EI (External Input) transaes lgicas onde dados entram na
aplicao e mantm dados internos.
2. Sada Externa EO (External Output) transaes lgicas onde dados saem da
aplicao para fornecer informaes para usurios da aplicao.
3. Consulta Externa EQ (External Query) transaes lgicas onde uma entrada solicita
uma resposta da aplicao.
4. Arquivos Lgicos Internos ILF (Internal Logical File) grupo lgico de dados
mantido pela aplicao.
5. Arquivos de Interface Externa EIF (External Logical File) grupo lgico de dados
referenciado pela aplicao, mas mantido por outra aplicao.
O manual do IFPUG fornece tabelas e diretrizes para determinar a complexidade de cada
elemento funcional [7]. A complexidade dos ILF e EIF baseada nmero de registros
lgicos RET (Record Element Types) e no nmero de itens de dados referenciados
DETs (Data Element Types) e a complexidade das transaes baseada no nmero de
Arquivos Referenciados FTR (File Types Referenced) e no nmero de Itens de Dados
Referenciados DET (Data Element Type).
Os elementos funcionais identificados so totalizados para calcular obteno dos
Pontos por Funo no Ajustados. Ento calculado calculado a partir de 14 (quatorze)
caractersticas gerais dos projetos, que permitem uma avaliao geral da funcionalidade
da aplicao: Comunicao de Dados, Processamento Distribudo, Atualizao de Dados
Online, Entrada de Dados Online, Volume de Transaes, Eficincia do Usurio Final,

282 WER 2002

Complexidade do Processamento, Facilidade de Implantao, Multiplicidade de Locais,


Facilidade de Mudanas, Facilidade Operacional, Desempenho, Utilizao do
equipamento, Reutilizao de Cdigo. A cada caracterstica ser atribudo um peso de
0(zero) a 5(cinco), de acordo com o Nvel de Influncia na aplicao. O Nvel de
Influncia Geral obtido pelo somatrio do nvel de influncia de cada caracterstica e o
Fator de Ajuste obtido pela expresso:
Fator de ajuste = 0,65 + (Nvel de Influncia Geral * 0,01)

(1)

O total de Pontos por Funo da aplicao ser encontrado mediante a multiplicao do


nmero de Pontos por Funo no ajustados pelo Fator de Ajuste:
Pfs Ajustados = Pfs No-Ajustados * Fator De Ajuste

(2)

Maiores detalhes sobre a tcnica podem ser obtidos em [7].

4 Proposta de Medio de Pontos por Funo a partir da Descrio


de Requisitos expressos em Notao UML
A medio de software atravs de Pontos por Funo uma ferramenta muito til para a
gerncia. Observamos tambm que a especificaes de requisitos por meio de casos de
uso est sendo cada vez mais adotada e que se faz necessrio realizar medies de Pontos
por Funo a partir das descries dos requisitos expressos em notao UML para
antecipar e facilitar o trabalho de gerenciamento.
Neste artigo apresentaremos uma descrio resumida de uma proposta de medio
utilizando Anlise de Pontos por Funo a partir de um subconjunto da notao UML que
foi apresentada em detalhes em [6].
Esta proposta de medio ser discutida nas fases relacionadas a seguir:
Apresentar estudo de caso no intuito de facilitar o entendimento da proposta;(4.1)
Identificar e descrever os Diagramas de Casos de Uso da forma especificada nesta
proposta; (4.2)
Elaborar o Diagrama de Classe da aplicao a ser medida; (4.3)
Especificar a fronteira da aplicao; (4.4)
Identificar as Funes de Dados a partir do Diagrama de Classes e do Diagrama de
Casos de Uso; (4.5)
Identificar as Funes Transacionais a partir do Diagrama de Casos de Uso; (4.6)
4.1

Estudo de Caso

Para melhor entendimento das fases desta proposta, ser apresentada a experincia de
implantao da proposta de medio de Pontos por Funo a partir da especificao de
requisitos baseada em casos de uso em um sistema desenvolvido no SERPRO. O

Medio de Pontos por Funo a Partir de Especificao de Requisitos 283

SERPRO, Servio Federal de Processamento de Dados, uma empresa de informtica


vinculada ao Ministrio da Fazenda, cuja funo principal a execuo de servios de
tratamento de informaes e processamento de dados para o governo federal. A Empresa
est sediada em Braslia, com representaes regionais em 10 capitais (Belm, Belo
Horizonte, Curitiba, Fortaleza, Porto Alegre, Recife, Rio de Janeiro, Salvador, So Paulo
e a prpria capital federal) e um quadro de 8.774 funcionrios. A Empresa encontra-se
estruturada em Unidades de Gesto (UG) responsveis por um segmento da
Administrao Pblica. Cada segmento atende a pelo menos um rgo federal com
caractersticas e necessidades prprias), por intermdio de projees da UG em cada uma
das unidades organizacionais. A natureza diversa desses clientes e a descentralizao do
desenvolvimento em suas diversas representaes exigem do SERPRO a manuteno de
um complexo parque de desenvolvimento e o envolvimento direto com as mais diferentes
plataformas tecnolgicas. Neste cenrio, a adoo de prticas para padronizao,
organizao e controle do processo de software torna-se fundamental para a perfeita
integrao entre as unidades de negcio. Dentre as Superintendncias, a SUNAT
(Superintendncia de Negcios - Administrao Tributria) iniciou, em 1998, o processo
de implantao de um plano de medies definindo como mtrica a ser adotada a Anlise
de Pontos por Funo (APF). A proposta apresentada neste artigo est sendo
implementada em 120 projetos desenvolvidos por cerca de 700 desenvolvedores. O
Sistema Senha, que ser usado como exemplo, foi desenvolvido, primeiramente,
utilizando-se mtodos tradicionais, e, a medio deste projeto foi realizada com a mtrica
Anlise de Pontos por Funo. O total de Pontos por Funo encontrado foi 186,60.
Considerando a necessidade da Empresa de iniciar a migrao de suas aplicaes para um
novo ambiente e visando obter uma maior produtividade no desenvolvimento, casos de
uso passaram a ser utilizados para documentar requisitos. O Sistema Senha foi um dos
primeiros projetos a serem especificados com este paradigma e a ser aplicada a proposta
apresentada neste artigo. O resultado obtido nessa nova contagem foi 186,40 Pontos por
Funo o que implica numa diferena mnima de pontuao.
A prxima Seo relata, passo a passo, o processo de medio de algumas
funcionalidades do Sistema Senha que tem como objetivo fazer o controle de acesso dos
usurios s Aplicaes de uma empresa, onde ocorrem interaes entre o cadastrador, que
inicia a ao, e o processo de incluso de usurio. O Sistema Senha tem como finalidade
cadastrar os usurios, com as respectivas permisses de acesso s transaes do Sistema
Integrado de Informaes - SII, garantindo que apenas usurios habilitados possam
acess-las. O Sistema de Controle de Acesso SENHA controla, verifica e gerencia os
usurios, os perfis e os relacionamentos entre estes e as transaes; possibilita ao projeto
SII a segurana necessria e imprescindvel ao ambiente e s informaes; e est baseado
nos seguintes conceitos:
USURIO - Pessoa fsica cadastrada no Sistema Integrado de Informaes (SII) e
habilitada para acesso s informaes.
CADASTRADOR - Usurio do Sistema Senha que exerce as funes de incluso e
habilitao de outros cadastradores, usurios e perfis do SII.

284 WER 2002

TRANSAO - uma operao do sistema, que executa alguma ao (incluso,


alterao, excluso, consulta) sobre as informaes do banco de dados.
TRANSAO DE USO COMUM - Transao disponvel para qualquer usurio do
SII.
PERFIL - Conjunto de transaes que definem a abrangncia de atuao de um
cadastrador ou usurio.
Ser detalhada a descrio dos Casos de Uso, na Figura 1, apenas das funes de
Cadastrar Usurio, Validar Acesso e Emitir Relatrio de Usurio no intuito de melhor
explicar a proposta. Vale ressaltar que o detalhamento de todas as funes e a
contabilizao total de todo o Sistema de Controle de Acesso - Senha est disponvel em
[6].
Cadastrar Usurio

Pontos de extenso:
1. Interno
2. Externo
3. Outra UA
Sistema Pessoa
Fsica
<<estende>

(Interno)
[tipo UI]

<<estende>>

(Externo)
[tipo UE]

<<inclui>>

Validar Acesso

<<estende>>

(Outra UA)
[tipo OU]
Sistema Pessoa
Fsica

Emitir Relatrio

Usurio Interno

Usurio Externo

Usurio OutraUA

Cadastrador

Cadastrador

Sistema Pessoa
Fsica

CNPJ

Unidade
Administrativa

Setor

Fig. 1. Diagrama de Casos de Uso

De acordo com os requisitos, so identificados para cadastramento trs tipos de


usurios com caractersticas distintas: Interno, Externo e Outra UA (Unidade
Administrativa). No caso de usurio Externo deve ser informado se uma Pessoa Fsica
ou Jurdica (CNPJ). No caso de usurio de Outra UA (Unidade Administrativa) deve ser
informada a UA e o Setor. Outro requisito da aplicao se o usurio est autorizado a
acessar a aplicao. Dever ser emitida relao com os usurios cadastrados.
O diagrama de Caso de Uso da Figura 1 ser descrito conforme orientao dada na
seo a seguir.

Medio de Pontos por Funo a Partir de Especificao de Requisitos 285

4.2

Diagramas de Caso de Uso (Use Case)

O desenvolvimento de Diagramas de Caso de Uso requer que a equipe de


desenvolvimento de software dedique mais tempo nos estgios iniciais do plano de
desenvolvimento e garanta que os requisitos sejam completos, rastreados e bem
documentados.
Tabela 1. Descrio de Caso de Uso Cadastrar Usurio
Cadastrar Usurio Entrada Externa
Fluxo Principal de Eventos:
O Use Case inicia o sistema e exibe para o cadastrador a tela para cadastrar um usurio no Sistema
SENHA.
O cadastrador deve informar o CPF e a senha do cadastrador
Inclui Validar Acesso
O cadastrador deve informar o Tipo do Usurio
Ponto de extenso [Tipo UI] <interno>
Ponto de extenso [Tipo UE] <externo>
Ponto de extenso [Tipo UO] <Outra UA>
Fazer a opo na tela: finalizar o use case ou inicializar
Fluxo Excepcional de Eventos O cadastrador pode cancelar a transao em qualquer momento.
Cadastrar Usurio Interno Ponto de Extenso
Para incluso de Usurio Interno, <<ATUALIZAR>>:
CPF,
SEQUENCIAL,
DATA CRIAO,
DATA EXTINO,
DATA REGISTRO,
DISPONIBILIDADE,
DATA VALIDADE SENHA,
SENHA ATUAL,
TENTATIVAS INVLIDAS,
ATIVO,
TIPO.
Atravs da interao com o ator PESSOA FSICA, que o Sistema Cadastro de Pessoa Fsica, obteremos
o nome do usurio.
Fluxo Excepcional de Eventos No Sistema Pessoa Fsica o CPF do usurio no vlido, o USE CASE
informa e reinicia no permitindo a incluso do usurio.
Fluxo Excepcional de Eventos O cadastrador pode cancelar a transao em qualquer momento.

Aplicar Pontos por Funo aumenta a qualidade do caso de uso. A aplicao da APF
ajuda a determinar se o caso de uso est num nvel de detalhe apropriado. Isto , se
capaz de descrever como dados so passados do ator para dentro da fronteira ou como
dados fluem de dentro da fronteira da aplicao para o ator, ento est num nvel
adequado de detalhe. Por outro lado, se no possvel descrever este nvel de
funcionalidade, ento o caso de uso necessita de mais detalhes. A idia bsica que se
possvel contar Pontos por Funo, o caso de uso est num nvel de detalhe apropriado.
Depende de quo grande o seu caso de uso bom estabelecer um limite superior de
tamanho de seu caso de uso de forma que seu tamanho seja controlado. Normalmente, o

286 WER 2002

tamanho mximo de um caso de uso no deveria ser maior que 50 Pontos por Funo.
Uma vez que um caso de uso torna-se muito grande, torna-se difcil de ser entendido.
Sugerem-se os seguintes passos para se descrever Casos de Uso de sistemas:
Na descrio do Use Case deve-se definir claramente as informaes que podero ser
atualizadas, utilizando para isso a expresso <<ATUALIZAR>>. Deve-se utilizar a
expresso supracitada quando pudermos identificar que se trata de uma Entrada
Externa (EI) com base nas regras do [7].
Na descrio do Use Case deve-se definir, tambm, as consultas que sero realizadas
utilizando a expresso <<CONSULTAR>> especificando-se quais os parmetros de
entrada e as sadas que devem ser exibidas. Deve-se utilizar a expresso supracitada
quando pudermos identificar que se trata de uma Consulta Externa (EQ) com base nas
regras do [7].
Na descrio do Use Case deve-se definir quais as informaes que sero apresentadas
utilizando a expresso <<SADAS>>. Deve-se utilizar a expresso supracitada quando
pudermos identificar que se trata de uma Sada Externa (EO) com base nas regras do
[7].
Descrever, tambm, as informaes que sero fornecidas pelo Use Case, que so
consideradas como Tipo de Elemento de Dado (DET) com base nas regras do [7]. Por
exemplo, uma informao de total que no seja armazenada.
Tabela 2. Descrio de Caso de Uso Emitir Relatrio
Emitir Relatrio Sada Externa (EO)
Fluxo Principal de Eventos: O Use Case iniciado quando o cadastrador solicita a emisso da Relao de
Usurios. Sero exibidas as seguintes <<SADAS>>:
CPF,
NOME CPF,
DATA CRIAO,
DATA EXTINO,
DATA REGISTRO,
DISPONIBILIDADE,
ATIVO,
TIPO,
CNPJ,
NOME CNPJ,
UNIDADE ADMINISTRATIVA EXERCCIO,
SETOR EXERCCIO,
DESCRIO SETOR EXERCCIO,
UNIDADE ADMINISTRATIVA LOTAO,
DESCRIO UNIDADE ADMINISTRATIVA LOTAO.
Fluxo Excepcional de Eventos O cadastrador pode cancelar a opo de incluir transao em qualquer
momento.

Na Tabela 1, na Tabela 2 e na Tabela 3 so apresentadas as descries dos diagramas


de use case Cadastrar Usurio, Validar Usurio e Emitir Relatrio respectivamente.
O importante neste ponto quantificar o tamanho destes requisitos esboados usando
unidades de tamanho de software objetivos tais como Pontos por Funo. Quantificar o

Medio de Pontos por Funo a Partir de Especificao de Requisitos 287

tamanho dos requisitos do usurio crtico para o gerenciamento e controle do projeto,


como visto anteriormente.
Tabela 3. Descrio de Caso de Uso Validar Acesso
Validar Acesso - Consulta Externa ( EQ)
Fluxo Principal de Eventos:
O Use Case iniciado pelo cadastrador e ser usado para <<CONSULTAR>> se o cadastrador est
autorizado a acessar a aplicao.
Para esta validao o usurio dever informar o CPF e a Senha. Caso sejam satisfeitas estas condies, o
Senha liberar aos usurios, as transaes vinculadas aos perfis a ele associado na unidade em questo.
Fluxo Excepcional de Eventos O cadastrador pode cancelar a opo de incluir transao em qualquer
momento pressionando o BOTO CANCELAR, isto reinicializar o USE CASE.
Fluxo Excepcional de Eventos Caso o cadastrador no esteja autorizado a acessar esta transao especfica,
no ser permitido o acesso para execuo desta transao.

4.3

Diagrama de Classes

A partir das informaes obtidas durante a elicitao e documentao de requisitos


utilizando casos de uso, esta proposta sugere que seja elaborada uma verso inicial do
diagrama de classes de forma a melhor visualizar as informaes de funes de dados
para a contagem. O Diagrama de Classes deve ser elaborado de acordo com a UML.
Como visto no incio deste artigo, estaremos utilizando um subconjunto da notao UML,
ou seja, estaremos tratando no Diagrama de Classes dos relacionamentos: associao,
agregao/composio e herana.
Vale ressaltar que na nossa Empresa temos todo o modelo de dados mapeado, ou seja,
no incio de qualquer especificao de requisitos de um projeto j temos o Diagrama de
Classes. Caso no houvesse o Diagrama de Classes no momento da especificao dos
requisitos poderamos mapear as funes de dados da mtrica Pontos por Funo a partir
dos casos de uso. Na Figura 2, apresentamos o Diagrama de Classes do Sistema Senha
que de acordo com os requisitos, so identificadas trs classes principais: Usurio, Perfil
e Transao. Como podem existir trs tipos de usurios, com caractersticas distintas,
estes esto definidos num relacionamento de herana. Como as associaes Usurio-Perfil
e Perfil-Transao possuem propriedades prprias, so definidas as classes associao
Perfil-Usurio e Transao-Perfil. Algumas classes relacionam-se a classes de outros
sistemas: a superclasse Usurio com a classe Pessoa Fsica (independente do tipo de
usurio) e, para os tipos especficos, a classe Usurio Externo relaciona-se classe
Estabelecimento, e a classe Usurio OutraUA, s classes Unidade Administrativa e Setor.
A classe transao est associada classe Aplicao a qual pertence a outro sistema.

288 WER 2002

4.4

Conceitos de Fronteiras

O ponto de vista do usurio essencial em Anlise de Pontos por Funo para determinar
quais partes da aplicao contribuem para a funcionalidade fornecida. O conceito de
fronteira de contagem a abstrao de alto nvel de uma aplicao que determina o que
ser medido. Antes que qualquer medio se inicie, o objeto do processo de medio deve
ser especificado.
Pessoa Fsica
CPF : Number
Nome : String

Usuario
CPF : Number
Seqencial : Number
Data Criao : Date
Data Extino : Date
Data Registro : Date
Data Validade Senha : Date
Disponibilidade : String
Senha Atual : Number
Ativo : String

Bloqueia( )
Desbloqueia( )
Atualiza Senha( )
Valida Acesso( )
Consulta( )
Emite Relatrio( )

vinculado

vincula

Aplicao
Cdigo : String
Nome : String

vinculado
*

Perfil Usuario
Data Inicio : Date
Data Registro : Date
Data Fim : Date

Perfil
Cdigo : Number
Nome : String
Data Criao : Date
Data Extino : Date
Data Registro : Date composto enquadra
Inclui( )
Atualiza( )
Desativa( )
Ativa( )
Consulta( )
Emite Relatrio( )

Inclui( )
Atualiza( )
Desativa( )
Reativa( )

Usuario Local
Inclui( )
Atualiza( )

Usuario Externo
CNPJ : Number
Inclui( )
Atualiza( )

participa

Transao Perfil
Data Incio : Date
Data Fim : Date
Data Registro : Date

Transao
Cdigo : String
Descrio : String
Data Criao : Date
Data Extino : Date
Data Registro : Date
Disponibilidade : String
Nvel Acesso : String
Tipo : String
Inclui( )
Atualiza( )
Consulta( )
Ativa( )
Desativa( )
Emite Relatrio( )

Inclui( )
Atualiza( )
Desativa( )
Reativa( )

Usuario OutraUA
Unidade Administrativa Exerccio :
Number
Setor Exerccio : Number
Unidade Administrativa Lotao : Number
Inclui( )

Estabelecimento
CGC : Number
Nome : String

Unidade Administrativa
UA : Number
Descrio : String

Setor
UA : Number
Setor : Number
Descrio : String

Fig. 2. Diagrama de Classes

A fronteira de contagem de Pontos por Funo indica a fronteira entre a aplicao


medida e as aplicaes externas ou o domnio do usurio e sempre dependente do
propsito e do ponto de vista da contagem.
Uma vez que o conceito de atores corresponder a usurios ou aplicaes externas em
Anlise de Pontos por Funo, cada tipo de usurio da aplicao ser um ator.
Similarmente, toda aplicao que se comunica com a aplicao considerada tambm deve
aparecer como um ator. Desta forma, o conjunto de atores nos fornece uma viso
completa dos usurios e das aplicaes externas.

Medio de Pontos por Funo a Partir de Especificao de Requisitos 289

As regras seguintes foram formuladas para garantir um mapeamento consistente e


coerente entre o diagrama Use Case e os procedimentos de medio de Pontos por
Funo. Regras propostas para Fronteiras:
I. Considere cada ator humano como um usurio do sistema
II. Considere cada ator no-humano, o qual no um sistema desenvolvido apenas
para fornecer funcionalidades para o sistema medido, como uma aplicao
externa.
A documentao requerida para este passo o diagrama de Casos de Uso exibindo
atores e Casos de Uso em um alto nvel.
Aps a identificao da fronteira da aplicao, a elaborao do diagrama de classe e
diagrama de Caso de Uso devidamente descrito poderemos, ento, iniciar o processo de
medio.
A contagem de Pontos por Funo poder mostrar, atravs dos questionamentos
necessrios ao mapeamento para identificao das funes de dados e funes
transacionais, se existe falta de clareza nos requisitos, porque Pontos por Funo vincula
os dados armazenados (objetos) a sua manipulao e uso dentro das funes do software.
4.5

Identificar as Funes de Dados

Um passo fundamental da medio de Pontos por Funo a identificao das funes de


dados: os Arquivos Lgicos Internos (ILFs) e Arquivos de Interface Externa (EIFs). Cada
funo de dado deve ser classificada de acordo com sua complexidade funcional relativa,
que baseada no nmero de registros lgicos, Tipo de Elemento de Registro (RET), e no
nmero de itens de dados referenciados, Tipos de Elementos de Dados (DETs).
Tabela 4. Arquivos Lgicos Internos e Arquivos de Interface Externa
ILFs
USUARIO
PERFIL
TRANSACAO
PERFIL POR USUARIO
TRANSACAO POR PERFIL
Total Arquivos Lgicos Internos (ILFs) = 5

EIFs
PESSOA FISICA
ESTABELECIMENTO
SETOR UA
APLICAAO
UNIDADE ADMINISTRATIVA
Total Arquivos de Interface Externa (EIFs) = 5

Como estamos utilizando uma prvia do diagrama de classe e o diagrama de Casos de


Uso nas fases iniciais do desenvolvimento, eles sero a principal fonte de informao para
identificao dos Arquivos Lgicos Internos (ILFs), Arquivos de Interface Externa (EIFs),
Tipos de Elementos de Dados (DETs) e Tipo de Elemento de Registro (RETs).
Regras de mapeamento proposta para classes:
III. Selecione toda classe como um arquivo lgico. As excees so aquelas que
fazem parte de um relacionamento de agregao/composio.
IV. Atributos de classes so candidatos a Tipos de Elementos de Dados (DETs) para
arquivos e para a transaes pelas quais so lidos e/ou mantidos.

290 WER 2002

V. Candidatos para Tipos de Elementos de Registros (RETs) so determinados


pelos subgrupos dos arquivos e pelas regras de relacionamento de associao,
agregao/composio e de herana.
Tabela 5. Grupos de elementos de dados
ILF ou EIF (Classes)
USUARIO
PERFIL
TRANSACAO
PERFIL POR USUARIO
TRANSACAO POR PERFIL
PESSOA FISICA
ESTABELECIMENTO
SETOR UA
APLICAAO
UNIDADE ADMINISTRATIVA

RETs
USUARIO+USUARIOiNTERNO
USUARIO+USUARIO EXTERNO
USUARIO+USUARIO OUTROS
PERFIL
TRANSACAO
PERFIL POR USUARIO
TRANSACAO POR PERFIL
PESSOA FISICA
ESTABELECIMENTO
SETOR UA
APLICAAO
UNIDADE ADMINISTRATIVA

Na figura 2 foi apresentado o Diagrama de classe do Sistema SENHA que tem como
objetivo o controle de acesso aos aplicativos da empresa. Conforme a regra III as classes
Usurio, Transao, Perfil, Perfil Usurio, Transao Perfil, Aplicao, Pessoa Fsica,
Estabelecimanto, Unidade Administrativa e Setor so candidatas a arquivos lgicos. A
partir dos arquivos lgicos identificados, poderemos usar as regras de contagem do [7],
para identificamos os Arquivos Lgicos Internos (ILFs) e Arquivos de Interface Externa
(EIFs) do Sistema SENHA, como apresentado na Tabela 4.
Tabela 6. Tipos de elementos de dados
USUARIO
Atributos da classe
CPF
SEQUENCIAL
DATA CRIAO
DATA EXTINO
DATA REGISTRO
DISPONIBILIDADE
DATA VALIDADE SENHA
SENHA ATUAL
TENTATIVAS INVALIDAS
ATIVO
TIPO
CNPJ
UNIDADE ADMINISTRATIVA EXERCCIO
SETOR EXERCCIO
UNIDADE ADMINISTRATIVA LOTAO
Total Tipos de Elementos de Dados (DETs) = 14

Medio de Pontos por Funo a Partir de Especificao de Requisitos 291

De posse dos Arquivos Lgicos Internos (ILFs) e Arquivos de Interface Externa (EIFs)
necessrio determinar suas complexidades onde precisaremos identificar os Tipos de
Elementos de Registros (RETs) e os Tipos de Elementos de Dados (DETs):
Contagem de Tipos de Elementos de Registros (RETs):
Baseados nas regras de contagem do IFPUG, identificamos no diagrama de classe da
figura 2 os RETs (grupos de elementos de dados reconhecidos pelo usurio) do Sistema
SENHA, conforme mostrado na Tabela 5.
Contagem de Tipos de Elementos de Dados (DETs) (Data Element Types):
Baseados nas regras de contagem do IFPUG, identificamos os DETs (Tipos de
elementos de dados) reconhecidos pelo cliente da classe Usurio do Sistema SENHA
conforme mostrado na Tabela 6.
Adicionalmente ser necessrio identificar como um diagrama de classes que possua
relacionamentos de associao, agregao, composio e herana poder ser mapeado
para as funes de dados: Arquivos Lgicos Internos (ILFs) e Arquivos de Interface
Externa (EIFs) e seus Tipos de Elementos de Registros (RETs) e os Tipos de Elementos
de Dados (DETs). Maiores detalhes podem ser obtidos em [6].
Associao. Regras de mapeamento proposta para relacionamentos de associao:
VI. Selecione a classe associao como um arquivo lgico, considerando, para a
contagem dos Tipos de Elementos de Dados (DETs), os atributos da classe
associao e os atributos que so chaves primrias das classes associadas.
VII. selecione as classes associadas como arquivos lgicos.
A classe Transao-Perfil uma classe associao. Esta ser contabilizada como um
Arquivo Lgico Interno (ILF), considerando como Tipos de Elementos de Dados (DETs)
os atributos Data-Incio, Data-Fim e Data-Registro, Cdigo-Perfil (chave da classe
associada Perfil), Cdigo-Transao (chave da classe associada Transao).
Agregao. Regras de mapeamento propostas para relacionamentos de
agregao/composio:
VIII. Uma classe que agregada a outra classe, uma candidata a um Tipo de Elemento
de Registro (RET) para o arquivo relacionado classe agregada e no a um
Arquivo Lgico Interno.
Herana. Regras de mapeamento proposta para relacionamentos de herana:
IX. Uma classe abstrata no uma candidata a um arquivo lgico. uma candidata a
um Tipo de Elemento de Registro (RET) em cada classe que herda suas
propriedades.
X. Subclasses de uma classe concreta so candidatas a arquivos lgicos ou a um
Tipo de Elemento de Registro (RET) daquela classe. Se as subclasses no so
contadas como arquivos lgicos, so subgrupos opcionais do arquivo relacionado
superclasse.
A classe Usurio considerada como Arquivo Lgico Interno (ILF) e as subclasses
Usurio Local, Usurio Externo e Usurio Outra UA como RETs da classe Usurio, pois
estas so subgrupos opcionais da classe Usurio.
Candidatos adicionais a arquivos. Alguns dados que so considerados por conveno
do Pontos por Funo, como arquivos internos/externos podem no ser representados em

292 WER 2002

um diagrama de classes, embora aquela funcionalidade seja requerida pelo usurio.


Mensagens de erro ou textos de help, por exemplo, podem ser um requisito e necessitam
de uma representao de acordo com as regras de Pontos por Funo. Estas informaes
entretanto no so modeladas normalmente como classes, mas so contempladas nos
diagramas de Casos de Uso.
XI. Se Casos de Uso fizer uso implcito de arquivos lgicos que no so
representados no diagrama de classes estes arquivos devem ser includos no
conjunto de arquivos.
As documentaes requeridas para este passo so as descries do Diagrama de Casos de
Uso e o Diagrama de Classes.
4.6

Identificar as Funes Transacionais

Uma das etapas na contagem de Pontos por Funo a identificao das funes
transacionais, que podem ser de trs tipos: Entrada Externa (EI), Sada Externa (EO) ou
Consulta Externa (EQ). Nesta seo, ser investigado como, a partir da documentao
inicial, as funes transacionais so identificadas.
Os Diagramas de Casos de Uso da UML correspondem a transaes na tcnica Anlise
de Pontos por Funo. Portanto, um conjunto de Casos de Uso sero os principais
candidatos a funes transacionais. Um Caso de Uso pode ser contado como uma ou mais
transaes, dependendo das tarefas que desenvolve.
Ser possvel escolher as candidatas a transao a partir do Diagrama de Casos de Uso
que se comunicam diretamente com usurios ou aplicaes externas.
Proposta para mapeamento de Funes Transacionais:
XII. Selecione todo Caso de Uso que possui uma relao direta com um ator. Este
Caso de Uso ser um candidato a uma ou vrias transaes.
XIII. Selecione todo Caso de Uso que estende um Caso de Uso selecionado acima
como um candidato. A extenso pode incluir interao com um usurio ou uma
aplicao externa.
XIV. Cada classe mantida e/ou lida por um Caso de Uso conta como um Tipo de
Arquivo referenciado (FTR) para a transao associada, se e somente se, a classe
foi identificada como um arquivo.
Deve-se notar que as direes das setas no modelo de Casos de Uso no indica o tipo de
transao.
A documentao requerida para este passo o diagrama de Casos de Uso exibindo
atores e Casos de Uso de alto nvel. Alm disso, a fronteira da aplicao identificada,
necessria como entrada.
Identificaremos os Entradas Externas (EIs), Consultas Externas (EQs) e Sadas
Externas (EOs) a partir dos Diagramas de Casos de Uso e suas descries levando-se em
considerao as regras XII, XIII e XIV e as regras de contagem de Pontos por Funo do
IFPUG. Vale salientar que na descrio dos Diagramas de Casos deUso deve-se ressaltar
a opo de atualizar com a expresso <<ATUALIZA>>, a opo de consultar com a

Medio de Pontos por Funo a Partir de Especificao de Requisitos 293

expresso <<CONSULTA>> e a opo de exibir informaes com a expresso


<<SAIDAS>>.
Definio da complexidade das Entradas Externas (EIs), Consultas Externas (EQs) e
Sadas Externas (EOs)
A complexidade das funes transacionais baseada na determinao de Tipos de
Elementos de Dados (DETs) e Tipos de Arquivos Referenciados (FTRs). Esta informao
deve ser extrada da documentao detalhada dos Diagramas de Casos de Uso e do
Diagrama de Classes.
4.6.1
Contagem de FTRs (File Types Referenced) para Entradas Externas (EIs)
Cada Entrada Externa deve ser classificada de acordo com sua complexidade funcional
relativa, que baseada no nmero de arquivos referenciados (FTRs) e no nmero de Itens
de dados referenciados (DETs).
Tabela 7. Nmero de arquivos referenciados das EIs
Entradas
Externas (EI)
Cadastra
Usurio

ILF apenas
mantido
Usurio

ILF ou EIF apenas


referenciado
Pessoa Fsica
Estabelecimento
Setor UA
Unidade- Administrativa

ILF mantido ou
referenciado

Total
5

O nmero de arquivos referenciados o somatrio do nmero de Arquivos Lgicos


Internos e de arquivos de Interface Externa atualizados ou consultados na Entrada
Externa, conforme apresentado na Tabela 7, o exemplo relativo ao diagrama de Casos de
Uso descrito na Figura 1.
Tabela 8. Contagem dos DETs das EIs
Cadastra Usurio
CPF
SEQUENCIAL
DATA CRIACAO
DATA EXTINCAO
DATA REGISTRO
DISPONIBILIDADE
DATA VALIDADE SENHA
SENHA ATUAL
ATIVO
TIPO
CNPJ
UNIDADE ADMINISTRATIVA EXERCCIO
SETOR EXERCCIO
UNIDADE ADMINISTRATIVA LOTAO
Total = 14

294 WER 2002

Contagem de Tipos de Elementos de Dados (DETs) para Entradas Externas (EIs):


O nmero de itens de dados referenciados o total de campos identificados pelo
usurio que so atualizados em um Arquivo Lgico Interno por uma Entrada Externa.
Para contagem dos Tipos de Elementos de Dados (DETs), iremos considerar as
informaes do diagrama de classes da Figura 2 e a descrio do use case da Tabela 1,
conforme mostrado na Tabela 8.
De acordo com o nmero de itens de dados (DETs) e de arquivos referenciados
(FTRs), classificam-se as Entradas Externas em simples, mdias ou complexas.
Para o exemplo acima teremos 5 Tipos de Arquivos Referenciados (FTRs) e 16 Tipos
de Elementos de Dados (DETs), onde 14 foram obtidos a partir dos Tipos de Arquivos
Referenciados (FTRs) e 2 so decorrentes de Itens de dados adicionais( teclas de funo e
mensagens de erro) o que implica em uma complexidade ALTA, ou seja, corresponde a 6
Pontos por Funo para a Entrada Externa Cadastra Usurio.
4.6.2
Contagem de FTRs para Sadas Externas (EOs)
Cada Sada Externa deve ser classificada de acordo com sua complexidade funcional
relativa, que baseada no nmero de arquivos referenciados e no nmero de itens de
dados referenciados.
Tabela 9. Contagem dos DETs das EOs
EO
relatorio_usuario
CPF
NOME
SEQUENCIAL
DATA CRIACAO
DATA EXTINCAO
DATA REGISTRO
TIPO
DISPONIBILIDADE
VALIDADE SENHA
SENHA ATUAL
CNPJ
NOME
UNIDADE ADMINISTRATIVA EXERCCIO
SETOR EXERCCIO
UNIDADE ADMINISTRATIVA LOTAO
Total = 7

O nmero de arquivos referenciados o somatrio do nmero de Arquivos Lgicos


Internos e de Arquivos de Interface Externa consultados pela Sada Externa, conforme
apresentado na Tabela 10, o exemplo relativo ao diagrama descrito na Figura 1.
Contagem de Tipos de Elementos de Dados (DETs) para Sadas Externas (EOs):
O nmero de itens de dados referenciados o total de campos identificados pelo
usurio que aparecem na Sada Externa.

Medio de Pontos por Funo a Partir de Especificao de Requisitos 295

Para contagem dos Tipos de Elementos de Dados (DETs) de Sadas Externas (EOs),
iremos considerar as informaes do diagrama de classes da Figura 2, e a descrio do
use case da Tabela 2, conforme mostrado na Tabela 9.
De acordo com o nmero de itens de dados (DETs) e de arquivos referenciados
(FTRs), classificam-se as Sadas Externas em simples, mdias ou complexas.
Tabela 10. Nmero de arquivos referenciados das EOs
Sada
Externas (EI)
Relatrio
Usurio

ILF apenas
mantido

ILF ou EIF apenas referenciado


Usurio

ILF mantido ou
referenciado
Pessoa Fsica
Estabelecimento

Total
3

Para o exemplo acima teremos 3 Tipos de Arquivos referenciados (FTRs) e 7 Tipos de


Elementos de Dados (DETs) o que implica em uma complexidade MDIA, ou seja,
corresponde a 5 Pontos por Funo para a Sada Externa Emite Relatrio de Usurio.
4.6.3
Contagem de FTRs (File Types Referenced) para Consultas Externas (EQs)
Cada Consulta Externa deve ser classificada de acordo com sua complexidade funcional
relativa, que baseada no nmero de arquivos referenciados e no nmero de itens de
dados referenciados.
Tabela 11. Contagem de FTRs
Consulta Externa (EI)
Valida Acesso

ILF ou EIF apenas referenciado


Usurio

Total
1

O nmero de arquivos referenciados o somatrio do nmero de Arquivos Lgicos


Internos e de Arquivos de Interface Externa acessados na Consulta Externa, conforme
apresentado na Tabela 11, o exemplo relativo ao diagrama de caso de uso descrito na
Figura 1.
Table 12. Contagem de DETs
EQ
valida acesso
CPF
SENHA
VALIDACAO
Total = 3

Contagem de Tipos de Elementos de Dados (DETs) para Consultas Externas (EQs):


O nmero de itens de dados referenciados o nmero de parmetros informados para
obteno do resultado da Consulta Externa mais os itens de sada, contando os repetidos
apenas uma vez.
Para contagem dos Tipos de Elementos de Dados (DETs), iremos considerar as
informaes do diagrama de classe da Figura 2 e a descrio do caso de uso da tabela 3,
conforme mostrado na Tabela 12.

296 WER 2002

De acordo com o nmero de itens de dados e de arquivos referenciados, classifica-se a


Consulta Externa em simples, mdia ou complexa. Para este exemplo teremos 1 Tipo de
Arquivo referenciado (FTR) e 3 Tipos de Elementos de Dados (DETs) o que implica em
uma complexidade BAIXA, ou seja, corresponde a 3 Pontos por Funo para a Consulta
Externa Valida Acesso.
4.6.4
Contribuio dos Entradas Externas (EIs), Consultas Externas (EQs) e
Sadas Externas (EOs)
Conclui-se a contagem das funes transacionais fazendo um balano da contagem dos
Entradas Externas (EIs), Consultas Externas (EQs) e Sadas Externas (EOs) conforme
Tabela 13.
Tabela 13. Contribuio Funes Transacionais
Tipo de Funo
Entradas Externas (EI)
Consultas Externas (EQ)
Sadas Externas (EO)

0
0
1
1
0
0
0
1
0

Complexidade Funcional
Baixa x 3 = 0
Mdia x 4 = 0
Alta
x 6 =6
Baixa
x 3
=3
Mdia x 4
=0
Alta
x 6
=0
Baixa
x 4 =0
Mdia
x 5 =5
Alta
x 7 =0

Total de Pontos de Funo


6
3
5

Depois de calculado o total de Pontos por Funo no ajustados com base no total nas
funes de dados e nas funes transacionais (ILFs + EIFs + EIs + EQs + EOs) ,
poderemos calcular o fator de ajuste para o total dos Pontos por Funo e o total de Pontos
por Funo da aplicao conforme apresentado na Seo 3.

Concluses e Trabalhos Futuros

Mostramos por meio do estudo de caso a possibilidade de Medio de Pontos por Funo
a partir de Especificao de Requisitos. O diagrama de Casos de Uso em conjunto com o
diagrama de classes fornecem uma direo para a contagem de Pontos por Funo.
fundamental termos disponvel uma mtrica confivel para as primeiras fases do processo
de desenvolvimento de software. A especificao de requisitos com a notao UML e a
Medio de Pontos por Funo podem ser usados em conjunto, efetivamente, para
alcanar sucesso no controle e gerenciamento dos projetos.
Anlise de Pontos por Funo podem ser facilmente aplicados ao mtodo de casos de
uso, um dos problemas com pontos por funo tem sido um conjunto de requisitos
incompleto ou inconsistente, adotando ambos, mtodo de caso de uso e Anlise de Pontos
por Funo, a qualidade do documento de requisitos pode ser melhorada, a medio
melhorada e a estimativa como um todo melhorada.

Medio de Pontos por Funo a Partir de Especificao de Requisitos 297

No SERPRO, a SUNAT (Superintendncia de Negcios - Administrao Tributria)


iniciou, em 1998, o processo de implantao de um plano de medies definindo como
mtrica a ser adotada a Anlise de Pontos por Funo (APF), baseando-se no padro
internacional estabelecido pelo IFPUG (International Function Points Users Group).
Quando utilizada em combinao com outras medidas, a Anlise de Pontos por Funo
(APF) pode ser utilizada para determinar, por exemplo, o nvel de produtividade da
equipe, o esforo requerido para o desenvolvimento do sistema, o custo, a taxa de
produo e de manuteno ou at a qualidade do sistema do ponto de vista do usurio.
Com a compatibilizao da Contagem de Pontos por Funo no paradigma Tradicional e
Orientada a Objeto, aproveitamos a cultura existente na Empresa em Pontos por Funo.
A mtrica de Anlise de Pontos por Funo j est sendo amplamente utilizada por
todos os Plos de Desenvolvimento da SUNAT, no Brasil, alm de outras
Superintendncias. Foram pontuados 100% dos projetos da SUNAT. Com a
familiarizao dos lderes de projeto e criao da base de histrico (baseline), nessa
primeira fase, est sendo possvel avaliar o acervo de projetos, alm de gerar subsdios
para a tomada de decises. Para tal foi utilizada uma ferramenta chamada Estimativa[21],
desenvolvida pelo SERPRO, para ajudar na contagem e armazenamento de dados
histricos.
Podemos verificar que com a medio dos Pontos por Funo a partir da especificao
dos requisitos obtivemos, na fase inicial do projeto, uma estimativa do total de Pontos por
Funo do projeto (186,40), praticamente igual a medio do projeto desenvolvido com o
paradigma tradicional (186,60). Vale salientar que o projeto foi desenvolvido
simultaneamente por duas equipes distintas, onde uma utilizou a especificao de
requisitos tradicional e a outra a especificao de requisitos orientada a objeto. Na
concluso do projeto o total de pontos por funo obtidos foi de 201. Esta experincia foi
realizada para podermos verificar a validade da aplicao da proposta de medio
apresentada em [6].
Durante o processo de implantao das prticas necessrias para atingir o Nvel 2 do
CMM, utilizamos esta Proposta de Medio em mais 120 projetos da organizao e
verificamos a exatido das estimativas realizadas nas pontuaes dos diversos projetos na
fase de requisitos.

Bibliografia
1. Greer, D., Bustard, D.W., Sunazuka, T.: Prioritisation of System Changes using Cost-Benefit and
Risk Assessments.Fourth IEEE International Symposium on Requirements Engineering RE'99.
Limerick, Ireland. (1999) 180--187
2. Tavares, H., Paim, F., Carvalho, A.: Implantando CMM Nvel 2: A Estratgia SERPRO. I
Simpsio Brasileiro de Qualidade de Software SBQS. Gramado, Brasil. (2002)
3. Leite, J., Castro, J., Pinheiro, F.: Plataforma Tecnolgica em Engenharia de Requisitos
Estratgias para o Aumento da Qualidade no Desenvolvimento de Sistemas.
http://www.cic.unb.br/~facp/per/perhome.html

298 WER 2002

4. Carvalho, A. E., Tavares, H. C., Castro, J.: Uma Estratgia para Implantao de uma Gerncia de
Requisitos visando a Melhoria dos Processos de Software. WER01. Buenos Aires, Argentina.
(2001)
5. Carvalho, A. E.: Uma Estratgia para Implantao de uma Gerncia de Requisitos visando a
Melhoria dos Processos de Software. Dissertao de Mestrado. UFPE, Brasil. (2001)
6. Tavares, H. C.: Medio de Pontos por Funo a partir da Especificao Orientada a Objeto.
Dissertao de Mestrado. UFPE, Brasil. (1999)
7. IFPUG: Medio de Pontos por Funo a partir da Especificao Orientada a Objeto. Function
Point Counting Practices Manual, Verso 4.1.1. International Function Point Users Group
http://www.ifpug.org (2000)
8. Dekkers, C.: Use Cases And Function Points - Wheres The Fit? Quality Plus Technologies,
inc. (2001)
9. Booch, G., Rumbaugh, J., Jacobson, I.: The Unified
Modeling Language User Guide.
Addison Wesley. (1999)
10.Schooneveldt, M.: Measuring the size of object oriented system. In Proc. 2nd Australian
Conference on Software Metrics. Australian Software Metrics Association. (1995)
11.Whitmire, S.: Applying function points to object-oriented software. In Software Engineering
Productivity Handbook. McGraw-Hill. (1993) 229--244
12.Sneed, H.: Estimating the Costs of Object-Oriented Software. In Proceedings of Software Cost
Estimation Seminar. (1995)
13.Couturier, G.: FP Usage in OO Technology Environment. International Function Point. New
Orleans, LA, USA. (1999)
14.Longstreet, D.: Use Cases And Function Points. Inc. (2001)
15.Toro, A. D., Corts, A. R., Corchuelo, R., Toro, M.: Supporting Requirements Verification
Using XSLT. IEEE Intl. Symposium on Requirements Engieneering (RE02). Essen, Germany.
(2002)
16.IFPUG: Function Point Counting Practices: Case Study 3 Object Oriented Analysis. Object
Oriented Design (Draft). International Function Point Users Group. (1995)
17.Fetcke, T., Abran, A., Nguyen, T. H.: Mapping the OO Jacobon approach to function point
analysis. In Proc. IFPUG 1997. Spring Conference. (1997) 134--142
18.Jacobson, I., Christerson, M., Jonsson, P., Overgaard, G.: Object Oriented Software Engineering:
A Use Case Driven Approach. Addison-Wesley. (1992)
19.Antoniol, G., Calzolari, F., Cristoforetti, L., Fiutem, R., Caldiera, G.: Adapting Function Points
to Object Oriented Information Systems. 10th Conference on Advanced Information Systems
Engineering [CAISE-98]. Pisa, Italia. (1998) 8--12
20.Castro, J. F.: Introduo Medio de Software atravs de Ponto de Funo. XII Simpsio
Brasileiro de Engenharia de Software. Maring\a, PR Brasil. (1998)
21.Hastings, T.: Adapting Function Points to contemporary software systems: A review of
proposals. Second Australian Conference on Software Metrics. University of New South Wales,
Sydney, Australia. (1995)
22.Candas, A., Lopes, C.: ESTIMATIVA: Uma Ferramenta para Agilizar o Dimensionamento de
Projetos no SERPRO com base na metodologia de An\alise de Pontos por Funo. XIII
Simpsio Brasileiro de Engenharia de Software - SBES'99. Florianpolis/SC, Brasil. (1999)
23.Anda, B., Dreiem, H., Jorgensen M.: Estimation Software Development Effort Based on Use
Cases-Experiences from Industry. Fourth Internation Conference on the Unified Modeling
Language. Toronto, Canada, september (2001)
24.Kusumoto, S., Imagawa, M., Morimoto, S.: Function Point Measurement from Java Programs.
24 International Conference on Software Engineering. Orlando, Flrida. (2002)

Você também pode gostar