INSTITUTO BRASILEIRO DE TECNOLOGIA AVANADA

ESPECIALIZAO EM ENGENHARIA DE SOFTWARE

NELSON RODRIGO LOMBARDI BASSETTO






Uma abordagem para um programa de medio baseado
em anlise de pontos de funo














So Paulo SP
2008

NELSON RODRIGO LOMBARDI BASSETTO




Uma abordagem para um programa de medio baseado
em anlise de pontos de funo





Trabalho de concluso de curso
apresentado como requisito final
para obteno do ttulo de Especialista
em Engenharia de Software,
pelo Instituto Brasileiro de
Tecnologia Avanada IBTA, na rea de
concentrao de Tecnologia da Informao.

Orientador: Prof. Luiz David Szilagyi




Banca Examinadora - Avaliador(es):

Luiz David Szilagyi
Especialista, Instituto Mackenzie






30 de outubro de 2008






Bassetto, Nelson Rodrigo Lombardi
B319a Uma abordagem para um programa de medio
baseado em anlise de pontos de funo [manuscrito] Nelson
Rodrigo Lombardi Bassetto.
096f., enc.
Orientador: Luiz David Szilagyi
Monografia Faculdade de Tecnologia IBTA
Bibliografia: f. 113-117
1. Tecnologia da informao, Brasil I. TTULO II. Bassetto, Nelson
Rodrigo Lombardi

005.1068















iv










minha me e avs



v
AGRADECIMENTOS


A Deus pelas oportunidades concedidas e caminhos que me agregam e me fazem
evoluir a cada dia;

minha me e avs pelo incentivo e apoio nos estudos;

minha famlia, por ter provido bases slidas que me estruturam e servem-me de
guia todos os dias;

Aos familiares e amigos prximos, pela tolerncia nos momentos de ausncia;

Ao colega Renato Duran Vittoruzzo Martins pelo competente apoio tcnico e
pertinentes sugestes;

Lucy Rizzo, professora de ingls de extrema competncia, por sua valiosa reviso
e sugestes quanto ao abstract deste trabalho;

Ao IBTA, pela oportunidade e pelo curso de alto nvel ministrado, o qual agregou
significativamente em minha formao.




vi

RESUMO


Visando proporcionar um meio que apie no desenvolvimento de solues
sistmicas com alto nvel de qualidade, produzidas em menor tempo e custo
possveis, este estudo prope uma abordagem de programa de medio baseado
em anlise de pontos de funo. Tal abordagem objetiva a obteno sistemtica de
dados significativos sobre a organizao de software que o implementa,
possibilitando analises, identificao de pontos positivos e falhos da organizao e
tomadas de deciso fundamentadas por dados quantitativos e concretos. Com o
estudo realizado, verificou-se que programas de medio baseados em anlise de
pontos de funo podem ajudar organizaes a gerenciar e tomar decises
baseadas em fatos, a ter maior previsibilidade de entrega de produtos, a melhorar
seu processo de desenvolvimento e seus produtos e a utilizar recursos com maior
eficincia.


Palavras chave: Anlise de Pontos de Funo, Medio Funcional, Programa de
Medio, Mtricas e Medio de Software.













vii


ABSTRACT


Aiming to provide an environment that supports the development of high quality
systemic solutions, produced with less time and cost, this study proposes an
approach to a measurement program based on function points analysis. This
approach intends to systematically achieve significant data of the software
organization which implements it, allowing analysis, identifying the organizations
strengths and weaknesses and decision-making taking into account real and
quantitative data. In this study, it was verified that measurement programs which rely
on function points analysis can help organizations to manage and make decisions
based on facts, to have greater predictability of products delivery, to improve its
development process and its products and to use resources more efficiently.


Key Words: Function Point Analysis, Functional Measurement, Measurement
Program, Metrics and Software Measurement.
viii

LISTA DE ABREVIAES, SIGLAS E SMBOLOS


AIE Arquivo Interface Externa
ALI Arquivo Lgico Interno
APF Anlise de Pontos de Funo
BFPUG Brazilian Function Point Users Group [Grupo Brasileiro de Usurios de
Pontos de Funo]
CE Consulta Externa
CGS Caractersticas Gerais do Sistema
CMM Capability Maturity Model [Modelo de Capacidade e Maturidade]
CMMI Capability Maturity Model Integration [Modelo de Capacidade, Maturidade
e Integrao]
EE Entrada Externa
FPA Function Point Analysis [Verificar APF]
IFPUG International Function Point Users Group [Grupo Internacional de Usurios
de Pontos de Funo]
MSF Microsoft Solutions Framework [Framework de Solues Microsoft]
PCs Pessoal Computers [Computadores Pessoais]
PF Pontos de Funo
RUP Rational Unified Process [Processo Unificado Rational]
SE Sada externa
TI Tecnologia da informao
UML Unified Modeling Language [Linguagem de modelagem unificada]
XP Extreme Programming







ix
LISTA DE ILUSTRAES


FIGURA 1: PROCESSO DE CONTAGEM DE PONTOS DE FUNO, ADAPTADO DE (IFPUG,
2000), PGINA 31 ...................................................................................................................... 1
FIGURA 2 - PROCESSO CCLICO DE UM PROGRAMA DE MEDIO, ADAPTADO DE (DEKKERS,
2002), PGINA 163 ...................................................................................................................31
FIGURA 3 - EXEMPLO DE RELATRIO COMPARATIVO DE MEDIES, ADAPTADO DE
(RUSSAC, 2002), PGINA 155..................................................................................................38
FIGURA 4 - EXEMPLO DE RELATRIO DE MTRICAS ORGANIZACIONAL, ADAPTADO DE
(RUSSAC, 2002), PGINA 156..................................................................................................40
FIGURA 5 - DEFINIO PROGRAMA MEDIO - FORMATO RELATRIO DETALHADO POR
PROJETO..................................................................................................................................69
FIGURA 6 - DEFINIO PROGRAMA MEDIO - FORMATO RELATRIO COMPARATIVO POR
PROJETO..................................................................................................................................71
FIGURA 7 - DEFINIO PROGRAMA MEDIO - FORMATO RELATRIO EVOLUCIONAL DA
ORGANIZAO ........................................................................................................................73
FIGURA 8 - DEFINIO DO PROGRAMA DE MEDIO - INTEGRAO DO PROGRAMA EM UM
CONTEXTO................................................................................................................................ 1
FIGURA 9 - DEFINIO DO PROGRAMA DE MEDIO - FLUXO PARA GERAO BIMESTRAL
DO RELATRIO EVOLUCIONAL DA ORGANIZAO..............................................................77










x
LISTA DE TABELAS


TABELA 1: FASES DO CICLO DE VIDA DE DESENVOLVIMENTO EM QUE A APF PODE SER
APLICADA, ADAPTADO DE (VAZQUEZ, ET AL., 2003) ............................................................16
TABELA 2: MATRIZ COMPLEXIDADE ALI / AIE, ADAPTADO DE (IFPUG, 2000), PGINA 69.........21
TABELA 3: MATRIZ DE COMPLEXIDADE EE, ADAPTADO DE (IFPUG, 2000), PGINA 165..........23
TABELA 4: MATRIZ DE COMPLEXIDADE SE / CE, ADAPTADO DE (IFPUG, 2000), PGINA 166 ..23
TABELA 5: MATRIZ TIPO FUNO - CONTRIBUIO EM PF, ADAPTADO DE (IFPUG, 2000),
PGINAS 69 E 167....................................................................................................................24
TABELA 6: EXEMPLO DE CONTAGEM DE PONTOS DE FUNO NO AJUSTADOS..................25
TABELA 7 - RELAO OBJETIVOS X MEDIDAS, ADAPTADO DE (HOLMES, 2002), PGINA 100 33
TABELA 8 - APLICABILIDADE DE MEDIDAS PARA ENDEREAMENTO DE OBJETIVOS,
ADAPTADO DE (DEKKERS, 2002), PGINA 165......................................................................34
TABELA 9 - RELAO OBJETIVOS, MEDIES, DADOS E RESPONSABILIDADES, ADAPTADO
DE (HOLMES, 2002), PGINAS 103 E 104................................................................................36
TABELA 10 - EXEMPLOS DE TREINAMENTOS PARA DIFERENTES AUDINCIAS, ADAPTADO DE
(HOLMES, 2002), PGINA 109..................................................................................................44
TABELA 11 - RELAO DE MTRICAS X OBJETIVOS COM O PROGRAMA DE MEDIO..........55
TABELA 12 - APURAO DO ESFORO GASTO NO PROJETO EM HORAS - SUMARIZAO...57
TABELA 13 - APURAO DO CUSTO TOTAL DO PROJETO - SUMARIZAO.............................59
TABELA 14 TAMANHO DO PROJETO INICIAL EM PONTOS DE FUNO - SUMARIZAO.....60
TABELA 15 - TOTAL DE PONTOS DE FUNO DE ALTERAES DE ESCOPO - SUMARIZAO
..................................................................................................................................................62
TABELA 16 - TOTAL DE PONTOS DE FUNO AO TRMINO DO PROJETO - SUMARIZAO...63
TABELA 17 QUANTIDADE TOTAL DE DEFEITOS ENCONTRADOS - SUMARIZAO ...............65
xi
TABELA 18 DEFINIO DO PROGRAMA DE MEDIO - RELAO MEDIDAS, DADOS, MEIOS,
PONTOS E RESPONSABILIDADE PELA COLETA ...................................................................66
TABELA 19 DEFINIO DO PROGRAMA DE MEDIO RELAO OBJETIVOS, MTRICAS E
SUAS COMPOSIES .............................................................................................................66
TABELA 20 - SUMARIZAO RELATRIO DETALHADO POR PROJETO.....................................70
TABELA 21 - SUMARIZAO RELATRIO COMPARATIVO POR PROJETO.................................72
TABELA 22 - SUMARIZAO RELATRIO EVOLUCIONAL DA ORGANIZAO...........................74
TABELA 23 - DEFINIO PROGRAMA MEDIO - ANLISE E REPORTE DE RESULTADOS .....75

xii

SUMRIO


1. INTRODUO...................................................................................................1
1.1. CONTEXTUALIZAO......................................................................................... 1
1.2. PROBLEMATIZAO............................................................................................ 2
1.3. OBJETIVOS DA PESQUISA ................................................................................... 2
1.4. JUSTIFICATIVAS ................................................................................................... 3
1.5. ENUNCIADO DA HIPTESE ................................................................................. 4
1.6. MTODO DE PESQUISA........................................................................................ 4
1.7. DELIMITAO....................................................................................................... 4
1.8. ORGANIZAO..................................................................................................... 5
2. MEDIO DE SOFTWARE...............................................................................6
2.1. INTRODUO........................................................................................................ 6
2.2. MEDIDA, MEDIO, MTRICAS E INDICADORES............................................ 6
2.3. MEDIO DE SOFTWARE ..................................................................................... 7
2.4. MTRICAS PARA ESTIMATIVA DE TAMANHO DE SOFTWARE .................... 10
3. PROGRAMA DE MEDIO ............................................................................28
3.1. INTRODUO...................................................................................................... 28
3.2. OBJETIVOS DE UM PROGRAMA DE MEDIO............................................... 28
3.3. BENEFCIOS DA IMPLEMENTAO DE UM PROGRAMA DE MEDIO..... 29
3.4. COMPOSIO DE UM PROGRAMA DE MEDIO.......................................... 30
3.5. FATORES CRTICOS DE SUCESSO EM UM PROGRAMA DE MEDIO........ 42
3.6. RECURSOS HUMANOS: TREINAMENTO E MUDANA CULTURAL............. 44
4. ABORDAGEM PARA UM PROGRAMA DE MEDIO BASEADO EM
ANLISE DE PONTOS DE FUNO ......................................................................46
4.1. PREMISSAS PARA O PROGRAMA DE MEDIO ABORDADO ...................... 47
4.2. DEFINIO DE OBJETIVOS E METAS............................................................... 51
4.3. DEFINIO DE MEDIES E MTRICAS......................................................... 53
xiii
4.4. DADOS, MEIOS E PONTOS DE COLETA E RESPONSABILIDADES................ 55
4.5. ANLISE E REPORTE DE RESULTADOS .......................................................... 67
4.6. INTEGRAO DO PROGRAMA DE MEDIO EM UM CONTEXTO DE
DESENVOLVIMENTO DE SISTEMAS.......................................................................... 75
5. CONCLUSES E TRABALHOS FUTUROS...................................................78
5.1. CONCLUSO........................................................................................................ 78
5.2. RELAO COM OS OBJETIVOS INICIAIS......................................................... 78
5.3. VALIDADE DA HIPTESE .................................................................................. 78
5.4. TRABALHOS FUTUROS...................................................................................... 79
REFERNCIAS.........................................................................................................81


















1
1. INTRODUO

1.1. CONTEXTUALIZAO

Com a exponencial evoluo dos computadores pessoais e em seguida com
o surgimento da internet, a rea de tecnologia da informao passou cada vez mais
a dar suporte aos negcios de corporaes e no se limitando a isso, tornou-se
componente chave para se atingir diferencial competitivo. Em alguns ramos de
atuao tornou-se essencial at mesmo para garantir a sobrevivncia das empresas
no mercado. Neste mesmo sentido, Bill Gates (1999 p. 11) cita tal evoluo:
Pela primeira vez, todo tipo de informao nmeros, texto, som, vdeo
pode ser posto numa forma digital que qualquer computador pode
armazenar, processar e enviar. Pela primeira vez, um hardware padro
combinado a uma plataforma de software padro est criando economias de
escala que disponibilizam a empresas de todos os tamanhos, a custos
baixos, poderosas solues de informtica. O termo pessoal na expresso
computador pessoal significa que cada profissional do conhecimento
dispe de uma forte ferramenta para analisar e usar a informao fornecida
por essas solues. A revoluo do microprocessador no s est dando
aos PCs um aumento exponencial de poder, como est propiciando a
criao de toda uma nova gerao de dispositivos digitais inteligentes
handlehelds [micros de mo], Auto PCs, smart cards [cartes inteligentes] e
outros a caminho que iro disseminar o uso da informao digital. Uma
das chaves para essa disseminao o aperfeioamento das tecnologias
da internet, que nos permitem conectividade mundial.

Devido a esta evoluo constante e a necessidade crescente de softwares
para o apoio aos negcios, diversas tecnologias, metodologias e padres so
desenvolvidas e estudadas. Processos, linguagens de programao, conceitos,
modelos arquiteturais e metodologias, so aperfeioados constantemente a fim de
se conseguir atender a esta demanda com maior qualidade do resultado final e com
o menor tempo e custo possvel, a ponto de se manter o custo-benefcio da soluo
sistmica adquirida. As empresas que conseguem servios de tecnologia da
informao com estas caractersticas podem obter vantagens competitivas, que
podem inclusive definir sua permanncia ou no no mercado. Putnam, et al., (2002)
cita tal cenrio competitivo quando afirma que as organizaes precisam cada vez
mais conseguir produtos de boa qualidade em tempo, esforo e custo limitados, o
que significa, em sua opinio, ter um bom nvel de produtividade da equipe.


2
1.2. PROBLEMATIZAO

Produtividade, porm, por si s no garante produtos de qualidade em esforo e
custo limitados. Nem mesmo a utilizao das melhores tecnologias, processos,
metodologias, linguagens de programao, etc. garantem tal resultado. Diversos
fatores esto envolvidos e diversas questes devem ser respondidas, como por
exemplo, como saber o quo produtiva foi a equipe no desenvolvimento de um
sistema? Como saber se o produto desenvolvido tem nveis de qualidade
compatveis com o mercado do mesmo ramo, a ponto de se constatar se a
organizao est ou no gastando apenas o valor adequado com retrabalho? Como
saber se o processo de desenvolvimento de software implementado pela
organizao tem sido eficiente e tem trazido benefcios que valham o custo
investido?
Sem respostas assertivas para tais questes, nenhuma tecnologia ou
processo de desenvolvimento, por mais atual e evoludo que seja, garante que os
sistemas esto sendo desenvolvidos com qualidade e produtividade satisfatrios, a
ponto de apoiarem na gerao de diferencial competitivo para a organizao.
Faz-se necessrio ento que se tenha um mecanismo para responder a tais
questes de maneira assertiva, que permita no s saber a situao real da
organizao de software, como tambm a identificao de pontos fortes e fracos,
buscando com base em tal anlise a evoluo constante. Neste mesmo sentido
(Holmes, 2002) afirma que organizaes de software precisam de uma forma para
gerenciar a carga de trabalho, permitindo-se decidir o que fazer, como fazer e
quando fazer e define ainda que os dias de utilizao de sentimento como base
para tomada de tais decises e como base tambm para responder s questes
relacionadas sua posio, esto extintos.


1.3. OBJETIVOS DA PESQUISA

Dado tal contexto e problematizao, objetiva-se com esta pesquisa, estudar
mtricas, medies e, por fim, programas de medio, buscando entender se tais
mecanismos podem suprir a necessidade por informaes assertivas, se possibilitam
a identificao de pontos que devem ser aprimorados no processo de

