Você está na página 1de 108

UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL

INSTITUTO DE INFORMTICA
PROGRAMA DE PS-GRADUAO EM COMPUTAO










Estimativa da Produtividade no
Desenvolvimento de Software


por

MARIA ISABEL HAUFE








Dissertao submetida avaliao
como requisito parcial
para obteno do grau de
Mestre em Cincia da Computao







Prof. Dra. Ana Maria de Alencar Price
Orientadora






Porto Alegre, janeiro de 2001.

2
CIP CATALOGAO NA PUBLICAO















Haufe, Maria Isabel
Estimativa da produtividade no desenvolvimento de software /
por Maria Isabel Haufe. Porto Alegre: PPGC da UFRGS, 2001.
108p.:il.
Dissertao (mestrado) Universidade Federal do Rio Grande
do Sul. Programa de Ps-Graduao em Computao, Porto Alegre,
BR-RS, 2001. Orientadora: Price, Ana Maria de Alencar.
1. Produtividade. 2. Mtricas. 3. Estimativas. 4. Gerncia de
Projetos. 5. Qualidade em Software. I. Price, Ana Maria de
Alencar. II. Ttulo.























UNIVERSIDADE FEDERAL DO RIO GRANDE DO SUL
Reitora: Profa. Wrana Panizzi
Pr-Reitor de Ensino: Prof. Jos Carlos Ferraz Hennemann
Pr-Reitor de Ps-Graduao: Prof. Philippe Olivier Alexandre Navaux
Diretor do Instituto de Informtica: Prof. Philippe Olivier Alexandre Navaux
Coordenador do PPGC: Prof. Carlos Alterto Heuser
Bibliotecria Chefe do Instituto de Informtica: Beatriz Haro

3
Agradecimentos


Para que este trabalho pudesse tornar-se realidade, muitos foram aqueles que me
ajudaram, que no mediram esforos colaborando das mais diferentes formas. Por isso,
julga-se oportuno destacar aqui, todos que tiveram importncia igualmente valorosa.

A meus pais que foram de grande importncia, me apoiando e me incentivando para que
este trabalho pudesse chegar ao fim.

Aos meus irmos que me ajudam quando mais precisei, me deram foras para continuar
a caminhada.

Aos meus amigos pela compreenso.

A minha orientadora, Ana Price, pela amizade, compreenso e auxlio no
desenvolvimento deste trabalho.

A professora Mara Abel pela amizade, e ajuda prestada.

A coordenao e aos funcionrios da UFRGS pelas informaes e servios prestados.


4
Sumrio


Lista de Abreviaturas ou Siglas ................................................ 66
Lista de Figuras........................................................................... 7
Lista de Tabelas........................................................................... 8
Resumo......................................................................................... 9
Abstract...................................................................................... 10
1 Introduo ...............................................................................11
2 Gerncia de Projetos de Software......................................... 14
2.1 Planejamento .................................................................................... 14
2.1.1 Elaborar Estimativas ....................................................................................... 16
2.1.2 Definir a Estrutura da Organizao do Projeto............................................... 17
2.1.3 Definir Premissa de Gesto............................................................................. 17
2.1.4 Elaborar Cronograma...................................................................................... 18
2.1.5 Orar o Projeto................................................................................................ 18
2.2 Controle............................................................................................. 19
2.3 Observaes ...................................................................................... 20
3 Tcnicas de Estimativas......................................................... 21
3.1 Estimativa do Esforo ...................................................................... 21
3.2 Estimativa de Putnam...................................................................... 22
3.3 Constructive Cost Model - COCOMO........................................... 24
3.4 Anlise de Pontos por Funo......................................................... 26
3.5 Pontos de Particularidade ............................................................... 28
3.6 Personal Software Process - PSP .................................................... 30
3.7 Comparativo entre as Tcnicas....................................................... 32
4 Ferramentas Existentes ......................................................... 35
4.1 ESTIMACS....................................................................................... 35
4.2 SLIM.................................................................................................. 36
4.3 SPQR/20 ............................................................................................ 36
4.4 ESTIMATE Professional ................................................................. 37
4.5 Resultados ......................................................................................... 38
5 Ferramenta Desenvolvida ..................................................... 41
5.1 Ambiente ........................................................................................... 41
5.2 Definies Tcnicas para a Ferramenta......................................... 43
5
5.3 Estrutura da Ferramenta ................................................................ 45
5.4 Casos de Uso...................................................................................... 48
5.5 Funcionalidades da Ferramenta ..................................................... 49
5.5.1 Parametrizao................................................................................................ 50
5.5.2 Cadastramento das Informaes Pessoais....................................................... 51
5.2.3 Cadastramento dos Projetos............................................................................ 51
5.5.4 Estimativas...................................................................................................... 53
5.5.5 Acompanhamento ........................................................................................... 55
5.6 Busca de Informaes numa Base Histrica.................................. 59
6 Estudos de Casos Submetidos ............................................... 64
6.1 Custos do Transporte....................................................................... 64
6.1.1 Definies do Custo do Transporte................................................................. 64
6.1.2 Resultados....................................................................................................... 66
6.2 EDI Troca de Informaes de forma Eletrnica........................ 70
6.2.1 Definies do EDI .......................................................................................... 71
6.2.2 Resultados....................................................................................................... 72
7 Concluso ............................................................................... 76
Anexo 1 Tabela de Decomposio............................................ 78
Anexo 2 Tabela de Multiplicadores (COCOMO)................... 79
Anexo 3 Tabelas dos Pontos por Funo................................. 81
Anexo 4 Tabelas do PSP ........................................................... 84
Anexo 5 Diagrama de Atividades ............................................ 85
Anexo 6 Diagramas de Interao............................................. 92
Anexo 7 Diagrama de Estados ................................................. 98
Anexo 8 Dicionrio de Dados ................................................... 99
Bibliografia.............................................................................. 106


6
Lista de Abreviaturas ou Siglas


APF Anlise de Pontos por Funo
CMM Capability Maturity Model
COCOMO Constructive Cost Model
IFPUG Internation Function Point Users Group
LOC Nmero de Linhas de Cdigo
PF Pontos por Funo
PM Programadores-Ms
PMP Proposta de Melhoria do Processo
PP Pontos de Particularidade
PROBE Proxy-Based-Estimating Method
PSP Personal Software Process
RBC Raciocnio Baseado em Casos
SEI Software Engineering Institute
SPC Software Productivity Centre
TRC Transporte Rodovirio de Cargas


7
Lista de Figuras


FIGURA 2.1 Ciclo bsico de Gerenciamento de Projetos .......................................... 14
FIGURA 2.1.1 Processo de Planejamento de Projetos................................................ 16
FIGURA 5.1.1 Ambiente necessrio para controle do desenvolvimento.................... 42
FIGURA 5.3.1 Diagrama de Classes........................................................................... 46
FIGURA 5.4.1 Diagrama de Casos de Uso................................................................. 48
FIGURA 5.5.4.1 Tela de Consulta da Estimativa de um Mdulo............................... 54
FIGURA 5.5.4.2 Tela de Consulta da Estimativa de um Funo................................ 55
FIGURA 5.5.5.1 Tela de Pontos de Reviso do Projeto ............................................. 56
FIGURA 5.5.5.2 Tela de Alocao dos Profissionais no Projeto................................ 56
FIGURA 5.5.5.3 Tela de Acompanhamento do Profissional ...................................... 57
FIGURA 5.5.5.4 Tela de Acompanhamento da Estimativa ........................................ 58
FIGURA 5.5.5.5 Tela de Comparao entre Estimativas............................................ 59
FIGURA 5.6.1 Ciclo do RBC...................................................................................... 60
FIGURA 5.6.2 Representao Estruturada - RBC...................................................... 61
FIGURA 5.6.3 Modelo de Caso da Ferramenta de Estimativa ................................... 61
FIGURA 5.6.4 Descrio de um de Caso para Ferrramenta de Estimativa ............... 62
FIGURA 6.1.2.2 Comparativo entre Estimativas no projeto Custos do Transporte 67
FIGURA 6.1.2.3 Comparativo da Mtrica PF-Fixo modificada para o Projeto de
Custos do transporte. ...................................................................................................... 68
FIGURA 6.1.2.4 Acompanhamento dos Profissionais no projeto Custos do Transporte
........................................................................................................................................ 69
FIGURA 6.1.2.5 Alocao dos Profissionais no Projeto Custos do Transporte ......... 69
FIGURA 6.1.2.6 Acompanhamento do Projeto Custos do Transporte .................... 70
FIGURA 6.2.2.2 Comparativo entre Estimativas no projeto EDI ........................... 73
FIGURA 6.2.2.3 Acompanhamento dos Profissionais no projeto EDI ................... 74
FIGURA 6.2.2.4 Alocao dos Profissionais no projeto EDI ................................. 74
FIGURA 6.2.2.5 Acompanhamento do Projeto no projeto EDI.............................. 75


8
Lista de Tabelas


TABELA 3.1.1 Estimativa do Esforo........................................................................ 22
TABELA 3.3.1 Coeficientes do COCOMO................................................................ 25
TABELA 3.5.1 Clculo de Pontos de Particularidade ................................................ 29
TABELA 3.7.1 - Comparao das Tcnicas Apresentadas............................................ 34
TABELA 4.5.1 Comparativo entre Ferramentas......................................................... 40
TABELA 5.2.1 - Comparativo das formas de medir o Tamanho do Projeto................. 43
TABELA 5.2.2 Converso de Pontos por Funo em Horas ...................................... 44
TABELA 6.2.2.1 Tabela Comparativa das Estimativas - EDI. ................................... 72
TABELA A.1.1 - Decomposio ................................................................................... 78
TABELA A.2.1 - Multiplicadores do COCOMO 81 ..................................................... 79
TABELA A.2.2 - Multiplicadores da extenso do COCOMO ...................................... 80
TABELA A.3.1.1 - Complexidade dos Arquivos Lgicos Internos .............................. 81
TABELA A.3.2.1 - Complexidade das Interfaces Externas........................................... 81
TABELA A.3.3.1 - Complexidade das Entradas Externas ............................................ 81
TABELA A.3.4.1 - Complexidade das Sadas Externas ................................................ 81
TABELA A.3.5.1 - Complexidade das Consultas Parte de Entrada ........................... 82
TABELA A.3.5.2 - Complexidade das Consultas Parte de Sada............................... 82
TABELA A.3.6.1 - Clculo dos Pontos por Funo ...................................................... 82
TABELA A.3.7.1 - Caractersticas dos Pontos por Funo........................................... 83
TABELA 4.1 Como aplicar o PSP.............................................................................. 84




9
Resumo


Este trabalho apresenta uma ferramenta para gerenciamento de projetos, priorizando as
fases de planejamento e o controle do desenvolvimento de software.

Ao efetuar o planejamento de um projeto necessrio estimar o prazo, o custo e o
esforo necessrio, aplicando tcnicas j aprovadas, existentes na literatura, tais como:
Estimativa do Esforo, Estimativa de Putnam, Modelo COCOMO, Anlise de Pontos
por Funo, Pontos de Particularidade e PSP. necessria a utilizao de uma
ferramenta que automatizem o processo de estimativa. Hoje no mercado, encontram-se
vrias ferramentas de estimativas, tais como: ESTIMACS, SLIM, SPQR/20,
ESTIMATE Professional.

O controle do desenvolvimento do projeto est relacionado ao acompanhamento do
projeto, do profissional e da prpria estimativa de custo e esforo de desenvolvimento.
Nenhuma das ferramentas estudadas permitiu o controle do projeto por parte da
gerncia, por isto esta se propondo o desenvolvimento uma nova ferramenta que
permita o planejamento e controle do processo de desenvolvimento. Esta ferramenta
deve permitir a comparao entre as diversas tcnicas de estimativas, desde que
baseadas na mesma medida de tamanho: pontos por funo. Para exemplificar o uso
desta ferramenta, foram aplicados dois estudos de casos desenvolvidos pela empresa
Newsoft Consultoria de Informtica.

Palavras-Chaves: Produtividade, Mtricas, Estimativas, Gerncia de Projetos e
Qualidade em software.

10
Title: Productivity Estimate in Software Development

Abstract


This paper presents an environment geared towards for project management, prioritizing
planning and development control.

In order to carry out project planning, the schedule, the cost and necessary effort have to
be estimated, applying previously tested techniques which are found in the literature
such as: Effort Estimate, Putnams Estimate, COCOMO Model, Function Point
Analysis, Features Points and PSP. This project also presents some features from the
ESTIMACS, SLIM, SPQR/20 and Estimate Professional tools that automate the
estimate process.

Project control is related to the project follow-up, to the professional and to the
development effort and the cost estimate itself. As none of the tools analyzed has
allowed this sort of control, a new tool that makes this control possible and also
compares several estimate techniques, provided that they are based on size
measurement, function points, was developed. To exemplify the use of this tool, two
case studies developed by the company Newsoft Consultoria de Informtica were
applied.


Keywords: Productivity, Metrics, Estimates, Project Management and Quality in
software.
11
1 Introduo


A globalizao da economia eleva o nvel de concorrncia entre as empresas sob todos
os aspectos, exigindo uma constante reduo de custos, melhora na qualidade dos
projetos, racionalizao de processos e desenvolvimento rpido de novos produtos e
servios, assim como o aperfeioamento dos recursos humanos e tcnicos.

Para algumas empresas, a estimativa de custo do software vital para a tomada de
deciso, constituindo-se num aspecto at mesmo de sobrevivncia delas no mercado.
Assim sendo, no se pode encarar tal atividade meramente como uma sofisticao de
algumas organizaes, mas como um fator decisivo para um bom planejamento e
administrao por parte dos elementos responsveis pelo gerenciamento dos projetos. A
utilizao de recursos computacionais e humanos consiste nos maiores custos de uma
empresa desenvolvedora de software.

De acordo com [PRE 97], o software medido por muitas razes:
Indicar a qualidade do produto
Avaliar a produtividade da equipe de desenvolvimento
Avaliar os benefcios derivados de novos mtodos e ferramentas
Formar uma linha bsica para estimativas
Ajudar a justificar os pedidos de novas ferramentas ou treinamento.

Apesar da existncia de tcnicas de estimativas de custo e esforo disponveis, muitas
vezes o gerente prefere valer-se somente de sua experincia, utilizando a semelhana
entre projetos a fim de realizar a estimativa de custo e esforo do software. Portanto,
desejvel que o gerente disponha de modelos e ferramentas automticas que o motivem
utilizao de modelos algortmicos de estimativa de custos e esforos.

De acordo com [SEL 96], a complexidade de softwares tende a aumentar
continuamente, fato que dificulta a garantia da qualidade dos produtos de software ao
longo do processo de desenvolvimento. O primeiro passo para controlar e reduzir a
complexidade do software compreender em que consiste essa complexidade e como
ela pode ser trabalhada.

Segundo Watts S. Humphrey At hoje, os produtos de software tm os seus
cronogramas atrasados, custos maiores do que os esperados e apresentam defeitos. Isto
tem como resultado uma srie de inconvenientes para os usurios e traz consigo uma
enorme perda de tempo e de recursos. Estes problemas so causados por prticas no
profissionais no desenvolvimento de software, que so ocasionadas pela atual cultura de
software [WEB 99].

Faz-se necessrio uma cultura onde:
O gerente do projeto deve seguir processos definidos, planejados e medidos.
O trabalho deve ser planejado antes de chegar-se a um cronograma.
O gerente deve medir e controlar, tanto os dados relativos ao tempo como ao
tamanho e defeitos nos produtos.
O projeto deve ser documentado e revisado antes de ser codificado.
12
A qualidade deve ser planejada, medida e controlada ao longo do processo de
desenvolvimento.
O trabalho concludo deve ser analisado e o resultado deve ser utilizado para
melhorar o processo.

A estimativa parte integrante do planejamento e controle do processo de gerncia de
projetos. Para que um gerente de projetos possa definir o prazo, o custo e o esforo do
desenvolvimento, ele deve utilizar tcnicas definidas para tal. Exemplo destas so:
Estimativa do Esforo, Estimativa de Putnam, Modelo COCOMO Constructive Cost
Model, Anlise de Pontos por Funo, Pontos de Particularidade e PSP Personal
Software Process.

Cada uma das tcnicas possui caractersticas especfcas. A Estimativa do Esforo
baseia-se no nmero de pessoas-ms que ir desenvolver determinada funo, enquanto
que a Estimativa de Putnam baseia-se na equao do software, relacionando o esforo
com o tempo de desenvolvimento. O Modelo COCOMO utiliza as equaes definidas
por Barry Boehm, a partir do nmero de linhas de cdigo. A Anlise de Pontos por
Funo baseia-se na funcionalidade do projeto a ser desenvolvido, a Tcnica Pontos de
Particularidade uma extenso da Anlise de Pontos por Funo e o PSP um processo
de melhoria pessoal.

Este trabalho tem como objetivo apresentar uma ferramenta que possibilite ao gerente
de projeto efetuar o planejamento e o controle dos projetos de desenvolvimento do
software.

O planejamento envolve a estimativa de custo e esforo do desenvolvimento do projeto,
a alocao dos profissionais e dos recursos necessrios. O processo de controle refere-se
ao acompanhamento do projeto, do profissional e da estimativa, que pretende verificar a
produtividade da equipe de desenvolvimento e a qualidade do software desenvolvido.

Este trabalho apresenta no Captulo 2, a importncia da gerncia de projetos,
priorizando o planejamento e o controle dos projetos de software a serem
desenvolvidos.

As tcnicas de estimativas encontradas na literatura, tais como: Estimativa do Esforo,
Estimativa de Putnam, Modelo COCOMO, Anlise de Pontos por Funo, Pontos de
Particularidade e PSP esto descritas no Captulo 3. E ao final deste captulo apresenta-
se um estudo comparativo entre essas tcnicas.

No Captulo 4 encontra-se a descrio de algumas ferramentas que automatizam o
processo de estimativa, tais como: ESTIMACS, SLIM, SPQR/20 e ESTIMATE
Professional. Ao final deste captulo tambm apresentado um estudo comparativo
entre essas ferramentas.

Verificou-se que nenhuma das ferramentas descritas no Captulo 4 atendia
completamente as necessidades de planejamento e controle da gerncia. Por este
motivo est se propondo, no Captulo 5, uma ferramenta de desenvolvimento adequado
ao planejamento e controle de projeto, juntamente com uma ferramenta de estimativa de
custo e esforo, que atenda as necessidades dos gerentes dos projetos.

13
No Captulo 6, descreve-se dois projetos, Custos para o Transporte e EDI Troca
Eletrnica de Informaes, desenvolvidos pela empresa Newsoft Consultoria de
Informtica. Estes projetos foram submetidos ferramenta de estimativa de custo e
esforo desenvolvida. Neste Captulo, tambm descreve-se os resultados obtidos para
cada um dos projetos analisados.

Finalmente no Captulo 7, encontra-se a concluso deste trabalho, e sugestes para
trabalhos futuros.
14
2 Gerncia de Projetos de Software


A complexidade das empresas modernas, fruto do elevado nvel de competitividade e de
avanos tecnolgicos, provocou um aumento na exigncia da qualidade e complexidade
das decises administrativas [CAN 99]. Um projeto envolve execues de diversas
atividades independentes e ao mesmo tempo, eleva o grau de risco e incerteza quanto ao
sucesso do projeto.

Este ambiente dinmico e incerto dos projetos requer um gerenciamento eficaz, com
procedimentos avanados de planejamento e controle do projeto.

A Figura 2.1 apresenta o ciclo bsico de gerenciamento de projetos de software
[FER 95]. O controle deve atuar tanto sobre o planejamento quanto sobre o
desenvolvimento. Podendo ocasionar desvios que geram aes corretivas. A avaliao
ao final do projeto, realimenta o planejamento de novos projetos e assim prossegue num
ciclo indefinido. Os padres so definidos a partir dos controles e das avaliaes para o
controle e planejamento do projeto.

Padres
Controle
Atuar sobre
os Desvios
Avaliao
Desenvolvi-
mento
Planejamento
Realimentao

FIGURA 2.1 Ciclo bsico de Gerenciamento de Projetos


2.1 Planejamento

O planejamento fundamental para o sucesso do projeto [FER 95]. A Figura 2.1.1
apresenta um processo de planejamento de projetos composto por:

15
Caracterizar Soluo: significa definir o escopo do projeto em termos de requisitos do
cliente.

Definir o Processo de Desenvolvimento: consiste em determinar o processo que apoiar
o desenvolvimento da soluo em termos de fases/etapas/atividades, padres, tcnicas a
serem utilizadas.

Selecionar Perfil do Pessoal: significa determinar as habilidades tcnicas e gerenciais
necessrias para o projeto em funo da natureza e das caractersticas da soluo e do
processo definido.

Elaborar Estimativas: consiste na elaborao de estimativas de prazo, esforo, custo do
projeto bem como de tamanho do software. Pode-se tambm considerar a produtividade
esperada da equipe.

Definir Estrutura da Organizao do Projeto: significa definir como o projeto ser
organizado em termos de coordenao, quem dever participar da coordenao,
definio das atribuies, indicao das funes de apoio ao projeto.

Definir Premissa de Gesto: significa determinar o modelo de gesto a ser adotado em
termos de monitoramento do projeto, informaes a serem fornecidas para o cliente
acerca do progresso do projeto, estabelecimento de pontos de controle, local de
desenvolvimento, aspectos relativos transferncia de tecnologia, tratamento de
mudanas de escopo.

Elaborar Cronograma: consiste em estabelecer prazos para cada fase / etapa / atividade
do projeto, conforme o processo de desenvolvimento definido.

Orar o Projeto: consiste em elaborar o oramento do projeto a partir dos resultados das
estimativas e da determinao quantitativa dos recursos necessrios, requeridos pelo
empreendimento.

16
Caracterizar a
Soluo
Definir o Processo
de
Desenvolvimento
Selecionar Perfil
do Pessoal
Elaborar
Estimativas
Definir Premissa
de Gesto
Definir Estrutura
da Organizao
do Projeto
Elaborar
Cronograma
Orar o
Projeto
Elaborar
Documento
de Planejamento

FIGURA 2.1.1 Processo de Planejamento de Projetos

No estgio de planejamento o gerente deve preocupar-se com [MAF 92]:

estabelecer as caractersticas bsicas da funcionalidade do sistema a ser
desenvolvido,
demonstrar a viabilidade tcnica e financeira do projeto,
analisar o custo atravs de comparaes custo-benefcio com projetos
concorrentes,
estabelecer as caractersticas bsicas da implementao mais econmica,
definir os custos materiais e humanos, juntamente com os cronogramas
estimados para essa implementao,
convencer o cliente / usurio que contratou o desenvolvimento do sistema que a
soluo proposta efetivamente contribuir para o objetivo da sua organizao.


2.1.1 Elaborar Estimativas

O processo de elaborar estimativa de custo e esforo do desenvolvimento do projeto,
uma etapa importante no processo de planejamento. Esta etapa composta das seguintes
atividades:

Definir a medida de tamanho: definir qual das medidas de tamanho ser
utilizada: nmero de pessoas-ms, nmero de linhas de cdigo, pontos por
funo ou pontos de objetos.
Definir a mtrica de estimativa: definir qual mtrica de estimativa ser utilizada:
Estimativa do Esforo, Estimativa de Putnam, Modelo COCOMO, Anlise de
Pontos por Funo, Pontos de Particularidade ou PSP.
17
Estimar o tamanho do projeto: aplicar um mtodo, tabela de decomposio,
experincia passada, ou contagem de pontos por funo, para identificar o
tamanho do projeto.
Definir as prioridades do desenvolvimento: definir a seqncia das atividades a
serem desenvolvidas.
Estimar o esforo necessrio: a partir do tamanho do projeto e da prioridade
estabelecida, definir o nmero de pessoas-ms necessrias para o
desenvolvimento aplicando a mtrica de estimativa definida.

No basta elaborar uma estimativa na fase inicial do desenvolvimento e no efetuar o
controle sobre o projeto, porque sem o controle os valores apresentados podem se
tornar incorretos.

Caso ocorram modificaes no projeto que afetem o seu tamanho, a estimativa deve ser
refeita e reanalisada, novos valores devem ser utilizados para efetuar o controle do
projeto.


2.1.2 Definir a Estrutura da Organizao do Projeto

Esta etapa do planejamento consiste na definio da equipe que trabalhar no
desenvolvimento do projeto.

Primeiramente deve ser definido que tipos de servios prestados pelos profissionais a
serem alocados no projeto: analistas, programadores, consultores. Depois desta
definio necessrio definir o perfil do profissional que ir executar estes servios:
tempo de empresa, conhecimento tcnico, conhecimento do negcio e escolaridade.

A partir destas definies devem ser sugeridos nomes de profissionais disponveis,
capazes de serem alocados para este novo projeto.

Para controle da gerncia interessante que estas informaes sobre os profissionais
alocados no projeto, possam ser visualizados em grficos (Ex: Grfico de Gantt ). Na
alocao dos profissionais deve ser considerada a data de incio da alocao, a data de
trmino da alocao, e o tempo disponvel para desenvolvimento do projeto. Um
profissional pode ser alocado em dois perodos diferentes de tempo. Tambm deve ser
considerado o tempo improdutivo do profissional: como atendimento de telefones,
suporte a outros projetos.


2.1.3 Definir Premissa de Gesto

Esta etapa do planejamento define o relacionamento entre o cliente e a software house.
Atualmente, os clientes querem ter informaes sobre o andamento do seu projeto, para
que ao final no sejam surpreendidos com um projeto que no atenda as suas
necessidades, ou que seja entregue aps o prazo estimado ou com um custo superior ao
definido.

18
Nesta etapa do planejamento definem-se os pontos de controle ou milestones. Pontos
de controle so datas de verificao do projeto. Quando se define uma data de
verificao define-se tambm o que deve estar desenvolvido at este ponto, permitindo
desta forma fazer uma relao do estimado com o desenvolvido.

Para determinar o que deve estar desenvolvido at a data de verificao, pode-se utilizar
as informaes referentes alocao dos profissionais juntamente com a sua capacidade
de produo.

Para projetos pequenos, durao de zero a quatro meses, os pontos de controle podem
ser definidos como sendo de quinze em quinze dias. Mas para projetos maiores, de
quatro meses a um ano, sugere-se que os pontos de controle sejam definidos ms-a-ms.
Para projeto de um ano a dois anos, os pontos de controle devem ser bimestrais, e para
projetos superiores devem ser trimestrais.

Nesta etapa tambm devem ser definidos os procedimentos a serem seguidos quando
ocorrer uma modificao no escopo do projeto. O cliente deve ser informado dos novos
prazos e custos do projeto.


2.1.4 Elaborar Cronograma

A partir das informaes das atividades a serem desenvolvidas, e dos profissionais
alocados para o projeto, deve-se definir o cronograma do projeto.

Primeiramente as prioridades das atividades do desenvolvimento devem ser revisadas, e
aprovadas pelo cliente. Depois de definidas as prioridades, deve-se relacionar as
atividades com os profissionais alocados e capacitados para o desenvolvimento da
atividade. Esta relao, tambm chamada de cronograma, deve ser divulgada para toda a
equipe de desenvolvimento, pois existem atividades que so dependentes de outras
atividades.

Um cronograma pode ser apresentado por meio de uma tabela, relacionando a atividade
com o profissional e o perodo no qual ele estar alocado para o seu desenvolvimento.


2.1.5 Orar o Projeto

Esta etapa do planejamento responsvel pela definio dos custos e do preo do
projeto. Com base nos profissionais alocados, nos cronogramas e observando os custos
administrativos pode-se determinar o custo do projeto. Sobre o custo do projeto deve ser
definido um percentual de lucro que a software house deseja obter para determinar o
preo do projeto.

O preo do projeto deve estar de acordo com as possibilidades do cliente e tornar o
projeto vivel para a software house.


19
2.2 Controle

No controle, devem ser empregados alguns procedimentos para medir e acompanhar: o
tempo, o custo e o esforo do desenvolvimento de um projeto, durante a sua vida, isto
significa coordenar a ao de todas as partes.

Em relao ao tempo, a melhor forma de gerenciar atravs de cronogramas,
representao grfica do tempo planejado, ou estimado, para que determinada atividade
seja executada. A forma de um escala de tempo, pode ser demonstrada por meio de
barras que indicam a durao e o perodo de tempo para a qual a atividade foi
programada, tambm pode ser demonstrado o confronto entre o tempo estimado e o
tempo real gasto no projeto.

Para o controle do custo utiliza-se como ferramenta bsica o oramento. Elaborado
ainda na fase preliminar do planejamento, por meio de estimativas de custos. medida
que o projeto vai sendo desenvolvido tambm o oramento vai sendo aperfeioado, at
chegar ao nvel operacional de execuo das atividades.

Tambm deve ser efetuado o controle do projeto, do profissional e da estimativa de
custo e esforo no desenvolvimento de software.

O projeto deve ser controlado atravs dos pontos de controle, ou milestones, definidos
na fase de planejamento. Um ponto de controle significa que em uma determinada data
se far uma verificao do andamento do projeto, se o que foi desenvolvido at o
momento est de acordo com o que foi estimado. A partir destes pontos de controle
possvel elaborar um grfico de linhas, visualizando o andamento do projeto. A partir
destas informaes o gerente do projeto pode tomar aes corretivas para acelerar ou
desacelerar o desenvolvimento do projeto.

O controle dos profissionais est relacionado diretamente produtividade da equipe de
desenvolvimento, esta no uma atividade fcil, pois o desenvolvimento depende do
conhecimento e da vontade do profissional. Primeiramente devem ser analisadas as
caractersticas de cada um dos profissionais que compem a equipe de
desenvolvimento. Depois deve-se definir uma mdia de produtividade por profissional.
O controle est na relao do que o profissional realmente produz com a sua mdia. De
tempos em tempos a mdia deve ser novamente refeita. O gerente do projeto deve
visualizar estas informaes atravs de grficos, para a tomada de aes corretivas, pois
a visualizao atravs de grficos facilita identificar quais profissionais apresentam
problemas quanto produtividade.

E o controle das estimativas, serve para efetuar os ajustes nas estimativas de acordo com
a empresa desenvolvedora do software. Tambm interessante efetuar uma comparao
entre diversas estimativas sobre um mesmo projeto, para identificar a estimativa que
mais se adapta ao projeto a ser desenvolvido.





20
2.3 Observaes

O processo de estimativa uma pequena parte do processo de planejamento e controle
de um projeto, mas extremamente importante. Pois a partir destas informaes que
se consegue:

Definir o tamanho previsto do projeto.
Definir o esforo necessrio para o desenvolvimento do projeto.
Definir o custo previsto do projeto.
Definir o tempo necessrio para o desenvolvimento do projeto.

De acordo com Deming, 85% dos problemas que ocorrem nos processos da empresa
de responsabilidade da gerncia [DEM 86]. Mais do que nunca, o ambiente
competitivo das empresas est a exigir um processo constante de mudanas, em
qualquer tipo de segmento produtivo.

Para que um processo de estimativa tenha sucesso necessrio:

Definir claramente quais mtricas devero ser coletadas e analisadas
Definir como os resultados das mtricas sero utilizados
Definir as mtricas que sero empregadas no projeto desde seu planejamento
Dar um feedback peridico equipe do projeto
Manter o comprometimento com o esforo da medio

importante ter em mente que a obteno da qualidade desejada de responsabilidade
de todos, mas principalmente dos nveis gernciais, pois so eles que definem os
oramentos e aprovam as aquisies de recursos, entre outros aspectos.


21
3 Tcnicas de Estimativas


Antes que um projeto seja planejado, os objetivos e o escopo devem ser estabelecidos,
solues alternativas devem ser consideradas e as restries administrativas e tcnicas
identificadas. Sem essas informaes impossvel definir estimativas de custos
razoveis e precisas.

A literatura apresenta uma srie de tcnicas de estimativas tais como: Estimativa do
Esforo [PRE 95], Estimativa de Putnam [PUT 78], Constructive Cost Model
(COCOMO) [BOE 81], Anlise de Pontos por Funo (APF) [IFP 94], Pontos de
Particularidade [PRE 95] e Personal Software Process (PSP) [HUM 95]. Essas tcnicas
apresentam os seguintes atributos em comum:

O escopo do projeto deve ser estabelecido antecipadamente,
As mtricas de software utilizam os histricos de aferies passadas como base
sobre as quais as estimativas sero feitas,
O projeto dividido em pequenas partes que so estimadas individualmente.

Hoje, as mtricas de estimativa de custo dividem-se em mtricas orientadas ao tamanho
e mtricas orientadas funo. As mtricas orientadas ao tamanho so medidas diretas
do software e do processo pelo qual ele desenvolvido [JON 91]. Elas provocam
controvrsias e no so universalmente aceitas como a melhor maneira de medir o
processo de desenvolvimento de software. A maior parte da controvrsia gira em torno
do uso das linhas de cdigo como uma medida chave. Mtricas orientadas funo so
medidas indiretas do software e do processo pelo qual ele desenvolvido. Em vez de
contar as linhas de cdigo, a mtrica orientada funo concentra-se na
funcionalidade ou utilidade do sistema.


3.1 Estimativa do Esforo

Segundo [PRE 95], a estimativa do esforo a tcnica mais comum para levantar os
custos de qualquer projeto de desenvolvimento de engenharia. Um nmero de pessoas-
dia, ms ou ano aplicado soluo de cada tarefa do projeto. Um custo em dlares
associado a cada unidade de esforo e um custo estimado derivado.

De acordo com a medida LOC (Nmero de Linhas de Cdigo), a estimativa do esforo
inicia com um delineamento das funes do software identificadas a partir do escopo do
projeto. As funes e as tarefas de desenvolvimento (anlise de requisitos, projeto,
codificao, teste, documentao) correlatas podem ser representadas como parte de
uma tabela, tal como ilustrada na Tabela 3.1.1.

O planejador estima o esforo (pessoas-ms) que ser exigido para concluir cada tarefa
de desenvolvimento para cada funo do software. Taxas de mo-de-obra (custo-esforo
unitrio) so aplicadas em cada uma das tarefas de desenvolvimento. Muito
provavelmente a taxa de mo-de-obra variar para cada tarefa. O pessoal de nvel snior
dever envolver-se fortemente na anlise de requisitos e nas primeiras tarefas de
22
realizao do projeto; o pessoal de nvel junior (programadores) dever envolver-se nas
ltimas tarefas de projeto, codificao e nos primeiros testes.


TABELA 3.1.1 Estimativa do Esforo
Anlise de
Requisitos
Projeto Codificao Teste Documentao Total




Funes
especficas do
projeto

Estimativas em
Pessoas-Ms
Total
Taxa($)
Custo ($)

O custo e o esforo de cada funo e tarefa de desenvolvimento so computados como o
ltimo passo. Se a estimativa do esforo for realizada independentemente da estimativa
LOC (tabela de decomposio por nmero de linhas de cdigo, apresentadas no Anexo
1) tem-se, ento, duas estimativas para o custo e para o esforo que podem ser
comparadas e acordadas. Se as duas estimativas demonstrarem razovel concordncia,
haver uma boa razo para acreditar que as estimativas so confiveis. Se por outro
lado, os resultados dessas tcnicas exibirem pouca concordncia, investigao e anlise
adicionais devem ser feitas.

Esta estimativa aplicada em empresas sem seguir uma regra definida, pois a sua
medida-chave o nmero de pessoas-ms que iro trabalhar no projeto. Medida esta
que identifica o maior custo de uma software house, e para controle da empresa
necessrio saber quais profissionais esto trabalhando em quais projetos.


3.2 Estimativa de Putnam

A estimativa de Putnam [PUT 78] um modelo dinmico de mltiplas variveis que
pressupe uma distribuio de esforo especfico ao longo da existncia de um projeto
de desenvolvimento de software. O modelo foi construdo a partir de uma distribuio
de mo-de-obra encontrada em grandes projetos (esforo total de 30 pessoas-ano ou
mais), porm a extrapolao para projetos de software menores possvel.

A estimativa de Putnam relaciona linhas de cdigo ao tempo e esforo de
desenvolvimento, utilizando as seguintes equaes:

L = C
k
* K
1/3
* T
4/3
ou, equivalentemente K = L
3
/ (C
k
3
* T
4
)

Onde,
L = nmero de linhas de cdigo
K = esforo medido em pessoas-ms ou pessoas-ano
T = durao do projeto em meses ou anos
C
k
= constante do estado da tecnologia.
23

Os valores tpicos para a constante do estado da tecnologia so: para um ambiente de
desenvolvimento pobre
1
C
k
= 2.000; para um ambiente de desenvolvimento de bom
2

nvel, C
k
= 8.000 e para um ambiente excelente
3
, C
k
= 11.000. O valor da constante de
tecnologia (C
k
) tambm pode ser derivado das condies locais utilizando dados
histricos coletados no esforo do desenvolvimento.

A estimativa de Putnam permite a troca do tempo pelo esforo. Ao acrescentar pessoas
num projeto, diminui-se o tempo do desenvolvimento. Em contra partida aumenta-se o
custo do projeto. Ao ultrapassar o ponto mximo para esta troca o projeto torna-se
incontrolvel. Em contra partida, os administradores, podem simular outras situaes,
verificando o tempo, o esforo e o custo do projeto. Quanto menor o tempo, maior o
esforo e o custo do desenvolvimento de um projeto.

Esta estimativa tambm permite o clculo da produtividade mdia constante atravs da
frmula:

PR = C
k
* D
-2/3
ou PR = C
k
* ( K / T
2
)
2/3


Onde,

PR = produtividade constante
D = K / T
2


Isso significa que a produtividade mdia constante (PR) est diretamente relacionada ao
tempo (T) e esforo do desenvolvimento do sistema (K). Por isto, conclui-se que
difcil medir a produtividade de um projeto com base em outro, por que ambos devem
ter o mesmo grau de dificuldade (mesmo nmero de arquivos, mesmo nmero de
consultas, relatrios...) e o mesmo tempo.

A equao utilizada pela estimativa de Putnam (tambm chamada de equao do
software) apresenta como resultado uma funo, fazendo com que o usurio defina
valores para determinar a curva (Rayleigh-Norden Tempo x Esforo) e decidir qual
ser o esforo e o tempo necessrio para o desenvolvimento do software.

Segundo [PIL 97], vrios pesquisadores criticam o uso de uma curva de Rayleigh como
base para a estimativa de custo e esforo do desenvolvimento de software, pois as
observaes originais de Norden no foram baseadas em teorias, mas em observao de
projetos de hardware.

O mtodo de Putnam baseado na viso que os projetos de software seguem padres
bem definidos e que podem ser modelados com um conjunto de equaes
exponenciais [SPC 99].



1
Ambiente de Desenvolvimento Pobre um ambiente sem base metodolgica, sem documentao e com revises
precrias.
2
Ambiente de Desenvolvimento Bom um ambiente que aplica metodologias, com documentao.
3
Ambiente de Desenvolvimento Excelente um ambiente com ferramentas e tcnicas automatizadas.
24
3.3 Constructive Cost Model - COCOMO

O modelo COCOMO foi desenvolvido para estimar esforos de desenvolvimento,
prazos e tamanho de equipe para projetos de sistemas de informaes, a partir de uma
amostra de 63 projetos concludos nas reas de negcios, controle cientfico, suporte e
sistemas operacionais. uma tcnica j bem documentada e bastante aceita
considerando o nmero de projetos desenvolvidos que a utilizaram.

Barry Boehm [BOE 81] apresenta uma hierarquia de modelos de estimativa de software,
da seguinte forma:

Modelo 1. O COCOMO bsico um modelo esttico de valor simples que computa o
esforo (e custo) de desenvolvimento de software como uma funo do tamanho do
programa expresso no nmero de linhas de cdigo estimado.

Modelo 2. O COCOMO intermedirio computa o esforo de desenvolvimento de
software como uma funo do tamanho do projeto e de um conjunto de direcionadores
de custo que incluem avaliaes subjetivas do projeto, do hardware, do pessoal e dos
atributos do projeto.

Modelo 3. O COCOMO avanado incorpora todas as caractersticas da verso
intermediria com uma avaliao do impacto dos direcionadores de custos sobre cada
passo (anlise, projeto, etc) do processo de engenharia de software.

O COCOMO pode ser aplicado em trs tipos de projetos de software. Usando a
terminologia de Boehm, so elas:
Tipo Orgnico projetos de software simples, relativamente pequenos, nos
quais pequenas equipes com boa experincia em aplicaes trabalham num
conjunto de requisitos no to rgidos;
Tipo Semidestacado (difuso) um projeto de software intermedirio (em
tamanho e complexidade) no qual equipes com nveis de experincia mistos
devem atingir uma combinao de requisitos rgidos e no to rgidos;
Tipo Embutido (restrito) um projeto de software que deve ser desenvolvido
dentro de um conjunto rgido de restries operacionais, de hardware e de
software.

Existe um grupo de pesquisa trabalhando para atualizar a tcnica COCOMO para os
novos processos de desenvolvimento [MAD 97].

O COCOMO utiliza as equaes desenvolvidas por Boehm para prever o nmero de
programadores-ms (PM) e o tempo de desenvolvimento (D), os quais so calculados a
partir do nmero de instrues-fonte (Linhas de Cdigo, Pontos por Funo, Pontos de
Objetos). Os resultados das equaes devem ser ajustados a fim de representarem as
influncias que ocorrem no desenvolvimento do projeto de software no que se refere a
atributos do produto, computacionais, de pessoal e de projeto. A tcnica utiliza, para
caracterizar essas variaes, a aplicao de multiplicadores de esforo s estimativas
nominais. No Anexo 2 so mostrados os multiplicadores de esforo propostos por
Boehm em 81 e na verso estendida do COCOMO, chamado de COCOMO II.

25
O COCOMO II adaptado aos ciclos de vida de software modernos. O modelo do
COCOMO original teve muito sucesso, mas ele no se aplica s novas prticas de
desenvolvimento de software to bem quanto ele se aplicava s prticas tradicionais. O
COCOMO II tem como alvo os projetos de softwares dos anos 1990 e 2000, e vai
continuar a evoluir nos prximos anos de acordo com [HON 97].

O COCOMO II incorpora um conjunto de indicadores de custos revisados e indicadores
de escala. Essa extenso suporta o planejamento de projeto ao identificar, categorizar,
quantificar e priorizar os recursos do mesmo, e detecta tambm as anomalias de
entradas na estimativa de custo, fornecendo aconselhamento no controle do risco alm
dos clculos comuns [MAD 97].

As equaes do COCOMO bsico so:

E = a
b
(KLOC) exp(b
b
)

D = c
b
( E exp(d
b
) )

A equao do COCOMO intermedirio assume a forma:

E = a
i
(KLOC) exp(b
i
) x EAF

Onde,
E = o esforo aplicado em pessoas-ms,
D = o tempo de desenvolvimento em meses cronolgicos,
KLOC = o nmero estimado de linhas de cdigo do projeto (expresso em milhares),
EAF = o fator de ajuste do esforo. Valores tpicos para o EAF variam de 0,9 a 1,4.

Os coeficientes a
b
, a
i
e c
b
e os expoentes b
b
, b
i
e d
b
so fornecidos na Tabela 3.3.1.

TABELA 3.3.1 Coeficientes do COCOMO
Projeto de Software a
b
b
b
c
b
d
b
a
i
b
i

Orgnico 2.4 1.05 2.5 0.38 3.2 1.05
Semidestacado 3.0 1.12 2.5 0.35 3.0 1.12
Embutido 3.6 1.20 2.5 0.32 2.8 1.20

O COCOMO foi utilizado pela US Army Organization como calibrador do modelo de
estimativas desenvolvido por essa organizao [GRA 99]. O COCOMO possui
coeficientes que no so vlidos para todas as organizaes, mas no estudo foi
verificado que os resultados do modelo desenvolvido e do COCOMO foram
semelhantes para projetos pequenos.

Barry Boehm est liderando um grupo de acadmicos que atuam em indstrias para
revisar o novo conjunto de equaes do COCOMO, e para coletar dados para avaliar
hipteses, selecionando os parmetros significativos [HON 97].




26
3.4 Anlise de Pontos por Funo

A tcnica Anlise de Pontos por Funo foi introduzida por Allan J. Albretch da IBM
em 1974. Foram analisadas centenas de softwares para isolar as variveis crticas e
determinar o tamanho do software. Essa medida determina o tamanho do software
atravs das funes executadas pelo software, ao invs de utilizar o volume ou a
complexidade do cdigo fonte como base para o clculo do tamanho.

A tcnica de Anlise de Pontos por Funo (APF) dimensiona uma aplicao na
perspectiva do usurio final, ao invs de levar em considerao as caractersticas
tcnicas da linguagem utilizada. APF dimensiona o software quantificando a
funcionalidade que ele proporciona aos usurios baseando-se, principalmente, no seu
desenho lgico.

Os objetivos da tcnica so:
Medir o que foi requisitado, e recebido do usurio; independente da tecnologia
utilizada para a implementao.
Prover uma mtrica de medio para apoiar a anlise de produtividade e
qualidade.
Prover uma forma de estimar o tamanho do software e um fator de normalizao
para comparao de software.
Permitir que qualquer usurio ligado a processamento de dados que conhea a
aplicao do software possa compreender e utilizar essa tcnica.

Alm de atingir os objetivos descritos, o processo de contagem de Pontos por Funo
deve ser simples para minimizar o trabalho adicional do processo de mensurao, e
conciso para permitir consistncia ao longo do tempo dos projetos e entre os usurios da
tcnica.

A mtrica de Pontos por Funo uma medida padronizada pela Organizao
Internacional IFPUG que procura ser independente de metodologia, tecnologia e
ferramenta de desenvolvimento, preocupando-se com a funcionalidade do ponto de vista
do cliente. A contagem do IFPUG inclui cinco etapas [CAS 98]:

definio do tipo de sistema a ser contado,
identificao das fronteiras do sistema,
contagem das bases de dados internas e externas,
contagem das funes de entrada, sada e consulta,
ajuste da contagem final atravs dos fatores de ajuste.