3
desenvolvimento de software da organizao e de aes e iniciativas que tem tido
bons resultados e que devem ser mantidas.
Para tal, objetiva-se levantar contedo bibliogrfico sobre medies e
mtricas que possibilitem a definio de um programa de medio alinhado a
objetivos de negcios, a fim de se conhecer suas caractersticas e suas
aplicabilidades no contexto de desenvolvimento de software atual.
Objetiva-se tambm estudar e levantar contedo bibliogrfico a respeito da
composio de um programa de medio, possibilitando entendimento das suas
aplicabilidades em um processo de desenvolvimento e sua relao com as mtricas
estudadas.
Por fim, com base nos estudos realizados, objetiva-se estabelecer uma
abordagem para um programa de medio passvel de implementao por
organizaes, independentemente do processo de desenvolvimento de sistemas
que utilizem.


1.4. JUSTIFICATIVAS

Programas de medio permitem chegar a respostas assertivas para as
questes mencionadas anteriormente, o que leva a melhoria no processo de
desenvolvimento de software e conseqentemente nos produtos deste processo.
(Minkiewicz, 2002) afirma que cada vez mais, organizaes esto se dando
conta do valor que a medio em organizaes de software agrega ao seu processo
de negcios, atravs de estratgia de negcios de longo prazo para medio de
performance e melhoria de processos de desenvolvimento de software. (Minkiewicz,
2002) afirma ainda que as companhias esto se dando conta tambm, de que o
investimento em entender e implementar um programa de medio bem sucedido
pago pela melhoria na produtividade do desenvolvimento de software e do processo
de desenvolvimento como um todo.
Tais melhorias vm a corroborar na busca por produtos com altos nveis de
qualidade, sendo produzidos em cada vez menos tempo e custo, ao mesmo tempo
sendo cada vez mais aderentes ao negcio da companhia, apoiando a organizao
a alcanar seus objetivos estratgicos.


4

1.5. ENUNCIADO DA HIPTESE

A hiptese desta pesquisa que um programa de medio permite a
organizaes gerenciarem a sua construo de software baseando-se em atributos
quantitativos medidos ao invs de informaes subjetivas ou sentimentos,
conseguindo-se com tal:
Gerenciamento e tomada de decises baseada em fatos;
Maior previsibilidade de entrega de produtos;
Melhorias no processo de desenvolvimento e seus produtos;
Melhoria na qualidade dos sistemas desenvolvidos;
Utilizao de recursos com maior eficincia;


1.6. MTODO DE PESQUISA

A metodologia de pesquisa utilizada neste trabalho a pesquisa descritiva,
onde conforme (Gill, 2007), dentre outras caractersticas, est busca pelo
estabelecimento de relao entre variveis. Neste trabalho, as variveis podem ser
consideradas como as diversas mtricas existentes e as diversas formas de
estabelecimento de um programa de medio.
A pesquisa bibliogrfica o principal instrumento deste trabalho, onde livros e
artigos cientficos so analisados (Gill, 2007), com o objetivo de se adquirir
embasamento terico, possibilitando o estabelecimento das relaes entre as
mtricas e o programa de medio.


1.7. DELIMITAO

Este trabalho est delimitado ao estudo de mtricas, programas de medio e
a relao entre eles. A customizao de processos de desenvolvimento de software
para a introduo do programa de medio abordado no ser discutido neste
trabalho, ficando esta como uma oportunidade de evoluo do estudo.

5
Possibilidades de continuidade deste estudo so discutidas em detalhes no ltimo
captulo deste estudo.


1.8. ORGANIZAO

Este estudo est organizado em cinco captulos. A seguir, o contedo de cada
capitulo sumarizado:

O primeiro captulo apresenta o contexto em que o trabalho est inserido,
problematizao, objetivos, justificativas, a hiptese de soluo do problema
apresentado, metodologia de pesquisa utilizada no trabalho, escopo e organizao
do trabalho como um todo. Seu objetivo prover informaes introdutrias sobre o
assunto, bem como a motivao que levou a sua realizao e a sua importncia.

O segundo captulo aborda uma pesquisa bibliogrfica sobre mtricas, tendo
como objetivo a contextualizao do assunto, delineando os principais tpicos e
conceitos que sero utilizados no desenvolvimento do trabalho.

O terceiro captulo traz uma pesquisa bibliogrfica sobre programas de
medio, tendo como objetivo a introduo, conceituao e contextualizao do
assunto, servindo como referncia para o estudo do captulo posterior.

O quarto captulo explora o estudo realizado sobre as mtricas e programas
de medio, estabelecendo-se, com base no levantamento bibliogrfico realizado,
uma abordagem para um programa de medio.

O quinto e ltimo captulo traz a concluso do trabalho, apontando a relao
entre os objetivos e o resultado atingido do estudo, a validade da hiptese inicial e
possibilidades de evoluo deste estudo.


6
2. MEDIO DE SOFTWARE

2.1. INTRODUO

Medio o ato de determinar uma indicao quantitativa da extenso,
quantidade, dimenso, capacidade ou tamanho de algum atributo de um produto ou
processo (Pressman, 2006). Medio de software compreende a medio de um
processo de desenvolvimento de software, cujo objetivo objetivo fornecer um
conjunto de indicadores de processo, que leva a aperfeioamentos no longo prazo
(Pressman, 2006) ou de um projeto, cujo objetivo fornecer mecanismos para o
controle do projeto.
Em busca da previsibilidade de entrega, da qualidade do produto de
desenvolvimento de software, da produtividade da equipe e da eficincia do
processo de desenvolvimento, a medio um item essencial. A medio de
software propicia a obteno de medidas quantitativas de um processo ou produto,
permitindo-se a anlise e avaliao dos valores obtidos, o que possibilita a tomada
de aes visando melhoria de qualidade como um todo. (Pressman, 2006)
confirma esta anlise quando afirma que a medio uma forma de apoio gesto,
que, quando conduzida adequadamente, apia na tomada de decises que
conduzem o projeto ao sucesso.
O objetivo deste captulo contextualizar a medio de software, apresentar
tpicos relacionados a mtricas para estimativa de tamanho de software e
apresentar a anlise de pontos por funo, mtrica utilizada como base do programa
de medio abordado por este trabalho. Dentro dos objetivos deste estudo, este
captulo vem a explorar a medio de software, no contexto da medio em um
projeto, visando prover base terica para o estabelecimento de uma abordagem de
medio para o estabelecimento de um programa de medio.


2.2. MEDIDA, MEDIO, MTRICAS e INDICADORES


7
Para que se defina medio de software, essencial que cada um dos termos
relacionados ao assunto estejam esclarecidos.
(Pressman, 2006) define que uma medida fornece uma indicao quantitativa
da extenso, quantidade, dimenso capacidade ou tamanho de algum atributo de
um produto ou processo. (Vazquez, et al., 2003 p. 31) refora tal definio, quando
afirma que medida a quantificao de uma caracterstica.
(IEEE, 1993) define mtrica como uma medida quantitativa do grau em que
um sistema, componente ou processo possui um determinado atributo.
(Pressman, 2006) define medio como o ato de determinar uma medida e
um indicador como uma mtrica, ou combinao de mtricas que fornece
profundidade na viso do processo de software, projeto de software ou produto em
si.
(Pressman, 2006 p. 352) exemplifica cada uma das definies apresentadas:
Quando um nico ponto de dados foi coletado (por exemplo, o nmero de
erros descoberto em um nico componente de software), uma medida foi
estabelecida. Medio ocorre como resultado da coleo de um ou mais
pontos de dados (por exemplo, um certo nmero de revises de
componentes e testes de unidade so investigados para coletar medidas do
nmero de erros em cada um). Uma mtrica de software relaciona as
medidas individuais de algum modo (por exemplo, o nmero mdio de erros
encontrados por reviso ou nmero mdio de erros encontrados por teste
de unidade).
[...] Um indicador fornece profundidade de viso que permite ao gerente do
projeto ou engenheiro de software ajustar o processo, projeto ou produto
para tornar as coisas melhores.


2.3. MEDIO DE SOFTWARE

Segundo (Pressman, 2006), a medio essencial em processos de
engenharia. Atravs da medio, possvel obter entendimento do processo e
projeto, tendo-se um mecanismo para avaliao objetiva. Tendncias (boas ou ms)
podem ser detectadas, melhores estimativas podem ser feitas e aperfeioamentos
reais podem ser obtidos ao longo do tempo. (Budag, 2007) confirma este raciocnio
quando diz que o objetivo da aplicao da medio de software fornecer aos
gerentes e engenheiros de software um conjunto de informaes tangveis para
planejar o projeto, realizar estimativas, gerenciar e controlar os projetos com maior
preciso.

8
Segundo (Pressman, 2006) as razes para o qual se mede um software so:
Caracterizar em um esforo a fim de obter entendimento de processos,
produtos, recursos e ambientes, e para estabelecer referncias, para
comparao com futuras avaliaes;
Para avaliar, a fim de determinar o estado em relao aos planos;
Para prever pela obteno de entendimento de relacionamento entre
processos e produtos e construo de modelos desses relacionamentos;
Para aperfeioar, pela identificao de bloqueios, causas fundamentais,
ineficincias e outras oportunidades para melhor a qualidade do produto e
desempenho do processo.

Complementando as razes citadas por Pressman, (Vazquez, et al., 2003),
entendem que as razes para se medir esto compreendidas em:
Ter mecanismos para manter sob controle um contexto de
desenvolvimento de software em que os requisitos tendem a expanso e
que os recursos tendem a escassez Atender ao mximo s expectativas
dos clientes com a utilizao do mnimo de recursos;
Apoiar no planejamento e controle da gerncia de projetos, apoiando na
definio de objetivos realistas e na adoo de medidas necessrias
preveno e correo dos desvios que causam impacto negativo ao
projeto;
Apoiar na tomada de decises do projeto, atravs de indicadores que
refletem uma tendncia de comportamento futuro;
Ter insumos para anlises Make-or-Buy [Construir ou Comprar], onde se
decide entre construir um software internamente ou em terceirizar sua
construo;
Ter mecanismos para a medio concisa de servios de desenvolvimento
de software prestados por terceiros.

Dados os motivos pelo qual medir, importante ressaltar que conforme pode
ser observado, a medio pode ser aplicada sobre alguns contextos distintos, porm
relacionados, como por exemplo, a medio em um processo de desenvolvimento
de software e a medio em um projeto. Na medio em um processo, o objetivo

9
obter mtricas e indicadores do processo, visando sua melhoria contnua. Na
medio ao longo de um projeto, tm-se mtricas para auxlio na estimativa, no
controle da qualidade, na avaliao da produtividade e no controle do projeto. Este
controle se d atravs de medies sistemticas e avaliao com base em regras
claramente definidas (Pressman, 2006). (Vazquez, et al., 2003 p. 22) enfatiza a
importncia das mtricas na medio de projetos:
A falta de mtricas de projeto prejudica de forma geral seu
acompanhamento, uma vez que, apesar de o problema estar l, ele no
percebido por aqueles que podem direcionar esforos na sua soluo. O
papel das mtricas permitir uma rpida identificao e correo de
problemas.

Para (Demarco, 1989), os aspectos quantitativos onde as mtricas podem ser
usadas so no escopo, tamanho, custo, risco e tempo empregado. Uma vez que se
sabe o tamanho do que deve ser construdo, possvel planejar e controlar o
projeto. Alm disso, tendo-se uma medida padro e comum de tamanho, possvel
fazer a relao com outras variveis, como por exemplo, o tempo gasto na
construo, a quantidade de erros encontrados por medida de tamanho,
conseguindo-se assim, apurar produtividade e indicadores de qualidade.
Segundo (Pressman, 2006), na maioria das vezes, em um projeto de
desenvolvimento de um sistema, as mtricas de projeto so aplicadas para a
apurao de estimativas. Para tal, so usadas mtricas para estimativa de tamanho
de software a partir das quais, estimativas de esforo e tempo so produzidas. Com
a evoluo do projeto, o gerente de projetos utiliza a estimativa de esforo e tempo
para controlar e monitorar o progresso da construo. Para tal, a taxa de produo,
representada em termos de modelos criados, os erros descobertos durante cada
tarefa de engenharia de software so medidos e registrados. Ao final, consegue-se
comparar se as estimativas iniciais esto aderentes ao realizado, e esta informao
retro-alimentada no processo de estimativa. Consegue-se tambm saber, o quanto
a equipe foi produtiva e o quanto foi efetiva com relao qualidade.
Uma vez que este processo de medio definido e utilizado, possvel
identificar reas falhas em projetos e, com o tempo, tomar aes visando sua
melhoria. medida que os pontos falhos so aperfeioados, (Pressman, 2006) os
defeitos so minimizados e, conforme a contagem de defeitos decresce, a

10
quantidade de retrabalho durante o projeto tambm reduzida, levando a diminuio
do custo total do projeto.
Contextualizada a medio de software, as medies ao longo de um projeto,
e estimativas de tamanho, a seguir so apresentadas mtricas para estimativa de
tamanho de software, as quais fazem parte das medies em projetos, apoiando na
apurao de estimativas de esforo, em indicadores para controle de qualidade,
produtividade e controle do andamento do projeto.


2.4. MTRICAS PARA ESTIMATIVA DE TAMANHO DE SOFTWARE

Segundo (Vazquez, et al., 2003), sempre que se tem uma necessidade de
implementao de um software para se atender demandas de uma organizao, as
principais questes que so feitas so quanto ao tempo necessrio para concluso
do projeto e o custo para a organizao. Para responder tais perguntas, diversos
fatores devem ser considerados, como as particularidades dos requisitos do projeto
de software, da equipe envolvida e da tecnologia empregada. (Vazquez, et al., 2003
p. 155) cita os principais fatores que, quando analisados, evidenciam as dificuldades
de obteno de respostas confiveis para as questes citadas:
Os requisitos traduzem com fidelidade as necessidades do negcio dos
usurios? J se encontram suficientemente estabilizados? Refletem
caractersticas de software transacionais de baixa complexidade ou
possuem atributos que exigem conhecimentos especficos, tais como alta
performance, matemtica complexa, processamentos distribudos, etc.?

A equipe de desenvolvimento possu conhecimento na rea de negcio que
ser atendida pelo projeto de software? Possu experincia na utilizao
das ferramentas necessrias concluso do projeto? Possu todos os perfis
necessrios impostos pelas caractersticas do projeto? Existem conflitos
internos equipe que precisam ser solucionados? possvel identificar uma
liderana entre os integrantes da equipe? Qual o grau de motivao da
equipe mediante o projeto?

A tecnologia j faz parte da cultura da organizao? Pode ser facilmente
absorvida por novos integrantes da equipe de projeto? Existe material de
apoio suficiente para o aprendizado da tecnologia? Sua aplicao exige
pessoal com algum tipo de especializao? Suporta a implementao de
todas as caractersticas do software? Atende inclusive aos requisitos no-
funcionais do projeto?


11
Dadas estas particularidades inerentes a cada projeto, apurar com exatido o
custo final e a data da concluso uma tarefa que s pode ser realizada quando o
projeto est concludo. Antes de tal fato, s possvel obter estimativas, o que no
deixa de se ser muito importante, uma vez que dados histricos sejam mantidos e
utilizados para o aperfeioamento das estimativas, chegando a um nvel de
confiana cada vez maior (Vazquez, et al., 2003).
Para a apurao de tais estimativas, mtricas podem ser utilizadas, dando
uma abordagem sistemtica ao processo, e, portanto aumentando a confiabilidade
no resultado. Segundo (Aguiar), as mtricas para estimativa de tamanho de
software surgiram com o objetivo de servir como mecanismo para se estimar o
esforo envolvido em projetos e o prazo associado ao desenvolvimento de sistemas.
Uma das primeiras tcnicas que surgiram com este intuito foi a SLOC (Source
Lines of Code), por volta de 1950/1960, a qual considerada como uma medio
fsica do tamanho do software, por medir o volume de cdigo-fonte contido no
mesmo. Para (Andrade, 2004), os principais benefcios desta tcnica esto no fato
de que ela pode ser aplicada automaticamente atravs da utilizao de ferramentas
que apurem a quantidade de linhas de cdigo do projeto e pelo fato de ter sido
usada por muito tempo, existindo grande quantidade de dados histricos de
estimativas realizadas. Por outro lado, o principal problema desta tcnica est no
fato de que a medio do cdigo fonte no representa propriamente o tamanho do
software ou do esforo envolvido, uma vez que este atributo est diretamente
condicionado tecnologia utilizada e ao mtodo de programao empregado.
(Andrade, 2004) reafirma esta concluso, quando diz que a contagem em LOC
depende do grau de reuso da linguagem de programao, o que pode levar uma
estimativa a ser cinco vezes superior a outra, devido s diferenas das linguagens
de programao quando as linhas em branco, linhas de comentrio, declarao de
dados e linhas de instrues. (Andrade, 2004) afirma ainda que esta tcnica
penaliza projetos pequenos e bem projetados, no se adapta s linguagens no
procedimentais e de difcil obteno na fase inicial do projeto.
Dadas as limitaes da medio fsica, tcnicas de medio baseadas em
funcionalidades foram propostas, as quais procuram medir a funcionalidade
disponibilizada pelo software, ao invs do tamanho fsico. Tais tcnicas so
denominadas mtricas funcionais de tamanho. Por medirem apenas o tamanho

12
funcional do sistema, possvel serem utilizadas em fases iniciais do projeto,
quando normalmente ainda no se tem muitos detalhes tcnicos.
Uma das primeiras tcnicas criadas com este objetivo foi a Pontos de Funo,
criada por Allan Albrecht em 1979. Na tcnica de Pontos de Funo os dados e as
transaes envolvidas no sistema so classificadas quanto a sua complexidade e
pontuadas. Um fator de ajuste determinado com base em caractersticas
especficas do sistema medido e aplicado quantidade de pontos apurados. Ao
trmino, tem-se a quantidade de pontos por funo do sistema medido. Segundo
(Aguiar), tal tcnica ganhou grande popularidade com a criao do IFPUG
(International Function Point Users Group) e com sua normatizao internacional,
atravs da norma ISSO/IEC 20926. (Aguiar) ainda afirma que esta tcnica tem sido
utilizada por diversas organizaes com sucesso, pois o pr-requisito para sua
utilizao o conhecimento dos requisitos do sistema e o da tcnica propriamente
dita.
Posteriormente, outras mtricas funcionais de tamanho foram propostas,
como Bang, Mark II, Full Function Points e Cosmic-FFP. Em 1993, Gustav Karner
criou uma variao dos Pontos de Funo especfica para a medio de
funcionalidade contida em casos de uso, denominada Pontos por Caso de Uso
(Aguiar). Nesta tcnica, diagramas de caso de uso so a base para a medio. Os
atores e casos de uso so classificados e pontuados quanto a sua complexidade no
sistema. Fatores tcnicos e ambientais so apurados e aplicados aos pontos
obtidos. Como resultado, tem-se a quantidade de pontos de casos de uso do
sistema e a quantidade de esforo envolvido na construo de tais casos de uso.
(Aguiar) diz que o problema desta tcnica reside no fato de que como no se
tem padres universais para a construo de casos de uso, a obteno de
estimativas confiveis de esforo exigiria a padronizao dos estilos de casos de uso
e um extenso trabalho de calibrao de um modelo de estimativas baseado em
pontos por caso de uso. Alm disso, a tcnica s pode ser utilizada por empresas
que adotem casos de uso como forma de expresso dos requisitos, o que
inviabilizaria sua utilizao em muitos casos e dificultaria sua utilizao como mtrica
padro para definio de contratos de servios de desenvolvimento de software e
medio de produto entregue.
Dadas as diversas mtricas apresentadas, preciso avaliar seus pontos fortes e
fracos e sua aplicabilidade no contexto de desenvolvimento de sistemas atual, uma

13
vez que muitas delas foram desenvolvidas h mais de trinta anos, quando o contexto
era completamente diferente. Devem ser levadas em considerao suas
aplicabilidades durante as fases de projeto, sua difuso de utilizao entre as
organizaes, sua facilidade de aplicao, a existncia de institutos
regulamentadores ou normas que regulamentem a utilizao, dentre outros fatores.
(Schuster, 2006), relaciona alguns itens que devem ser levados em considerao na
escolha de uma mtrica:
Deve ter detalhamento dos passos a serem seguidos para a utilizao da
mtrica;
Deve prover resultados consistentes;
Deve ser de fcil entendimento;
Precisa ser objetiva, minimizando a influncia de julgamentos pessoais;
Deve ser efetiva no custo, ou seja, o resultado obtido deve compensar e
exceder o esforo da utilizao da mtrica;
Precisa fornecer informaes que evidenciem a situao atual e sejam
relevantes para a tomada de deciso;
Deve ser apropriada para cada etapa do ciclo de vida do software;
Deve servir para a realizao de estimativas;
Deve possibilitar a obteno de sries histricas;

A anlise de pontos de funo atende a todos os requisitos mencionados.
Segundo (Andrade, 2004) a tcnica a mais utilizada no mercado. (Aguiar) afirma
que nenhuma outra tcnica de medio funcional alcanou tal nvel de disseminao
ou investimento. Capers Jones afirma em (Jones, 2002) que a APF est
rapidamente se tornando uma mtrica dominante no mundo do software. (Aguiar)
ainda lista algumas razes pela qual utilizar Pontos de Funo:
A tcnica mantida por uma organizao internacional sem fins lucrativos
desde 1986, o International Function Point Users Group IFPUG;
Possui suporte no Brasil atravs do Brazilian Function Point Users Group
BFPUG;
Existe um programa de certificao mantido pelo IFPUG, com o objetivo de
certificar profissionais na tcnica, o que vem a aumentar sua credibilidade,
uma vez que profissionais possam aplic-la de forma normatizada;

14
padronizada internacionalmente pela ISO, atravs da norma ISO/TEC
20926, possibilitando uniformidade da aplicao;
Utiliza como base requisitos em alto nvel de abstrao, sendo independente
de artefatos, podendo ser utilizado por organizaes que utilizem qualquer
forma de representao de requisitos;
A existncia de grande acervo de dados sobre pontos de funo
armazenados por diversas organizaes possibilita a realizao de estudos e
comparaes;
A utilizao de pontos de funo em contratos e licitaes uma realidade no
Brasil, tendo surgido a partir de iniciativas de organizaes governamentais e
rapidamente alcanado o mercado em geral;

Dadas tais motivaes e o contexto do trabalho, o tpico seguinte detalha a
tcnica de Pontos de Funo, com o objetivo de explor-la, a fim de se obter
fundamentao terica para definio da sua aplicao em um programa de
medio.


2.4.1. Anlise de Pontos de Funo

2.4.1.1. A Anlise de Pontos de Funo
A Anlise de Pontos de Funo [APF], do ingls Function Point Analysis [FPA],
um mtodo padro para medio do desenvolvimento de software do ponto de vista
1

do usurio
2
(IFPUG, 2000). A APF mede o software quantificando a funcionalidade
que ele prov ao usurio, baseado em um design lgico inicial (IFPUG, 2000).


1
Viso do Usurio: qualquer descrio formal de suas necessidades de negcios em sua prpria
linguagem. A viso do usurio pode variar em sua forma fsica, podendo estar representada das
seguintes formas: Catalogo de transaes, documento de requisitos, especificaes externas,
especificaes detalhadas, manual do usurio, etc. (IFPUG, 2000).
2
Usurio para a APF: qualquer pessoa que especifique requisitos funcionais ou qualquer pessoa ou
coisa que interaja com o sistema. Exemplos: Ator em um caso de uso, uma aplicao, um gestor ou
um usurio final (Vazquez, et al., 2003).

15
Sendo assim, a tcnica tem como objetivo medir os produtos entregues, atravs da
medio do que ser construdo. Como a construo ser feita, quais processos,
metodologias, tecnologias, ferramentas, linguagens de programao, etc. no so
questes levadas em considerao na anlise de pontos de funo. Tal fato faz com
que a tcnica seja independente de tecnologia, possibilitando sua utilizao
consistente por diversas organizaes (Vazquez, et al., 2003). Em resumo, os
objetivos da anlise de pontos de funo so (IFPUG, 2000):
Medir a funcionalidade que o usurio solicita e recebe
Medir desenvolvimento e manuteno de software independentemente de
tecnologia de implementao
Ser uma medida consistente entre vrios projetos e organizaes
Ser simples o suficiente para eliminar o esforo adicional com a medio

Dentre os benefcios da anlise de pontos de funo o principal a possibilidade
da sua utilizao como um meio para se estimar custos e recursos necessrios para
o desenvolvimento e manuteno de software. Alm disso, a APF pode ser utilizada
como meio para medio do tamanho de pacotes, como fator de normalizao para
a comparao de software. A APF tambm pode apoiar na gerncia de escopo de
projetos de software, pois, uma vez que se tenha o tamanho do software medido,
possvel medi-lo novamente a cada alterao de escopo, conseguindo-se quantific-
las. A APF tambm pode ser utilizada na gerncia de contratos de software, servindo
como meio para quantificao de trabalho realizado, ou a realizar, permitindo a
precificao sobre uma medida comum e entendida por ambas as partes. A APF
tambm apia na mensurao de indicadores de qualidade e de produtividade, pois,
uma vez que se tenha estabelecido o tamanho do produto, que se saiba a
quantidade de tempo empregado para a construo deste produto e a quantidade de
defeitos encontrados neste produto, possvel apurar tais indicadores. Sem o
tamanho do produto estabelecido, tais indicadores no poderiam ser encontrados
com facilidade e preciso. O (IFPUG, 2000) confirma tais benefcios quando lista as
principais formas de utilizao da APF pelas organizaes:


16
Uma ferramenta para determinar o tamanho de um pacote de aplicao
adquirido, pois possibilita a contagem das funes contidas neste pacote;
Uma ferramenta para ajudar usurios a determinar os benefcios de uma
aplicao para sua organizao, pela contagem de funes que atendem
a seus requisitos;
Uma ferramenta para medir unidades de um produto de software,
suportando anlise quanto qualidade e produtividade;
Um meio para estimar custo e recursos requeridos para um
desenvolvimento de software ou manuteno;
Um fator de normalizao de software para comparaes.

Segundo (Vazquez, et al., 2003), a APF pode ser aplicada na maioria fases
do ciclo de vida de um software, entretanto, no aplicvel em todas, como por
exemplo, manutenes corretivas e manutenes perfectivas. Tal fato se d, pois
em tais fases no se tem a viso do usurio, uma vez que ele normalmente no
sabe o motivo da ocorrncia do erro corrigido na manuteno corretiva nem o que
melhorar tecnicamente na manuteno perfectiva. (Vazquez, et al., 2003) afirma
ainda que em algumas fases, dada a pouca quantidade de informaes, a APF pode
ser utilizada apenas no contexto de estimativa. A tabela 1 a seguir resume as fases,
quando a APF pode ser aplicada ou no, e, sendo aplicvel, se o resultado obtido
pode ser considerado como uma estimativa ou medio.

Tabela 1: Fases do ciclo de vida de desenvolvimento em que a APF pode ser aplicada,
adaptado de (Vazquez, et al., 2003)


17

Dado que a APF mede os requisitos do usurio em sua viso, importante
ressaltar quais tipos de requisitos que a APF se prope a medir. A norma ISSO/IEC
14.143-1 define que existem trs tipos de requisitos do usurio: Funcionais, de
Qualidade e Tcnicos. Os requisitos funcionais compreendem procedimentos que o
software deve executar para atender s necessidades do usurio. Os requisitos de
qualidade compreendem, conforme a norma ISO/IEC 9126, requisitos de
funcionalidade, confiabilidade, usabilidade, eficincia, manutenibilidade e
portabilidade. J os requisitos tcnicos compreendem a tecnologia para
desenvolvimento, manuteno e suporte a execuo do software, como por
exemplo: linguagens, ferramentas de teste, OS, BD e tecnologia de interface com o
usurio. Segundo (Vazquez, et al., 2003), dados tais tipos de requisitos, o nico que
a APF se prope a medir so os requisitos funcionais. (Vazquez, et al., 2003) afirma
ainda que para a APF, os requisitos funcionais so classificados em dois tipos:
Interao do usurio com o sistema (requisitos de transaes) e armazenamento
dos dados manipulados em transaes (requisitos de armazenamento).

2.4.1.2. Processo de contagem

O processo de contagem de pontos de funo pode ser representado pela Figura
1 a seguir. Cada caixa da figura representa um passo no processo de contagem,
que executado seqencialmente, de acordo com a ordem estabelecida. O
resultado do processo a aferio do nmero de pontos de funo ajustados. A
seguir, cada passo do processo ser explicado detalhadamente.


Figura 1: Processo de contagem de pontos de funo, adaptado de (IFPUG, 2000), pgina 31

18

Identificar o propsito da contagem
Como o prprio nome diz, neste passo, determina-se o propsito da
contagem. O propsito compreende o objetivo que se tem com a contagem, que
pode variar de acordo com o contexto em que a medio est inserida. O propsito
da contagem influncia na definio do tipo, escopo e fronteira da contagem
(IFPUG, 2000). Se a APF est sendo aplicada para se ter uma estimativa de esforo
com base em uma proposta de desenvolvimento de software, o objetivo da
contagem apurar o total de pontos de funo estimados. Se a APF est sendo
aplicada para contar uma aplicao instalada, visando verificar se o estimado est
de acordo com o realizado, o propsito da contagem apurar o tamanho do
software em pontos de funo. Uma vez que se tem o propsito identificado, sabe-se
o resultado esperado da aplicao da tcnica.

Determinar o tipo da contagem
A anlise de pontos de funo pode ser aplicada para medir trs tipos de
projetos: Projeto de desenvolvimento, Projeto de melhoria e Aplicao Base. No
projeto de desenvolvimento, medem-se as funes fornecidas na primeira instalao
do software, quando o projeto est completo [criao de um novo software]. No
projeto de melhoria, medem-se modificaes em aplicaes j existentes, entregues
quando o projeto est completo [manuteno evolutiva]. Na aplicao base, medem-
se as funes fornecidas ao usurio, da aplicao atualmente instalada [medio de
um projeto inteiro e funcional] (IFPUG, 2000).

Determinar a fronteira da aplicao
A fronteira da aplicao uma interface conceitual entre aplicao interna e o
mundo externo da aplicao, independente de consideraes tcnicas ou
implementao, de acordo com a viso externa de negcio do usurio da aplicao
(IFPUG, 2000). A definio da fronteira da aplicao muito importante no processo
de contagem, pois, uma vez tendo-a definida, pode-se saber o que deve ser contato
como sendo interno aplicao e o que deve ou no ser contado como sendo
externo aplicao. Para a APF, os itens que compem a parte interna de uma
aplicao tm pesos diferentes dos itens externos.

19
importante ressaltar, que para a delimitao da fronteira da aplicao, deve
ser levada em considerao a viso do usurio. Aspectos tcnicos no devem ser
levados em considerao na delimitao. Uma fronteira mal posicionada pode alterar
a perspectiva da contagem de uma viso lgica para uma viso fsica, o que pode
ter como conseqncia a duplicidade na identificao de funes, ou sua omisso
(Vazquez, et al., 2003).

Determinar o escopo da contagem
A determinao do escopo da contagem consiste na identificao da
funcionalidade que ser contada no processo de contagem (IFPUG, 2000). Define-
se quais as aplicaes envolvidas, quais funcionalidades e tipos de funcionalidades
sero contados. O escopo da contagem determinado pela identificao do
propsito da contagem. Uma vez que se tenha definido qual o propsito da
contagem, sabe-se o que est ou no no escopo. O escopo pode abranger a
contagem de uma aplicao inteira ou parte dela, pode abranger a contagem de
vrias aplicaes, ou, por exemplo, de um projeto que envolve a criao de uma
nova aplicao e a manuteno de outras que tero integrao com a nova
aplicao a ser construda.

Contar funes do tipo dados
O processo de contagem das funes do tipo dados consiste em identificar os
requisitos de armazenamento de dados sob a tica do usurio, de acordo com a sua
lgica, e classific-los quanto ao seu tipo e complexidade, determinando sua
contribuio individual em pontos de funo (IFPUG, 2000). Por exemplo: em um
sistema de emisso de notas fiscais, o usurio identifica que so entidades que
devem ser mantidas pelo sistema clientes e nota Fiscal. Uma vez identificadas tais
entidades, o passo seguinte a sua classificao.
importante ressaltar, que as funes do tipo dados devem ser identificveis
pelo usurio, ou seja, deve ser de seu conhecimento e reconhecimento. No so
consideradas funes do tipo dado, por serem meramente questes tcnicas de
implementao os seguintes itens: Vises de bancos de dados, armazenamento
visando maior performance, dados de domnio com inteno nica de manter
integridade referencial no banco de dados, dados de configurao da aplicao que
no estejam relacionadas ao negcio ou que no sejam reconhecidas pelo usurio

20
(IFPUG, 2000). Tal restrio dada para que no se tenha distores entre as
contagens em fases inicias, onde no se tem detalhamentos tcnicos e as fases
finais, onde toda a aplicao e soluo tcnica j foi definida.
As funes do tipo dado podem ser classificadas de duas formas (IFPUG,
2000):

ALI Arquivos lgicos internos: Armazenamento de dados, identificvel
pelo usurio, mantido dentro da fronteira da aplicao contada. Exemplos:
o Tabelas que armazenam dados da aplicao
o Entidades de negcio
o Entidades de referncia
o Arquivos mantidos no s pela aplicao, mas tambm por outra
aplicao
AIE Arquivo de interface externa: Armazenamento de dados, identificvel
pelo usurio, mantido fora da fronteira da aplicao contada, porm, utilizado
pela aplicao contada em algum momento. Exemplos:
o Dados externos utilizados pela aplicao