O modelo definido por Albretch considera cinco componentes: arquivo, interface,
entrada, sada e consulta e atribui uma complexidade e funcionalidade que varia de
simples, mdia e complexa.

Esta tcnica possui vrias extenses, cada uma com suas caractersticas prprias [PRE
95], [FUR 97]. A contagem dos Pontos por Funo dentro de uma mesma organizao
pode tambm variar dependendo dos aspectos considerados pelas pessoas que fizeram
efetivamente a contagem. Isso aparece por causa dos desvios nas avaliaes subjetivas
[MAT 94]. A forma de minimizar esse problema definir indicadores padres para
poder encontrar o ponto mdio. Outro fator que tambm influncia na variabilidade da
27
contagem a equipe (grupo) do projeto. Para amenizar esse problema necessrio
considerar as pessoas como fator de ajuste.

A seguir mostrado o caminho que deve ser percorrido para se calcular os Pontos por
Funo:

Passo 1: Contar o nmero de pontos existentes para cada parte do projeto,
contando o nmero de arquivos, nmero de interfaces, nmero de entradas, nmero de
sadas e nmero de consultas.

Passo 2: Identificar o nvel de cada item contado conforme a Tabela de
Complexidade do Item (Anexo 3, A.3.1 A.3.5).

Passo 3: Multiplicar os Pontos por Funo de acordo com a classificao
encontrada na Tabela de Clculo dos Pontos por Funo (Anexo 3, A.3.6).

Passo 4: Somar todos os Pontos por Funo de cada item contado e multiplicado.

Passo 5: Os Pontos por Funo devem sofrer um ajuste conforme o ambiente onde
sero desenvolvidos. Utilizando a Tabela de Caractersticas Gerais (Anexo 3, A.3.7)
identifica-se o NI (nvel de influncia) e aplica-se a frmula a seguir para encontrar o
Fator de Ajuste.

Fator de Ajuste = (NI * 0,01) + 0,65.

Passo 6: Aplicar o Fator de Ajuste nos Pontos por Funo calculados a partir da
frmula:

PF Ajustados = PF Brutos * Fator Ajuste.

Aproximadamente 40 diferentes mtodos de Anlise de Pontos por Funo existem hoje
em dia [MAX 00].

Um destes mtodos, tambm muito utilizado, considerando o componente interface,
definido por Albretch, como sendo parte do componente arquivo, e utilizando nveis
de complexidades pr-definidos ao invs de simples, mdio e complexo. O clculo de
APF resultante seria:

APF = ( 4 x entrada + 5 x sada + 4 x consulta + 10 x arquivos ) * Ck

Onde:
Ck o Fator de Ajuste (calculado da mesma forma que Albretch definiu)
4, 5, 4 e 10 so os coeficientes utilizados para sistemas de complexidade mdia.

A mtrica de Anlise de Pontos por Funo foi definida no perodo do desenvolvimento
Estruturado. Hoje em dia, as empresas esto optando pelo desenvolvimento
Orientado a Objetos. Ao desenvolver um projeto orientado a objetos possvel definir
o nmero de pontos de objetos da mesma forma que no desenvolvimento estruturado se
define o nmero de pontos por funo. Mas ao invs de verificar as funes a serem
desenvolvidas devem ser verificados as classes e eventos a serem programados.
28
3.5 Pontos de Particularidade

Em 1986, a empresa Software Productivity Research, Inc. desenvolveu um modelo
experimental aplicado lgica de Pontos por Funo em processos de software, e
sistemas operacionais. Para evitar confuso com o mtodo de Pontos por Funo essa
alternativa experimental foi chamada de Pontos de Particularidade (Features Points). A
tcnica de Pontos de Particularidade proposta por Jones [JON 86], uma extenso da
tcnica de Pontos por Funo.

A mtrica de Pontos de Particularidade um super conjunto da mtrica Pontos por
Funo e introduz mais um parmetro (nmero de algoritmos) nos padres dos Pontos
por Funo (entrada, sada, consulta, arquivo e interface).

A medida de Pontos de Particularidade utilizada em aplicaes em que a
complexidade algortmica elevada. Quando se aplica, numa organizao, os Pontos
por Funo e Pontos de Particularidade, os resultados podem ser iguais quando o
software desenvolvido no tem uma complexidade muito elevada. J em casos de
desenvolvimento de software complexos (maior nmero de algoritmos que o nmero de
arquivos) a tcnica Pontos de Particularidade apresenta um resultado maior que a de
Pontos por Funo. Se o nmero de algoritmos for menor que o nmero de arquivos, a
mtrica, Ponto de Particularidade apresentar um resultado menor que a mtrica, Pontos
por Funo.

A maior diferena entre Pontos por Funo e os Pontos de Particularidade o novo
parmetro: nmero de algoritmos. Algoritmos so definidos dentro do contexto padro
da engenharia de software, como sendo rotinas que executam determinada funo
dentro do sistema. Alguns exemplos de algoritmos tpicos: rotinas de clculo de datas
nos calendrios, extrao de tabelas e clculo de salrios.

Os parmetros da mtrica Pontos de Particularidade so:

Nmero de Entradas: uma entrada consiste no fornecimento de algum dado do usurio
ou da aplicao para o software.

Nmero de Sadas: uma sada compreende os dados produzidos pela aplicao
fornecidos ao usurio, que incluem impresso de relatrios,
informaes na tela e mensagens de erros. Os componentes
individuais dos relatrios ou telas no so contados.

Nmero de Consultas: uma consulta do usurio diferente das entradas porque est
envolvida com o controle do software, tanto que fornece dados
orientados da aplicao.

Nmero de Arquivos: nmero de tabelas que esto relacionadas ao projeto.

Nmero de Interfaces: todas as interfaces atravs das quais so transmitidas
informaes para outra parte do sistema so contadas. Estas
incluem: discos, impressoras, modens, links, etc.

29
Nmero de Algoritmos: abrange todos os algoritmos requeridos para cumprir a
especificao.

O mtodo de Pontos de Particularidade similar aos de Pontos por Funo como pode
ser visto na Tabela 3.5.1. Cada um dos parmetros deve ser multiplicado por um fator
de complexidade correspondente como mostra a Tabela 3.5.1. Estes fatores podem ser
alterados conforme a experincia da organizao, a partir de estimativas anteriores.

TABELA 3.5.1 Clculo de Pontos de Particularidade
Tipo Nmero de Pontos Complexidade Pontos X Complexidade
Nmero de Algoritmos X 3
Nmero de Entradas X 4
Nmero de Sadas X 5
Nmero de Consultas X 4
Nmero de Arquivos X 7
Nmero de Interface X 7
Sub Total
Fator de Ajuste da Complexidade
Total dos Pontos de Particularidade Ajustados

A seguir so mostrados quais algoritmos so significativos e devem ser contados:

Os algoritmos que esto de acordo com a resoluo do problema.
Os algoritmos que esto de acordo com a definio do problema.
Os algoritmos que possuem entradas ou valores iniciais.
Os algoritmos que possuem sadas ou processam um resultado.
Os algoritmos que incluem ou chamam algoritmos subordinados a ele.
Os algoritmos que representam, via conceitos de programao estruturada
padro as seqncias: if-then-else, do-while, case...

O Total de Pontos por Funo e o Total de Pontos de Particularidade podem ser
combinados dando o Valor dos Pontos por Funo usando a frmula:

VPF = TPF x [ 0,65 + (0,01 x TPP)]

Onde:
VPF = Valor de Pontos por Funo
TPF = Total dos Pontos por Funo
TPP = Total dos Pontos de Particularidade

O Valor de Pontos por Funo representa a complexidade do projeto de software. E a
organizao necessitaria de validaes para relacionar os valores de Pontos por Funo
com o esforo de desenvolvimento do software e o nmero de defeitos.

Essa tcnica acrescenta outros Pontos por Funo que tambm devem ser medidos para
facilitar, e tornar mais precisos o clculo do esforo, do tempo e do custo do projeto.


30
3.6 Personal Software Process - PSP

O Personal Software Process (PSP), processo derivado do SEI-CMM (Software
Engineering Institute Capability Maturity Model) foi desenvolvido como recurso para
capacitao, melhoria e otimizao do processo individual de trabalho. Essa nova
abordagem uma grande oportunidade para aplicar conceitos importantes de engenharia
de software em nvel individual para desenvolver software e no apenas para codificar
programas [HUM 95].

Assim como um processo de software uma seqncia de etapas necessrias para se
desenvolver ou fazer manutenes em software, o PSP faz uso de um conjunto de sete
etapas seqenciais e progressivas, como mostra a Figura 3.6.1. Feitas sob medida para
desenvolver programas de tamanho modular entre 50 a 5.000 linhas de cdigo. Ou seja,
PSP pode ser aplicado desde a construo de um simples programa ao desenvolvimento
de um software complexo com um grande nmero de programas. Cada uma dessas
etapas possui um conjunto de roteiros formulrios e gabaritos associados (vide Anexo
4).
A Evoluo do Processo PSP
Medio Pessoal
Planejamento Pessoal
Qualidade Pessoal
Processo Cclico
PSP0
Processo Atual
Registro de Tempos e Defeitos
PSP0.1
Padro de codificao
Medio de tamanho
Proposta de melhoria do processo
PSP1
Estimativa de Tamanho
Relatrio de Testes
PSP2
Reviso de Cdigo
Revises de Projeto
PSP3
Desenvolvimento Cclico
PSP1.1
Planejamento de Tarefa
Planejamento de escalonamento
PSP2.1
Gabaritos de Projetos
FIGURA 3.6.1 - Evoluo do Processo do PSP

O PSP visa demonstrar os princpios do processo pessoal, determinar a situao do
processo atual de software, desenvolver um processo de planejamento para
desenvolvimento de software, medir o tamanho do software como parte do cronograma
e dos recursos necessrios para o software, realizar medies apropriadas do processo
pessoal, fazer revises significativas de projeto e cdigo, executar gerenciamento da
qualidade do software, estabelecer um padro de referncia para medir as melhorias do
processo pessoal e determinar o impacto das mudanas sobre a eficincia profissional.

O PSP introduz os conceitos de processo de software no nvel pessoal, em uma srie de
sete etapas [SIL 97]:
Medio Pessoal
31
PSP0 Nessa etapa os profissionais de software aprendem a aplicar os formulrios e
roteiros do PSP aos seus trabalhos pessoais, medindo tempos e defeitos de
desenvolvimento, defeitos esses injetados ou removidos. Isso faz com que os
engenheiros de software renam informaes reais e prticas que serviro como
ponto de referncia contra o qual ser medido o progresso enquanto aprendem a
praticar o PSP. PSP0 possui trs fases: planejamento, desenvolvimento e autpsia,
sendo o desenvolvimento composto de projeto, codificao, compilao e teste.
PSP0.1 Adiciona um padro de codificao, medio de tamanho e formulrio de
Proposta de Melhoria do Processo (PMP). Os profissionais de software registram no
PMP os problemas, tpicos importantes para discusso e argumentao e as idias a
serem usadas futuramente, aperfeioando assim os seus processos pessoais.

Planejamento Pessoal
PSP1 Introduz o mtodo PROBE (Proxy-Based-Estimating Method), atravs do
qual profissionais de software estimam tamanhos e tempos de desenvolvimento para
novos programas, com base nos seus prprios dados pessoais. PROBE utilizado
para indicar a qualidade da estimativa de tamanho e tempo.
PSP1.1 Adio de escalonamento e de planejamento das tarefas

Qualidade Pessoal
PSP2 Introduz o gerenciamento de defeitos. Com os dados de defeitos reunidos
previamente, os profissionais de software constroem e usam checklists para reviso
de produtos e cdigos. No treinamento salientada a importncia de focar qualidade
desde o incio e como revisar eficientemente os programas.
PSP2.1 Introduz as tcnicas de especificao de projeto e anlise em adio
preveno de defeitos, anlise e comparao de processos. Medindo os tempos das
tarefas realizadas e o nmero de defeitos injetados ou removidos em cada fase do
processo. Os profissionais aprendem a avaliar e melhorar a eficincia pessoal.

Processo Cclico
PSP3 a etapa final do PSP, onde os profissionais de software combinam
mltiplos PSP2.1 de uma forma cclica para construir mdulos com milhares de
linhas de cdigo. Neste nvel, os profissionais exploram os mtodos de verificao
de projeto, assim como os princpios e mtodos de definio de processo.

No Anexo 4, apresentada uma tabela com as principais tarefas que devem ser seguidas
para a implantao do PSP numa empresa.

Um ponto crtico percebido por [SIL 97] a dependncia entre as tabelas do
treinamento em relao ao paradigma de programao que est sendo utilizado para
implementar (exemplo: procedimentos versus orientao objetos). Conseqentemente
h uma forte dependncia dos exerccios em relao linguagem e ao ambiente de
programao.






32
3.7 Comparativo entre as Tcnicas

As estimativas so confiveis? A nica resposta razovel a esta pergunta : no se pode
ter certeza. Qualquer tcnica de estimativa, no importa quo sofisticada seja, deve
sofrer uma verificao cruzada com outra abordagem. Mesmo assim, o senso comum e
a experincia devem prevalecer [PRE 97].

Alguns problemas comuns encontrados com relao s estimativas [JON 91]:

As estimativas relativas preciso de projetos de software so difceis de serem
obtidas, em parte porque os gerentes de projetos no gostam de tornar pblicos
os seus fracassos.
A principal razo, porm, que a maioria dos gerentes de projeto no fazem as
estimativas. Se as fazem, no controlam o objeto estimado. Se controlam o
objeto estimado, no fazem os acompanhamentos ou constantemente substituem
as estimativas por outras at que as originais sejam esquecidas.

Quando as estimativas so feitas, no entanto, os resultados do controle mostram que
geralmente elas tendem a no se concretizar, principalmente porque:

As estimativas so realizadas por pessoas que no possuem o conhecimento
necessrio para aplic-las.
No se faz as previses adequadas para contrabalanar os efeitos das distores.
No se segue exatamente a regra definida na literatura de como se deve estimar
um projeto.
No se sabe como lidar com os problemas polticos que dificultam o processo de
estimativa, como por exemplo: a incluso de novas funes em um projeto pode
modificar o seu cronograma.
No se baseiam em estimativas de desempenhos passados.

Cada tcnica possui as suas prprias caractersticas. A Tabela 3.7.1 mostra um
comparativo entre as tcnicas descritas neste captulo.

Ao analisar a Tabela 3.7.1, identifica-se que a Estimativa de Putnam, COCOMO,
Anlise de Pontos por Funo e Pontos de Particularidade levam em considerao a
tecnologia utilizada pela organizao. A Estimativa de Putnam considera a tecnologia
para definir a sua constante tecnolgica, enquanto as estimativas COCOMO, Anlise de
Pontos por Funo e Pontos de Particularidade utilizam a tecnologia como fator de
ajuste de seus clculos.

O COCOMO a nica tcnica que faz distino em relao ao tipo de projeto. Ele
sugere valores diferenciados para cada um deles (orgnico, semidestacado e embutido)
obtendo resultados diferenciados.

Anlise de Pontos por Funo e Pontos de Particularidade so as nicas estimativas
onde a linguagem de programao no interfere nos resultados. Elas estimam a
funcionalidade do sistema, independentemente da linguagem. Entretanto o projeto fsico
interfere no clculo, pois estas tcnicas necessitam saber qual o nmero de arquivos,
entradas, sadas, consultas e interfaces para calcular a estimativa. O PSP tambm
necessita das informaes sobre o projeto fsico do sistema.
33

O tamanho do projeto interfere em todas as estimativas. Na Estimativa do Esforo, esta
interferncia indireta porque ela trabalha com o nmero de profissionais que executam
determinada funo do projeto em determinada tarefa do desenvolvimento. Ento,
quando o projeto volumoso, o nmero de profissionais deve aumentar e quando
pequeno deve reduzir. Mas o tamanho do projeto no interfere diretamente no clculo
da estimativa. Por este motivo no foi identificado na tabela comparativa que o tamanho
do projeto interfira na estimativa.

O COCOMO e a estimativa de Putnam no calculam o custo de um projeto, apenas o
esforo e o tempo necessrio para o seu desenvolvimento. Enquanto que as demais
estimativas permitem acrescentar uma taxa de mo-de-obra definida pela organizao
sobre algum aspecto do projeto. Por exemplo, a Estimativa do Esforo aplica a taxa de
mo-de-obra para cada tarefa do desenvolvimento a ser executada. J a Anlise de
Pontos por Funo permite que se aplique a taxa de mo-de-obra por pontos.

Os gerentes de projetos desejam controlar o risco do desenvolvimento de um projeto.
Ainda no se conhecem todos os riscos dos projetos, mas a estimativa COCOMO j est
implementando alguns fatores de risco no clculo do seu fator de ajuste.

Cada umas das tcnicas, aqui apresentadas, possui suas prprias caractersticas, mas
devem ser modeladas de acordo com a organizao que as aplica, pois cada organizao
trabalha de uma forma diferente.

Pode-se acrescentar nas tcnicas aqui apresentadas outros fatores ou elementos para
transformar uma tcnica de estimativa mais factvel para a organizao. Por exemplo,
uma empresa pode determinar o nmero de pontos por funo ou nmero de linhas de
cdigo que um profissional de determinado grau de escolaridade e tempo de empresa
capaz de produzir. Considerar o tempo gasto em outras atividades, como por exemplo,
ligaes telefnicas, suporte a clientes e intervalos.

O nvel de conhecimento do profissional sobre o projeto, o tempo trabalhado em
projetos similares e o custo do profissional tambm devem ser considerados, bem como
o ambiente, a linguagem de programao, a tecnologia de desenvolvimento e as
ferramentas de gerenciamento de projeto disponveis.


34
TABELA 3.7.1 - Comparao das Tcnicas Apresentadas
Estimativa do
Esforo
Putnam COCOMO Anlise de Pontos
por Funo
Pontos de
Particularidade
PSP
Base da Estimativa Nmero de
Profissionais para
cada tarefa
Tamanho do
Software,
Constante de
Tecnologia.
Tamanho do
Software, Fator de
Ajuste.
Tamanho do
Software, Fator de
Ajuste.
Tamanho do
Software, Fator de
Ajuste.
Tamanho do
Software
Tamanho do Produto ___ Linhas de Cdigo Linhas de Cdigo N
o
Entradas
N
o
Sadas
N
o
Consultas
N
o
Arquivos
N
o
Interface
N
o
Entradas
N
o
Sadas
N
o
Consultas
N
o
Arquivos
N
o
Interface
Linhas de Cdigo
A tecnologia interfere? No
4
SIM SIM SIM SIM No
4

O tipo de projeto interfere? No
4
No
4
SIM No
4
No
4
No
4

O tamanho do projeto interfere? No
4
SIM SIM SIM SIM SIM
O custo calculado sobre uma taxa de mo-de-
obra definida pela organizao?
SIM No
5
No
5
SIM SIM SIM
Possui um fator de ajuste? No
4
No
4
SIM SIM SIM No
4

Permite o Controle do Risco? No
4
No
4
SIM No
4
No
4
No
4

A linguagem de programao interfere? SIM SIM SIM No
6
No
6
No
6

Projeto Fsico interfere? No
4
No
4
No
4
SIM SIM SIM
Leva em considerao a experincia dos
profissionais?
SIM No
4
No
4
o
4
No
4
No
4

Ferramentas ___ SLIM
[PRE 95]
BYL
WICOMO
DECPland
[PRE 95]
Estimacs
[PRE 95]
SPQR/20
[PRE 95]
PSP Tool
[SIL 97]

4
No interfere diretamente no clculo.
5
Na bibliografia consultada no se encontrou caso onde se aplique uma taxa de mo-de-obra sobre o COCOMO ou sobre a Estimativa de Putnam, o que seria possvel aplic-la sobre o
tamanho do projeto, medido em nmero de Linhas de Cdigo.
6
No interfere diretamente no clculo, mas ao se definir o nmero de pontos que um profissional capaz de fazer, a linguagem de programao interfere.
35
4 Ferramentas Existentes

Quando se planeja um oramento e um cronograma para um projeto, e o mesmo no
cumprido, muitas vezes o projeto forado a ser abortado ou sacrificar sua qualidade ou
ser entregue sem retirar todos os erros [TSO 99].

Para solucionar estes problemas, muitas empresas esto desenvolvendo ferramentas de
estimativa de custo para automatizar o processo a fim de medir e acompanhar o
andamento do mesmo. Encontram-se vrias referncias reportando experincias de
empresas que utilizam tcnicas prprias de estimativa de custo e esforo de
desenvolvimentos de software, tais como [GRA 99], [KAU 99], [HAL 97] e [DRA 96].

A seguir sero apresentadas algumas ferramentas de estimativa de custo e esforo que
aplicam as tcnicas apresentadas no captulo 3. As ferramentas so as seguintes:
ESTIMACS, SLIM, SPQR/20 e ESTIMATE Professional.


4.1 ESTIMACS

ESTIMACS [SAK 98] um sistema proprietrio, projetado para dar estimativas de
custo de desenvolvimento em um estgio de concepo do projeto numa viso macro,
tendo como base a medida Pontos por Funo e os fatores pessoais da equipe de
desenvolvimento. Os Pontos por Funo so as entradas primrias da estimativa de
custo.

O software ESTIMACS usa um questionrio contendo 25 questes. Das quais 6
questes se referem ao nmero de arquivos, nmero de sadas, nmero de organizaes,
nmero de subsistemas, nmero de entradas e complexidade lgica (estas 6 questes so
as de maior peso para o software). Cada resposta representada por um valor numrico.
As respostas para as questes baseadas nos requisitos do sistema so: entradas para o
software obter uma estimativa em horas do desenvolvimento do sistema.

A ferramenta ESTIMACS contm tambm um conjunto de modelos que habilitam o
gerente a estimar:

O esforo de desenvolvimento do sistema
Definir a equipe e o custo do projeto
Definir a configurao de hardware
Verificar o risco do projeto

O modelo do esforo de desenvolvimento do sistema combina os dados sobre usurios,
desenvolvedores, geografia do projeto, nmero de funes de negcio, complexidade da
aplicao, performance e confiana.

ESTIMACS pode descrever equipes e custos usando como base de dados um ciclo de
vida para fornecer a distribuio de trabalho e informao de custo do desenvolvimento.

36
A configurao de hardware do projeto medida em tamanho, sendo que o hardware
definido pelas respostas de algumas questes que ajudam o planejador a avaliar o
volume de transaes, janelas de aplicao e outros dados.

O nvel de risco associado com o sucesso da implementao do sistema proposto
determinado basicamente em resposta ao questionrio que examina os fatores do projeto
tais como tamanho, estrutura e tecnologia.

O software ESTIMACS utiliza-se de um algortmico heurstico, baseado em milhares de
projetos, para apresentar os resultados do novo projeto a ser estimado. A utilizao
destes projetos histricos do a ferramenta ESTIMACS segurana e consistncia nos
resultados apresentados.


4.2 SLIM

SLIM [HON 97] um sistema de custo automatizado desenvolvido pela Quantitative
Software Management. Aplica o modelo de estimativa de Putnam, programao linear,
simulao esttica, avaliao do programa e a tcnica de reviso ou tcnica PERT para
derivar as estimativas de projetos de software.