importante ressaltar que o termo arquivo utilizado na nomenclatura das
funes do tipo dado no se refere a um arquivo fsico de um sistema e sim a um
agrupamento lgico de dados (IFPUG, 2000). Uma vez classificados quanto ao tipo,
o prximo passo a determinao da complexidade. Para tal, para cada arquivo
lgico identificado, determina-se a quantidade de tipos de dados e tipos de registros
que o arquivo lgico compreende.
Um tipo de dado um campo nico, reconhecido pelo usurio e no repetido
(IFPUG, 2000). Um exemplo de tipo de dado do arquivo lgico nota fiscal seu valor
total. J um tipo de registro um subgrupo de dados dentro de um arquivo lgico,
reconhecido pelo usurio (IFPUG, 2000), como por exemplo, os itens da nota fiscal.
Uma vez apurado o arquivo lgico, a quantidade de tipos de dados e tipos de
registros compreendidos, o passo seguinte classific-lo quanto a sua
complexidade. Para tal, a tabela 2 a seguir deve ser considerada.


21
Tabela 2: Matriz complexidade ALI / AIE, adaptado de (IFPUG, 2000), pgina 69

TR Tipo de Registro / TD Tipo de Dado

Contar funes do tipo transao
Para ter entendimento quanto ao processo de contagem das funes do tipo
transao, necessrio que se tenha esclarecido antes um conceito chave da APF,
que o processo elementar. O processo elementar a menor unidade de atividade
com significado para o usurio, completo em si mesmo, que deixa a aplicao em
estado consistente (IFPUG, 2000). Em outras palavras, um processo elementar pode
ser entendido como uma funcionalidade completa do sistema que o usurio enxerga,
por exemplo: Cadastrar clientes, emitir nota fiscal, etc.
O processo de contagem das funes do tipo transao consiste em
identificar os processos elementares da aplicao que est sendo contada,
identificar a principal inteno de cada processo elementar encontrado, classific-los
quanto ao tipo e quanto a complexidade, determinando sua contribuio individual
em pontos de funo (Vazquez, et al., 2003).
Uma vez identificados os processos elementares, o passo seguinte
identificar sua principal inteno, classificando-o. Os processos elementares podem
ser classificados em:

Entrada Externa: Processo elementar que processa dados ou informaes
de controle
3
vindos de fora da fronteira da aplicao, mantendo um ou mais
ALI (IFPUG, 2000). Exemplos (Vazquez, et al., 2003):
o Transaes que recebem dados externos utilizados na manuteno de
ALIs;


3
Informaes de Controle: Influencia processos elementares da aplicao. Especifica o que,
quando ou como os dados so processados (IFPUG, 2000).

22
o Operaes de incluso, excluso e alterao de registros em arquivos;
o Processamento em lotes de atualizao de bases cadastrais a partir de
arquivos de movimento;

Consulta Externa: Processo elementar que envia dados ou informaes de
controle para fora da fronteira da aplicao. Nas consultas externas no h
manuteno de ALIs nem apurao de frmulas, clculos ou dados
derivados
4
(IFPUG, 2000). Exemplos (Vazquez, et al., 2003):
o Gerao de arquivo de movimento para outra aplicao;
o Recuperao de dados com base em critrios informados;
o Consultas implcitas, embutidas em outras transaes;
o Telas de login com verificao de senhas;
o Controles tipo drop down [lista suspensa] ou semelhantes;

Sada Externa: Processo elementar que envia dados ou informaes de
controle para fora da fronteira da aplicao, mantendo um ou mais ALIs ou
contendo apurao de frmulas, clculos ou dados derivados (IFPUG, 2000).
Exemplos (Vazquez, et al., 2003):

o Relatrio com totalizao de dados;
o Relatrios que tambm atualizam arquivos;
o Consultas contendo clculos ou gerao de dados derivados;
o Informaes em formato grfico;
o Telas de login com informao de senha, em que a senha
criptografada;

Uma vez identificado e classificado o processo elementar, o prximo passo
a determinao da sua complexidade, o que permite determinar sua contribuio em
pontos de funo. Para tal, o processo semelhante determinao de
complexidade dos arquivos lgicos, porm, para as funes do tipo transao,


4
Dados Derivados: Dados que requerem processamento que no seja apenas ou que seja adicional
recuperao simples e validao de informaes de arquivos lgicos (IFPUG, 2000).

23
conta-se a quantidade de arquivos referenciados e tipos de dados envolvidos no
processo elementar (IFPUG, 2000).
Tipos de dados so campos, reconhecidos pelo usurio, no repetidos, que
entram ou saem da aplicao e que sejam relevantes a execuo do processo
elementar (Vazquez, et al., 2003). Podem ser considerados tipos de dados o nome
do cliente em um relatrio de clientes, a ao que dispara a emisso do relatrio,
como por exemplo o clique no boto emitir, a mensagem exibida informando que o
relatrio foi impresso com sucesso, etc., ou seja, todas as informaes relevantes,
envolvidas no processo elementar. J para a contagem dos arquivos referenciados
so considerados os arquivos lgicos envolvidos no processo de alguma forma, seja
sendo consultados ou mantidos (IFPUG, 2000). Por exemplo, o arquivo lgico de
clientes um arquivo referenciado na emisso de relatrio de clientes.
Contados os processos elementares, classificados quanto ao seu tipo e
definidas as quantidades de tipos de dados e arquivos referenciados para cada
processo elementar identificado, o prximo passo sua classificao quanto a sua
complexidade. Tal classificao dada pelas tabelas 3 e 4 a seguir.

Tabela 3: Matriz de complexidade EE, adaptado de (IFPUG, 2000), pgina 165


Tabela 4: Matriz de complexidade SE / CE, adaptado de (IFPUG, 2000), pgina 166


AR TIPO DE REGISTRO / TD TIPO DE DADO


24
Determinar contagem de pontos de funo no ajustados
A contagem dos pontos de funo no ajustados se d pela converso da
quantidade de funes do tipo dados e transao classificadas quanto
complexidade, para o nmero de pontos de funo correspondente de acordo com
cada tipo de funo e complexidade (IFPUG, 2000). Tal transformao feita de
acordo com a tabela 5 a seguir.

Tabela 5: Matriz Tipo Funo - Contribuio em PF, adaptado de (IFPUG, 2000), pginas 69 e
167


Uma vez que se tenha a quantidade de funes de cada tipo e complexidade,
e se saiba a contribuio em pontos de funo de cada tipo de funo e
complexidade, pode-se chegar ao nmero de pontos de funo no ajustados da
aplicao contada. A tabela 6 a seguir ilustra um exemplo de uma contagem de
pontos de funo no ajustados de uma aplicao.


25
Tabela 6: Exemplo de contagem de pontos de funo no ajustados


Determinar o fator de ajuste
O fator de ajuste indica a funcionalidade geral fornecida pela aplicao ao
usurio, ou seja, caractersticas gerais da aplicao que refletem funes que
afetam a aplicao de maneira geral, no consideradas na contagem de funes do
tipo dado e funes do tipo transao. O objetivo com a aplicao do fator de ajuste
ajustar o nmero de pontos de funo por conta de caractersticas da aplicao
que impactem no esforo empregado, no medido na contagem dos pontos de
funo no ajustados (Vazquez, et al., 2003).
O processo de determinao do fator de ajuste consiste na pontuao de zero
a cinco quanto ao nvel de influncia em relao aplicao medida, para quatorze
caractersticas gerais do sistema [CGS] (IFPUG, 2000). Tais caractersticas so
listadas a seguir:
1. Comunicao de Dados
2. Processamento Distribudo
3. Performance
4. Configurao Altamente Utilizada
5. Volume de Transaes
6. Entrada de Dados On-Line
7. Eficincia do Usurio Final

26
8. Atualizao On-Line
9. Complexidade de Processamento
10. Reusabilidade
11. Facilidade de Instalao
12. Facilidade de Operao
13. Mltiplos Locais
14. Facilidade de Mudanas

Uma vez apurado o nvel de influncia de cada caracterstica geral do sistema, a
sua somatria reflete o nvel total de influncia. Este nvel multiplicado por 0,01 e
somado a 0,65, chegando-se ao fator de ajuste da aplicao, podendo este variar de
0,65 a 1,35, produzindo um ajuste de -35% ou +35% (IFPUG, 2000). A frmula que
contempla tal operao apresentada a seguir.

Valor Fator Ajuste = (Total Nvel Influncia * 0,01) + 0,65

Determinar o nmero de pontos de funo ajustados
Uma vez apurado o nmero de pontos de funo da aplicao contada, e o
fator de ajuste, pode-se chegar ao nmero de pontos de funo ajustados. Tal
nmero indica o tamanho funcional da aplicao em pontos de funo.
A apurao do nmero de pontos de funo ajustados varia de acordo com o
tipo da contagem realizada, pois cada tipo de contagem envolve operaes
diferenciadas. Enquanto uma contagem de aplicao base mede a aplicao j
implantada para o usurio, um projeto de desenvolvimento mede um projeto de um
sistema novo, onde podem estar envolvidas criaes de funes de converso de
dados, caso dados pr-existentes sejam aproveitados. J em um projeto de
melhoria, funes podem ser alteradas, inclusas e excludas. Considerando-se tais
diferenas entre os tipos de contagem, a seguir so apresentadas as frmulas para
apurao do nmero de pontos de funo ajustados para cada tipo de contagem.

Contagem do Tipo Aplicao Base: Na contagem dos pontos de funo de
uma aplicao j instalada para o usurio, medem-se apenas as
funcionalidades j disponveis. Para tal, a frmula para apurao a seguinte
(IFPUG, 2000):

27

PFA = PFNA * VFA, onde:
PFA = Pontos de funo da aplicao
PFNA = Pontos de funo no ajustados
VFA = Valor do fator de ajuste

Contagem do Tipo Projeto de Desenvolvimento: J para os projetos de
desenvolvimento, como mencionado anteriormente, funes de converso
podem fazer parte do projeto. Para chegar-se ao nmero de pontos de funo
ajustados para este tipo de projeto, a frmula utilizada (IFPUG, 2000):

PFD = (PFNA + PFFC) * VFA, onde:
PFD = Pontos de funo projeto de desenvolvimento
PFNA = Pontos de funo no ajustados
PFFC = Pontos de funo de funes de converso
VFA = Valor do fator de ajuste

Contagem do Tipo Projeto de Melhoria: Nos projetos de melhoria, alm das
eventuais funes de converso, novas funes podem ser adicionadas,
funes existentes podem ser modificadas ou excludas. Considerando-se tal
cenrio, para se apurar o nmero de pontos de funo ajustados para este
tipo de projeto, a formula utilizada a seguinte (IFPUG, 2000):

PFM = [(PFAD + PFAL + PFFC) * VFAN] + (PFEX * VFAA), onde:
PFM = Pontos de funo projeto de melhoria
PFAD = Pontos de funo de funes adicionadas
PFAL = Pontos de funo de funes alteradas
PFEX = Pontos de funo de funes excludas
PFFC = Pontos de funo de funes de converso
VFAN = Valor do fator de ajuste da aplicao aps melhoria
VFAA = Valor do fator de ajuste anterior ao projeto de melhoria


28
3. PROGRAMA DE MEDIO

3.1. INTRODUO

Para que se melhore uma organizao de TI, necessrio que se use dados
para determinar boas prticas, melhorar o modelo de processos, estabelecer
benchmarks, analisar tendncias, melhorar estimativas, estabelecendo um
conhecimento sobre a organizao que vai de gerentes a desenvolvedores (Russac,
2002). (Holmes, 2002) afirma que o uso do sentimento como subsidio para tomada
de deciso no uma forma eficaz. (Dekkers, 2002) afirma ainda que no se pode
gerenciar o que no se pode medir. Organizaes de software precisam de uma
forma de gerenciar a carga de trabalho e decidir o que fazer, quando fazer e onde
fazer.
Tais formas de gerenciamento e meios de tomadas de deciso podem ser
providos por um programa de medio, o qual pode ser definido como a aplicao
continua de tcnicas baseadas em medio para o processo de desenvolvimento de
software e seus produtos, visando sua melhoria, promovendo gerenciamento de
informao rpida e significante (Dekkers, 2002).
Contextualizada a medio de software no captulo anterior, este captulo vem
a apresentar conceitos de um programa de medio, seus objetivos, benefcios e
composio. Dentro dos objetivos deste trabalho, este captulo vem a explorar os
conceitos de programas de medio, visando prover base terica para o
estabelecimento de uma abordagem de programa de medio baseado em anlise
de pontos de funo.


3.2. OBJETIVOS DE UM PROGRAMA DE MEDIO

Um programa de medio tem como objetivo medir um processo de
desenvolvimento de software ou um determinado projeto de desenvolvimento de
software em termos de atributos quantitativos, possibilitando anlises com base em
dados concretos, permitindo a identificao de pontos falhos e boas prticas,

29
possibilitando a melhoria contnua do processo de desenvolvimento de software da
organizao que o aplica.
Tais melhorias no processo de desenvolvimento de software trazem como
conseqncia a melhoria nos produtos de software desenvolvidos pela organizao,
o que vem a aumentar a satisfao dos clientes, melhorar o ambiente de trabalho da
equipe de TI e a reduzir custos da organizao de TI como um todo.


3.3. BENEFCIOS DA IMPLEMENTAO DE UM PROGRAMA DE MEDIO

Uma vez que se tenha estabelecido um programa de medio, mtricas
podem ser usadas para identificao de boas prticas, melhora no processo de
desenvolvimento, estabelecimento uma linha de base para se determinar
tendncias, apoio em estimativas e planejamento de projetos, apoio no
gerenciamento de oramento, identificao da quantidade e a qualidade de um
produto distribudo, comparao da efetividade e eficincia do processo atual e
ferramentas, prover base para comparaes de mercado e permitir melhor
comunicao entre clientes e desenvolvedores (Russac, 2002). Alm disso, as
mtricas ajudam ainda a clarear os detalhes quanto definio do produto correto, a
execuo efetiva do projeto e a distribuio do produto no tempo correto (Dekkers,
2002). Com alguns indicadores de projetos, como produtividade, qualidade e
previsibilidade de estimativas, lideres podem tomar suas decises baseadas em
informaes slidas, ao invs de apenas sentimentos ou experincias pessoais
(Silveira, 2002).
Alm das possibilidades de melhoria no processo e de qualidade, iniciativas
do mercado atual vm a confirmar que a medio de software formal leva a um
melhor gerenciamento e acompanhamento do processo de desenvolvimento de
software. Entre tais iniciativas, esto o ISSO 9000 e iniciativas de melhoria de
processo definidas pelo Software Engineering Institutes Capability Maturity Model
[SEI CMM for Software] e o Capability Maturity Model Integration [CMMI] (Dekkers,
2002).



30
3.4. COMPOSIO DE UM PROGRAMA DE MEDIO

Um programa de medio pode variar, dentre outros fatores, de acordo com a
necessidade, oramento, tempo e quantidade de pessoas disponveis de cada
organizao. Independentemente de tais caractersticas, a formalizao de um
programa de medio deve conter um conjunto de padres e procedimentos para
coleta, armazenamento, anlise e reporte de dados. Alm disso, papis e
responsabilidades devem ser definidas para suportar a execuo do programa
(Silveira, 2002).
Tais definies por si s no so suficientes. Para ser bem sucedido, o
programa de medio deve ser baseado em objetivos e metas da organizao, as
quais vem a definir o que se espera melhorar e em que nvel, com a implementao
do programa de medio (Silveira, 2002; Dekkers, 2002; Russac, 2002).
Definidos os objetivos e metas, medies que resultem em informaes que os
suportem devem ser definidas. O passo seguinte a definio de como tais
medies sero realizadas e posteriormente como sero analisadas e reportadas. O
ltimo passo ento, a definio de como tal programa de medio ser
implementado na organizao, o que contempla a definio da forma de
implementao, recursos envolvidos, documentao e educao necessrias.
(Holmes, 2002) e (Dekkers, 2002) definem ainda que o programa de medio
deve ser implementado e melhorado de forma contnua. Uma vez que o primeiro
conjunto de medies tenha sido implementado com sucesso, os objetivos podem
ser revisados para determinar o prximo conjunto de medies para definir e
implementar (Holmes, 2002).
(Dekkers, 2002) ilustra tal raciocnio com a Figura 2 a seguir. Tal figura
representa resumidamente tambm, todos os passos do programa de medio
descritos anteriormente. No planejamento, identifica-se os objetivos da corporao
antes que o programa seja desenhado e implementado. Na implementao,
selecionam-se e desenham-se as mtricas apropriadas que atendam o planejado,
em conjunto com treinamento, iniciao e coleta de medies piloto especificas. No
passo de medio, a coleta de dados atual, anlise, auditoria e reporte de dados so
feitos com as medies alvo, e informaes gerenciais so compiladas e
apresentadas. No passo final, ao, identifica-se e constroem-se melhorias de
processos apropriadas, baseadas nas informaes do passo anterior. Do passo da

31
ao, volta-se ento para o passo do planejamento, garantindo-se que o programa
de medio ainda est dentro do escopo definido e coletando as mtricas corretas
(Dekkers, 2002).


Figura 2 - Processo cclico de um programa de medio, adaptado de (Dekkers, 2002), pgina
163

A seguir, cada passo do programa de medio citado discutido em detalhes.


3.4.1. Planejamento - objetivos e metas da organizao