O SLIM usa as curvas de Rayleigh separadas para design e cdigo; teste e validao;
manuteno e gerenciamento [JOH 98].

O sistema habilita o gerente a desempenhar as seguintes funes:

Calibrar o ambiente de desenvolvimento de software local, interpretando dados
histricos fornecidos pelo gerente.
Criar um modelo de informao do software para ser desenvolvido por extrao
de caractersticas de software bsicos, atributos pessoais e consideraes
ambientais.

Uma vez que o tamanho do software tenha sido estabilizado, o SLIM computa o desvio
de tamanho, um perfil de sensibilidade que indica os desvios do custo e esforo em
potencial e um checklist da consistncia dos dados coletados com os softwares de
tamanhos similares. Um gerente pode invocar uma anlise de programao linear que
considere de difcil desenvolvimento, custos e esforos, solicitando uma distribuio
ms-a-ms do esforo e o checklist de consistncias dos dados coletados do sistema
com os de tamanhos similares.


4.3 SPQR/20

SPQR/20 [WU 97] uma ferramenta de estimativa de custo desenvolvida pela Software
Productivity Research Inc, baseada no modelo pontos de particularidade.

Esta ferramenta faz com que o usurio complete um conjunto simples de questes de
escolhas mltiplas que indicam:
37

Objetivo, Escopo, Tipo e Classe do projeto
Tipo de aplicao, inovao
Facilidade de trabalho
Requisitos do programa e do projeto
Documentao do usurio
Tempo de resposta
Experincia da equipe
Percentual de reuso do cdigo
Linguagem de programao
Complexidade lgica do algortmico
Dados de custos relacionados ao projeto.

Alm dos dados de sada para outras ferramentas, o SPQR/20 estima tambm:

Nmero de pginas total de documentao do projeto
Potencial de defeitos total para o projeto
Eficincia de remoo de defeitos acumulados
Nmero de defeitos total no final (entrega) do projeto
Nmero de defeitos por KLOC.


4.4 ESTIMATE Professional

ESTIMATE Professional um software desenvolvido pela Software Productivity
Centre (SPC), que est sendo utilizado em mais de 1200 companhias [SPC 00]. Esta
ferramenta implementa os modelos de Putnam, COCOMO 2.0 e Simulao Monte
Carlo.

Para estimar um projeto necessrio:
Estimar o tamanho do produto definir as especificaes dos requisitos obtendo
o tamanho do produto em nmero de linhas de cdigo.
Definir as prioridades acertar a lgica da estimativa, definindo o tipo de
projeto e as restries.
Criar uma distribuio de probabilidade de cronograma neste ponto a
ferramenta utiliza a Simulao de Monte Carlo para sugerir solues.
Revisar e acertar os resultados definir o cronograma e custo do
desenvolvimento do software o mais prximo do real, baseando-se nas
definies do projeto.

O software ESTIMATE Professional permite:

Gerar uma estimativa do esforo, cronograma e custo do desenvolvimento,
Apresentar uma variedade de opes de estimativas cientificamente,
Justificar a sua estimativa em relatrios extensivos,
Estimar o tamanho do projeto seja ele pequeno, mdio ou grande,
Criar um banco de dados histrico,
Estimar o tamanho do projeto em linhas de cdigo,
Refinar a estimativa inicial conforme o projeto progride,
38
Ter um resumo da estimativa,
Exportar as informaes para outros aplicativos, tais como Microsoft Project,
Customizar qualquer driver de custo (ex: atributos do projeto quanto a
confiabilidade, tamanho da base de dados e complexidade).

O software ESTIMATE Professional retira a adivinhao das estimativas dos projetos,
ele reconhece a natureza voltil do desenvolvimento de software e leva em considerao
esta incerteza e variabilidade usando a Simulao de Monte Carlo.


4.5 Resultados

Cada uma das ferramentas de estimativa automatizadas, apresentadas neste captulo,
conduz para um dilogo com o gerente do projeto para a obteno das informaes
sobre o projeto. a partir destas informaes que ser efetuada a estimativa do custo e
esforo do desenvolvimento de software, gerando tabelas e grficos a serem analisadas
pelo gerente do projeto.

A Tabela 4.5.1 mostra que em todas as ferramentas de estimativa estudadas, os dilogos
entre o gerente do projeto e a ferramenta so efetuados atravs de questionrios. Nestes
questionrios os usurios informam o nmero de linhas de cdigo ou o nmero de
pontos por funo do projeto, informaes estas entradas manualmente. Caso o usurio
informe um valor incorreto, a estimativa tambm ser incorreta.

A ferramenta ESTIMATE Professional tem uma funo que auxilia o clculo dos
pontos por funo. O usurio deve informar o nmero de entradas, sadas, consultas,
interfaces e arquivos de acordo com o seu entendimento. Este processo de contagem dos
pontos por funo pode ser automatizado se a ferramenta de estimativa visualizar o
banco de dados do projeto e as funes a serem desenvolvidas.

Tanto a ferramenta ESTIMACS como a ferramenta ESTIMATE Professional relatam o
uso de uma base de dados histrica para ajuste das suas estimativas.

As ferramentas estudadas tm como objetivo estimar o esforo e o custo do
desenvolvimento do software, permitindo um acompanhamento do projeto. Mas
nenhuma delas permite o acompanhamento do profissional, da estimativa e o confronto
entre diversas estimativas.

Kemerer reportou que o percentual mdio de erros em pessoas-ms estimados foi de
772% no modelo SLIM, 85% no ESTIMACS. Este percentual de erro elevado faz com
que a qualidade das estimativas seja questionvel. Felizmente ocorre uma melhora
significativa a partir das experincias de equipes nas calibraes / ajustes dos modelos
[KEM 87].

Uma pesquisa elaborada em 1999 pelo International Jornal of the Computer the Internet
and Management revelou [TSO 99]:

33,3% das empresas consultadas utilizaram algumas vezes uma ferramenta de
estimativa de custo para fazer o planejamento dos seus projetos.
39
80% das respostas disseram que as empresas tm tempos e oramentos
incorretos aplicando ferramentas de estimativa de custos.
100% sentem que a insuficincia de dados histricos um fator crtico, para a
no utilizao de ferramentas de estimativa de custo.



40

TABELA 4.5.1 Comparativo entre Ferramentas
ESTIMACS SLIM SPQR/20 ESTIMATE
PROFISSIONAL
Base da Ferramenta Pontos por funo.
Fatores pessoais da equipe de
desenvolvimento.
Estimativa de Putnam.
Programao linear.
Simulao esttica.
Avaliao do programa.
Tcnica de reviso.
Pontos de Particularidade. Estimativa de Putnam.
COCOMO 2.0.
Simulao Monte Carlo.
Pontos por Funo.
Obteno das
Informaes
Questionrio com 25
questes.
Atravs do nmero de linhas
de cdigo (LOC).
Questionrio. Questionrio.
Permite o gerente Estimar o esforo e o custo.
Definir a equipe e a
configurao de hardware.
Verificar o risco do projeto.
Calibrar o ambiente de
desenvolvimento
Criar um modelo de
informao do software.
Conferir ms-a-ms o
andamento do projeto
Criar diversos cenrios de
estimativas.
Identificar o potencial de
defeitos do projeto.
Identificar a eficincia de
remoo dos defeitos.
Identificar o nmero total de
defeitos do projeto.
Identificar o nmero de
defeitos por KLOC.
Gerar uma estimativa do
esforo, cronograma e custo
do desenvolvimento de
software.
Criar um banco de dados
histrico.
Obter um resumo da
estimativa.
Exportar qualquer
informao para outros
aplicativos.
Refinar a estimativa inicial de
acordo com o progresso do
projeto.
Base de dados histrica Sim No No Sim
Fabricante Proprietrio Quantitative Software
Management
Software Productivity
Research Inc
Software Productivity Center
Utilizao 1200 companhias
41
5 Ferramenta Desenvolvida

Identificou-se a necessidade de implementar uma ferramenta para estimar custo e o
esforo de projetos de desenvolvimento de software, pois as ferramentas existentes
(apresentadas no captulo 4), no atendiam a todas as caractersticas, a seguir:

Estimativa do custo e esforo do desenvolvimento: estimar um projeto definindo
o tempo e o esforo necessrio para desenvolv-lo, de acordo com as
caractersticas do projeto e de acordo com a disponibilidade da equipe.
Acompanhamento dos projetos: possibilita a visualizao do projeto durante o
seu desenvolvimento, permitindo identificar se o projeto est antecipado ou
atrasado, e com estas informaes o gerente de projeto pode tomar aes
corretivas.
Acompanhamento dos profissionais: permitir visualizar a produo da equipe de
desenvolvimento individualmente, desta forma identificar os profissionais
subestimados e superestimados.
Acompanhamento das estimativas: permitir visualizar a estimativa, e modific-la
caso seja necessrio; cada estimativa pode ser apropriada para determinado tipo
de projeto.
Comparativo entre estimativas: permitir comparar diversas estimativas,
verificando a que melhor se aplica ao projeto a ser desenvolvido.
Armazenamento das bases histricas: permitir que o gerente de projeto tenha
conhecimento sobre problemas e solues utilizados em projetos semelhantes j
concludos.
Integrao com outros os sistemas: permitir exportar e importar os dados
gerados pela ferramenta para outras ferramentas, tais como: Excel, Word,
MsProject.

Na verdade, est se propondo uma ferramenta que estime o projeto, mas uma ferramenta
que permita o acompanhamento e o controle do desenvolvimento, verificando tambm a
produtividade da equipe, em outras palavras, que permita o planejamento e o controle,
por parte do gerente do projeto.


5.1 Ambiente

Para que uma ferramenta de estimativa de esforo e custo do desenvolvimento de
software seja utilizada dentro de uma empresa necessrio um ambiente adequado para
que a sua utilizao no se torne invivel.

A base de uma ferramenta de estimativa os seus dados, e estes sempre devem estar
atualizados. Quanto maior a integrao entre a ferramenta de estimativa com o
ambiente de desenvolvimento mais fcil se torna a sua utilizao.

Uma empresa de desenvolvimento de software possui em seu ambiente de
desenvolvimento uma ferramenta de modelagem dos dados e uma ferramenta de
desenvolvimento. Para completar este ambiente sugere-se uma ferramenta de estimativa
42
de custo e esforo, que tambm permita fazer o acompanhamento e o controle de
projetos e da equipe de desenvolvimento.


Ferramenta de
Modelagem dos
Dados
Ferramenta de
Desenvolvimento
Ferramenta de
Estimativa/
Acompanhamento/
Controle
Banco Dados
Desenvolvimento
Banco Dados
Estimativa
Banco Dados
Apontamento
de Horas

FIGURA 5.1.1 Ambiente necessrio para controle do desenvolvimento

Como a Figura 5.1.1 apresenta, o banco de dados da ferramenta de estimativa deve ser
atualizado pelas ferramentas de modelagem dos dados, tais como: Rational Rose ou
System Architect e pelas ferramentas de desenvolvimento. Ferramenta de controle dos
trabalhos, normalmente so desenvolvidas internamente pela empresa, em conjunto com
a ferramenta de desenvolvimento.

A ferramenta de modelagem deve transferir para o banco de dados das estimativas as
informaes referentes aos projetos, mdulos, funes a serem desenvolvidas, e os
bancos de dados utilizados pelo projeto, incluindo tabelas e atributos.

Enquanto que a ferramenta de desenvolvimento deve transferir as informaes
referentes aos trabalhos executados, informaes estas sobre o tempo real gasto no
desenvolvimento das funes do projeto. Quanto mais prximas s informaes de
tempo contidas no banco de dados da estimativa estiverem em relao ao tempo real
gasto, mais ajustes podem ser feitos nas estimativas, criando uma maior confiana na
ferramenta e nos seus resultados.

As informaes referentes s horas trabalhadas sobre uma funo devem ser obtidas da
forma mais automtica possvel. Pode-se dividir as horas trabalhadas sobre uma funo
de trs formas:

Horas efetivamente trabalhadas sobre a funo pode-se considerar o tempo que
o programador permaneceu com a funo em aberto. Entretanto, quando um
programador ficar com uma funo em aberto por mais de 15 minutos sem
43
efetuar nenhuma modificao, a aplicao e o contador de tempo devem ser
interrompidos automaticamente.
Horas trabalhadas para entendimento da funo devem ser informadas
manualmente, pois no possvel definir um processo que automatize a
contagem do tempo que o profissional ficou estudando uma funo do projeto.
Isto porque normalmente na fase de estudo acontecem reunies, conversas com
os usurios/analistas.
Horas trabalhadas com testes da funo pode-se definir o mesmo processo
utilizado na contagem do tempo trabalhado efetivamente sobre uma funo, mas
neste caso considerando o tempo de execuo da funo. Uma rotina de
processamento no deve ser cancelada se ultrapassar o tempo de 15 minutos.
Somente deve ser cancelada a aplicao se ultrapassar os 15 minutos e nenhum
processo sobre a funo estiver sendo executado.

O ideal para o ambiente que esta integrao seja automatizada, mas caso isto no seja
possvel, ela deve ocorrer atravs de procedimentos internos definidos pela empresa,
procedimentos estes de importao e exportao das informaes. Deve-se poder
garantir que as informaes existentes nos bancos de dados sejam reais.


5.2 Definies Tcnicas para a Ferramenta

As mtricas de estimativa de custo e esforo baseiam-se no tamanho do projeto. Este
tamanho pode ser medido atravs do nmero de linhas de cdigo, pontos por funo ou
pontos por objetos.

A Tabela 5.2.1 apresenta um comparativo entre as formas de medir o tamanho de um
projeto.

TABELA 5.2.1 - Comparativo das formas de medir o Tamanho do Projeto
Linhas de
Cdigo
Pontos por
Funo
Pontos por
Objetos
A linguagem de programao
interfere?
SIM NO NO
Exige o projeto fsico
definido?
NO SIM SIM
Independncia de Tecnologia? NO SIM SIM
Possibilita comparaes? NO
7
SIM SIM
nfase: Cdigo Funcionalidade Objetos / Eventos
Designado para: Qualquer
Aplicao
Aplicao de
Negcios
Aplicao de
Negcios
Padro de Contagem NO SIM SIM

Analisando a tabela comparativa (Tabela 5.2.1) percebe-se que Pontos por Funo e
Pontos por Objetos so semelhantes. A diferena entre eles uma questo conceitual: ao
definir funes utilizando a anlise estruturada obtm-se os pontos por funo, enquanto
que ao definir os eventos na anlise orientada a objetos tm-se os pontos por objetos.

7
Se os projetos utilizarem a mesma linguagem de programao permitida a comparao.
44

Como medida base para a ferramenta, decidiu-se utilizar a medida de pontos por funo
para determinar o tamanho do projeto, por permitir uma comparao entre projetos e ser
independente da tecnologia utilizada pela empresa desenvolvedora de software.

Tendo a medida de tamanho em pontos por funo, decidiu-se implementar as seguintes
mtricas: Anlise de Pontos por Funo definida pela IFPUG, Anlise de Pontos por
Funo com nveis de complexidade fixos e Pontos de Particularidade definidos por
Capers Jones. Entretanto, outros mtodos baseados em pontos por funo podem ser
implementados pelo prprio usurio da ferramenta. E futuramente pode-se pensar em
implementar, mtodos baseados em outras formas de medidas de tamanho.

Para que fosse possvel um confronto entre a estimativa do projeto e o projeto realmente
desenvolvido, deve-se definir uma forma de converso de pontos por funo para horas.
Pois o projeto estimado est identificado pelo nmero de pontos por funo, e o projeto
realmente desenvolvido est identificado pelo tempo, horas trabalhadas pela equipe de
desenvolvimento.

Como cada profissional possui caractersticas diferentes em relao ao conhecimento
tcnico, conhecimento do negcio, tempo de empresa e escolaridade. Optou-se em
definir a Tabela 5.2.2 onde a soma dos valores apresentados de acordo com as
caractersticas define o valor de converso por profissional (horas x pontos por funo).
Estes valores podem variar de 8 pontos por hora at 46 pontos por hora.

No existe uma definio nica de converso de pontos por funo para horas, pois isto
pode variar dependendo da linguagem de programao utilizada. A Tabela 5.2.2 foi
definida com base nos projetos, Custos do Transporte e EDI Troca eletrnica de
Informaes, j desenvolvidos da empresa Newsoft Consultoria de Informtica,
utilizando a linguagem de programao Progress Caracter.

TABELA 5.2.2 Converso de Pontos por Funo em Horas
Caractersticas Nveis
Muito
Fraco
Fraco Bom timo Excelente
Conhecimento Tcnico 3 5 7 10 15
Conhecimento do Negcio 3 5 10 15 20
0 6
meses
6 18
meses
18 36
meses
36 72
meses
Acima de
72 meses
Tempo de Empresa 1 2 3 5 1
2
o

Grau
Tcnico Superior Ps-
Graduao
Ps-
Graduao
Escolaridade 1 2 3 4 4

Por exemplo: Um profissional com dois anos de empresa, com um bom conhecimento
tcnico, com um timo conhecimento no negcio do projeto e com curso tcnico teria
como valor de converso:

Conhecimento Tcnico = 7
Conhecimento do Negcio = 15
Tempo de Empresa = 3
45
Escolaridade = 2

Valor de converso = Soma = 27

Isto significa que a cada hora trabalhada o profissional produz 27 pontos por funo.
Uma funo estimada em 215 pontos por funo, este profissional deve desenvolv-la
em torno de 8 horas, na linguagem de programao Progress Caracter.

A ferramenta desenvolvida utiliza, para armazenamento das informaes, o banco de
dados Acess 2000 da Microsoft, por se tratar de um banco de dados com um custo
acessvel e com capacidade de armazenamento. Foi utilizada a linguagem de
programao JAVA por se tratar de uma linguagem nova e que permite o
desenvolvimento de aplicativos para internet.

Na construo da interface se utilizou a ferramenta NetBeans da Sun, por ser uma
ferramenta freeware. Para a construo dos grficos utilizou-se as classes pr-definidas
pela Kavachart [KAV 00]


5.3 Estrutura da Ferramenta

Ao analisar as mtricas a serem implementadas na ferramenta juntamente com as
informaes dos projetos e as solicitaes de respostas, definiu-se o seguinte diagrama
de classes, apresentado na Figura 5.3.1.

46
Profiss ional
Frias
cd_profi ss ional
nr_seq _fr ias
Nvel de Compl exidade
cd_ es tim ativa
i d_i dentif ic ador
nr _seq_compl exidade
Histrico Mdulo
cd_projeto
cd_estimativa
nr_seq_his trico
cd_mdulo
Histrico Revis o
cd_projeto
cd_estimativa
nr_seq_his trico
nr_seq_reviso
Es timativa
cd_estimativa
0. .n 0. .n
Fator de Ajuste
cd_estimativa
nr_seq_ajuste
0..n 0..n
Banco de
Dados
cd_banco
Tab ela
cd_banco
cd_tabela
0..n 0..n
Tipo de Funo
cd_tp_funo
Funo
Tabela
cd_funo
cd_tabela
1
0..n
1
0..n
Mdulo
cd_pr ojeto
cd_mdulo
0..n
1
0..n
1
Pontos Reviso
cd_projeto
nr_seq_reviso
0..n
1
0..n
1
Histrico Projeto
cd_projeto
cd_e s tima tiva
nr _seq_his t rico
0..n 0..n
0..n 0..n
1
0. .n
1
0. .n
Profi ss ional Al ocad o
cd_p roj eto
cd_profiss ional
nr_seq_aloca o
Funo
cd_mdulo
cd_funo
0..n 0..n
1
0..n
1
0..n
0..n
1
0..n
1
Funo
Profiss ional
cd_f uno
cd_pro fi ss ional
0..n 0..n
Proje to
Profiss ional
cd_projeto
cd_profiss ional
0..n 0..n
Apo ntamento
cd_ profi ss ion al
dt _apont amento
nr_seq_apontamento
0..n
0..1
0..n
0..1
Profiss ional His trico -
RH
cd_profiss ional
nr_seq_his trico_RH
Projeto
cd _cl iente
cd_projeto
0. .n 0. .n
0..n 0..n
0..n 0..n
0. .n 0. .n
Serivo
cd_servio
0..n 1 0..n 1
Cliente Servio
cd_cliente
cd_ servio
1
0. .n
1
0. .n
Cliente
cd_cliente
0..n
1
0..n
1
0. .n
1
0. .n
1
Histrico Fator de
Ajuste
cd_projeto
cd_estimativa
nr_seq_his trico
nr_seq_ajuste
0..n 0..n
0..n
1
0..n
1
Hi stri co Fun o
cd_mdulo
cd_estimativa
nr_seq_his trico
cd_funo
0..n 0..n
0..n 1 0..n 1
Profiss ional
cd_profiss ional
1
0..n
1
0..n
0..n 0..n
1
0..n
1
0..n
1
0..n
1
0..n
0..n 0..n
1
0..n 0..n
1

FIGURA 5.3.1 Diagrama de Classes.

O projeto a ser estimado est definido pelas classes: Cliente, Projeto, Mdulo, Funo,
Pontos de Reviso, Projeto Profissional e Profissional Alocado. Todo projeto pertence a
um cliente. Um projeto pode ser subdividido em vrios mdulos e estes subdivididos
em funes. A classe Ponto de Reviso tem como objetivo definir em quais momentos o
projeto deve ser revisado, definindo o que j deve estar concludo. Quanto classe
Projeto Profissional, ela permite uma definio de quais profissionais trabalharo no
desenvolvimento do projeto e a classe Profissional Alocado determina quando o
profissional ir trabalhar sobre o projeto.

47
Tambm foi definida uma subdiviso para as funes de um projeto, esta subdiviso
classifica a funo a ser implementada, a classe referente a esta classificao a classe
Tipo de Funo (Ex: cadastro simples, cadastro mdio, cadastro complexo, listagem
simples, listagem mdia).

Neste diagrama encontra-se as classes Banco de Dados e Tabela que so referentes aos
bancos de dados utilizados pelos projetos a serem desenvolvidos. Estas informaes so
necessrias para automatizar o processo de contagem dos pontos por funo. Como por
exemplo, o projeto de Custos do Transporte utiliza-se dos bancos de dados: TRC
(Transporte Rodovirios de Cargas), MGADM (Magnus administrativo), CUSTO. Do
banco TRC utilizada as informaes referente a Tabela de Veculo, do banco
MGADM utilizada as informaes referentes a Tabela de Estabelecimento e as demais
informaes necessrias so retiradas do banco CUSTOS, especfico para este projeto.

A classe Funo Tabela serve como elo de ligao entre a funo e a tabela do banco de
dados, nesta classe se determina o tipo de ligao que est sendo feita: entrada, sada,
consulta ou interface. Esta informao interfere no clculo do nmero de pontos por
funo de um projeto, porque para calcular o nmero de pontos necessrio saber que
tipo de ligao ocorre entre a funo e a tabela.

As classes Profissional, Profissional Histrico e Profissional Frias referem-se s
informaes da equipe de desenvolvimento.

A classe Servio serve para definir que tipo de servio est sendo executado (Ex:
consultoria, programao ou anlise).

A mtrica de estimativa definida pelas classes Estimativa, Nvel de Complexidade e
Fator de Ajuste.

Ao estimar um projeto utilizando uma mtrica de estimativa, os resultados so
armazenados nas classes: Histrico Projeto, Histrico Mdulo, Histrico Funo e Fator
de Ajuste do Projeto. Da forma como foi definido, caso ocorra alguma modificao na
estrutura do projeto, ele pode ser reestimado sem perder as informaes da primeira
estimativa.

As informaes referentes aos tempos reais trabalhados esto armazenadas na classe
Apontamento. E ao finalizar uma funo a ferramenta agrupa estas informaes de
tempo por profissional e as armazena na classe Funo Profissional.

A classe Histrico Reviso armazena as revises feitas sobre uma determinada
estimativa de projeto. Esta classe serve para verificar o andamento do projeto em
relao a uma determinada estimativa do projeto. Um projeto pode ser acompanhado
por vrias estimativas, isto permite melhor um confronto entre as estimativas.






48
5.4 Casos de Uso

Analisando os objetivos da ferramenta a ser desenvolvida, definiu-se os seguintes casos
de uso: Parametrizar Sistema, Cadastrar Projeto, Apontar Horas Trabalhadas, Estimar
Projeto, Estimar Funo, Avaliar Projeto, Avaliar Estimativa e Avaliar Profissional
(Figura 5.4.1).

Estimar Funes
(from Incl uded Use Cases)
Sis tema de RH
(fro m Actors)
Parametrizar o Si stema
(fro m <Use Case Na me>)
Cadas trar Projeto
( from <Use Ca se Name> )
Estimar Projetos
(from <Use Case Name>)
Gerente de Projeto
(from Actors )
Cliente
(from Actors )
Avali ar Profi s si onal
(from Incl uded Use Cases)
Avaliar Es timativa
( fr om Inc lu ded Use Ca ses)
Aval iar Pr oj eto
(from Incl uded Use Cases)
Equipe de
Des envolvimento
(from Actors)
Apontar Horas Trabalhadas
(from <Use Case Name>)

FIGURA 5.4.1 Diagrama de Casos de Uso

49
O caso de uso Parametrizar Sistema tem, como objetivo, o cadastramento das classes de
apoio, tais como o cadastramento dos Profissionais, Estimativas, Tipos de Funes e
Servios.

Enquanto que o caso de uso Cadastrar Projetos se responsabiliza pelas informaes
referentes ao projeto, quais os seus mdulos, funes, pontos de reviso e profissionais
alocados.

O caso de uso Apontar Horas Trabalhadas tem exatamente a funo de armazenamento
das horas trabalhadas pelos profissionais sobre as funes do projeto.

O caso de uso Estimar Funo est contido no caso de uso Estimar Projeto, porque
quando se estima um projeto, na verdade, est se estimando todas as funes
pertencentes a ele.

Avaliar Projetos, Avaliar Estimativas e Avaliar Profissionais so os casos de uso
referentes ao controle do desenvolvimento. Ser a partir destas informaes que aes
corretivas devem ser tomadas.


5.5 Funcionalidades da Ferramenta

De acordo com o diagrama de classes e o diagrama de casos de uso, a ferramenta de
estimativa desenvolvida implementa as seguintes funcionalidades: Definio de
Parmetros, Cadastramento das Informaes Pessoais, Cadastramento dos Projetos,
Estimativas e Acompanhamento. No Anexo 5 encontram-se os diagramas de atividades
da ferramenta.

A Definio de Parmetros implementa os mtodos de estimativas utilizados pela
ferramenta, tais como Pontos por Funo definidos pelo IFPUG, Pontos por Funo
com nvel de complexidade fixo ou Pontos de Particularidade. E os tipos de funes
permitidas, tipos de funes uma subdiviso de acordo com as caractersticas e
complexidade da funo (ex: Cadastro Simples, Cadastro Normal, Cadastro Complexo,
Cadastro Muito Complexo). A complexidade varia de acordo com o nmero de
informaes de entrada, sada, necessrios para o desenvolvimento da funo.

Os Cadastros referem-se s informaes definidas pela empresa, informaes estas
sobre os profissionais e servios executados por eles. Caso a empresa j possua estas
informaes em um outro banco de dados, por exemplo, no banco de dados de recursos
humanos, deve ser feita a integrao das informaes.

A Definio do Projeto a ser estimado, uma parte importante no processo de
estimativa, pois a partir esta definio que ser calculado o nmero de pontos por
funo de acordo com a mtrica de estimativa selecionada. A definio de um projeto
consiste no cadastramento do cliente que solicitou o projeto, no cadastramento do
prprio projeto com seus mdulos (subdivises), funes, pontos de reviso,
profissionais alocados, banco de dados utilizados, tabelas dos bancos de dados,
relacionamento entre as funes e tabelas, e apontamento de horas.

50
As informaes que puderem vir da integrao com a ferramenta de modelagem dos
dados e da ferramenta de desenvolvimento devem ser utilizadas. mandatrio, que o
gerente do projeto sempre fique sabendo das modificaes do projeto, pois estas
modificaes podem alterar as estimativas.

Hoje, a ferramenta permite fazer, uma estimativa por projeto, ou mdulo do projeto ou
uma simulao de uma funo especifica. permitido estimar um projeto atravs de
vrias estimativas. Ao modificar o projeto no decorrer do desenvolvimento necessrio
reestim-lo.

Em relao ao acompanhamento, a ferramenta tem trs objetivos:

Acompanhamento do projeto verificar como est o andamento do projeto, se
est sendo cumprido o prazo e o custo de acordo com o que foi definido (pontos
de reviso).
Acompanhamento do profissional verificar a produtividade da equipe de
desenvolvimento individualmente.
Acompanhamento da estimativa verificar a utilizao do modelo de
estimativas, comparando o previsto com o real e fazendo o confronto de vrias
estimativas sobre um mesmo projeto.

Os acompanhamentos devem ser visualizados pelos gerentes de projetos de forma
grfica, para facilitar a tomada de decises. Eles podem ser dirios, semanais, quizenais,
mensais, bimestrais, isto varia de acordo com a necessidade do projeto e da empresa
desenvolvedora.

A partir das informaes de acompanhamento o gerente do projeto deve conseguir
concluir, se o projeto est no prazo, se o problema com a equipe de desenvolvimento
ou com a estimativa, ou se o projeto deve ser reestimado. Aes corretivas devem ser
tomadas a partir destas informaes, o gerente do projeto tambm deve considerar a sua
experincia nas decises.


5.5.1 Parametrizao

Nos Parmetros encontram-se os programas para Parametrizao das Estimativas, e o
Cadastro de Tipos de Funes.

A Parametrizao das Estimativas tem como objetivo o cadastramento das frmulas de
clculo das estimativas. As estimativas so baseadas em valores, nveis de
complexidade e fatores de ajustes. Estas informaes podem e devem ser modificadas,
de acordo com a necessidade de cada empresa. Ao cadastrar os fatores de ajuste de uma
estimativa, o usurio deve informar o valor mnimo e mximo para o respectivo fator.
Quando forem definidos os valores dos fatores de ajuste de um projeto, somente sero
vlidos os valores que estiverem neste intervalo. Pode-se estimar um projeto sobre
vrias tcnicas de estimativas diferentes, permitindo desta forma um confronto entre as
estimativas, verificando a que melhor se adapta ao projeto.

51
O cadastro de Tipos de Funes tem como objetivo criar uma subdiviso das possveis
funes do projeto. (Ex: Cadastros Simples, Cadastros Mdios, Cadastros Complexos,
Listagens, Atualizaes, Relatrios, etc) A partir desta subdiviso, pode-se verificar
melhor o desenvolvimento do sistema, pois a ferramenta de estimativa desenvolvida
permite a visualizao das informaes de acordo com esta subdiviso, isto significa
que o gerente de projeto pode verificar que tipo de funo est causando erros na
estimativa do projeto. Neste programa de cadastramento de Tipos de Funes tambm
so informados os valores padres a serem acrescidos, como entrada, sada, consulta,
interface e algoritmo. Estes devem ser definidos pela empresa desenvolvedora,
analisando os padres de programao (ex: o nmero de mensagens de erro que deve ser
considerado como sada). Estas informaes sero repassadas para o cadastro de
funes do projeto.


5.5.2 Cadastramento das Informaes Pessoais

Nos Cadastros das Informaes Pessoais encontram-se os programas para
cadastramento dos Profissionais e dos Servios executados pela empresa
desenvolvedora do software.

O cadastro de Profissionais tem como objetivo o cadastramento das pessoas envolvidas
no processo de desenvolvimento do software. Neste cadastro so informados os
perodos de frias do profissional como as mudanas salariais, portanto est relacionado
diretamente ao custo do projeto. Tambm identificado o valor do ponto por funo
padro do profissional, isto , significa quantos pontos o profissional capaz de
desenvolver em 1 hora de trabalho. Esta informao ser sugerida posteriormente na
alocao do profissional ao projeto.

O cadastramento dos Servios executados pela empresa tem como objetivo definir quais
os tipos de servios que a empresa desenvolvedora oferece para os seus clientes (Ex:
consultoria, programao, anlise, etc). Neste cadastro encontram-se os valores padres
cobrados pela empresa pela execuo do servio, valor do salrio padro do profissional
que o executa, como tambm o valor do ponto por funo. Caso o profissional no
possua valor do ponto por funo o valor informado no servio, ser utilizado como
sugesto na alocao do profissional ao projeto.


5.2.3 Cadastramento dos Projetos

No Cadastramento dos Projetos encontram-se os programas para cadastramento de
Clientes, Projetos, Funes do Projeto, Banco de Dados, Tabelas dos Bancos de Dados,
Relacionamento entre as Funes e as Tabelas como tambm o cadastramento dos
Apontamentos de Horas (horas trabalhadas realmente no projeto).

O cadastro de Clientes tem como objetivo o cadastramento das empresas que
solicitaram os projetos a serem desenvolvidos e estimados. O cliente pode negociar um
valor de servio diferenciado, desta forma necessrio que se faa o cadastramento
52
destes valores, para que a obteno do custo do projeto estimado seja prximo do custo
real.

No cadastro de Projetos encontram-se as informaes sobre o projeto a ser desenvolvido
e estimado. Ao cadastrar um projeto tambm necessrio que se faa o cadastramento
dos mdulos. Eles podem ser entendidos como sendo uma subdiviso do projeto.
Tambm deve ser determinada a alocao dos profissionais que trabalharo no projeto,
juntamente com as suas caractersticas. Desta forma ser possvel identificar o custo do
projeto mais precisamente. Neste cadastro tambm possvel definir quais sero os
pontos de reviso do projeto, para relacionar o estimado com o produzido.

J, o cadastro de Funes de um Projeto tem como objetivo o cadastramento das
funcionalidades que o projeto ir ter. Uma funo pode ser comparada com um
programa ou evento. Ao informar qual o tipo de funo com a qual est relacionada, de
acordo com a finalidade da funo e da sua complexidade, a ferramenta herda as
informaes armazenadas no cadastramento do Tipo de Funo. Informaes estas
referentes ao nmero de interfaces, nmero de algoritmos, nmero de entradas, nmero
de sadas e de consultas a serem acrescentadas no clculo da estimativa. Uma funo
pode ser cancelada, isto significa ser ignorada nos clculos das estimativas ou finalizada
significando que a funo j foi desenvolvida totalmente e possvel fazer uma
comparao entre o custo previsto e o real.

O cadastro de Banco de Dados tem como objetivo o cadastramento dos bancos de dados
que sero utilizados pelos projetos a serem estimados.

O cadastro das Tabelas dos Bancos de Dados tem como objetivo o cadastramento das
classes implementadas no banco de dados, que sero utilizadas pelas funes do projeto
a ser desenvolvido. Ao cadastrar as tabelas o usurio tambm deve informar quais so
seus atributos. Estas informaes sero utilizadas posteriormente nos clculos das
estimativas.

O cadastro de Relacionamentos entre as Funes e as Tabelas prioritrio para a
estimativa. Pois a partir deste relacionamento, que se consegue obter as informaes
referentes ao nmero de entradas, nmero de sadas, nmero de consultas, nmero de
interfaces e nmero de arquivos com que a funo se relaciona. Ao relacionar uma
funo a uma tabela, o usurio deve informar que tipo de relacionamento existe entre
eles (entrada, sada, consulta ou interface). Uma tabela pode estar relacionada por vrios
tipos, a partir desta informao que se consegue definir o nmero de entradas, sadas,
consultas, interfaces e arquivos relacionados.

J o Apontamento de Horas tem como objetivo armazenar as informaes reais do
projeto quanto ao profissional que trabalhou e o tempo trabalhado. Com estas
informaes ser possvel fazer um relacionamento entre o custo previsto e o real.






53
5.5.4 Estimativas

Nas Estimativas encontram-se os programas para estimar um projeto, um mdulo do
projeto, e o programa para estimar uma funo especfica do projeto (simulao).

Estimar um projeto significa estimar o seu tamanho considerando todos os seus
mdulos e conseqentemente as suas funes. Estimar significa definir o nmero de
pontos por funo de um projeto / mdulo / funo. Ao estimar um projeto, o usurio
deve definir os fatores de ajustes do projeto, fatores estes que interferem no clculo da
estimativa. Toda estimativa armazenada em um banco de dados histrico para poder
ser utilizada posteriormente. Ser a partir das informaes calculadas, que o gerente do
projeto poder verificar o andamento e definir novos cronogramas.

Estimar um mdulo de um projeto significa estimar todas as funes que o compem.
Na verdade a ferramenta no estima um projeto ou um mdulo, mas sim uma funo, a
menor parte de um projeto. A soma das estimativas das funes que compem um
mdulo, a estimativa do mdulo. Conseqentemente a soma das estimativas dos
mdulos resulta na estimativa do projeto.

Estimar uma funo significa identificar o nmero de entradas, sadas, consultas,
interfaces, arquivos e algoritmos relacionados a ela. Cada valor encontrado (nmero de
entradas, nmero de sadas, nmero de consultas, nmero de intefaces, nmero de
arquivos e nmero de algoritmos) multiplicado por um fator de complexidade definido
pela estimativa. A soma dos valores multiplicados resulta no nmero de pontos por
funo brutos de uma funo. Para se conseguir o nmero de pontos por funo lquido
da funo, necessrio aplicar um fator de ajuste determinado por um questionrio
sobre o ambiente e sobre as caractersticas do projeto, previamente definido pelo
usurio.

O gerente de projeto deve conseguir visualizar os resultados destas estimativas de forma
numrica ou grfica. A Figura 5.5.4.1 apresenta um exemplo da consulta numrica dos
pontos por funo do mdulo 1 - Cadastros do projeto Custos do Transporte. Pode-se
observar que nesta figura so apresentados os nmeros de pontos por funo estimados
para cada uma das funes que compem o mdulo 1 Cadastros. Na figura so
apresentados tambm os nmeros de pontos por funo j concludos. Isto ocorre
porque o projeto j foi desenvolvido e finalizado. O boto grfico permite que o
gerente de projeto visualize as mesmas informaes, mas de forma grfica atravs de
um grfico de barras.


54

FIGURA 5.5.4.1 Tela de Consulta da Estimativa de um Mdulo.

O gerente de projeto tambm deve conseguir visualizar os valores utilizados nos
clculos da estimativa de uma funo, pois desta forma o gerente consegue identificar se
o clculo da estimativa est correto. A Figura 5.5.4.2 apresenta um exemplo do clculo
da funo SCS Simulao do Custo do projeto Custos do Transporte. Pode-se
observar que nesta figura so apresentados os nmeros de pontos de entrada, sada,
consulta, interface, arquivos e algoritmos, como tambm os fatores de complexidades
utilizados como multiplicadores. Ao final so apresentados os nmeros de pontos por
funo brutos, qual o fator de ajuste utilizado e o nmero de pontos por funo lquidos.
55


FIGURA 5.5.4.2 Tela de Consulta da Estimativa de um Funo


5.5.5 Acompanhamento

No Acompanhamento encontram-se os programas para efetuar as revises do projeto,
visualizar a alocao dos profissionais no projeto, a produtividade do profissional, o
mtodo de estimativa e fazer um comparativo entre as estimativas com o real.

O gerente pode efetuar o acompanhamento do projeto atravs de pontos de reviso,
milestones, previamente definidos no cadastro de projetos. Ao efetuar uma reviso a
ferramenta calcula todos pontos que at aquele momento foram desenvolvidos, e os
armazena na classe Histrico Reviso. A partir das informaes dos milestones e dos
pontos desenvolvidos, pode ser gerado o grfico apresentado na Figura 5.5.5.1.

Analisando o grfico apresentado (Figura 5.5.5.1), o gerente do projeto pode visualizar
o andamento do projeto. Se ele est atrasado ou adiantado em relao ao que foi
programado, caso seja necessrio aes corretivas devem ser tomadas. O cliente sempre
deve ser informado sobre o andamento do projeto.

A Figura 5.5.5.1 apresenta um exemplo do grfico de andamento do projeto Custos do
Transporte, sobre a mtrica de estimativa de Pontos de Particularidade. A linha
tracejada apresenta o projeto estimado e a linha contnua apresenta os dados reais do
projeto.
56

FIGURA 5.5.5.1 Tela de Pontos de Reviso do Projeto

O programa de acompanhamento da alocao dos profissionais no projeto,
demonstrado atravs de um grfico de Gantt (Figura 5.5.5.2). Este grfico pode auxiliar
o gerente de projeto na criao dos milestones, da seguinte maneira: ao definir as
datas de reviso, o gerente de projeto pode emitir o grfico de Gantt visualizando a
alocao dos profissionais em determinado projeto e desta forma ter uma idia melhor
de quanto do projeto j deve estar concludo. Caso o projeto se prolongue, novas
alocaes podem surgir, como novos pontos de reviso ou milestones.


FIGURA 5.5.5.2 Tela de Alocao dos Profissionais no Projeto

57
O grfico de Gantt formado por barras horizontais que representam o perodo de
tempo trabalhado ou previsto. Na Figura 5.5.5.2 apresenta a alocao prevista dos
profissionais, SSI, MIH e ECP no projeto Custos do Transporte. O profissional SSI foi
alocado em dois perodos diferentes de tempo, 24/09/1998 at 24/12/1998 e 10/02/1999
at 01/04/1999, cada alocao indicada por uma barra, no grfico. A profissional MIH
tambm foi alocada em dois perodos e a profissional ECP em apenas um perodo. O
nome do profissional apresentado no eixo y do grfico, e no eixo x so apresentadas as
datas de alocao dos profissionais.

A produtividade do profissional pode ser observada num confronto das informaes
sobre os dados estimados e das informaes reais (Figura 5.5.5.3). A produtividade
estimada de um profissional pode estar incorreta por dois motivos: a ferramenta est
subestimando o profissional ou, realmente, ele no est produzindo o esperado. O
gerente do projeto deve sempre levar em considerao a sua experincia, caso o
problema esteja na ferramenta, o gerente deve reavaliar os parmetros do profissional
(nmero de pontos).


FIGURA 5.5.5.3 Tela de Acompanhamento do Profissional

A Figura 5.5.5.3 apresenta um exemplo do grfico de acompanhamento do profissional
SSI, para o projeto Custos do Transporte, este grfico apresentado sobre os tipos de
funes desenvolvidos pelo profissional (CAD1 = Cadastros Simples, CAD2 =
Cadastros Mdios, CAD3 = Cadastros Complexos, CAD4 = Cadastros Muito
Complexos, REL1 = Relatrios Simples, REL2 = Relatrios Mdios). Pode-se observar
no grfico, que ocorreu uma diferena significativa na funo CAD4 - Cadastros Muito
Complexos, isto porque a mtrica de estimativa utilizada subestimou as funes deste
tipo (CAD4 Cadastros Muito Complexos).
58

O programa que acompanha a estimativa, um programa que confronta as informaes
estimadas com as informaes reais do projeto (Figura 5.5.5.4). O gerente pode
selecionar visualizar os dados do projeto pelos mdulos ou pelos tipos de funes, de
acordo com a sua necessidade.

A Figura 5.5.5.4 apresenta o acompanhamento da estimativa de Pontos de
Particularidade para o projeto Custos do Transporte. Neste exemplo esto sendo
demonstradas as informaes de acordo com os tipos de funes existentes no projeto
(CAD1 = Cadastros Simples, CAD2 = Mdios, CAD3 = Complexos, CAD4 = Muito
Complexos, LIS1 = Listagem Simples, LIS2 = Mdia, LIS3 = Complexa, REL1 =
Relatrios Simples e REL2 = Mdios). Novamente pode ser observado que a mtrica de
estimativa subestimou as funes do tipo CAD4 Cadastros Muito Complexos.


FIGURA 5.5.5.4 Tela de Acompanhamento da Estimativa

O comparativo entre estimativas sobre um mesmo projeto tem como objetivo,
identificar o melhor mtodo de estimativa para este tipo de projeto. A melhor forma de
visualizar este comparativo atravs de um grfico de linhas, se o projeto j estiver
concludo interessante que as informaes reais do projeto tambm sejam avaliadas.

59

FIGURA 5.5.5.5 Tela de Comparao entre Estimativas

A Figura 5.5.5.5 apresenta um exemplo do comparativo entre as mtricas PF-PP (Pontos
de Particularidade), PF-IFPUG (Pontos por Funo definidos pelo IFPUG) e PF-FIXO
(Pontos por Funo com Nvel de complexidade Fixo) para o projeto Custos do
Transporte. No eixo X esto descritos os mdulos que compem o projeto (1
Cadastros, 2 Atualizao, 3 Operao, 4 Simulao, 5 Relatrios das Operaes,
6 Listagem das Atualizaes, 7 Listagem dos Cadastros). E no eixo y so
identificados os nmeros de pontos por funo calculados para cada mdulo do projeto.


5.6 Busca de Informaes numa Base Histrica

As ferramentas de estimativa devem manter uma base de dados histrica dos projetos
estimados para que posteriormente as estimativas possam ser utilizadas / visualizadas,
auxiliando o gerente de projeto na escolha do melhor mtodo de estimativa.

Para a busca de uma estimativa de um projeto numa base de dados histrica, pode-se
utilizar o conceito de Raciocnio Baseado em Casos - RBC.

Raciocnio Baseado em Casos uma tcnica que se prova ter sucesso em uma grande
variedade de reas de aplicao [KRA 97]. Um sistema de RBC resolve novos
problemas adaptando solues que foram utilizadas para resolver problemas anteriores
[KOL93].

60
Num primeiro estgio deve-se permitir que o gerente visualize as estimativas de
projetos semelhantes, representados como casos e armazenados em um repositrio.
Futuramente, pode-se implementar procedimentos que, a partir de projetos j estimados,
se solucione estimativas de projetos novos utilizando raciocnio baseado em casos
propriamente dito.