Um programa de medio s tem sentido quanto est alinhado com objetivos e
metas da organizao de TI. Caso contrrio, o programa poder no sobreviver por
muito tempo, pois alm de depender muito do apoio de nveis gerenciais, caso no
traga nenhum benefcio para a organizao, esforos gastos com o programa no
tero sentido.
Uma das principais caractersticas de um programa de medio, que atravs
dele, informaes para tomada de decises podem ser obtidas. Alm disso, um
programa de medio pode mostrar a situao atual da organizao, possibilitando o
estabelecimento de metas. Tais objetivos e metas podem e devem ser estabelecidos
no planejamento do programa. (Holmes, 2002) confirma tal raciocnio quando afirma
que importante que sejam estabelecidos objetivos e metas para que se tenha
como produto do programa de medio exatamente o que se precisa. Caso no
definidos, o produto da medio poder ser intil.

32
Os objetivos podem variar de departamento para departamento e de nvel para
nvel, por isso, devem ser realizadas entrevistas com grupos que abranjam todos os
departamentos e nveis envolvidos. (Holmes, 2002) afirma que importante que
empregados de todos os nveis sejam entrevistados, fazendo com que se sintam
parte do processo de definio, facilitando-o como um todo. (Holmes, 2002) afirma
ainda que importante que o escopo de tais objetivos e metas seja bem definido, de
forma a no sobrecarregar pessoas. Visando a definio apropriada de tal escopo,
(Silveira, 2002) acredita que a implementao pode ter uma abordagem baseada em
fases.
Para a efetiva definio de tais objetivos, (Dekkers, 2002) afirma que
importante que se leve em considerao algumas caractersticas. Para (Dekkers,
2002) os objetivos devem ser: estratgicos, mensurveis, atingveis, realsticos e
focados. Uma vez definidos os objetivos e metas, eles devem ser consolidados e
priorizados (Holmes, 2002). A seguir, (Holmes, 2002) relaciona alguns exemplos de
objetivos de um programa de medio:

Melhorar a produtividade dos projetos;
Melhorar a qualidade dos projetos;
Reduzir o custo dos projetos;
Implementar inspees formais.


3.4.2. Definio de medies

Definidos os objetivos e metas, o passo seguinte a definio das medies
que sero necessrias para endere-los. Devem ser definidas medidas que
mostrem o status ou progresso de cada objetivo ou iniciativa em particular (Holmes,
2002).
Se um objetivo da organizao melhorar a produtividade da manuteno em
50%, algumas questes de mtricas devem ser Quais so nossos nveis atuais de
suporte?, Quantas oportunidades de melhorias existem?, Como ns saberemos
quando atingirmos 50% de melhora?. As mtricas requeridas para responder a tais
perguntas incluem as taxas de suporte do passado e atuais (por exemplo, horas
trabalhadas em manuteno por tamanho do produto), combinadas com

33
caractersticas das aplicaes (como o tipo e linguagem de desenvolvimento) e
nveis de qualidade e suporte (defeitos por tamanho do produto suportado). A seguir,
(Holmes, 2002) ilustra um exemplo de objetivos e medidas que os endeream.

Tabela 7 - Relao Objetivos X Medidas, adaptado de (Holmes, 2002), pgina 100


Na tabela 7, pode ser observado que dependendo das questes que a
organizao pretende responder, diferentes mtricas devem se requeridas para
prover respostas (Dekkers, 2002). Uma medida pode suportar mais de um objetivo,
permitindo que mais objetivos sejam endereados (Holmes, 2002).
Pode ser observado tambm, que a medio em pontos de funo uma
medida presente em todas as mtricas que endeream objetivos. O tamanho de
aplicaes de software em pontos de funo, em conjunto com outras medies,
produzem mtricas normalizadas por tamanho em pontos de funo as quais podem
ser calculadas e usadas para anlises comparativas (Dekkers, 2002). Como
exemplo, (Dekkers, 2002) afirma que para calcular taxas de entrega, o tamanho de
cada produto de desenvolvimento em pontos de funo pode ser dividido pelo
esforo de trabalho empregado em horas. Tal taxa de entrega pode ser utilizada
para anlises comparativas entre organizaes, proporcionando oportunidades de
melhoria no processo.
(Dekkers, 2002) cita ainda outras aplicabilidades do tamanho em pontos de
funo no endereamento de objetivos. Mtricas de produtividade e entrega podem

34
ser calculadas pela utilizao de pontos de funo com outras medidas. Mtricas de
qualidade (densidade de defeitos) e proporcionalidade de suporte (tamanho da
aplicao suportada, por pessoas envolvidas no trabalho de manuteno) so
tambm possveis utilizando-se pontos de funo e outras medidas correlatas
coletadas.
O quanto as mtricas apiam no endereamento dos objetivos definidos e
quantos objetivos uma mtrica pode enderear, deve ser um fator levado em
considerao na definio das mtricas utilizadas pela organizao. A seguir,
(Dekkers, 2002) relaciona medidas que podem ser utilizados no endereamento de
objetivos e o quanto tais medidas podem ser reaproveitadas.

Tabela 8 - Aplicabilidade de medidas para endereamento de objetivos, adaptado de (Dekkers,
2002), pgina 165




35
3.4.3. Definio de coletas de dados

Uma vez que as medidas que endeream os objetivos definidos estejam
estabelecidas, o passo seguinte a definio das coletas de dados que sero
necessrias para que se chegue a tais medidas. (Holmes, 2002) organiza a coleta
de dados em quatro passos:

1. Definio de dados necessrios;
2. Definio de pontos de coletas de dados;
3. Definio de responsabilidades pela coleta dos dados;
4. Meios de coletas de dados.

A seguir, cada passo citado discutido.

3.4.3.1. Definio de dados
Definem-se quais dados so necessrios para suportar as mtricas definidas.
Cada pedao de dado necessrio para uma medida precisa ser identificado e
definido em termos que todos possam entender. Por exemplo, se medio da
produtividade atravs de pontos de funo por hora selecionado, pontos de funo
e esforo gasto em horas sero dados requeridos. O esforo gasto precisar ainda
ser definido baseado nas atividades que devem ser consideradas na sua
composio, como por exemplo, definio de requisitos, design, codificao, etc.
(Holmes, 2002).

3.4.3.2. Definio de pontos de coletas de dados
Definem-se os pontos do processo de desenvolvimento em que os dados
definidos sero coletados. Para (Holmes, 2002), as atividades de coleta de dados
devem ser integradas ao ciclo de vida do processo de desenvolvimento, fazendo
com que a medio torne-se parte do processo e no seja percebido como algo
extra. (Holmes, 2002) afirma ainda que a coleta de dados deve ser feita apenas em
pontos necessrios para suportar as medies selecionadas. Por exemplo, se o
objetivo melhorar a produtividade do projeto e a medio escolhida para o
acompanhamento da produtividade pontos de funo por hora, significa que ser

36
necessrio fazer a contagem em pontos de funo durante determinadas fases do
projeto.

3.4.3.3. Definio de responsabilidades pela coleta dos dados
Uma vez definidos os dados e os pontos de coleta, definem-se os papis
responsveis pela coleta e divulgao dos dados. Tal tarefa consiste na identificao
dos papis exercidos durante o processo de desenvolvimento de software executado
pela organizao, definindo-se quais, dentre os papis identificados, sero
responsveis pela coleta e divulgao de cada parte de informao, de acordo com
suas atribuies, habilidades e funes.

3.4.3.4. Meios de coletas de dados
A definio de meios de coletas de dados implica na definio dos mtodos e
formas empregadas em cada tarefa de coleta. (Holmes, 2002) afirma que para tal,
importante que os dados j existentes da organizao sejam aproveitados.
Uma vez definidos os dados, pontos de coletas, responsabilidades e meios,
(Holmes, 2002) ilustra um exemplo da relao entre tais informaes.

Tabela 9 - Relao Objetivos, Medies, Dados e Responsabilidades, adaptado de (Holmes,
2002), pginas 103 e 104


37
3.4.4. Anlise e reporte de resultados

Definidos os objetivos, mtricas, dados, responsabilidades e pontos de coleta, o
passo seguinte a definio de como tal conjunto de informaes ser reportado,
para quem ser reportado e com que freqncia (Holmes, 2002). Os relatrios de
um programa de medio so itens chave em qualquer programa de medio.
atravs deles e das anlises feitas sobre eles que o programa de medio se
justifica, uma vez que os relatrios provero informaes necessrias quanto ao
andamento na busca pelos objetivos da organizao e as anlises provero insumos
para melhoria no processo de desenvolvimento como todo.
(Silveira, 2002) considera que os relatrios de um programa de medio podem
ser produzidos para prover informaes quanto a tendncias de produtividade,
defeitos e tempo de resposta ao mercado. (Silveira, 2002) afirma ainda que resumo
dos projetos, detalhes e relatrios de anlises podem ser gerados para cada projeto
finalizado.
Para a definio de como os dados sero reportados, (Holmes, 2002) afirma
que importante considerar que as vrias audincias identificadas podem ter
diferentes necessidades ou foco, podendo ser necessrios relatrios
individualizados. As audincias dos relatrios podem incluir gerentes de projetos,
gerentes da rea de desenvolvimento, time de medio, times de projetos e outros.
(Holmes, 2002) afirma que o pblico alvo dos relatrios devem ser envolvidos para
validao dos resultados e verificao quanto ao atendimento de expectativas e
necessidades, sendo que especificamente o time de projeto deve receber anlises e
relatrios do projeto em que participaram, podendo utilizar os dados para identificar
possibilidades de melhorias em seus prximos projetos.
Compilar e reportar os dados coletados por si s no suficiente. (Holmes,
2002), (Silveira, 2002) e (Russac, 2002) afirmam que anlises sobre os resultados
devem ser feitas, permitindo a identificao de pontos positivos e falhos nos
projetos, objetivando a promoo dos pontos positivos e a extino dos pontos
falhos para nos prximos projetos. (Russac, 2002 p. 154) afirma que o ponto mais
critico de todo o processo de mtricas a anlise dos dados e ainda questiona:
Para que serve uma coleo de dados se no so analisados quanto aos aspectos
bons e ruins do projeto?.

38
Para (Silveira, 2002), o processo de anlise de resultados deve incluir a anlise
de indicadores de performance do projeto, comparando seus resultados contra
projetos passados, a performance geral da organizao, corporao e industria ou
benchmarks de mercado. (Russac, 2002) afirma ainda que a utilizao de um banco
de dados de mtricas torna possvel tal comparao. A figura 3 a seguir ilustra um
exemplo de relatrio comparativo entre resultados do projeto e os resultados da
organizao e do mercado.

Projeto XYZ

Os resultados apresentados so fictcios.
Figura 3 - Exemplo de relatrio comparativo de medies, adaptado de (Russac, 2002), pgina
155

(Silveira, 2002) afirma que baseado em tal anlise, reas de melhoria no
processo devem ser identificadas, recomendando aes para projetos futuros.
Complementando tal raciocnio, (Holmes, 2002) afirma que os dados no devem ser
reportados sem contextos ou explicaes. Para (Holmes, 2002) necessrio que
anlises sejam feitas sobre os dados e que seja assegurado que as informaes
sero interpretadas e usadas de maneira correta pela audincia. (Holmes, 2002) cita
ainda trs informaes que no podem faltar nos relatrios de um programa de
medio:

39
Observaes: O que foi identificado. Exemplo: Defeitos entregues por
pontos de funo diminuram no ltimo perodo para algumas reas;
Concluses: O que a anlise est dizendo. Exemplo: A diminuio nos
defeitos entregues nestas reas pode ser atribudo a implementao das
inspees formais durante o ciclo de vida;
Recomendaes: Como proceder diante de tais observaes e concluses.
Exemplo: Inspees formais devem ser consideradas para toda a
organizao.

Para que se chegue a concluses quanto ao projeto executado, (Russac, 2002)
afirma que importante que se faam reunies com o time do projeto, apresentando
resultados parciais, apontando reas falhas e questionando quanto aos fatores que
possam ter contribudo para o resultado. Se por exemplo a taxa de produtividade foi
muito abaixo de projetos similares, (Russac, 2002) afirma que importante que se
olhe as razes possveis, como por exemplo, a utilizao de uma nova ferramenta
ou tecnologia sem o devido preparo. Para (Russac, 2002) to importante quanto
identificao de reas falhas, a identificao das reas positivas, identificando-se
as razes do sucesso, possibilitando que o time continue com suas melhores
prticas.
Aps ter analisado os dados, ter se reunido com o time do projeto e ter
identificado pontos positivos e falhos, bem como seus motivos, (Russac, 2002)
define que um relatrio deve ser divulgado no s ao time do projeto, como tambm
a todos os times de projetos e gerentes, possibilitando que todos aprendam com as
lies aprendidas.
Alm dos relatrios de projetos, relatrios organizacionais tambm podem ser
elaborados, comparando-se diferentes mtricas da organizao atravs do tempo.
Grficos para cada mtrica, representando o perodo atual, podem demonstrar a
gerentes e executivos tendncias organizacionais, alertando-os para reas que
requerem melhorias futuras ou reconhecimento (Russac, 2002). A seguir
apresentado um exemplo de tal relatrio.

40

Figura 4 - Exemplo de relatrio de mtricas organizacional, adaptado de (Russac, 2002), pgina
156


3.4.5. Implementao do programa de medio
Definidos os objetivos e metas, dados, coletas, responsabilidades, formas de
anlise e reporte de resultados, preciso que se planeje a implementao do
programa. Tal implementao pode variar quanto forma, tamanho, quantidade de
recursos envolvidos, escopo, fases, tipo e tamanho da organizao, dentre outros
fatores. Para (Holmes, 2002), a implementao do programa de medio requer
planejamento e desenvolvimento, bem como tomada de decises, sendo que a
abordagem seguida pode depender do nvel de recursos e da estrutura da
organizao. Tais variantes so discutidas a seguir.

3.4.5.1. Forma de implementao
(Holmes, 2002) define que as possveis formas de implementao de um
programa de medio podem variar da seguinte forma:

Em toda a organizao de uma s vez;
Em projetos selecionados ou aplicaes em algumas reas ou departamentos;
Em reas ou departamentos selecionados em fases, enquanto o processo
incorporado na organizao.

41
Para (Dekkers, 2002), iniciar um programa de medio em toda a organizao
de uma s vez no a melhor escolha, pois, corre-se o risco de se chegar a
mtricas desalinhadas, alm do risco da introduo de um novo conceito de forma
abrupta. (Dekkers, 2002 p. 166) afirma ainda que a melhor forma de se iniciar um
programa de medio atravs de um projeto piloto e argumenta: Pequeno e tmido
sempre melhor do que audacioso e catico para a implementao de novos
conceitos.

3.4.5.2. Formas de utilizao de recursos
(Holmes, 2002) afirma que dado o esforo necessrio de recursos para a
realizao das atividades do programa de medio, preciso que se defina quais
recursos sero envolvidos, considerando-se o tempo disponvel de cada recurso e
seu expertise no assunto. Diante de tal necessidade, (Holmes, 2002) aponta trs
possibilidades quando da definio da forma de utilizao de recursos em um
programa de medio:
Utilizar um recurso de cada departamento;
Utilizar recursos externos;
Estabelecer um grupo centralizado de mtricas.

(Russac, 2002) afirma ainda que mais de uma possibilidade pode ser
combinada, principalmente em fases iniciais do programa, onde o conhecimento de
medio e expertise no assunto so necessrios. Para (Holmes, 2002), consultorias
ou especialistas no assunto podem ser contratados inicialmente para apoiar no
programa de medio, transferindo aos poucos seu conhecimento para a equipe
interna, at que se consiga estabelecer um time centralizado de medio.

3.4.5.3. Documentao do programa e mtodos
Definida a forma de implementao e os recursos envolvidos, (Holmes, 2002)
afirma que a documentao do processo de medio e seus mtodos deve ser feita.
Para tal, (Holmes, 2002) define que deve ser documentado como o programa de
medio ser integrado ao ciclo de desenvolvimento atual, as atividades especificas
de medio, quando e como tais atividades so executadas, formulrios,
ferramentas e formatos de relatrios, desta forma garantindo que o programa ser
implementado consistentemente, sendo claro para todos os envolvidos.

42

3.5. FATORES CRTICOS DE SUCESSO EM UM PROGRAMA DE MEDIO

Programas de medio podem falhar, podem no produzir o resultado esperado
ou mesmo podem gerar sentimentos indesejveis nas equipes de projetos, levando
a conseqncias incalculveis caso no sejam implementados adequadamente ou
caso detalhes importantes no sejam levados em considerao.
Ao definir um programa de medio muito importante que sejam levadas em
considerao boas prticas e experincias vividas por pessoas com experincia no
assunto. A seguir, uma lista de fatores considerados como crticos para os autores
considerados nesta pesquisa so listados.