Um sistema de RBC funciona comparando a descrio de um problema a ser resolvido
com os casos descritos em uma base de casos. O sistema recupera ento o caso mais
parecido segundo critrios de similaridade previamente definidos e apresenta a
estimativa associada ao usurio. Pela descrio do caso recuperado e soluo associada,
o usurio decide como fazer a adaptao da soluo ao novo problema. Esse
procedimento pode ser representado atravs de um ciclo (Figura 5.6.1, modificada a
partir de [ABE 96]).

DOMNIO
AQUISIO/INDEXAO
BASE DE CASOS
SOLUO
ADAPTAO PELO
GERENTE (MANUALMENTE)
MELHOR
CASO
AVALIAO
RECUPERAO
NOVO PROBLEMA

FIGURA 5.6.1 Ciclo do RBC

A base de casos construda utilizando-se casos significativos, ou seja, que apresentem
descries e solues distintas, e descritos apenas pelos atributos relevantes na definio
da estimativa de cada projeto. Normalmente a base de casos resulta da replicao de
uma base de dados histrica, cujos erros, informaes no relevantes e casos duplicados
so eliminados.

O modelo de casos descreve os parmetros de comparao entre os casos de uso. O
modelo de casos da ferramenta de estimativa de custo e esforo de desenvolvimento
utiliza uma representao estruturada, conforme a Figura 5.6.2.

61
Classe: Estimativa
Classe: Funo
Classe: RH
Classe: Servio
Descrio do Problema

FIGURA 5.6.2 Representao Estruturada - RBC

O modelo de casos est descrito na Figura 5.6.3, na qual encontram-se as classes:

Classe Estimativa: a super classe do caso, est relacionada com as demais classes e
nela tambm armazenada a soluo do problema. Como no est se propondo uma
adaptao automatizada ao caso mais semelhante soluo tambm deve fazer parte do
problema.
Classe Funo: utilizada para identificar o nmero de funes para cada tipo de funo
predeterminada pelo sistema
Classe Servio: utilizada para identificar o nmero de profissionais de acordo com o
servio por ele executado.
Classe RH: utilizada para identificar o perfil dos profissionais

Classe: Estimativa
Nome do projeto: string
Lista Funes: instncia Classe Funo
Lista Servios: instncia Classe Servio
Lista RH: instncia Classe RH
Tempo do Projeto: inteiro [meses]
Custo do Projeto: decimal [reais]
Esforo: inteiro [pessoas/ms]
Classe Funo
Tipo de Funo: one-of [cad1, cad2, cad3, cad4, atu1, atu2, atu3, lis1, lis2, lis3, rel1, rel2, rel3]
Nmero de funes: inteiro
Classe Servios
Tipo de Servio: one-of [anajr, anapl, anasn, prgjr, prgpl,prgsn]
Nmero de profissionais: inteiro
Classe RH
Identificador: inteiro
Tempo de Empresa: one-of[0-6meses, 6-18meses, 18-36meses, 36-72meses, acima72meses ]
Conhecimento Tcnico: one-of[muito fraco, fraco, bom, timo, excelente]
Conhecimento do Negcio: one-of[muito fraco, fraco, bom, timo, excelente]
Escolaridade: one-of[2
o
grau, tcnico, superior, ps-graduado]
Soluo do problema

FIGURA 5.6.3 Modelo de Caso da Ferramenta de Estimativa

Para recuperao do melhor caso, ou o caso mais semelhante, utiliza-se o mtodo de
comparao Algoritmo de vizinhana, que mede a diferena de valores de cada um
62
dos atributos definidos no modelo de casos com os existentes na base de dados histrica
(ou base de casos).

Para os tipos numricos (inteiros), utiliza-se o seguinte algoritmo de similaridade,
considerando uma distribuio uniforme para os valores dos atributos.

Similaridade(A1P, A1C) = 1 - | A1C A1P|
(val max val min)
Onde:
A1P = Atributo 1 do Projeto a ser estimado.
A1C = Atributo 1 do Caso constante na base de casos.
Val max = valor mximo que o atributo pode ter.
Val min = valor mnimo que o atributo pode ter.

E para os tipos simblicos utiliza-se o seguinte algoritmo.

Se atributos possuem valores diferentes, similaridade = 0, se atributos com valores
iguais, similaridade = 1.

O caso que obtiver a maior soma das similaridades escolhido como o melhor caso, e
este deve ser apresentado para o gerente, para que ele possa analisar. O gerente pode ou
no aceit-lo como sendo um caso semelhante.

A Figura 5.6.4 apresenta uma descrio de um caso que deve ser preenchida pelo
gerente de projeto para a busca de um caso semelhante.


Modelo de Casos Ferramenta de Estimativa
Nome do Cliente:___________________________
Nome do Projeto: __________________________
Tempo do Projeto: _________________
Custo do Projeto: __________________
Esforo do Projeto: ________________
Tipo da Funo No. Funes
________________________
________________________
________________________
Servio No.Profissionais
________________________
________________________
________________________
No.Profissional Tempo/Empresa Conhec/Tcnico Conhec/rea Escolaridade
________________________________________________________________
________________________________________________________________
________________________________________________________________

FIGURA 5.6.4 Descrio de um de Caso para Ferrramenta de Estimativa

63
Um ponto muito importante em um sistema de RBC, que no pode ser esquecido, em
relao confiana nos casos existentes na base de dados. Devem ser instncias de
casos reais, de modo a que a base de casos seja representativa da soluo do problema.

64
6 Estudos de Casos Submetidos


Aps a ferramenta de estimativa de custo e esforo do desenvolvimento de software ter
sido concluda, foram escolhidos dois projetos, desenvolvidos pela empresa Newsoft
Consultoria de Informtica Ltda, para mostrar a utilidade da ferramenta desenvolvida,
apresentando os resultados obtidos.

A empresa Newsoft desenvolve um sistema chamado de TRC (Transporte Rodovirio
de Cargas) para empresas transportadoras de mercadorias. A linguagem de
desenvolvimento a linguagem de programao Progress Caracter, em ambiente Unix.

Os projetos analisados foram Custos do Transporte e EDI Troca de Informaes de
forma Eletrnica, ambos os projetos sero incorporados ao sistema TRC.


6.1 Custos do Transporte

O projeto Custos para o Transporte tem como objetivo identificar todos os custos
envolvidos diretamente e indiretamente na transferncia de mercadorias. Este sistema
deve ser integrado com o sistema geral TRC. A partir do custo, o sistema deve ser capaz
de apresentar o valor ideal de preo a ser cobrado do cliente partindo de um percentual
de lucro sobre os custos.

Este projeto foi desenvolvido em parceria com a Transportadora Condor de So Bento
do Sul, utilizando o banco de dados Progress para armazenamento dos dados, e foi
desenvolvido na linguagem de programao Progress Caracter.

O sistema de Custo do Transporte divide-se basicamente em trs partes principais:
Cadastros Veculos, Marca, Modelo, Combustvel.
Atualizao de Valores Despesas administrativas, valores do combustvel,
licenciamento.
Simulaes Preo, Custo, Viagem e Previso de Viagem

Sendo que a terceira parte Simulaes a mais complexa, exigindo bastante
conhecimento sobre a rea.


6.1.1 Definies do Custo do Transporte

Para o projeto Custo do Transporte, primeiramente foi alocado um analista MIH, um
programador SSI e um estagirio ECP.

O analista MIH possua as seguintes caractersticas:
36 a 72 meses de trabalho na empresa
timo conhecimento na tecnologia
Bom conhecimento sobre o negcio
65
Com curso superior completo

O programador SSI possua as seguintes caractersticas:
18 a 36 meses de trabalho na empresa
timo conhecimento sobre a tecnologia
Bom conhecimento sobre o negcio
Com curso tcnico completo

O estagirio ECP possua as seguintes caractersticas:
6 a 18 meses de trabalho na empresa
Pouco conhecimento sobre a tecnologia
Pouco conhecimento sobre o negcio
Com curso superior completo

A partir destas caractersticas definiu-se que o analista MIH desenvolveria 25 pontos
por hora trabalhada o programador SSI 23 pontos por hora trabalhada e o estagirio
ECP 12 pontos por hora trabalhada, conforme a tabela apresentada no Captulo 5.2.

O projeto Custos do Transporte foi dividido nos seguintes mdulos e funes:
Cadastros: Parmetros do Mdulo, Marca, Modelo, Veculo, Combustvel, Tipo
de Lubrificante, Lubrificantes, Medida dos Pneus, Funes de Transporte,
Licenciamento e Tipo de Operao.
Atualizaes: Despesas Administrativas, Ficha Tcnica, Salrios dos
Funcionrios, Valor do Combustvel, Valor do Lubrificante, Valor do
Licenciamento, Valor da Lavaes e Valor dos Pneus.
Operaes: Operaes com e sem Veculo
Simulaes: Simulao do preo, do custo, da viagem e da viagem prevista.
Relatrios das Operaes: Relatrio das operaes com e sem veculo.
Listagem das Atualizaes: Listagem das informaes referentes aos valores
cadastrados na rotina Atualizaes.
Listagem dos Cadastros: Listagem das informaes cadastrais da rotina
Cadastros.

As funes de simulao do custo, do preo, da viagem e da viagem previstas foram
consideradas programas com alta complexidade, porque internamente apresentam
frmulas matemticas complexas e informaes de diversas tabelas.

No desenvolvimento deste projeto, houve preocupao com relao ao desempenho do
projeto, reutilizao do cdigo, facilidade a mudanas no sistema e facilidades
operacionais. O usurio do sistema deve ser uma pessoa com conhecimento sobre a rea
de Custos e com conhecimento sobre a tecnologia (frmulas de clculo) para conseguir
analisar corretamente as informaes produzidas pelo sistema, e efetuar simulaes
teis para a transportadora.





66
6.1.2 Resultados

Este projeto implementa funes com alto nvel de complexidade, principalmente
aquelas que se referem s simulaes (mdulo 4 do projeto de Custos do Transporte).

A ferramenta de estimativa desenvolvida permite uma comparao das estimativas
Pontos de Particularidade (PF-PP), Pontos por Funo definidos pelo IFPUG (PF-
IFPUG), Pontos por Funo com nvel de complexidade Fixo (PF-Fixo) com o tempo
real gasto no desenvolvimento do projeto. A Tabela 6.1.2.1 foi montada com base nas
informaes apresentadas pela ferramenta para o projeto de Custos do Transporte.

Ao analisar estas informaes, concluindo que todas as mtricas (PF-PP,PF-IFPUG e
PF-Fixo) subestimaram o projeto. A mtrica PF-PP apresentou um percentual de erro
em torno de 40%, enquanto que a mtrica PF-IFPUG apresentou 44% de erro e a
mtrica PF-Fixo 30% de erro.

TABELA 6.1.2.1 Tabela Comparativa das Estimativas Custo do Transporte
Mdulo PF - PP PF - IFPUG PF - Fixo Real
Pontos % erro Pontos % erro Pontos % erro Pontos
1 - Cadastros 1.440,56 1.001,62 1.584,78 448,50
2 - Atualizaes 1.440,82 1.111,42 17,64 1.623,82 1.349,50
3 - Operaes 627,08 675,88 719,80 560,00
4 - Simulaes 4.362,72 61,75 4.860,48 57,38 5.292,36 53,59 11.404,50
5 - Relatrio das Operaes 248,88 63,40 161,04 76,32 287,92 57,66 680,00
6 - Listagem das Atualizaes 536,80 2,75 351,36 36,35 624,64 552,00
7 - Listagem dos Cadastros 491,65 319,64 14,65 583,16 374,50
Total 9.148,51 40,47 8.481,44 44,81 10.716,48 30,27 15.369,00

(221,20) (123,33) (253,35)
(6,77) (20,33)
(11,98) (20,69) (28,54)
(13,16)
(31,28) (55,72)
Se o mdulo 4 Simulaes (mdulo responsvel pelo maior desvio das estimativas)
fosse desconsiderado, os percentuais de erro das estimativas seriam os seguintes: para a
mtrica PF-PP 19% de erro e a mtrica PF-Fixo 36% de erro, ambas super estimaram o
projeto. Enquanto que a mtrica PF-IFPUG apresentou 8,66% mas subestimou o
projeto.

A mtrica PF-Fixo aplica um fator de complexidade igual a trs para os algoritmos, e
um fator de complexidade dez para arquivos e interfaces. Se o fator de complexidade
aplicado aos algoritmos fosse modificado para dez, igual ao fator de complexidade dos
arquivos e interfaces, a mtrica de estimativa apresentaria um percentual de erro igual a
25%.

Para aperfeioar a ferramenta de estimativa, deve-se analisar os valores apresentados na
Tabela 6.1.2.1 de acordo com o tipo da funo a ser desenvolvido, pois existem grandes
variaes de percentual de erro, como pode ser observado no mdulo de 1- Cadastros
220% de erro na estimativa de Pontos de Particularidade. 120% de erro na estimativa de
Ponto por Funo do IFPUG e 250% na estimativa de Pontos por Funo Fixo.

A ferramenta de estimativa de custo e esforo permite tambm com que o gerente do
projeto, visualize as informaes contidas na Tabela 6.1.2.1 de forma grfica, como
apresentado na Figura 6.1.2.2. Graficamente possvel perceber o grande desvio
causado pelo mdulo 4 Simulaes.

67


FIGURA 6.1.2.2 Comparativo entre Estimativas no projeto Custos do Transporte

Outra forma do gerente de projeto visualizar a estimativa do projeto a partir de um
grfico de barras, que compara somente as informaes de uma mtrica selecionada
com as informaes reais do projeto. A Figura 6.1.2.3 apresenta o grfico de barras da
estimativa PF-Fixo no projeto de Custos do Transporte. Da mesma forma pode-se
visualizar o grande desvio da estimativa em relao ao mdulo 4 Simulaes.

68

FIGURA 6.1.2.3 Comparativo da Mtrica PF-Fixo modificada para o Projeto de
Custos do transporte.

Analisando a produtividade dos profissionais envolvidos (MIH, SSI e ECP) verificou-se
que o profissional SSI, produz normalmente o que foi estimado, ocorrendo desvios nas
funes com alto nvel de complexidade. O profissional MIH foi subestimado para as
funes de cadastros mdios, mas tambm apresentou um desvio quanto as funes de
alto nvel de complexidade. Enquanto que o profissional ECP foi subestimado em
relao s funes de nvel simples e mdio de complexidade. Conforme apresentado
nos grficos da Figura 6.1.2.4.


Profissional MIH Profissional SSI


69
Profissional ECP

FIGURA 6.1.2.4 Acompanhamento dos Profissionais no projeto Custos do Transporte

A princpio, o projeto foi estimado para ser desenvolvido em seis meses, com a alocao
dos profissionais MIH, SSI e ECP, conforme a Figura 6.1.2.5. As barras consideram o
tempo que o profissional foi alocado para o projeto.


FIGURA 6.1.2.5 Alocao dos Profissionais no Projeto Custos do Transporte

Os pontos de reviso ou milestones foram definidos mensalmente, por se tratar de um
projeto com um cronograma de seis meses de desenvolvimento A Figura 6.1.2.6
apresenta o andamento do projeto, utilizando a mtrica de estimativa PF-Fixo. A linha
tracejada significa o estimado, e a linha corrente significa as informaes reais do
desenvolvimento do projeto. Pode-se observar que do perodo 01/11/1998 at
01/12/1998 no foi produzido o que foi estimado, mas os atrasos no projeto realmente
ocorreram porque no perodo de 01/01/1999 at 01/03/1999 no ocorreu o desempenho
esperado, o que causou um atraso no projeto em torno de um ms.

70


FIGURA 6.1.2.6 Acompanhamento do Projeto Custos do Transporte


6.2 EDI Troca de Informaes de forma Eletrnica

O projeto EDI Troca de Informaes de forma Eletrnica tem como objetivo permitir
a troca de informaes entre as empresas transportadoras e seus clientes, seguindo um
padro predefinido.

Esta troca de informaes serve para agilizar o processo de transporte de mercadorias
como tambm serve para o gerenciamento das informaes.

Este projeto tambm foi desenvolvido utilizando a linguagem de programao Progress
Caracter, acessando um banco de dados Progress.

O projeto EDI se dividia em trs partes principais:
Cadastramento dos layouts (como os arquivos de comunicao esto definidos,
esta definio pode ser obtida atravs de um padro de comunicao, exemplo
Proceda ou ser uma definio proprietria do cliente )
Importao dos arquivos
Exportao dos arquivos

As funes deste projeto foram trabalhosas, por serem genricas, tentando atender a
diversos tipos de layouts diferentes.




71
6.2.1 Definies do EDI

Para o projeto EDI Troca de informaes de forma eletrnica, foram alocados um
analista LA, e um estagirio ECP.

O analista LA possua as seguintes caractersticas:
18 a 36 meses de trabalho na empresa
timo conhecimento na tecnologia
Bom conhecimento sobre o negcio
Com curso superior completo

O estagirio ECP possua as seguintes caractersticas:
6 a 18 meses de trabalho na empresa
Pouco conhecimento sobre a tecnologia
Pouco conhecimento sobre o negcio
Com curso superior completo

A partir destas caractersticas definiu-se que o analista desenvolveria 23 pontos por hora
trabalhada e o estagirio 12 pontos por hora trabalhada, conforme a tabela apresentada
no captulo 5.2.

O projeto Custos do Transporte foi dividido nos seguintes mdulos:
Cadastros: Cadastro de clientes, Eventos de Entregas, Status de Entrega, Eventos
do TRC, Layout e Caminho de Busca.
Listagens: Listagem dos cadastros.
Movimentao: Importar arquivos e exportar arquivos de acordo com os layouts
gerados.
Consulta: Consultar a movimentao importada e exportada.
Especiais: Gerar os programas a serem executados pelas rotinas de importao e
exportao.

Depois de alguns estudos, o mdulo de consulta foi cancelado, pois com as consultas
bsicas j existentes no sistema TRC era possvel repassar as informaes necessrias
para os usurios, no havendo a necessidade de se implementar novas funes de
consulta.

As funes especiais de gerao de programas de importao e exportao so
programas com complexidade considervel, porque internamente apresentam muitas
validaes / verificaes. Estes programas tm como objetivo auxiliar o
desenvolvimento de um novo layout, definido pelo cliente.

No desenvolvimento deste projeto, houve a preocupao com relao ao desempenho do
projeto, reutilizao do cdigo, facilidade a mudanas e facilidades operacionais. O
usurio final do software deve ser uma pessoa com conhecimento sobre a rea tcnica,
transferncia de arquivos, para conseguir receber e enviar os arquivos para os clientes
de forma a no causar problemas, tais como: arquivos incorretos ou arquivos
incompletos.


72
6.2.2 Resultados

Este projeto possui um nvel de complexidade mdia, possui algumas funes
(exportao / importao e gerao de programas) com nvel elevado de complexidade,
mas apresenta vrias funes (cadastramento) de nvel baixo e mdio.

Verificando a tabela comparativa (Tabela 6.2.2.1), obtida atravs das informaes
apresentadas pela ferramenta de estimativa, entre as mtricas, PF-PP (Pontos de
Particularidade), PF-IFPUG (Pontos por Funo definidos pelo IFPUG), PF-Fixo com
nvel de complexidade fixo e o tempo real gasto no desenvolvimento do projeto EDI
Troca de informaes de forma Eletrnica, identificou-se que a mtrica PF-PP (Pontos
de Particularidade) apresentou um resultado bem prximo do real (3% de erro).

TABELA 6.2.2.1 Tabela Comparativa das Estimativas - EDI.
Mdulo PF - PP PF - IFPUG PF - Fixo Real
Pontos % erro Pontos % erro Pontos % erro Pontos
1 - Cadastros 1.380,12 21,98 1.331,76 24,72 1.587,20 10,28 1.769,00
2 - Consulta 0,00 0,00 0,00 0,00
3 - Especial 899,00 1.062,68 987,04 688,00
4 - Listagem 1.068,87 918,84 1.216,43 373,50
5 - Movimentao 1.044,08 26,71 1.173,04 17,65 1.160,63 18,52 1.424,50
Total 4.392,07 4.486,32 4.951,30 4.255,00

(30,67) (54,46) (43,47)
(186,18) (146,01) (225,68)
(3,22) (5,44) (16,36)

A Figura 6.2.2.1 apresenta os dados da Tabela 6.2.2.1 Tabela Comparativa das
Estimativas de forma grfica. Normalmente, o gerente do projeto prefere visualizar as
informaes de forma grfica para identificar com mais rapidez os pontos de
discrepncia, e caso seja necessrio pode recorrer s informaes especficas que
geraram o grfico.

73

FIGURA 6.2.2.2 Comparativo entre Estimativas no projeto EDI

Analisando a produtividade dos profissionais envolvidos (LA e ECP) verificou-se que o
profissional LA ao desenvolver funes com baixo nvel de complexidade leva mais
tempo do que o estimado, mas para funes com mdio ou alto nvel de complexidade,
desenvolve no tempo estimado.

Enquanto que o profissional ECP foi subestimado para as funes do tipo de listagem,
enquanto que para o desenvolvimento das funes de cadastrados atingiu o esperado.
Quanto s funes de atualizao foi superestimada para as de mdia complexidade e
subestimada para as de alto nvel de complexidade. Quando isto ocorre, deve ser
verificado se o problema est com o profissional ou com a estimativa do projeto.
Analisando ambas as situaes verificou-se que o profissional ECP, juntamente no
perodo de desenvolvimento das atualizaes de mdia complexidade tambm estava
adquirindo conhecimento sobre o assunto o que causou uma improdutividade.

As informaes sobre os profissionais, pode ser visualizada pelos grficos apresentados
na Figura 6.2.2.3.








74

Profissional LA Profissional ECP
FIGURA 6.2.2.3 Acompanhamento dos Profissionais no projeto EDI

A princpio, o projeto EDI foi planejado para ser desenvolvido quando os profissionais
estivessem disponveis. Por este motivo o projeto prolongou-se durante oito meses. O
projeto foi iniciado em novembro/1998, foi colocado de lado no perodo de
janeiro/maro de 1999 quando foi novamente reiniciado e concludo em julho de 1999.

Por ter sido um projeto sem prazo definido de entrega, o acompanhamento do projeto
ocorreu conforme a alocao dos profissionais. A Figura 6.2.2.4 apresenta o grfico de
Gantt da alocao dos profissionais e com base neste grfico definiram-se os pontos de
controle. Isto significa que os pontos de controle foram sendo definidos durante o
desenvolvimento do projeto, isto no uma boa prtica.


FIGURA 6.2.2.4 Alocao dos Profissionais no projeto EDI

No se pode determinar que neste projeto ocorreram atrasos ou antecipaes com
relao ao projeto, porque nenhuma data de trmino do projeto foi definida
75
inicialmente. Portando a Figura 6.2.2.5 apresenta apenas um cenrio, um
acompanhamento fictcio do projeto.


FIGURA 6.2.2.5 Acompanhamento do Projeto no projeto EDI



76
7 Concluso


Neste trabalho foi apresentada a importncia do gerenciamento de projetos no
desenvolvimento de software. O gerenciamento de projetos dividido em duas partes,
Planejamento e Controle das atividades a serem executadas pela equipe de
desenvolvimento do projeto.

Uma etapa do processo de Planejamento de projeto estimar o tamanho, o custo e o
esforo no processo de desenvolvimento do sistema de software em questo. Para
estimar um projeto deve ser aplicada alguma mtrica de estimativa. Exemplos:
Estimativa do Esforo, Estimativa de Putnam, Modelo COCOMO, Anlise de Pontos
por Funo, Pontos de Particularidade ou PSP.

Cada mtrica possui caractersticas prprias. A mtrica Estimativa do Esforo determina
o esforo e o custo do desenvolvimento de um projeto atravs do nmero de
profissionais que executaram cada tarefa de desenvolvimento. A mtrica de Estimativa
de Putnam determina o esforo e o tempo necessrio para o desenvolvimento de um
projeto atravs das curvas de Rayleigh. O modelo COCOMO baseia-se nas equaes
definidas por Barry Boehm para determinar o esforo, o tempo e o nmero de
profissionais necessrios para desenvolver o projeto. A mtrica de Anlise de Pontos
por Funo baseia-se na funcionalidade do sistema para determinar o tamanho do
projeto. Pontos de Particularidade uma mtrica estendida da mtrica de Anlise de
Pontos por Funo, pois considera tambm o clculo do nmero de algoritmos a ser
desenvolvido. O PSP no pode ser considerado somente uma estimativa para um
processo de melhoria profissional pessoal, onde se inclui uma etapa de estimativa.

Todas as mtricas aqui apresentadas so baseadas no tamanho do projeto. E o tamanho
do projeto pode ser definido pelo nmero de linhas de cdigo, pontos por funo ou
pontos por objetos.

Para aplicar uma mtrica de estimativa em uma empresa de desenvolvimento de
software fez-se necessria uma ferramenta que automatize este processo, caso contrrio
torna-se invivel.

Ao analisar as ferramentas, ESTIMACS, SLIM, SPQR/20 e ESTIMATE Professional,
verificou-se que nenhuma delas atendia totalmente s necessidades do gerente de
projeto. Um gerente de projeto deve ser capaz de acompanhar o projeto, a estimativa e
os profissionais que desenvolvem o sistema. Por este motivo optou-se em desenvolver
uma nova ferramenta para estimativa e controle de projetos de software.

Antes de desenvolver uma ferramenta de estimativa investigou-se um ambiente ideal
para que o gerenciamento do projeto (planejamento e controle de projetos). Quanto
melhor o ambiente, mais integrado, melhores so as condies de gerenciamento,
criando desta forma um ambiente de trabalho ideal. Este ambiente deveria conter
ferramentas de desenvolvimento, modelagem dos dados e de estimativa. As informaes
existentes para cada uma das ferramentas devem ser compartilhadas com as demais, de
forma automatizada se possvel.

77
A ferramenta de estimativa deve permitir um acompanhamento do projeto, do
profissional e da estimativa. Deve ser possvel estimar um projeto atravs de vrias
tcnicas de estimativas, permitindo um comparativo entre as estimativas obtidas,
verificando desta forma a melhor mtrica de estimativa para determinado projeto.

Dois projetos de software foram submetidos ferramenta de estimativa desenvolvida.
Dois projetos pouco, para que concluses possam ser tiradas, mas pode se observar
que a mtrica de estimativa de Pontos Fixos (considerando o projeto como um todo)
mais recomendada para projetos onde exista uma complexidade algortmica bem
elevada. E que a mtrica de Pontos de Particularidade a melhor mtrica aplicada em
projeto com complexidade algortmica mdia, sem muitas frmulas matemticas. Deve-
se considerar tambm que ao aplicar uma mtrica de estimativa sobre um projeto,
algumas funes podem apresentar variaes de erro considerveis, que ao final se
complementam.

Conclui-se que para ter um ambiente de desenvolvimento com que gere produtos de alta
qualidade e produtividade necessrio um bom gerenciamento - planejamento e
controle do processo de desenvolvimento. O gerente de projeto deve ter condies de
obter informaes, de forma automtica, sobre o andamento do projeto e a
produtividade da equipe de desenvolvimento, identificando os problemas, para que
aes corretivas possam ser tomadas. No entanto o gerente de projeto ainda deve valer-
se tambm da sua experincia, pois cada projeto um projeto, com caractersticas
semelhantes e caractersticas diferenciadas de outros projetos.

A ferramenta de estimativa desenvolvida ainda pode ser aperfeioada e melhorada. O
processo de RBC pode ser implementado, como tambm novos projetos devem ser
introduzidos para que concluses mais realistas possam ser retiradas.

A ferramenta de estimativa hoje implementa somente mtricas de estimativa baseadas
em pontos por funo ou pontos por objeto, mas futuramente podem ser implementadas
mtricas baseadas em linhas de cdigo. Deve-se tomar cuidado quando se define uma
mtrica baseada em linhas de cdigo, porque a contagem de linha deve ser muito bem
especificada - quais tipos de linhas de cdigo devem ser contadas (comentrios, linhas
em branco).

As empresas desenvolvedoras de software devem tomar conscincia que para melhorar
a qualidade e a produtividade do processo de desenvolvimento necessrio mensurar
este processo. A partir do conhecimento das medidas, possvel definir metas para
aumentar a qualidade e produtividade do desenvolvimento. E com o conhecimento
sobre a produtividade da equipe de desenvolvimento possvel estabelecer prazos e
custos mais prximos da realidade.


78
Anexo 1 Tabela de Decomposio


A Tabela de Decomposio pode ser utilizada para ajudar a estimativa a encontrar o
nmero de linhas de cdigo de um projeto. Esta tcnica determina o tamanho do
software, pode ser utilizada em conjunto com as mtricas COCOMO e Putnam
determinando o nmero total de linhas de cdigo do projeto. No entanto pode estimar o
custo e o esforo do projeto, desde que se aplique a taxa de mo-de-obra e a mdia
produzida pelos profissionais.

Para utilizar-se a tabela de decomposio necessrio definir o nmero de Linhas de
Cdigo ou Pontos por Funo ou Pontos de Particularidade, por uma viso otimista,
pessimista e a mais provvel. A partir destas informaes consegue-se clculo esperado
a partir da frmula:

Esperado = ( otimista + ( 4 * mais provvel ) + pessimista ) / 6

Deve ser informados, tambm, o valor do ponto ou da linha e a quantidade de linhas ou
pontos produzidos por ms, para calcular o custo e o tempo, segundo as frmulas
abaixo.

Custo = Esperado * $Linha

Meses = Esperado / Linha-ms

Desta forma consegue-se construir a seguinte tabela:

TABELA A.1.1 - Decomposio
Funo Otimista Mais
Provvel
Pessimista Esperado $
Linha
Linha-
Ms
Custo Meses



Funes do
projeto definidas
no escopo.

Total


Custo Estimado
Projeto
Esforo
Exigido





79
Anexo 2 Tabela de Multiplicadores (COCOMO)


TABELA A.2.1 - Multiplicadores do COCOMO 81
Cd Descrio Muito
Baixo
Baixo Normal Alto Muito
Alto
Extra
Alto
01 Atributos do Produto
01 Confiabilidade desejada 0,75 0,88 1,00 1,15 1,40 -
02 Tamanho do banco de dados - 0,94 1,00 1,08 1,16 -
03 Complexidade do produto 0,70 0,85 1,00 1,15 1,30 1,65
02 Atributos do Ambiente
01 Limitao de tempo de execuo - - 1,00 1,11 1,30 1,66
02 Limitao de memria - - 1,00 1,06 1,21 1,56
03 Volatibilidade do equipamento - 0,87 1,00 1,15 1,30 -
04 Tempo de Turnaround do computador - 0,87 1,00 1,07 1,15 -
03 Atributos de Pessoal
01 Capacidade dos analistas 1,46 1,19 1,00 0.86 0,71 -
02 Capacidade dos programadores 1,42 1,17 1,00 0,86 0,70 -
03 Experincia na aplicao 1,29 1,13 1,00 0,91 0,82 -
04 Experincia com o sistema operacional 1,21 1,10 1,00 0,9 - -
05 Experincia na linguagem de programao 1,14 1,07 1,00 0,95 - -
04 Atributos do Projeto
01 Uso de prticas modernas de programao 1,24 1,10 1,00 0,91 0,82 -
02 Uso de ferramentas de desenvolvimento 1,24 1,10 1,00 0,91 0,83 -
03 Tempo disponvel para o projeto 1,23 1,08 1,00 1,04 1,10 -

80
TABELA A.2.2 - Multiplicadores da extenso do COCOMO
Cd Muito
Baixo
Baixo Normal Alto Muito
Alto
Extra
Alto
01 Escala de Drives
01 Precedncia 6,20 4,96 3,72 2,48 1,24 0,00
02 Flexibilidade de desenvolvimento 5,07 4,05 3,04 2,03 1,01 0,00
03 Arquitetura / Resoluo de risco 7,07 5,65 4,24 2,83 1,41 0,00
04 Coeso da equipe 5,48 4,38 3,29 2,19 1,10 0,00
05 Maturidade do processo 7,80 6,24 4,68 3,12 1,56 0,00
02 Atributos do Produto
01 Confiabilidade desejada 0,82 0,92 1,00 1,10 1,26 -
02 Tamanho do banco de dados - 0,90 1,00 1,14 1,28 -
03 Complexidade do produto 0,73 0,87 1,00 1,17 1,34 1,74
04 Documentao 0,81 0,91 1,00 1,11 1,23 -
03 Atributos do Ambiente
01 Limitao de tempo de execuo - - 1,00 1,11 1,29 1,63
02 Limitao de memria - - 1,00 1,05 1,17 1,46
03 Volatibilidade do equipamento - 0,87 1,00 1,15 1,30 -
04 Atributos de Pessoal
01 Capacidade dos analistas 1,42 1,19 1,00 0,85 0,71 -
02 Capacidade dos programadores 1,34 1,15 1,00 0,88 0,76 -
03 Continuidade do Pessoal 1,20 1,09 1,00 0,91 0,84 -
04 Experincia dos analistas 1,22 1,10 1,00 0,88 0,81 -
05 Experincia dos programadores 1,19 1,09 1,00 0,91 0,85 -
06 Experincia na linguagem de programao 1,29 1,12 1,00 0,90 0,81 -
05 Atributos do Projeto
01 Uso de prticas modernas de programao 1,17 1,09 1,00 0,90 0,78 -
02 Uso de ferramentas de desenvolvimento 1,22 1,09 1,00 0,93 0,86 0,8
81
Anexo 3 Tabelas dos Pontos por Funo


A.3.1 Arquivos Lgicos Internos

Os Arquivos Lgicos Internos representam os requerimentos de armazenamento de
dados, cuja manuteno feita pela prpria aplicao.

TABELA A.3.1.1 - Complexidade dos Arquivos Lgicos Internos
1 a 19 itens de dados
referenciados
20 a 50 itens de dados
referenciados
51 ou mais itens de
dados referenciados
1 registro lgico SIMPLES SIMPLES MDIA
2 a 5 registros lgicos SIMPLES MDIA COMPLEXA
6 ou mais registros lgicos MDIA COMPLEXA COMPLEXA

A.3.2 Arquivo Interface Externas

Os Arquivos de Interface Externos representam as necessidades dos dados, originadas
externamente aplicao.

TABELA A.3.2.1 - Complexidade das Interfaces Externas
1 a 19 itens de dados
referenciados
20 a 50 itens de dados
referenciados
51 ou mais itens de
dados referenciados
1 registro lgico SIMPLES SIMPLES MDIA
2 a 5 registros lgicos SIMPLES MDIA COMPLEXA
6 ou mais registros lgicos MDIA COMPLEXA COMPLEXA

A.3.3 Entradas Externas

As Entradas Externas representam as atividades de manuteno de dados

TABELA A.3.3.1 - Complexidade das Entradas Externas
1 a 4 itens de dados
referenciados
5 a 15 itens de dados
referenciados
16 ou mais itens de
dados referenciados
1 arquivo referenciado SIMPLES SIMPLES MDIA
2 arquivos referenciados SIMPLES MDIA COMPLEXA
3 ou mais arquivos
referenciados
MDIA COMPLEXA COMPLEXA

A.3.4 Sadas Externas

As Sadas Externas representam as atividades da aplicao que tem como resultado a
sada dos dados.

TABELA A.3.4.1 - Complexidade das Sadas Externas
1 a 5 itens de dados
referenciados
6 a 19 itens de dados
referenciados
20 ou mais itens de
dados referenciados
1 arquivo referenciado SIMPLES SIMPLES MDIA
2 a 3 arquivos referenciados SIMPLES MDIA COMPLEXA
4 ou mais arquivos
referenciados
MDIA COMPLEXA COMPLEXA
82

A.3.5 Consultas Externas

As Consultas Externas so uma combinao de Entradas / Sadas de dados, onde uma
entrada ocasiona a recuperao imediata de dados.

Para classificar uma Consulta Externa:
Calcula-se a complexidade funcional da parte de entrada das consultas externas
Calcula-se a complexidade funcional da parte de sada das consultas externas
Escolhe a maior complexidade encontrada

TABELA A.3.5.1 - Complexidade das Consultas Parte de Entrada
1 a 4 itens de dados
referenciados
5 a 15 itens de dados
referenciados
16 ou mais itens de
dados referenciados
1 arquivo referenciado SIMPLES SIMPLES MDIA
2 arquivos referenciados SIMPLES MDIA COMPLEXA
3 ou mais arquivos
referenciados
MDIA COMPLEXA COMPLEXA

TABELA A.3.5.2 - Complexidade das Consultas Parte de Sada
1 a 5 itens de dados
referenciados
6 a 19 itens de dados
referenciados
20 ou mais itens de
dados referenciados
1 arquivo referenciado SIMPLES SIMPLES MDIA
2 a 3 arquivos referenciados SIMPLES MDIA COMPLEXA
4 ou mais arquivos
referenciados
MDIA COMPLEXA COMPLEXA

A.3.6 Tabela de Clculo dos Pontos por Funo

TABELA A.3.6.1 - Clculo dos Pontos por Funo
Tipo de Funo Complexidade e
Funcionalidade
Total de Pontos Pontos X Complexidade
Arquivo Simples X 7 =
Mdia X 10 =
Complexa X 15 =

Interface Simples X 7 =
Mdia X 10 =
Complexa X 15 =

Entrada Simples X 3 =
Mdia X 4 =
Complexa X 6 =

Sada Simples X 4 =
Mdia X 5 =
Complexa X 7 =

Consulta Simples X 3 =
Mdia X 4 =
Complexa X 6 =

Total de Pontos por Funo Brutos





83

A.3.7 Caractersticas Gerais dos Sistemas

Atribui-se um peso de 0 a 5 para cada uma destas caractersticas, de acordo com o seu
nvel na aplicao:

0 Nenhuma influncia
1 Influncia Mnima
2 Influncia Moderada
3 Influncia Mdia
4 Influncia Significativa
5 Grande Influncia

TABELA A.3.7.1 - Caractersticas dos Pontos por Funo
Caractersticas
01 Comunicao de Dados
02 Processamento Distribudo
03 Performance
04 Utilizao do Equipamento
05 Volume de Transaes
06 Entrada de Dados on-line
07 Eficincia do Usurio Final
08 Atualizao on-line
09 Processamento Complexo
10 Reutilizao de Cdigo
11 Facilidade de Implantao
12 Facilidade Operacional
13 Mltiplos Locais
14 Facilidade de Mudanas

84
Anexo 4 Tabelas do PSP


Ao aplicar o PSP, a companhia deve seguir os seguintes tpicos:

TABELA 4.1 Como aplicar o PSP
Tpico Nvel do
PSP
Descrio
A estratgia do PSP e a sua Linha Bsica PSP0 Calcule a mdia e o desvio padro de
nmeros reais guardados em uma lista
vinculada
O Processo de Planejamento PSP0.1 Conte o LOC de um programa
Produza o padro de contagem LOC
Produza o padro de cdigo
Medindo o Tamanho do Software PSP0.1 Aumente o programa para contar o LOC do
objeto ou o LOC da funo / procedimento
Reporte anlise de defeitos
Estimando o Tamanho do Software PSP1 Calcule os parmetros de regresso linear de
pares de nmero reais guardados em uma
lista vinculada
Estimativa de recursos e cronograma PSP1.1 Integrao numrica usando a regra de
Simpson.
Medies no PSP PSP1.1 Aumente o programa para calcular um
intervalo de previso de 90% e 70%
Reviso do Cdigo e do Design Relatrio intermedirio de anlise do
processo
Gerenciamento da Qualidade do Software PSP2 Calcule a correo de pares de nmeros
reais guardados em uma lista vinculada
Design do Software PSP2 ou
PSP2.1
Organize uma lista vinculada
Verificao do Design do Software PSP2.1 Teste o Qui-quadrado para normalidade
Escalonando o PSP PSP3 Calcule os parmetros de regresso linear
mltipla para conjuntos de quatro nmeros
reais guardados em uma lista vinculada
Definindo o Processo de Software e usando
o PSP
Relatrio final de anlise do processo.


85
Anexo 5 Diagrama de Atividades


O Diagrama de Atividade representa como a ferramenta de estimativa de custo e esforo
est desenvolvida. O processo de estimar um projeto est subdividido em Parametrizar a
ferramenta, Cadastrar as Informaes referentes empresa, Cadastrar os projetos,
Estimar os projetos, e Gerenciar os projetos. Esta diviso pode ser visualizada no Anexo
A.5.1 Viso Geral.

O processo de Parametrizar a ferramenta composto por definir as mtricas de
estimativa que a ferramenta implementa e os tipos de funes. O Cadastramento das
Informaes referentes empresa so subdivididos em Cadastrar os profissionais que
desenvolvem os projetos e os servios prestados pela empresa desenvolvedora. Ao
cadastrar um profissional as informaes referentes a frias e histricos salariais
tambm devem ser informadas. Anexo A.5.2 Cadastros e Parmetros.

O processo de Cadastrar Projetos engloba um conjunto de atividades, tais como:
Cadastrar Cliente, Cadastrar Projeto, Cadastrar Mdulos, Cadastrar Funes, Alocar
Profissionais, Definir Pontos de Controle, Cadastrar Banco de Dados, Cadastrar as
Tabelas dos bancos de dados, Relacionar as Tabelas com as Funes do Projeto e
Apontar o nmero de horas trabalhadas. Anexo A.5.3 Projetos.

Estimar um Projeto significa estimar os seus mdulos e conseqentemente estimar as
funes, a ferramenta desenvolvida permite tambm uma simulao da funo do
projeto, Anexo A.5.4 Estimar Projetos. O Anexo A.5.4.1 detalha como a ferramenta
de estimativa calcula a funo do projeto.

O processo de Acompanhamento foi subdividido em Gerenciar Projetos, Gerenciar
Profissionais e Gerenciar Estimativas, para facilitar o entendimento das informaes
apresentadas pela ferramenta desenvolvida. Anexo A.5.5 Acompanhamento.
86

A.5.1 Viso Geral


Estimar
Projeto
Parametrizar
Cadastrar
Dados da
Empresa
Cadastrar
Projetos
Estimar os
Projetos
Gerenciar os
Projetos










87
A.5.2 Parmetros e Cadastros



Parametrizar
Parametrizar
Estimativa
Parametrizar
Tipo de
Funo
Sistema
Parametrizado
Cadastrar
Dados da
Empresa
Cadastrar
Profissionais
Cadastrar
Servios
Dados da
Empresa
Cadastrados
Cadastrar
Frias
Cadastrar
Histricos

















88
A.5.3 Projetos
Cadastrar
Projetos
Cadastrar
Cliente
Cadastrar
Banco
Cadastrar
Funo
Tabela
Cadastrar
Projeto
Cadastrar
Tabela
Cadastrar
Mdulo
Cadastrar
Profissional /
Projeto
Cadastrar
Funo
Cadastrar
Apontamento
Cadastro do
Projeto
Cadastrar
Pontos de
Reviso

89

A.5.4 Estimar Projetos



Estimar
Projetos
Estimar
Mdulo
Estimar
Funo
Projeto
Estimado
Estimar
Projeto





















90

A.5.4.1 Estimar Funo

Estimar
Funo
Nr. Pontos
Fator de
Ajuste
Calculada
Funo
Complexidade


















91
A.5.5 Acompanhamento


Gerenciar
Projetos
Gerenciar
Projeto
Gerenciar
Profissional
Gerenciar
Estimativa
Acomp.
Estimativa
Comparativo
Estimativas
Acomp.
Projeto
Verificao
Aloc. Prof
Projeto
Gerenciado
















92
Anexo 6 Diagramas de Interao


Para facilitar o entendimento do processo de estimativa de custo e esforo de um projeto
optou-se em detalhar, atravs do uso de diagramas de interaes, os mtodos mais
complexos existentes nas classes da ferramenta de estimativa desenvolvida.

A.6.1 Cadastrar Projetos

Definir como um projeto deve ser includo na ferramenta de estimativa desenvolvida.

Janela Cadastrar
Projetos
Projeto Mdulo Projeto
Profissional
Profi ssional Ponto de Reviso
IncProjeto()
VerProfissional(responsvel)
IncMdulo()
IncProjetoProfiss ional()
VerProfissional(alocado)
VerProfissional(responsvel)
Inc Ponto Revis o()





93

A.6.2 Estimar uma Funo

Define como uma funo deve ser estimada. Os mtodos Entrada, Sada, Consulta,
Arquivo, Interface e Algoritmos foram detalhados no Anexo A.6.2.1. Os mtodos
CompEntrada (complexidade de entrada), CompSada (complexidade de sada),
CompConsulta (complexidade de consulta), CompArquivo (complexidade de arquivo),
CompInterface (complexidade de Interface), CompAlgoritmo (complexidade do
algoritmo) foram detalhados no Anexo A.6.2.2. E o anexo A.6.2.3 detalha o mtodo
para clculo do fator de ajuste.

Janela: Es timar
Fun o
His trico Funo Clculo Funo
I ncHi s tor ic oFuncao()
Entrada()
Saida()
Cons ulta()
Arquivo()
Inter fa ce()
Algoritmo()
CompEn trada()
CompSaida()
CompCons ulta()
CompArquivo()
CompInterface()
CompAlgoritmo()
Fator_de_Ajus te()


94
A.6.2.1 Calcular o Nmero de Pontos

Cl cul o Funo Funo Tabel a Funo Tabel a Metodo i nvocado
Entrada()
NrAtri bEntrada()
NrAtri butos()
NrAtri bEntradaAcres()
Sai da( )
Nr Atri bSai da( )
NrAtri butos()
NrAtri bSai daAcres()
Consul ta()
NrAtri bConsul ta()
NrAtri butos()
NrAtri bConsul taAcres()
Arqui vo( )
NrT abel as
NrTabel asAcres()
Interface()
NrAtri bInterface()
NrAtri butos()
NrAtri bInterfaceAcres()
Al gori tmo()
NrAl gori tmosAcres()