Preciso e consistncia de dados: Dados so suscetveis a forma como so
alimentados. Caso os dados no sejam precisos na alimentao, os resultados
tambm no sero precisos. muito importante que as informaes utilizadas
pelo programa de medio sejam consistentes. O lanamento de horas
trabalhadas em projetos um dos principais pontos de ateno. Horas extras,
horas gastas em manuteno de aplicativos diversos, horas gastas em reunies
fora do projeto, etc. devem ser computadas apropriadamente, para no
influenciar no resultado do projeto (Silveira, 2002; Dekkers, 2002; Russac, 2002);
Integrao ao dia-a-dia: Programas de medio bem sucedidos so aqueles
que se tornam parte do processo dirio. Para ser bem sucedida, a medio no
pode ser vista como um trabalho adicional, ou como tarefas sem valor agregado
no ciclo de desenvolvimento (Dekkers, 2002). Lderes seniores e gerentes de
projetos precisam acreditar no programa de mtricas, fazendo todos os esforos
possveis para garantir que o processo de mtricas est sendo seguido e as
pessoas esto tendo tempo suficiente para coletar dados das mtricas (Silveira,
2002);
Compromisso com a implementao: Organizaes que implementam
medio como algo a ser feito no tero sucesso. preciso que se tenha
compromisso com a mudana. O sucesso do programa ser determinado pela
fundio da gerncia continua (Dekkers, 2002);
Alinhamento com os objetivos da organizao: O programa de mtricas deve
apoiar na melhoria do processo e deve estar alinhado com os objetivos da

43
organizao. importante que sejam analisados cenrios antes e depois do
programa de medio, estabelecendo uma correlao entre as iniciativas de
melhorias do processo e dos resultados atuais, verificando como os resultados
da melhoria do processo esto impactando os objetivos da organizao (Silveira,
2002). Alm disso, quando o programa de medio est alinhado com os
objetivos e iniciativas da organizao, o processo torna-se parte de algo que j
acontece no dia-a-dia, sendo significante para todos os colaboradores (Holmes,
2002);
Pensar grande, porm, comear pequeno: importante que sejam
selecionadas poucas mtricas para implementao inicial. Um planejamento
adequado, usando uma abordagem baseada em fases, evitando implementaes
big bang, evitar que o escopo seja to vasto que no possa mostrar resultado
em tempo hbil ou que seja impossvel de ser atingido (Silveira, 2002; Russac,
2002);
Utilizao de padres de mercado: Mtricas padres de mercado (como a
anlise de pontos de funo) facilitam comparaes de resultados com outras
organizaes, uma vez que so difundidas e utilizadas por diversas organizaes
(Russac, 2002);
Considerar o tempo como maturidade: Um programa de mtricas precisa de
tempo, projetos e observaes para que seja considerado maduro. No uma
boa prtica tirar concluses baseadas em nmeros limitados de observaes
(Silveira, 2002);
Utilizao de resultados de forma adequada: Os resultados devem ser
utilizados nica e exclusivamente para a melhoria do processo de
desenvolvimento de sistemas como um todo, tomada de decises e definio de
objetivos. Colaboradores no devem ser julgados (Silveira, 2002; Russac, 2002);
Consultoria e treinamento externo: importante que se tenha profissionais
certificados pelo IFPUG (certified function point specialist CFPS) na equipe de
medio ou que se obtenha consultoria de tais profissionais. Transferncia de
conhecimento uma chave, podendo ajudar a evitar imprevistos (Dekkers, 2002).
Neste mesmo sentido (Russac, 2002) afirma ainda que importante que todos os
envolvidos no programa de medio tenham treinamento adequado.


44

3.6. RECURSOS HUMANOS: TREINAMENTO E MUDANA CULTURAL

Como na maioria dos processos de mudana ou implantao de novos conceitos,
os recursos humanos tm papel fundamental e devem ser considerados a todo
momento. No que diz respeito implantao de um programa de medio, algumas
questes relacionadas ao papel dos recursos humanos devem ser levadas em
considerao.
Primeiramente, como discutido anteriormente, recursos humanos devem ser
definidos para a execuo de atividades de medio. Dada tal definio,
necessidades de treinamento para tais recursos podem surgir. Uma vez definidos os
recursos e o programa de medio, mudanas culturais devero surgir e preciso
que se esteja preparado para enfrentar as conseqncias que as mudanas
culturais podem trazer. A seguir, tais questes so discutidas em detalhes.

3.6.1. Necessidade de treinamento

(Holmes, 2002) afirma que educao apropriada necessria para todos os
envolvidos no programa de medio, dependendo das suas atividades dentro do
processo estabelecido. (Holmes, 2002) exemplifica tipos de treinamento apropriados
para os vrios tipos de funes dentro de um programa de medio atravs da
tabela 10 apresentada a seguir.

Tabela 10 - Exemplos de treinamentos para diferentes audincias, adaptado de (Holmes, 2002),
pgina 109



45

3.6.2. Mudana cultural

A implantao de um programa de medio em uma organizao pode trazer
diversos benefcios, como visto at aqui. Porm, preciso que se esteja atento a
questes que muitas vezes passam desapercebidas, e que podem causar danos
incalculveis. o caso da mudana cultural, a qual dependendo da forma como for
tratada, pode levar ao descontentamento da equipe e em ltima instncia a perda de
profissionais.
(Dekkers, 2002) define que a medio, como qualquer outra iniciativa corporativa,
envolve mudana cultural, transformando uma organizao que gerencia por
sentimento em outra que gerencia baseada em fatos. As pessoas passam a ver seu
trabalho, sua carreira e at mesmo a si prprios de forma diferente quando passam
a conviver em um contexto onde se pratica a medio. Dado tal cenrio, (Dekkers,
2002) afirma ainda que no h dvidas que quando a medio de software
introduzida, a resistncia a mudanas das pessoas aflorada. Sendo algo inevitvel
e muito comum, necessrio que a gerncia esteja consciente e preparada para tais
resistncias. (Dekkers, 2002) relaciona os principais tipos de manifestao de
resistncia implantao do programa de medio:

Questionamento quanto consistncia das informaes;
Testes do comprometimento e apoio gerencial ao programa de medio;
Compartilhamento de percepes, rumores e mitos sobre a iniciativa.

Para reduzir o impacto da mudana cultural, (Dekkers, 2002) recomenda que
sistemas de recompensa e punio sejam realinhados para promover e
recompensar a coleta de dados precisa, ao invs de punir resultados insatisfatrios.
(Dekkers, 2002) alerta ainda que a medio s ser bem sucedida, se as pessoas
no forem punidas com os dados que elas prprias reportam.




46

4. ABORDAGEM PARA UM PROGRAMA DE MEDIO
BASEADO EM ANLISE DE PONTOS DE FUNO

Os captulos anteriores introduziram e contextualizaram mtricas, medies e
programas de medies e apresentaram referncias e embasamentos tericos. O
objetivo deste captulo e apresentar uma abordagem simplificada para um programa
de medio, usando-se como mtrica base, a medio em pontos de funo.
A anlise de pontos de funo foi selecionada como medio base, pois, como
visto anteriormente, tal medio amplamente utilizada pelo mercado, o que permite
a realizao de comparaes entre as medies realizadas pela organizao e as
realizadas por outras organizaes. Alm disso, tal medio proporciona uma
medida padro de sistemas, podendo esta ser relacionada a diversas outras
medidas / mtricas, chegando-se a fatores e taxas. Tais fatores e taxas so
amplamente utilizados em programas de medio.
Como foi descrito no decorrer deste estudo, existem diversas formas de
implementao de um programa de medio, podendo tal implementao variar de
acordo com cada organizao, do processo de desenvolvimento de software
utilizado (ou pela no utilizao), pela quantidade de recursos disponveis, pela
forma adotada para implantao, de acordo com os objetivos e metas da
organizao, dentre outras variantes (para mais detalhes quanto s formas de
variao, referenciar-se ao tpico 3.4 deste trabalho). Dada tamanha variao, a
abordagem apresentada por este estudo no se prende a caractersticas
especficas, ficando a customizao para cada tipo de ambiente a cargo de estudos
posteriores.
Este captulo apresenta as premissas para implementao do programa de
medio definido, e em seguida o programa de medio em si. A abordagem
apresentada totalmente embasada pelo estudo realizado e apresentado no
decorrer deste trabalho. A estrutura da definio para o programa utilizado neste
estudo segue os passos definidos por (Holmes, 2002) (discutido no captulo 3).



47
4.1. PREMISSAS PARA O PROGRAMA DE MEDIO ABORDADO

Para que se implemente o programa de medio abordado por este estudo,
algumas premissas so assumidas. Tais premissas so listadas a seguir.

4.1.1. Processo de desenvolvimento de software
A abordagem de programa de medio apresentada no est associada a
nenhum processo de desenvolvimento de software especfico, desta forma sendo
passvel de aplicao em organizaes que no implementem nenhum processo at
organizaes que implementem processos rigorosos e formais.
Entretanto, conforme visto no decorrer deste estudo, um programa de medio,
quando implementado por uma organizao, passa a fazer parte do seu contexto de
desenvolvimento de software, sendo que novas atividades so atribudas a
profissionais e mtricas so apuradas com base em produtos especficos gerados
por este contexto de desenvolvimento. Por conta de tal integrao, este estudo
assume que determinados itens estejam presentes no contexto de desenvolvimento
de software da organizao. Tais itens so especificados nos tpicos seguintes.

4.1.2. Atividades / Disciplinas consideradas
Este trabalho pressupe que o contexto de desenvolvimento de sistemas esteja
dividido em disciplinas
5
onde atividades especficas sejam realizadas por papis
6



5
Disciplinas: (Kroll, et al., 2003) definem que disciplinas so containers utilizados para organizar
atividades de um processo. Em outras palavras, disciplinas so agrupamentos de determinados
papis e atividades em reas de conhecimento ou especialidade. Por exemplo, a disciplina de
Requisitos compreende o papel do analista de sistemas para a realizao da atividade de anlise de
requisitos.
6
Papel: Um papel define o comportamento e as responsabilidades de um individuo ou um grupo de
indivduos que trabalham em um time. O comportamento expresso em termos de atividades que o
papel executa e cada papel associado a um conjunto de atividades. Papeis no representam
indivduos nem ttulos de funes. Um individuo hora pode trabalhar desempenhando atividades de
um papel, hora desempenhando atividades de outro. So exemplos de papis: Analista de Sistemas,
Arquiteto, Analista de Testes, Desenvolvedor, etc. (Kroll, et al., 2003).

48
especficos. Tal suposio se d, pois, para que se defina um programa de medio,
necessrio que se saiba quais atividades so realizadas pela organizao, uma

vez que tais atividades sero levadas em considerao em diversas medies.
Tais atividades ou mesmo a presena ou no das disciplinas podem variar de
organizao para organizao e principalmente pelo processo de desenvolvimento
de software utilizado ou pela sua no utilizao. As disciplinas tambm podem variar
entre organizaes quanto nomenclatura e quanto s atividades que
compreendem. Dada tamanha variao, a abordagem deste trabalho no impe a
realizao de atividades especificas, nem a produo de artefatos
7
especficos,
entretanto, considera apenas que as disciplinas estejam presentes no processo de
desenvolvimento da organizao.
A seguir so listadas e descritas as disciplinas e as atividades que
compreendem, limitando-se as que so consideradas por esta abordagem de
programa de medio:

Gerncia de Projetos: Gerenciamento, planejamento e acompanhamento de
projetos.

Requisitos: Definio do que o sistema deve prover, definio das fronteiras /
delimitaes do sistema, definio do escopo do projeto.

Analise e Design: Definio arquitetural, traduo dos requisitos em projeto
tcnico.

Implementao: Transformao do projeto tcnico em codificao, gerando-
se como resultado um produto de software executvel.



7
Artefatos: So pedaos de informaes produzidos, modificados ou usados por um processo. So
produtos tangveis de um projeto. Exemplos: Modelo de casos de uso, diagramas de classes,
documentos de definio arquitetural, etc. (Kroll, et al., 2003).

49
Testes: Averiguao e avaliao da qualidade do produto desenvolvido,
atravs da busca e documentao de falhas e da verificao se produto est
de acordo com os requisitos estabelecidos.

4.1.3. Recursos humanos e papis considerados
Este estudo pressupe que a organizao disponha de recursos humanos
capacitados para execuo de determinados papis dentro de um contexto de
desenvolvimento de sistemas. No h restrio quanto quantidade de recursos
para a execuo de tais papeis, ficando a cargo da organizao sua definio.
Caso a organizao no disponha de recursos capacitados para a execuo de
todos os papeis definidos, pode ser considerada a opo de contratao de
consultorias especializadas, de novos recursos capacitados, ou de capacitao dos
recursos disponveis. Tais opes so discutidas em detalhes neste trabalho no
captulo 3.
A seguir, os papeis necessrios para a implementao desta abordagem de
programa de medio so listados e detalhados. Cada papel pode variar quanto s
atribuies de organizao para organizao, por isto, esta relao considera
apenas as atribuies necessrias para a implementao do programa de medio.

Gerente de Projetos / Lder de Projetos: Profissional responsvel pelo
acompanhamento dos projetos, e por garantir que as horas despedidas nos
projetos sejam contabilizadas adequadamente, bem como os custos.

Analista de Sistemas / Analista de Requisitos: Profissional responsvel
pela definio dos requisitos sistmicos e por sua medio em pontos de
funo.

Desenvolvedor: Profissional responsvel pelo desenvolvimento dos sistemas
definidos.

Analista de Testes: Profissional responsvel pela elaborao e execuo de
planos de testes e pela contabilizao de defeitos encontrados em projetos.


50

4.1.4. Ferramentas mandatrias e desejveis
A abordagem deste trabalho no impe a utilizao de ferramentas especficas
ou especialistas, porm, dada a necessidade de determinados controles, de
aplicao de tcnicas especficas e de manipulao de grandes volumes de dados
conforme o programa de medio executado, algumas ferramentas podem ajudar
na produtividade dos trabalhos executados e outras se fazem necessrias. A seguir,
tais ferramentas so listadas e detalhadas.

4.1.4.1. Mandatrias
Repositrio de mtricas: Ferramenta responsvel pelo armazenamento das
diversas mtricas coletadas e analisadas no programa de medio.
Recomendvel a utilizao de ferramentas especialistas ou ferramentas
customizadas pela organizao, porm, planilhas eletrnicas podem ser
consideradas quando da impossibilidade das opes anteriores.

Repositrio de horas trabalhadas (tambm conhecido como time-
tracking): Ferramenta responsvel por prover mecanismo para lanamento
e armazenamento de horas trabalhadas de profissionais em projetos.
Recomendvel a utilizao de ferramentas especialistas ou ferramentas
customizadas pela organizao, porm, planilhas eletrnicas podem ser
consideradas quando da impossibilidade das opes anteriores.

Ferramentas para medies: Ferramentas responsveis pelo apoio nas
tarefas de medies e de aplicaes de mtricas e tcnicas especficas
Planilhas eletrnicas ou ferramentas especialistas podem ser consideradas.

4.1.4.2. Desejveis
Gerador de grficos: Ferramenta responsvel por anlises sobre dados,
medies e mtricas e gerao de grficos customizados sobre tais dados.
Podem ser consideradas a utilizao de planilhas eletrnicas, ferramentas
customizadas pela organizao ou ferramentas especialistas.


51
Ferramentas estatsticas: Ferramentas que faam anlises comparativas
sobre bases histricas de mtricas e produzam relatrios estatsticos.
aconselhvel a utilizao de ferramentas customizadas pela organizao ou
ferramentas especialistas.

Ferramentas de medio integradas: Ferramenta que integre lanamento
de horas, cronograma e repositrio de mtricas. aconselhvel a utilizao
de ferramentas customizadas pela organizao ou ferramentas especialistas.

Estabelecidas as premissas, a seguir o programa de medio apresentado.


4.2. DEFINIO DE OBJETIVOS E METAS

Conforme visto nos captulos anteriores, os objetivos e metas de um programa
de medio variam de organizao para organizao, sendo que estas devem ser
estabelecidas principalmente pelo nvel executivo da organizao e deve ter
colaborao de todos os indivduos atingidos pelo programa de medio.
Para a abordagem definida por este estudo, so definidos quatro objetivos e
metas, os quais foram selecionados por serem objetivos comuns dentre diversas
organizaes de software. Tais objetivos so listados e detalhados a seguir.

4.2.1. Melhorar a produtividade dos projetos
Objetiva-se que o programa de medio mostre a produtividade empregada em
cada projeto, e que com tal, seja parte do programa de medio a realizao de
anlises para identificao dos fatores que levam a melhores ou piores
produtividades, tendo como resultado, a relao e aplicao de aes que levem a
melhoria da produtividade em todos os projetos da organizao.
Tal objetivo atendido tem como benefcio a entrega de produtos em tempo
menor, reduzindo-se por conseqncia custos e permitindo que a organizao
atenda a um nmero maior de demandas de software.


52
4.2.2. Melhorar a qualidade dos projetos
Objetiva-se que o programa de medio mostre a qualidade dos produtos de
software, e que com tal, seja parte do programa de medio a realizao de anlises
para identificao dos fatores que levam a melhores ou piores qualidades, tendo
como resultado a relao e aplicao de aes que levem a melhora na qualidade
de todos os produtos desenvolvidos pela organizao.
Tal objetivo atendido tem como benefcio a entrega de produtos com menor
nmero de defeitos e mais aderentes s necessidades do cliente, diminuindo o
nmero de retrabalhos e aumentando a satisfao do cliente.