95
A.6.2.2 Calcular os Nveis de Complexidade
Mtodo i nvocado Cl cul o Funo Esti mati va Nve l
CompEntrada()
VerEst i mati va ()
CompEntrada()
[no enc ont rada] CompEnt rada( )
CompSai da()
VerEst i mati va ()
CompSai da()
[no encontrada] CompSai da()
CompConsul ta ()
VerEst i mati va ()
CompConsul ta()
[no en con tr ada ] CompCo nsu lta( )
CompA rqui vo( )
VerEst i mati va ()
CompArqui vo()
[no encontrada] CompArqui vo()
CompIn terface ()
VerEst i mati va ()
Co mp Int er face( )
[no en con tr ada ] CompInt er face( )
CompAl gori tmo()
VerEst i mati va ()
CompAl gor itmo( )
[no encontrada] CompAl gori tmo()

96
A.6.2.3 Calcular o Fator de Ajuste

Mtodo
invocado
Cl cul o Funo Pr ojeto Fat or His trico
Mdulo
Fat or()
VerHis tricoMdulo()
[s e exis te] ValorProjetoFator()
Aplicao da frmula()


A.6.3 Acompanhamento de Projetos


O processo de acompanhamento do projeto ocorre atravs dos pontos de controle
determinados na definio do projeto. O mtodo de acompanhamento de projetos est
baseado na reviso do projeto. A reviso do projeto significa a verificao dos pontos j
concludos, em relao aos pontos estimados.

Frame Gerenciar
Projetos
Ponto Revis o His trico Projeto His trico
Mdulo
His trico
Funo
Funo
VerPontoRevis o()
IncHistricoProjeto()
Ponto s Previs tos ()
Pontos Previs tos ()
Pon tos Con cluidos ()
Pontos Concluidos
Sit uao ()






97

A.6.4 Acompanhamento de Profissionais

Acompanhamento do profissional feito atravs de um confronto das informaes
estimadas e concludas. O diagrama a baixo descreve o mtodo de acompanhamento do
profissional por tipo de funo desenvolvida.

Fr ame Acom panham ent o
Profis s ional
Tipo de Funo Profis s ional His trico
Funo
Funo
Profis s ional
VerProfis s ional()
Ver TpFun o()
Pontos Pre vi s to()
Pont os Reais Con clu idos ()

A.6.5 Acompanhamento das Estimativas

O Acompanhamento da estimativa confronta as informaes estimadas e reais sobre o
projeto, este acompanhamento pode ser efetuado por mdulo ou por tipo de funo.
Fram e Gerenciar
Es ti mati vas
Es timativa Tipo de Funo His tr ico
Mdulo
His trico
Funo
Profis s ion al
Fun o
VerEs timativa()
Pontos Es timados ()
Pontos Es timados ()
Pontos Concluidos ()
Pontos Concluidos ()
VerTpFun o()
Pontos Es timados ()
Pontos Es timados ()
Pontos Concluidos ()
Pontos Concluidos ()
98

Anexo 7 Diagrama de Estados

A Classe Funo possui vrios estados, e cada estado com caractersticas prprias:

Criada: uma funo nova na ferramenta.
Em Andamento: a partir do momento que foi efetuado um apontamento de horas sobre a
funo, significa que j foi iniciada.
Cancelada: quando uma funo no tiver mais objetivo para o projeto.
Finalizada: quando funo j foi desenvolvida totalmente.

O diagrama de estados permite uma visualizao da transferncia de estados da Funo
do Projeto.

A.7.1 Funo do Projeto



Criada
Em
Andamento
Cancelada Finalizada
Apontamento
Finalizada
Modificada
Finalizada
Cancelada
Cancelada
Modificada
Criada
Cancelada
Modificada







99
Anexo 8 Dicionrio de Dados


Classe: Apontamento
Atributo Descrio Tipo
# Cd_profissional Cdigo do Profissional Texto
# Dt_apontamento Data do Apontamento Data
# Nr_seqncia Nmero de Seqncia Nmero
Hr_inicio Hora de Incio Nmero
Hr_fim Hora Final Nmero
Cd_cliente Cdigo do Cliente Texto
Cd_projeto Cdigo do Projeto Texto
Cd_mdulo Cdigo do Mdulo Texto
Cd_funo Cdigo da Funo Texto
Cd_servio Cdigo do Servio Texto

Classe: Banco de Dados
Atributo Descrio Tipo
# Cd_banco Cdigo do Banco Texto
Ds_banco Descrio do Banco Texto

Classe: Campos da Tabela
Atributo Descrio Tipo
# Cd_banco Cdigo do Banco Texto
# Cd_tabela Cdigo da Tabela Texto
# Cd_atributo Cdigo do Atributo Texto
Nm_atributo Nome do Atributo Texto

Classe: Cliente
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
Nm_cliente Nome do Cliente Texto
Nr_cgc_cpf Nmero do CGC/CPF do Cliente Nmero
Nm_contato Nome do Contato Texto
Endereo
8
Endereo do Cliente

Classe: Cliente Servio
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_servio Cdigo do Servio Texto
Vl_servio Valor do Servio Nmero




8
Endereo: Nmero do Telefone, Nmero do Fax, Rua, Nr, Bairro, Cidade, Estado e
CEP.
100
Classe: Estimativa
Atributo Descrio Tipo
# Cd_estimativa Cdigo da Estimativa Texto
Ds_estimativa Descrio da Estimativa Texto
Vl_complexidade_arquivo Valor da Complexidade do Arquivo Nmero
Vl_complexidade_entrada Valor da Complexidade da Entrada Nmero
Vl_complexidade_sada Valor da Complexidade da Sada Nmero
Vl_complexidade_consulta Valor da Complexidade da Consulta Nmero
Vl_complexidade_interface Valor da Complexidade da Interface Nmero
Vl_complexidade_algoritmo Valor da Complexidade do Algoritmo Nmero

Classe: Fator Ajuste
Atributo Descrio Tipo
# Cd_estimativa Cdigo da Estimativa Texto
# Nr_seq_ajuste Nmero da Seqncia de Ajuste Numero
Ds_caracterstica Caracterstica Texto
Vl_mnimo_ajuste Valor mnimo do Fator de Ajuste Nmero
Vl_mximo_ajuste Valor mximo do Fator de Ajuste Nmero

Classe: Funo
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
# Cd_funo Cdigo da Funo Texto
Ds_funo Descrio da Funo Texto
Cd_tipo_funo Tipo de Funo Texto
Cd_prof_resp Cdigo do Profissional Responsvel Texto
Dt_incio Data de Incio da Funo Data/Hora
Dt_trmino Data de Trmino da Funo Data/Hora
Dt_prevista_incio Data Prevista de Incio Data/Hora
Dt_prevista_trmino Data Prevista de Trmino Data/Hora
Nr_interfaces_acres Nmero de interfaces a serem acrescidas Nmero
Nr_entradas_acres Nmero de entradas a serem acrescidas Nmero
Nr_sadas_acres Nmero de sadas a serem acrescidas Nmero
Nr_consultas_acres Nmero de Consultas a serem acrescidas Nmero
Nr_algoritmos_acres Nmero de algoritmos a serem acrescidas Nmero
Id_situao Situao da Funo Nmero
Dt_situao Data da Situao Data/Hora

Classe: Funo Profissional
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
# Cd_funo Cdigo da Funo Texto
# Cd_profissional Cdigo do Profissional Texto
Vl_ponto_funo Valor do Ponto Funo Nmero
Nr_horas Nmero de Horas Trabalhadas Nmero
101
Classe: Funo Tabela
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
# Cd_funo Cdigo da Funo Texto
# Cd_banco Cdigo do Banco Texto
# Cd_tabela Nome da Tabela Texto
Id_entrada Tabela de Entrada Lgico
Id_sada Tabela de Sada Lgico
Id_consulta Tabela de Consulta Lgico
Id_interface Tabela de interface Lgico
Nr_atributos Nmero de Atributos Nmero

Classe: Histrico Fator de Ajuste Projeto
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_estimativa Cdigo da estimativa Texto
# Nr_seq_histrico Seqncia do Histrico Nmero
# Nr_seq_ajuste Seqncia do Fator de Ajuste Nmero
Vl_caracterstica Valor da Caracterstica Nmero

Classe: Histrico Funo
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
# Cd_funo Cdigo da Funo Texto
# Cd_estimativa Cdigo da Estimativa Texto
# Nr_seq_histrico Seqncia do Histrico Nmero
Nr_ponto_entrada Nmero de Pontos de Entrada Nmero
Nr_ponto_sada Nmero de Pontos de Sada Nmero
Nr_ponto_consulta Nmero de Pontos de Consulta Nmero
Nr_ponto_interface Nmero de Pontos de Interface Nmero
Nr_ponto_algoritmos Nmero de Pontos de Algoritmos Nmero
Nr_ponto_arquivos Nmero de Pontos de Arquivos Nmero
Vl_compl_entrada Valor da Complexidade de Entrada Nmero
Vl_compl_sada Valor da Complexidade de Sada Nmero
Vl_compl_consulta Valor da Complexidade de Consulta Nmero
Vl_compl_interface Valor da Complexidade da Interface Nmero
Vl_compl_algoritmos Valor da Complexidade dos Algoritmos Nmero
Vl_compl_arquivos Valor da Complexidade dos Arquivos Nmero
Vl_fator_ajuste Valor do Fator de Ajuste Nmero
Cd_profissional_alocado Cdigo do Profissional Alocado Texto
Vl_ponto_funo Valor do Ponto Funo Nmero



102
Classe: Histrico Mdulo
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
# Cd_estimativa Cdigo da Estimativa Texto
# Nr_seq_histrico Seqncia do Histrico Nmero
Dt_estimativa Data da Estimativa Data/Hora
Nr_pontos_estimados Nmero de Pontos estimados neste Mdulo Nmero

Classe: Histrico Projeto
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Nr_seq_histrico Nmero de Seqncia de Histrico Nmero

Classe: Histrico Reviso
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Nr_seq_reviso Nmero da Reviso do Projeto Nmero
# Cd_estimativa Cdigo da Estimativa Texto
# Nr_seq_histrico Seqncia do Histrico Nmero
Nr_pontos_previsos Nmero de Pontos Previstos Nmero
Nr_pontos_real Nmero de Pontos Realmente Trabalhados Nmero
Dt_reviso Data da Reviso Data/Hora
Cd_prof_reviso Cdigo do Profissional que fez a Reviso Texto

Classe: Mdulo
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_modulo Cdigo do Mdulo Texto
Ds_modulo Descrio do Mdulo Texto
Dt_incio Data de Incio do Mdulo Data/Hora
Dt_trmino Data de Trmino do Mdulo Data/Hora
Dt_prevista_incio Data Prevista de Incio Data/Hora
Dt_prevista_trmino Data Prevista de Trmino Data/Hora
Cd_profissional_resp Cdigo do Profissional Responsvel Texto
Nr_interfaces_acres Nmero de Interfaces a serem acrescidas Nmero
Nr_entradas_acres Nmero de Entradas a serem acrescidas Nmero
Nr_sadas_acres Nmero de Sadas a serem acrescidas Nmero
Nr_consultas_acres Nmero de Consultas a serem acrescidas Nmero
Nr_algoritmos_acres Nmero de Algoritmos a serem acrescidos Nmero





103

Classe: Nvel Complexidade
Atributo Descrio Tipo
# Cd_estimativa Cdigo da Estimativa Texto
# Id_identificador Identificador Nmero
# Nr_seq_compl Seqncia da Complexidade Texto
Nr_tabela_de Nmero de Tabelas de Nmero
Nr_tabela_ate Nmero de Tabelas ate Nmero
Nr_atributos_de Nmero de Atributos de Nmero
Nr_atributos_ate Nmero de Atributos ate Nmero
Vl_complexidade Valor da Complexidade Nmero

Classe: Ponto Reviso
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Nr_seq_reviso Seqncia da Reviso Nmero
Cd_profissional_responsvel Cdigo do Profissional Responsvel Texto
Dt_prevista_reviso Data Prevista de Reviso Data/Hora
Pc_esperado Perc. Esperado de Concluso Nmero

Classe: Profissional
Atributo Descrio Tipo
# Cd_profissional Cdigo do Profissional Texto
Nm_profissional Nome do Profissional Texto
Dt_admisso Data de Admisso Data/Hora
Dt_demisso Data de Demisso Data/Hora
Endereo
9
Endereo do Cliente
Nr_horas_trabalhadas Nmero de Horas Trabalhadas por dia Nmero
Vl_ponto_funo Valor do Ponto por Funo Nmero
Cd_servio Cdigo do servio executado atualmente Texto

Classe: Profissional Alocado
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_profissional Cdigo do Profissional Texto
# Nr_seq_alocacao Nmero de Seqncia de Alocao Nmero
Dt_incio_prevista Data de Incio dos Trabalhos Data/Hora
Dt_trmino_prevista Data de Trmino dos Trabalhos Data/Hora

Classe: Profissional Frias
Atributo Descrio Tipo
# Cd_profissional Cdigo do Profissional Texto
# Nr_seq_frias Seqncia de Frias Texto
Dt_incio_frias Data de Incio das Frias Data/Hora
Dt_fim_frias Data de Trmino das Frias Data/Hora

9
Endereo: Nmero do Telefone, Rua, Nr, Bairro, Cidade, Estado e CEP.
104
Classe: Profissional Histrico - RH
Atributo Descrio Tipo
# Cd_profissional Cdigo do Profissional Texto
# Nr_seq_histrico Seqncia do Histrico Texto
Dt_histrico Data do Histrico Data/Hora
Vl_salrio Valor do Salrio Nmero
Cd_servio Cdigo do Servio Texto

Classe: Projeto
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
Ds_projeto Descrio do Projeto Texto
Cd_responsvel Cdigo do Responsvel Texto
Dt_incio Data de Incio do Projeto Data/Hora
Dt_fim Data de Fim do Projeto Data/Hora
Dt_prevista_incio Data Prevista de Incio do Projeto Data/Hora
Dt_prevista_fim Data Prevista de Trmino do Projeto Data/Hora

Classe: Projeto Profissional
Atributo Descrio Tipo
# Cd_cliente Cdigo do Cliente Texto
# Cd_projeto Cdigo do Projeto Texto
# Cd_profissional Cdigo do Profissional Texto
Nr_pontos Nmero de pontos produzidos Nmero
Id_empresa Tempo de Empresa Nmero
Id_conhec_tcnico Conhecimento da Tecnologia Texto
Id_conhec_negcio Conhecimento do Negcio Texto
Id_escolaridade Nvel de Escolaridade Texto

Classe: Servio
Atributo Descrio Tipo
# Cd_servio Cdigo do Servio Texto
Ds_servio Descrio do Servio Texto
Vl_servio Valor do Servio Nmero
Vl_salrio_padro Valor do Salrio Padro Nmero
Vl_ponto_funo Valor do Ponto por Funo Nmero

Classe: Tabela
Atributo Descrio Tipo
# Cd_banco Cdigo do banco Texto
# Cd_tabela Cdigo da Tabela Texto
Nm_tabela Nome da Tabela Texto






105
Classe: Tipo de Funo
Atributo Descrio Tipo
# Cd_tp_funo Cdigo do Tipo de Funo Texto
Ds_tp_funo Descrio do Tipo de Funo Texto
Nr_algoritmos_acres Nmero de Algoritmos a ser acrescidos Nmero
Nr_interfaces_acres Nmero de Interfaces a ser acrescidos Nmero
Nr_entradas_acres Nmero de Entradas a ser acrescidos Nmero
Nr_sadas_acres Nmero de Sadas a ser acrescidos Nmero
Nr_consultas_acres Nmero de Consultas a ser acrescidos Nmero
Vl_ponto_funo Valor do Ponto por Funo Nmero

106
Bibliografia

[ABE 96] ABEL, Mara. Um estudo sobre Raciocnio Baseado em Casos. Porto Alegre:
CPGCC/UFRGS, 1996.
[AGU 99] AGUIAR, Maurcio. Estimativas Confiveis de Prazos para Gerentes de
Projetos. Developers Magazine, Rio de Janeiro, v.3, n.33, maio 1999.
[BEC 99] BECKER, Shirley A. BOSTELMAN, Mitchell L. Aligning Strategic and Project
Measurement Systems. IEEE Software, New York, v.16, n.3, May/June 1999.
[BOE 81] BOEHM, Barry. Software Engineering Economics. New Jersey: Prentice-Hall,
1981.
[CAN 99] CASAROTTO FILHO, Nelson; FAVERO Jose S; CASTRO, Joo E. E.
Gerncia de Projetos / Engenharia Simultnea. So Paulo: Atlas, 1999.
[CAS 98] CASTRO, Jaelson F. B. Introduo a Medio de Software atravs de Pontos
por Funo. In: SIMPSIO BRASILEIRO DE ENGENHARIA DE
SOFTWARE, SBES, 12., 1998. Anais... Maring: Departamento de
Informtica/Universidade Estadual de Maring, 1998.
[DEM 86] DEMING, Edward. Out of the Crisis. [S.l.]: MIT Press, 1986.
[DRA 96] DRAKE, Thomas. Measuring Software Quality: A Case Study. Computer, Los
Alamitos, v.29, n.11, Nov. 1996.
[FER 95] FERNANDES, Aguinaldo A. Gerencia de Software Atravs de Mtricas. So
Paulo: Atlas, 1995.
[FUR 97] FUREY, Sean Why We Should Use Function Points? IEEE Software, New
York, v.14, n.2, March/April 1997.
[GRA 99] GRABLE, Ross et al. Metrics for Small Projects: Experiences at the SED. IEEE
Software, New York, v.16, n.2, March/April 1999.
[HAL 97] HALL, Tracy; FENTON, Norman. Implementing Effective Software Metrics
Programs. IEEE Software, New York, v.14, n.2, March/April 1997.
[HON 97] HONG, Danfeng. Software Cost Estimation. Canad: Department of
Computer Science University of Calgary, 1997 Disponvel em: <http://
www.cpsc.ucalgary.ca/~hongd/SENG/621/report2.html> Acesso em: ago 2000.
[HUM 95] HUMPHREY, Watts A Discipline for Software Engineering, [S.l.]: Addison-
Wesley, 1995.
[IFP 94] IFPUG. Function Points Counting practice manual: Relise 4. Westerville,
Ohio, 1994.
[JOH 98] JOHNSON, Kim. Software Cost Estimation: Metrics and Models. 1998.
Disponvel em:
<http://sern.ucalgary.ca/courses/seng/621/w98/johnsenk/cost.htm>. Acesso em:
set. 2000.
[JON 86] JONES, Capers. A Short History of Functions Points and Feature Points
Software Productivity Research. [S.l.]: Beurlington Inc, 1986.
[JON 91] JONES, Capers. Produtividade no Desenvolvimento de Software. 2.ed. So
Paulo: Makron Books, 1991.
[KAU 99] KAUTZ, Karlheinz. Making Sense of Measurement for Small Organizations.
IEEE Software, New York, v.16, n.2, March/April 1999.
[KAV 2000] KAVACHAR. Visual Enginnering. Disponvel em:
<http://www.ve.com/kavachart/index.html>. Acesso em: maro 2000.
[KEM 87] KEMERER, Chris F. An Empirical Validation of Software Cost Estimation
Models. Communications of the ACM, [S.l.], v.30, n.3, 1987.
[KOL 93] KOLODNER, J. Case Based Reasoning. San Mateo, Califrnia: Morgan
107
Kaufmann, 1993.
[KRA 97] KRAMPE, Dirk. LUSTI, Markus. Case-Based Reasoning for Information
System Design. [S.l.:s.n], 1997.
[MAD 97] MADACHY, Raymond J. Heuristic Risk Assessment Using Cost Factors.
IEEE Software, New York, v.13, n.4, May/June 1997.
[MAF 92] MAFFEO, Bruno. Engenharia de Software e Especificao de Sistemas. Rio
de Janeiro: Campus, 1992.
[MAT 94] MATSON, Jack E; BARRETT, Bruce E; MELLICHAMP, Joseph M. Software
Development Cost Estimation Using Function Points. IEEE Transactions on
Software Engineering, [S.l.], v.20, n.4, April 1994.
[MAX 2000] MAXWELL, Katrina D. FORSELIUN, Pekka. Benchmarking Software
Development Productivity. IEEE Software, New York, Jan./Feb. 2000.
[MAX 99] MAXWELL, Katrina; WASSENHOVE Luk Van, DUTTA Soumitra
Perfomance Evaluation of General and Company Specific Models in Software
Development Effort Estimation. Management Science, [S.l.], v.45, n.6, June
1999.
[PIL 97] PILLAI, K; SUKUMARAN, Nair A Model for Software Development Effort
and Cost Estimation. IEEE Transactions on Software Engineering, [S.l.],
v.23, n.5, May 1997.
[PRE 95] PRESSMAN, Roger S. Engenharia de Software 3.ed. So Paulo: Makron
Books, 1995.
[PRE 97] PRESSMAN, Roger S. Software Engineering 4.ed. New York: McGraw-Hill,
1997.
[PUT 78] PUTNAM, Lawrence H. A General Empirical Solution to the Macro Software
Sizing and Estimating Problem. IEEE Transactions on Software Engineering,
[S.l.] v.4, n.4, June 1978.
[ROT 99] ROTHENBERGER, Marcus A; HERSHAUER, James A software reuse
measure: Monitoring an enterprise-level model driven development process.
Information & Management [S.l.], v. 35 , May 1999.
[RUB 2000] RUBIN, Howard. The mutiple Dimensions of Metrics: Metrics and the
learning Organization. 1998. Disponvel em:
<http://www.cutter.com/itms/itms0002.html> Acesso em: out. 2000.
[SAK 98] SAKTHIVEL, Sachi. A Comparative Study of Two non-sloc Methods to
Estimate System Development Effort. Disponvel em:
<http://www.sbaer.uca.edu/docs/procedingsII/98dsi0840.htm> Acesso em: set.
2000.
[SEL 96] SELLERS, Henderson. Object Oriented Metrics: Measures of Complexity.
New Jersey: Prentice Hall, 1996.
[SIL 97] SILVA, Djalma D. Uma proposta de Verso e Ferramenta do PSP para o
Domnio de Aplicaes Comercias. So Carlos: USP, 1998.
[SPC 2000] SOFTWARE PRODUCTIVITY CENTRE. Tools and Solutions for Software
Development. 2000. Disponvel em <http://www.spc.ca>. Acesso em: maio
2000.
[SPC 99] SOFTWARE PRODUCTIVITY CENTRE. Tools and Solutions for Software
Development. 1999. Disponvel em: <http://ww.spc.ca/about/index.html>
Acesso em: fev. 1999.
[TSO 99] TSOI, Ho L. The Usage of Estimating Tools for Software Project Development
A Survey Study. International Journal of the Computer, the internet and
management, [S.l.] v.7, n.2, May/Aug. 1999. Disponvel em:
<http://www.journal.au.edu/ijcim/may99/article2.html>. Acesso em: set. 2000.
108
[WEB 99] WEBER, Kival C.; ROCHA, Ana R. C Qualidade e Produtividade em
Software. 3.ed. So Paulo: Makron Books, 1999.
[WU 97] WU, Liming. The Comparison of the Software Cost Estimating Methods.
1997. Disponvel em:
<http://sern.ucalgary.ca/courses/seng/621/w97/wul/seng621_11.html> Acesso
em: fev. 1999.

Você também pode gostar