4.2.3. Reduzir o nmero de alteraes de escopo
Alteraes de escopo so geradas pela identificao de novos requisitos no
contemplados na definio anterior, ou alterao de requisitos / regras de negcio
definidas. Ambos os casos exigem trabalho adicional ou mesmo retrabalho por parte
da equipe de desenvolvimento de sistemas, o que pode significar aumento no custo,
diminuio da qualidade ou alterao de prazos.
Objetiva-se com o programa de medio que alteraes de escopo sejam
monitoradas e que, atravs de analises, identifiquem-se as principais causas,
visando sua reduo ou extino.

4.2.4. Reduzir custos dos projetos
Objetiva-se que o programa de medio mostre o custo despedido pela
organizao para produzir unidades de software. Tal medio dever ser comparada
com medies realizadas em projetos semelhantes, procurando-se identificar o quo
custoso est ou no o processo de desenvolvimento de software implementado pela
organizao.
Uma vez identificado que o custo est acima do padro, dever ser parte do
programa de medio a realizao de anlises para identificao das principais
causas, visando sua reduo ou extino. Tal objetivo atendido, traz como benefcio
a utilizao eficiente de recursos da organizao, permitindo-se que custos
excedentes sejam revertidos para investimentos na rea como um todo.



53
4.3. DEFINIO DE MEDIES E MTRICAS

Definidos os objetivos do programa de medio, devem ser definidas as
medies e mtricas necessrias que permitam saber o andamento atual de cada
objetivo. Uma vez que se saiba o quo cada projeto est dentro ou no dos objetivos
definidos, anlises podem ser realizadas a fim de se reverter situaes ou de se
manter melhores prticas.
A seguir, as medies e mtricas necessrias para cada objetivo definido no
item anterior so relacionadas.

4.3.1. Medies e mtricas necessrias para o objetivo Melhorar a
produtividade dos projetos
Para que se melhore a produtividade dos projetos, o primeiro passo saber o
esforo empregado sobre determinada unidade de medida de software padro. Para
tal, a mtrica dada pela seguinte formula:

Taxa de produtividade = Esforo gasto no projeto em horas / Total de pontos
de funo ao trmino do projeto

4.3.2. Medies e mtricas necessrias para o objetivo Melhorar a qualidade
dos projetos
Par que se melhore a qualidade, o mesmo raciocnio empregado na melhora de
produtividade vlido. Deve-se saber a qualidade atual. Esta, pode ser dada pela
quantidade total de defeitos encontrados dividido pelo tamanho do software em
pontos de funo ao trmino do projeto. A seguinte frmula representa esta mtrica:

Taxa de defeitos = Quantidade total de defeitos encontrados / Total de pontos
de funo ao trmino do projeto

4.3.3. Medies e mtricas necessrias para o objetivo Reduzir o nmero de
alteraes de escopo
Para que se reduza o nmero de alteraes de escopo, preciso saber a taxa
de crescimento funcional do software ao longo da sua construo. Para tal, a
quantidade de pontos de funo provenientes de alteraes de escopo deve ser

54
obtida e considerada sobre a quantidade de pontos de funo iniciais. Entende-se
como pontos de funo provenientes de alterao de escopo, apenas os pontos de
funo includos, alterados ou excludos por conta de alteraes de escopo.
Funcionalidades no afetadas pela alterao de escopo no so considerados nesta
conta. Tal mtrica ento dada pela seguinte frmula:

Taxa de mudana de escopo = Total de pontos de funo de alteraes de
escopo / Total de pontos de funo iniciais

4.3.4. Medies necessrias para o objetivo Reduzir custos dos projetos
Para que se saiba o quanto se tem gasto efetivamente com a construo de um
software, necessrio que se saiba o custo por unidade de medida de software
produzido. Tal mtrica dada pela seguinte frmula:

Eficincia do Custo = Custo total do projeto / Total de pontos de funo ao
trmino do projeto

4.3.5. Medies necessrias para o programa de medio
Definidas as mtricas para o endereamento cada objetivo, medies devero
ser realizadas a fim de se obter os dados necessrios para compor cada mtrica. A
seguir tais medies so listadas. Determinadas medies podem ser utilizadas para
enderear mais de uma mtrica ou objetivo.
Esforo gasto no projeto em horas
Quantidade total de defeitos encontrados
Custo total do projeto
Total de pontos de funo iniciais
Total de pontos de funo de alteraes de escopo
Total de pontos de funo ao trmino do projeto

A tabela 11 a seguir resume as mtricas necessrias para cada objetivo definido.


55
Tabela 11 - Relao de mtricas X objetivos com o programa de medio

Definidas as mtricas e medies necessrias, o passo seguinte a definio
dos momentos em que tais medies sero realizadas e quais papis sero
responsveis por sua realizao.


4.4. DADOS, MEIOS E PONTOS DE COLETA E RESPONSABILIDADES

Conforme visto no decorrer deste estudo, a definio de coleta de dados
compreende a definio de pontos chave do programa de medio, onde se definem
quais so os dados necessrios para compor as mtricas definidas e como, quando
e por quem tais dados so coletados.
No tpico anterior foram definidas as mtricas necessrias para enderear os
objetivos esperados com o programa de medio, onde foi visto que tais mtricas
exigem que dados especficos sejam combinados. Tais dados devem ser definidos
individualmente, a fim de se saber do que so compostos, como e em que pontos
sero apurados e posteriormente por quem.
A seguir, cada mtrica definida para o programa de medio descrita em
detalhes e definida quanto aos dados envolvidos, meios e pontos de coleta e
responsabilidades pela coleta. Como produto final definida uma tabela de relao
objetivo, medio, dados e responsveis de todo o programa de medio.

4.4.1. Esforo gasto no projeto em horas
Compreende a quantidade de horas gastas no projeto pela equipe participante,
em determinadas atividades. Como este dado ser relacionado posteriormente com
a quantidade de pontos de funo do projeto para se apurar a produtividade, deve-

56
se ser definido um escopo quanto ao que se deseja saber se foi ou no produtivo em
comparao a outros projetos. Um escopo muito extenso na definio de esforo em
horas, como por exemplo, abrangendo todo o projeto, tende a deixar a taxa de
produtividade pouco objetiva, uma vez que compreende muitas atividades realizadas
por diversos papis, tornando assim pouco assertiva a identificao das possveis
causas de eventuais discrepncias.

4.4.1.1. Dados
Dadas tais definies, estabelecida a apurao do esforo gasto no projeto em
horas como:

Esforo gasto no projeto em horas =
Quantidade de horas gastas em atividades de anlise de requisitos +
Quantidade de horas gastas em atividades de anlise e projeto +
Quantidade de horas gastas em atividades de implementao

Horas gastas nas demais atividades do projeto como gerncia de projetos,
testes, analise de negcios, distribuio, etc., no devem ser contabilizadas neste
item.

4.4.1.2. Meio de coleta
Para a coleta dos dados identificados para esta medio, necessrio que cada
profissional que desempenhe os papis que compe a medio, lance as horas em
que trabalhou no projeto desempenhando tal papel no repositrio de horas
trabalhadas definido pela organizao (time-tracking). Tal ferramenta considerada
como mandatria para esta abordagem de programa de medio e discutida no
item 4.1.3 deste captulo.

4.4.1.3. Pontos de coleta
As horas devero ser lanadas ao trmino das atividades ou caso a atividade
ultrapasse uma semana de durao, as horas trabalhadas devero ser lanadas no
trmino da semana.


57
4.4.1.4. Responsabilidade de coleta
Analistas de sistemas e desenvolvedores so responsveis pelo lanamento de
horas semanal. O gerente de projetos responsvel por garantir o correto
lanamento das horas de tais profissionais.

4.4.1.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao do esforo gasto no
projeto em horas apresentada.
Tabela 12 - Apurao do esforo gasto no projeto em horas - sumarizao


4.4.2. Custo total do projeto
Compreende o custo total despedindo com profissionais durante a sua atuao
no projeto. Ao contrrio do esforo para a apurao da produtividade, onde
limitado o escopo da medio, no custo total do projeto deve ser considerado o
custo do projeto inteiro.

4.4.2.1. Dados
Dadas tais definies, estabelecida a apurao do custo total do projeto como:

Custo total do projeto =
Somatria (Horas gastas por profissional X Valor/hora profissional)

58

4.4.2.2. Meio de coleta
Todos os profissionais envolvidos no projeto devero ter as horas em que
trabalharam no projeto devidamente contabilizadas no repositrio de horas
trabalhadas definido pela organizao (time-tracking). Tal ferramenta considerada
como mandatria para esta abordagem de programa de medio e discutida no
item 4.1.3 deste captulo.
O valor/hora por profissional tambm dever estar disponvel no repositrio de
horas trabalhadas, para posterior apurao da relao entre horas trabalhadas e
valor/hora do profissional.

4.4.2.3. Pontos de coleta
Os pontos de coleta das horas trabalhadas segue a mesma regra definida pelo
item 4.4.1.3, ou seja, ao trmino de cada atividade ou caso a atividade ultrapasse
uma semana, ao trmino da semana. O valor/hora de todos os profissionais
envolvidos no projeto devero ser lanados / atualizados antes do inicio de cada
projeto.

4.4.2.4. Responsabilidade de coleta
Todos os envolvidos no projeto so responsveis pelo lanamento das suas
horas trabalhadas, sendo o Gerente de Projetos o responsvel pela exatido das
informaes e por garantir que todos os envolvidos tiveram suas horas
contabilizadas. Gerentes de projetos tambm so responsveis por manter
atualizado o valor/hora dos profissionais.

4.4.2.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao do custo total do
projeto apresentada.


59
Tabela 13 - Apurao do custo total do projeto - sumarizao


4.4.3. Total de pontos de funo iniciais
Compreende a medio do tamanho do projeto em pontos de funo, logo aps
o fechamento do escopo de requisitos do projeto. Para tal, todos os requisitos do
projeto devem ser considerados e sobre eles dever ser aplicada a tcnica de
anlise de pontos de funo, conforme descrito no capitulo 2 deste estudo.

4.4.3.1. Dados
Dadas tais definies, estabelecida a apurao do total de pontos de funo
iniciais como:

Total de pontos de funo inicias =
Medio de todo o projeto em pontos de funo aps o primeiro fechamento do
escopo

4.4.3.2. Meio de coleta
Com base nos requisitos definidos para a aplicao, a tcnica de anlise de
pontos de funo deve ser aplicada, atravs do uso de uma planilha de clculo ou
ferramenta especialista, conforme discutido no item 4.1.3 deste captulo. O valor
apurado deve ser lanado na ferramenta repositrio de mtricas, tambm discutida
no item 4.1.3 deste captulo.


60
4.4.3.3. Pontos de coleta
A medio inicial em pontos de funo deve ser realizada logo aps o
fechamento do escopo inicial do projeto, sendo este devidamente oficializado e
entendido pelas partes envolvidas no projeto.

4.4.3.4. Responsabilidade de coleta
Uma vez oficializado o fechamento do escopo, uma demanda para medio em
pontos de funo deve ser gerada pelo Gerente de Projetos. O Analista de Sistemas
ento o responsvel pela atendimento de tal demanda.

4.4.3.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao do total de pontos
de funo iniciais apresentada.
Tabela 14 Tamanho do projeto inicial em pontos de funo - sumarizao


4.4.4. Total de pontos de funo de alteraes de escopo
Compreende a medio dos requisitos alterados, includos e excludos a cada
eventual mudana de escopo que ocorra no projeto. Para tal, apenas tais requisitos
do projeto devem ser considerados aps a mudana do escopo, e sobre eles
aplicada a tcnica de anlise de pontos de funo, conforme descrito no captulo 2
deste estudo.

4.4.4.1. Dados
Dadas tais definies, estabelecida a apurao do total de pontos de funo de
alterao de escopo como:


61
Total de pontos de funo de alteraes de escopo =
Total de pontos de funo de requisitos includos + Total de pontos de funo de
requisitos alterados + total de pontos de funo de requisitos excludos

4.4.4.2. Meio de coleta
Com base nos requisitos alterados, includos ou excludos com a alterao de
escopo, a tcnica de anlise de pontos de funo deve ser aplicada, atravs do uso
de uma planilha de clculo ou ferramenta especialista, conforme discutido no item
4.1.3 deste captulo. O valor apurado deve ser lanado na ferramenta repositrio de
mtricas, tambm discutida no item 4.1.3 deste captulo.

4.4.4.3. Pontos de coleta
A medio em pontos de funo deve ser realizada logo aps o fechamento do
escopo do projeto, aps mudana de escopo, sendo esta devidamente oficializada e
entendida pelas partes envolvidas no projeto.

4.4.4.4. Responsabilidade de coleta
Uma vez oficializado o fechamento do escopo, aps mudana de escopo, uma
nova demanda para medio em pontos de funo deve ser gerada pelo Gerente de
Projetos. O Analista de Sistemas ento o responsvel pelo atendimento de tal
demanda.

4.4.4.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao do total de pontos
de funo de alterao de escopo apresentada.


62
Tabela 15 - Total de pontos de funo de alteraes de escopo - sumarizao


4.4.5. Total de pontos de funo ao trmino do projeto
Compreende a medio de todo o projeto em pontos de funo, aps a sua
concluso. Para tal, todo o projeto entregue deve ser considerado, e sobre ele
aplicada a tcnica de anlise de pontos de funo, conforme descrito no captulo 2
deste estudo.

4.4.5.1. Dados
Dadas tais definies, estabelecida a apurao do total de pontos de funo ao
trmino do projeto como:

Total de pontos de funo ao trmino do projeto =
Medio de todo o projeto em pontos de funo aps sua concluso

4.4.5.2. Meio de coleta
Com base no projeto entregue a tcnica de anlise de pontos de funo deve ser
aplicada, atravs do uso de uma planilha de clculo ou ferramenta especialista,
conforme discutido no item 4.1.3 deste captulo. O valor apurado deve ser lanado
na ferramenta repositrio de mtricas, tambm discutida no item 4.1.3 deste
captulo.


63
4.4.5.3. Pontos de coleta
A medio em pontos de funo deve ser realizada logo aps a disponibilizao
final do projeto para rea cliente, sendo esta devidamente oficializada e entendida
pelas partes envolvidas no projeto.

4.4.5.4. Responsabilidade de coleta
Uma vez oficializada a entrega do projeto para a rea cliente, uma nova
demanda para medio em pontos de funo deve ser gerada pelo Gerente de
Projetos. O Analista de Sistemas ento o responsvel pelo atendimento de tal
demanda.

4.4.5.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao to total de pontos de
funo ao trmino do projeto apresentada.

Tabela 16 - Total de pontos de funo ao trmino do projeto - sumarizao


4.4.6. Quantidade total de defeitos encontrados
Compreende a contabilizao da quantidade de defeitos encontrados durante a
realizao de testes de validao sobre os produtos de software gerados. Defeitos
encontrados em testes de verificao, caso realizados pela organizao, no so
contabilizados nesta medio. A quantidade de defeitos encontrados deve ser
contabilizada a cada iterao de testes realizada, caso acontea mais do que uma,
chegando-se ao total de defeitos encontrados em toda a realizao dos testes.


64
4.4.6.1. Dados
Dadas tais definies, estabelecida a apurao da quantidade de defeitos
encontrados como:

Quantidade total de defeitos encontrados =
Quantidade total de defeitos de validao encontrados no produto de software.

4.4.6.2. Meio de coleta
A quantidade de defeitos encontrados no produto de software testado dever ser
lanada na ferramenta repositrio de mtricas, discutida no item 4.1.3 deste captulo.

4.4.6.3. Pontos de coleta
Logo aps a concluso de cada iterao de realizao de testes. Entende-se
como iterao de testes a concluso de uma etapa inteira de testes, sendo o motivo
da concluso a impossibilidade de continuar com os testes por algum defeito crtico
ou a realizao efetiva de todos os testes planejados. Iteraes de testes em
produtos de software podem ocorrer por diversas vezes at que o produto esteja
estvel. Sempre que concluda uma iterao, a quantidade de defeitos dever ser
contabilizada.

4.4.6.4. Responsabilidade de coleta
O analista de testes responsvel pela realizao dos testes o responsvel pela
contabilizao da quantidade de defeitos encontrados em seus testes.

4.4.6.5. Relao sumarizada
A seguir a relao sumarizada das definies para apurao do custo total do
projeto apresentada.


65
Tabela 17 Quantidade total de defeitos encontrados - sumarizao


4.4.7. Relao objetivo, medio, dados e responsveis
Definidos os objetivos no tpico 4.2, as medies para enderear tais objetivos
no tpico 4.3, os dados necessrios para apurar tais medies e os meios de coleta
e responsabilidades pelas coletas de tais dados no tpico 4.4, este tpico traz a
relao sumarizada de todas as definies. A matriz a seguir apresenta a relao
medida, dado, meio, ponto e responsabilidade pela coleta.


66
Tabela 18 Definio do Programa de Medio - Relao Medidas, Dados, Meios, Pontos e
Responsabilidade pela coleta


A seguir, apresentada a matriz de relao objetivos / metas, com as
mtricas que as endeream e suas composies, definidas pela relao entre
medies apresentadas na matriz anterior.

Tabela 19 Definio do Programa de Medio Relao Objetivos, Mtricas e suas
Composies


67
4.5. ANLISE E REPORTE DE RESULTADOS

Definidas as medies necessrias e seus responsveis, este tpico aborda a
definio de como tais dados, aps coletados, sero analisados e reportados.
Conforme visto nos captulos anteriores, esta definio abrange a especificao do
formato, audincia, freqncia de entrega dos relatrios, bem como os responsveis
por anlises sobre os resultados.
Esta abordagem de programa de medio define a apurao de trs relatrios,
os quais so os meios definidos para reporte dos resultados quanto s medies
definidas, fornecendo desde dados detalhados de cada projeto at sumarizados de
toda a organizao de software, provendo assim dados necessrios para anlises
quanto ao resultado de projetos individualizados e dados necessrios para anlises
quanto ao resultado da organizao como um todo.
Tais relatrios so detalhados a seguir e em seguida apresentada uma
sumarizao geral das definies quanto ao reporte e analise de resultados.

4.5.1. Relatrio detalhado por projeto

4.5.1.1. Objetivo
Prover informaes detalhadas de cada projeto, permitindo anlises minuciosas
sobre cada resultado. Apresenta o resumo de todo o ciclo de vida do projeto, em
termos de medies, mtricas e apuraes.
Permite que o time envolvido no projeto, gerncia da organizao, gerentes de
projetos e demais times da organizao visualizem resultados gerais do projeto,
possibilitando o reconhecimento de bons resultados e anlise e tomada de aes
quando de resultados ruins.

4.5.1.2. Audincia
Todo o time envolvido no projeto, todos os gerentes de projetos, gerncia da
organizao e demais times de desenvolvimento de sistemas da organizao.

4.5.1.3. Formato
O relatrio detalhado por projeto composto pela identificao do projeto, onde
constam dados de identificao e classificao do projeto, pelos dados do ciclo de

68
vida do projeto, onde constam as medies realizadas, dados relacionados ao custo
do projeto, envolvidos nas atividades contabilizadas para apurao da taxa de
produtividade e suas respectivas contabilizaes de horas trabalhadas no projeto,
histrico de iteraes de testes e quantidade de defeitos encontrados. O relatrio
tambm composto pelos resultados do projeto, onde constam apuraes de
mtrica definida para o programa de medio e a comparao com mdias de
resultados da organizao em formato grfico. Por fim, o relatrio apresenta a
anlise dos resultados. A Figura 5 a seguir ilustra o formato descrito. Os dados
apresentados na ilustrao so meramente ilustrativos.



69

Figura 5 - Definio Programa Medio - Formato Relatrio Detalhado por Projeto

70
4.5.1.4. Responsvel pela apurao, anlise e divulgao
O Analista de Sistemas o responsvel pela apurao e divulgao. Analista de
Sistemas em conjunto com Gerente de Projetos e time envolvido so responsveis
pela anlise de resultados, sendo o Analista de Sistemas o responsvel pela anlise
final embasada pela anlise conjunta.

4.5.1.5. Freqncia de entrega
Aps a publicao em produo de cada projeto.

4.5.1.6. Sumarizao
A seguir, apresentada a sumarizao das definies para o relatrio detalhado
por projeto.

Tabela 20 - Sumarizao Relatrio Detalhado por Projeto


4.5.2. Relatrio comparativo por projeto

4.5.2.1. Objetivo
Prover resultados sumarizados do projeto, em comparao com mdias de
projetos semelhantes. Permite que seja avaliado se os resultados do projeto esto
melhores do que a mdia, se esto dentro dos padres da organizao ou se esto
abaixo da mdia da organizao.
Alm de apontar os resultados do projeto, este relatrio mostra o quanto o
projeto colaborou ou no com os objetivos e metas da organizao, mostrando
resultados do projeto em associao com os objetivos definidos com o programa de
medio.

71
4.5.2.2. Audincia
Todo o time envolvido no projeto, todos os gerentes de projetos, gerncia da
organizao e demais times de desenvolvimento de sistemas da organizao.

4.5.2.3. Formato
O relatrio comparativo por projeto composto pela identificao do projeto,
onde constam dados de identificao e classificao do projeto, pelos resultados do
projeto, onde constam os resultados em relao aos objetivos definidos para o
programa de medio e a mdia dos resultados de projetos semelhantes, e por fim,
pela anlise dos resultados. A Figura 6 a seguir ilustra o formato descrito. Os dados
apresentados na ilustrao so meramente ilustrativos.


Figura 6 - Definio Programa Medio - Formato Relatrio Comparativo por Projeto

72
4.5.2.4. Responsvel pela apurao, anlise e divulgao
O Analista de Sistemas o responsvel pela apurao e divulgao. Analista de
Sistemas em conjunto com Gerente de Projetos e time envolvido so responsveis
pela anlise de resultados, sendo o Analista de Sistemas o responsvel pela anlise
final embasada pela anlise conjunta.

4.5.2.5. Freqncia de entrega
Aps a publicao em produo de cada projeto.

4.5.2.6. Sumarizao
A seguir, apresentada a sumarizao das definies para o relatrio
comparativo por projeto.

Tabela 21 - Sumarizao Relatrio Comparativo por Projeto


4.5.3. Relatrio evolucional da organizao

4.5.3.1. Objetivo
Prover informaes histricas da organizao quanto ao seu desempenho.
Mostra tendncias (onde a organizao estava e para onde est indo), resultado de
tomada de aes (melhorias, aplicao de prticas de sucesso identificadas em
anlises sobre resultados ao longo da utilizao do programa de medio, utilizao
de novas ferramentas, aplicao de treinamento, etc.) ao longo do tempo e posio
da organizao em relao aos objetivos e metas definidas inicialmente.
Permite a tomada de aes, uma vez identificadas tendncias negativas, a fim
de revert-las. Possibilita a anlise quanto a boa ou m sucesso de aes tomadas
e a tomada de aes corretivas tempo. Permite que se identifique se a

73
organizao est ou no no caminho certo rumo a atingir objetivos e metas
definidas.

4.5.3.2. Audincia
Toda a organizao de software.

4.5.3.3. Formato
O relatrio evolucional da organizao composto pelo perodo de anlise
considerado no relatrio, pelos resultados de cada indicador considerado no
programa de medio ao longo dos meses analisados e, por fim, pela anlise dos
resultados. A figura 7 a seguir ilustra o formato descrito. Os dados apresentados na
ilustrao so meramente ilustrativos.


Figura 7 - Definio Programa Medio - Formato Relatrio Evolucional da Organizao

74
4.5.3.4. Responsvel pela apurao, anlise e divulgao
O Analista de Sistemas o responsvel pela apurao e divulgao. Analista de
Sistemas em conjunto com Gerentes de Projetos e Gerente da Organizao so
responsveis pela anlise dos resultados.

4.5.3.5. Freqncia de entrega
Bimestral, porm, podendo ser apurado a qualquer momento quando da
necessidade.

4.5.3.6. Sumarizao
A seguir, apresentada a sumarizao das definies para o relatrio detalhado
por projeto.

Tabela 22 - Sumarizao Relatrio Evolucional da Organizao



4.5.4. Sumarizao das Definies quanto a Anlise e Reporte de Resultados
Detalhados todos os relatrios quanto a sua audincia, responsveis e
freqncia de entrega, a seguir a sumarizao geral apresentada.


75
Tabela 23 - Definio Programa Medio - Anlise e Reporte de Resultados



4.6. INTEGRAO DO PROGRAMA DE MEDIO EM UM CONTEXTO DE
DESENVOLVIMENTO DE SISTEMAS

Nos tpicos anteriores deste captulo foram definidos os objetivos, dados,
mtricas, relatrios e responsabilidades do programa de medio, concluindo assim
a sua definio. Uma vez definido o programa, este tpico aborda a sua integrao
em um contexto de desenvolvimento de sistemas, resumindo e ilustrando (atravs
de diagramas de atividades da UML 2.0) o programa de medio definido.
Como descrito anteriormente neste estudo, a abordagem de programa de
medio apresentada no restrita para implementao em um processo de
desenvolvimento de sistemas em especfico, sendo passvel de aplicao a qualquer
organizao de software que se encaixe nas premissas definidas por esta
abordagem. Tais premissas consideram que determinados papis, atividades e
ferramentas estejam presentes na organizao de software, o que define um
contexto de desenvolvimento de sistemas.
Para ilustrar a integrao do programa de medio proposto em um contexto de
desenvolvimento de sistemas, a Figura 8 a seguir apresenta todas as macro-

76
atividades provenientes do programa de medio definidas ao longo da sua
especificao feita nos tpicos anteriores, em conjunto com as demais macro-
atividades realizadas pela organizao ao longo de um fluxo de construo de
software. O objetivo apresentar, em linhas gerais, como o programa de medio
abordado se integra em tal fluxo j realizado pela organizao.



Por no fazer parte do fluxo de desenvolvimento de sistemas da organizao, a
apurao bimestral do relatrio evolucional da organizao, o qual definido no
tpico 4.5.3, ilustrado separadamente do fluxo principal, atravs da figura 9 a
seguir. A ilustrao apresenta o fluxo das macro-atividades envolvidas no processo
de gerao do relatrio e as responsabilidades por cada atividade.

Figura 8 - Definio do Programa de Medio - Integrao do programa em um contexto
de desenvolvimento de sistemas

77

Figura 9 - Definio do Programa de Medio - Fluxo para gerao bimestral do relatrio
evolucional da organizao

78
5. CONCLUSES E TRABALHOS FUTUROS

5.1. CONCLUSO

Este estudo abordou o cenrio da crescente necessidade por solues
sistmicas com cada vez mais qualidade e em menor tempo e custo possvel,
fatores estes atualmente decisivos para o apoio estratgico de organizaes ou
mesmo sua sobrevivncia. Visando suprir tal necessidade, objetivou-se com este
trabalho, o estudo de medies, mtricas e programas de medio, a fim de se
verificar se poderiam apoiar no fornecimento de informaes quantitativas e
consistentes sobre a organizao de software e seus produtos, a fim de possibilitar a
avaliao de resultados e tomada de decises baseada em fatos, visando o
aperfeioamento continuo do processo de desenvolvimento de sistemas e seus
produtos, possibilitando assim, suprir as necessidades descritas.


5.2. RELAO COM OS OBJETIVOS INICIAIS

Visando o estabelecimento de um programa de medio baseado em anlise de
pontos de funo, o estudo dividiu-se em trs etapas. A primeira etapa consistiu no
estudo de mtricas e medies e dentre elas a anlise de pontos de funo. A
segunda etapa consistiu no estudo de programas de medio e a terceira na
proposio de um programa de medio, atingindo assim os objetivos iniciais
enunciados deste trabalho.


5.3. VALIDADE DA HIPTESE

Pde-se concluir com este estudo que a anlise de pontos de funo uma
medio extremamente adequada para composio em programas de medio,
pois, independente de tecnologia, processo ou metodologia, o que possibilitou que
fosse amplamente utilizada pelo mercado. Tal fato permite que anlises
comparativas de resultados entre organizaes sejam feitas, sendo este um fator

79
muito relevante para um programa de medio, uma vez que possibilita saber a
posio da organizao em relao a organizaes semelhantes. Alm disso,
verificou-se que a anlise de pontos de funo normatizada por um rgo
internacional, o IFPUG, o qual responsvel por garantir a continuidade e evoluo
da tcnica.
Verificou-se tambm com este estudo, que programas de medio podem ajudar
organizaes a coletar e analisar dados sobre si prprias, permitindo saber o quo
efetivo o seu desenvolvimento de sistemas. Tais analises no s permitem que um
gerenciamento e tomada de decises baseada em fatos seja implantado na
organizao, como tambm permitem que pontos falhos sejam identificados e
corrigidos e que pontos positivos sejam mantidos e promovidos para toda a
organizao. Conclu-se que tais atividades possibilitam a organizao melhorar
seus processos e produtos, desenvolvendo-os cada vez com mais qualidade e
produtividade, o que por conseqncia permite a utilizao de recursos com maior
eficincia. Tais caractersticas vm a confirmar a hiptese enunciada deste estudo.


5.4. TRABALHOS FUTUROS

A seguir, so listadas possveis evolues deste trabalho.

5.4.1. Estudo de caso da implementao do programa de medio proposto
Este trabalho limitou-se a propor um programa de medio. Uma possvel
evoluo a implementao efetiva do programa proposto, a anlise e
documentao de resultados obtidos e, se necessrio, a sua adequao.

5.4.2. Estudo de ferramentas disponveis para apoio no programa de medio
proposto
O trabalho tambm limitou-se a descrever os tipos de ferramentas necessrias,
no apresentando ferramentas especficas, ou mesmo realizando estudos sobre
elas. Outra possvel evoluo a anlise de ferramentas de medies, mtricas e
repositrios de mtricas existentes no mercado ou mesmo a proposio de uma
ferramenta customizada para apoio em programas de medio.


80
5.4.3. Customizao de um processo de desenvolvimento de sistemas com o
programa de medio proposto
O estudo no se restringiu a um processo de desenvolvimento de sistemas
especfico. Uma possvel evoluo a customizao de um determinado processo
de desenvolvimento de sistemas, como o RUP, MSF, XP, Scrum, etc., ou mesmo um
processo j customizado para uma organizao, integrando o programa de medio
proposto.



81
REFERNCIAS

Aguiar, Mauricio. BFPUG. [Online] [Citado em: 2008 de 04 de 21.]
www.bfpug.com.br/artigos/UCP/Aguiar-Pontos de Funcao ou Pontos por Caso de
Uso.pdf.
Andrade, Edimia Leonor Pereira de. 2004. Pontos de Caso de Uso e Pontos de
Funo na gesto de estimativa de tamanho de projetos de software orientados a
objetos. Universidade Catlica de Brasilia. Braslia : s.n., 2004. Master Thesis.
Budag, Mnica. 2007. Desenvolvimento de um Processo Baseado em Mtrica para
Estimar Esforo em um Projeto de Implantao de Software. Centro de Cincias
Exatas e Naturais, Universidade Regional de Blumenau. Blumenau : s.n., 2007.
Dekkers, Carol A. 2002. How and When Can Functional Size Fit with a
Measurement Program? [A. do livro] International Function Point Users Group. IT
measurement: pratical advice from the experts. Indianapolis : Pearson Education,
Inc., 2002, pp. 161-169.
Demarco, Tom. 1989. Controle de Projetos de Software. Rio de Janeiro : Campus,
1989.
Gates, Bill. 1999. A empresa na velocidade do pensamento: com um sistema
nervoso digital. So Paulo : Companhia de letras, 1999. p. 11.
Gill, Antonio Carlos. 2007. Como elaborar projetos de pesquisa. 4. So Paulo :
Atlas, 2007.
Holmes, Lori. 2002. Measurement Program Implementation Approaches. [A. do
livro] International Function Point Users Group. IT measurement: pratical advice from
the experts. Indianapolis : Pearson Education, Inc., 2002, pp. 97-110.
IEEE. 1993. Standard Glossary of Software Engineering Terminology. s.l. : IEEE,
1993.

82
IFPUG. 2000. Function Point Counting Practices Manual. Princeton Junction :
International Function Point Users Group, 2000.
Jones, Capers. 2002. The Expanding Roles of Function Point Metrics. [A. do livro]
International Function Point Users Group. IT measurement: pratical advice from the
experts. Indianapolis : Pearson Education, Inc., 2002, pp. 3-30.
Kroll, Per e Kruchten, Philippe. 2003. The Rational Unified Process Made Easy: a
practioner's guide to the RUP. Boston : Pearson Education, 2003.
Minkiewicz, Arlene F. 2002. Benchmarking. [A. do livro] International Function Point
Users Group. IT Measurement: pratical advice from the experts. Indianapolis :
Pearson Education Inc., 2002, pp. 113-124.
Pressman, Roger S. 2006. Engenharia de Software. 6. So Paulo : Mc Graw-Hill,
2006.
Putnam, Lawrence H. e Ware, Myers. 2002. The Core of Sofware Planning. [A. do
livro] International Function Point Users Group. IT Measurement: pratical advice from
the experts. Indianapolis : Pearson Education Inc, 2002, pp. 53-66.
Russac, Janet. 2002. Cheaper, Better, Faster: A Measurement Programa That
Works. [A. do livro] International Function Point Users Group. IT measurement:
pratical advice from the experts. Indianapolis : Pearson Education, Inc., 2002, pp.
147-157.
Schuster, Carlos. 2006. Mtricas de sofware com nfase em anlise de pontos de
funo apresentando estudo de caso na empresa Data Sul S.A. Sociedade
Educacional de Santa Catarina, Instituto Superior Tupy. Joinville : s.n., 2006.
Silveira, Mrio Luiz Barroso da. 2002. EDS Brazil Metrics Program: Measuring for
Improvement. [A. do livro] International Function Point Users Group. IT
measurement: pratical advice from the experts. Indianapolis : Pearson Education,
Inc., 2002, pp. 85-96.

83
Vazquez, Carlos Eduardo, Simes, Siqueira Guilherme e Albert, Machado
Renato. 2003. Anlise de Pontos de funo: medio, estimativas e gerenciamento
de projetos de software. 6. So Paulo : rica, 2003.