Upload
duongdieu
View
227
Download
2
Embed Size (px)
Citation preview
"
DESENVOLVIMENTO DE SISTEMAS:
UM ESTUDO SOBRE MEDIDAS
DE DESEMPENHO
GERALDO JORGE CAPUTO
TESE SUBMETIDA AO CORPO DOCENTE DO INSTITUTO DE POS-GRADUA(;:~O E
PESQUISA EM ADMINISTRA(;:~O DA UNIVERSIDADE FEDERAL DO RIO DE
JANEIRO, COPPEAD/UFRJ, COMO PARTE DOS REQUISITOS NECESSÁRIOS PARA
A OBTEN(;:AO DO GRAU DE MESTRE EM CI~NCIAS (M.Sc.).
APROVADA POR:
/ PROF.
RIO DE JANEIRO, RJ - BRASIL MAIO DE 1991
,
i i
CAPUTO, Geraldo Jorge
Desenvolvimento de Sistemas: Um Estudo Sobre
Medidas de Desempenho. Rio de Janeiro, 1991.
179 p., 29,7 em (COPPEAD/UFRJ, M.Se.
Admi ni straç13o, 1991).
Tese - Universidade Federal do Rio de Janeiro,
COPPEAD, Mestrado em Administraç13o.
1. Desenvolvimento de Sistemas I. COPPEAD
I L Ti tulo I I L Séri e
i i i
À minha esposa Eliane e à Ana
RacheI, Ana Cláudia e Ana Carolina,
com amor~ dedico este trabalho.
iv
AGRADECIMENTOS
Certamente inúmeras pessoas contribuíram para que eu
chegasse ao final desta importante etapa de minha vida. Agradeço,
portanto, a todos que, direta ou indiretamente, me apoiaram neste
trabal ho.
Aos professores Roberto Nogueira e Donaldo de Souza
Dias, pela criteriosa orientação e pelo apoio dado na elaboração
desta tese.
Aos amigos Paulo Gomberg e Jason Freitas Alves,
inestimável incentivo.
pelo
A todos os demais companheiros da EMBRATEL, pela valiosa
colaboraç,';\o na coleta de dados e na troca de experiências.
Aos companheiros de turma, especialmente, Abdalla,
Evandro, Fernando, Horácio e Meyer, qLle comigo trilharam o caminho
que leva um grupo de trabalho a se tornar um grupo de amigos.
Aos empregados da COPPEAD, cuja dedicação e simpatia em
muito facilitaram meu relacionamento com esta intituiç,';\o.
A EliaMe, por tudo.
v
Reswncl da tese apresentada à COF'PEAD/UFRJ como parte dos requi sitos para a obtençâo do grau de Mestre em Ciências (M.Sc.)
DESENVOLVIMENTO DE SISTEMAS:
UM ESTUDO SOBRE MEDIDAS
DE DESEMPENHO
GERALDO JORGE CAPUTO
MAIO - 1990
ORIENTADOR: PROF. DONALDO DE SOUZA DIAS
PROGRAMA: ADMINISTRAC/'\O
Esta pesquisa visa analisar comparativamente o comporta-
mento de medidas de desempenho quando submetidas a um ambiente de
desenvolvimento de sistemas de uma grande empresa estatal brasile-
ira.
Este estudo é de grande importência para os gerentes de
desenvolvimento e os analistas/programadores das equipes de desen-
volvimento, pois contribui para que o processo de desenvolvimento
de sistemas seja entendido com maior clareza, especialmente no que
diz respeito ao desempenho das equipes de desenvolvimento de sis-
temas.
vi
Foram testadas 8 maneiras diferentes de se medir o de-
sempenho no desenvolvimento de um sistema. A medida que apresen-
tOl.1 o maior grau de correI aç:go com o esforç:o real i zado no ambi ente
selecionado foi a gerada pela aplicaç:go, a posteriori,
COCOMO Intermediário.
do modelo
Sugere-se a aplicaç:go de pesquisas similares em outros
ambientes, confrontando os modelos deste estudo, além de outros,
objetivando enriquecer o conhecimento sobre o desempenho no desen
volvimento de sistemas e os fatores que efetivamente o influen
ciam ..
vii
Abstract Df the thesis presented to COPPEAD/UFRJ as part Df the requiriments for the Master Degree in Science (M.Sc.)
SVSTEMS DEVELOPMENT:
A STUDV ON PERFORMANCE
MEASURE
GERALDO JORGE CAPUTO
1991, May
The purpose Df this research is to analize comparatively
performance measul'ing behaviors applied to a systems .development
environment in a large government company in Brazil.
The study is considered Df great importance for systems
development managers and their staff, as it contributes for a bet-
ter understanding Df staff performance in developing systems.
Eight diferent forms·of measuring the performance in
systems development were tested and the measure identified as the
one which showed the bigger correlation with the effort applied in
the selected environment was the one generated by the Intermedia-
te CaCOMO Model. This model was applied to 27 complete developed
systems.
viii
It is sugested the execution of similar research in
other environments, in order to confront the models of this study
and other models, with the objective of increasing the knowledge
about the performance in developing systems and the factors that
influence it.
SUMÁRIO
PAG.
CAPiTULO I INTRODUÇAO 001
CAPíTULO 11 REVISAO DE LITERATURA 007
1. ESCOLHA DOS MODELOS 008
2. ANÁLISE DE PONTOS DE FUNÇ~O 013
3. O MODELO CaCOMO 031
4. a MODELO BANG 069
5. LINHAS DE CÚDIGO FONTE 093
6. SíNTESE DOS MODELOS 101
CAPíTULO III - METOLOGIA DA PESQUISA 105
1- INTRODUÇ~O 106
., . .::. . PERGUNTA DA PESQUISA 108
3. HIPÚTESES E VARIÁVEIS 109
4. TESTE DE HIPúTESES 118
5. UNIDADE DE ANÁLISE 121
6. O PROCESSO DE COLETA DE DADOS 123
CAPíTULO IV RESULTADOS 126
1. RESULTADOS DESCRITIVOS 127
2. TESTE DE HIPúTESES 146
CAPiTULO V CONCLUS5ES 153
BIBLIOGRAFIA 160
ANEXO 1 166
ANEXO 2 171
FIGURA 11.1
FIGURA 11.2
FIGURA I r. 3
FIGURA IV.l
FIGURA IV.2
FIGURA IV.3
FIGURA IV.4
FIGURA IV.5
FIGURA IV.6
FIGURA IV.7
FIGURA IV.8
FIGURA IV.9
FIGURA IV.l0
FIGURA IV.l1
FIGURA IV.12
LISTA DE FIGURAS
Modelo Cascata do Ciclo de Vida de um Sistema
Modelo Composto de Requisistos
Aplicação da Regra de Partição Uniforme
Distribuiçgo dos projetos por área responsável
Distribuiçgo dos projetos por linguagem de programação utilizada
Distribuição dos projetos por modo de desenvolvimento
Homem-Mes Real por projeto
Homem-Mes Nominal por projeto
Homem-Mes Ajustado por projeto
Homem-Mes Nominal corrigido por projeto
Homem-Mes Ajustado corrigido por projeto
Total de linhas de código fonte por projeto
Total corrigido de linhas de código fonte por projeto
Pontos de Função por projeto
BANGDADOS por projeto
PAG.
034
073
084
134
135
136
137
138
139
140
141
142
143
144
145
QUADRO 11.1
QUADRO 11.2
QUADRO I1.3
QUADRO I 1.4
QUADRO II.5
QUADRO I 1.6
QUADRO 11.7
QUADRO I 1.8
QUADRO I 1.9
QUADRO lI. 10
QUADRO 11.11
QUADRO 11.12
QUADRO 11.13
QUADRO II.14
QUADRO IV.1
QUADRO IV.2
QUADRO IV.3
xi
LISTA DE QUADROS
Contagem de PONTOS DE FUNÇAO n,l,lo ajustados
Fator de Complexidade Técnica
Nível da Funçâo de Processamento para o Tipo de Entrada Externa
Nível da FL\nÇ,l,lO de Processamento para o Tipo de Saída Externa
Nível da Funç,l,lo de Processamento para o Arquivo Interno Lógico
Nível da Funç,l,lo de Processamento para Arquivo de Interfaces Externos
Nível da Funç,l,lo de Processamento para o Tipo de Consulta Externa
Características qLle distinguem os modos de desenvolvimento de software
Multiplicadores de esforço no desenvolvimento de software
Distribuiç,l,lo, por fase, do esforço e do prazo no Modo Orgânico
Distribuiç,l,lo, por fase, do esforço e do prazo no Modo Difuso
Distribuiçâo, por fase, do esforço e do prazo no Modo Restrito
Algoritmo de cálculo do BANG para sistemas orientados para funç5es
Algoritmo de cálculo do BANG para sistemas orientados para dados
Características gerais dos projetos
Características específicas dos projetos
Resultados das regress5es lineares
PAG.
015
017
019
(121
022
024
026
043
062
066
067
068
091
092
130
133
148
TABELA 11.1
TABELA I 1.2
TABELA 11.3
TABELA 11.4
TABELA 11.5
TABELA 11.6
TABELA II. 7
TABELA 1 1.8
Hii
LISTA DE TABELAS
Equaç5es de estimativa nominal do esforço no COCOMO Intermediário
Equaç5es para estimativa do prazo de desenvolvimento
Os seis primitivos do modelo de especificação
Ponderação de dados para correção do tamanho de primitivos funcionais
Fatores de ponderação de comple><idade por categoria do primitivo
Ponderação dos relacionamentos dos objetos
Linguagens selecionadas e seus níveis de PONTOS DE FUNÇAO
Características dos modelos escolhidos
PAG.
061
063
077
086
089
090
097
104
CAP1TULO I
INTRDDUÇAD
.2.
CAPíTULO I INTRODUÇ/,\O
A comunidade de processamento de dados, principalmente
seus gerentes, tem dado crescente atenç:âo ao pl"ocesso de desenvol
vimento de sistemas devido ao constante aumento do custo de soft-
Este custo tem aumentado tanto em termos absolutos como
percentual mente em relaç:âo ao orç:amento total de processamento de
dados, conforme observado por Kemerer [1987J.
Boehm e Papaccio [1988] apontam a tend~ncia crescente do
custo associado ao desenvolvimento de software, tanto nos Estados
Unidos da América como em todo o mundo. Eles ressaltam que em
1980 havia entre 900.000 e 1.000.000 de pessoas nos EUA trabalhan
do com software e custando, anualmente, US$ 40 bilh5es (2% do Pro-
duto Nacional Bruto americano). Além disso, estimativas recentes
indicam a taxa de crescimento de pessoal em aproximadamente 7% ao
ano e a de custo total do software em torno de 12% ao ano EFisher,
1974; Jones, 1983; Lieblein, 1985J. Usando estes valores, Boehm e
Papaccio conclu:íram que em 1990 deveria ser gasto, somente nos
EUA, cerca de US$ 125 bilh5es no desenvolvimento de software, "va
lor suficientemente grande para merecer esforços visando um maior
entendimento e controle do processo de desenvolvimento de softwa-
As técnicas da engenharia de software procuram reverter
esta tend~ncia. Para tanto, existe, hoje, um grande i.nteresse no
estudo e aplicaç:âo de medidas que possibilitem quantificar diver
sos aspectos relacionados ao desenvolvimento de sistemas.
.3.
Do ponto de vista pragmático, o estudo sobre medidas de
desempenho no desenvolvimento de sistemas é importante pelas se
guintes raz5es: primeiro, para estimar o esforço (conseqüentemente
o custo) de se desenvolver um sistema e, segundo, para aumentar o
desempenho no desenvolvimento dos sistemas, uma vez que vários fa
tores relacionados ao desempenho estar80 sendo controlados.
No presente trabalho, o termo "desempenho no desenvolvi
mento de software" refere-se à relaçâo existente entre o tamanho
do software prodclzido e o esforço humano necessário para produzí
lo. Deste modo, o entendimento desta relaçâo depende do estabele
cimento de métricas que possam medir tanto o tamanho do software
quanto o esforço para desenvolvê-lo. AI guns autores, como AI-
brecht (1979,1984], Boehm (1988], Conte (1986), Drummond ( 1985],
Jeffery (1987] e Pressman (1987], utilizam a palavra ·produtivida
de" para indicar esta relaçâo.
Pressman (1987) aponta cinco raz5es pelas quais um soft-
ware é mensurado:
para indicar a qualidade do produto;
para determinar a produtividade das pessoas que desen
volvem o produto;
para determinar os benefícios (em termos de produtivi
dade e qualidade) derivados dos novos métodos e fel"ra
mentas da engenharia de software;
para formar uma base de informaç5es para as estimati-
vas e
.4.
para ajudar a justificar as necessidades de novas fer
ramentas ou de treinamento adicional.
Segundo Kemerer [1987J, os custos, sempre crescentes,
associados ao desenvolvimento de software, têm direcionado os pes
quisadores no sentido de obterem melhor entendimento sobre o pro
cesso de desenvolvimento, bem como de construirem e avaliarem fer
ramentas de estimativa de custos de software.
o interesse sobre métricas relacionadas ao desenvolvi-
mento de software n~o é recente. COté et alli [1988J apontam o
artigo "Quantitative measLlrement of program quality", de RLlbney e
Hartwick [1968J, como o mais antigo a tratar do assunto, sendo que
os fundamentos para a métrica de software foram estabelecidos na
década de 70. A partir destes fundamentos, muitos outros resulta-
dos se obtiveram nos anos 80. Ramamoorthy et alli [1986J explicam
como as métricas de software assumir~o um papel importante nas fu
turas metodologias de desenvolvimento.
Basili e Zelkowitz [1978J definiram cinco importantes
fatOres que influenciam o desempenho no desenvolvimento de um
software:
- Fatores pessoais o tamanho e a experiência da
organizaçgo que desenvolve o
softwõ\re.
.5.
- Fato~es do p~oblema
- Fato~es do p~ocesso
- Fato~es do p~oduto
a complexidade do p~oblema a
se~ ~esolvido e o núme~o de mu
danças nos ~equisitos e ~est~i
ç5es do p~ojeto.
as técnicas de análise e de
p~ojeto utilizadas, linguagens
disponíveis e p~ocedimentos de
~evisgo.
confiabilidade e desempenho do
sistema desenvolvido.
- Fato~es dos ~eCu~SOs - disponibilidade de fe~~amentas
pa~a desenvolvimento e de re
cursos de ha~dwa~e e de softwa-
~e.
A p~eocupaç.o de tantos pesquisado~es com ~espeito ao
processo de desenvolvimento e aos fato~es que decididamente afetam
o desempenho associado a este p~ocesso enfati~a a crescente impor
tancia dada ao estudo das medidas de desempenho.
Foi escolhido um contexto específico pa~a se~em avalia
dos alguns modelos que implementa~am mét~icas de desempenho, vi
sando dete~mina~ qual delas melho~ se co~~elaciona com o esfo~ço
de desenvolvimento no ~efe~ido contexto.
o ambiente de desenvolvimento que serviu de base pa~a
este estudo ele caso localizou-se na Emp~esa Brasileira de Teleco-
.6.
munica<;5es S/A EMBRATEL, que colocou à disposi<;go as informa-
<;5es sobre os vários projetos que constituiram a pesquisa, bem co
mo os profissionais a eles ligados.
Neste ambiente, selecionaram-se 27 sistemas e sobre eles
foram aplicadas 8 maneiras de medir desempenho no desenvolvimento
de sistemas baseadas nos modelos Pontos de Fun<;go [Albrecht,
1979J, COCOMO [Boehm, 1981J, BANG [DeMarco, 1982) e em Linhas de
Código Fonte.
Pretendeu-se, desta forma, contribuir ngo SÓ com o en
tendimento sobre a implementa<;Bo de métricas de software, mas tam
bém com o conhecimento adquirido sobre as próprias métricas, dando
maiores condi<;5es gerenciais de planejamento e controle do proces
so de desenvolvimento.
.7.
CAP:f.TULD Ir
REVISAO DE LITERATURA
.8.
1. A ESCOLHA DOS MODELOS
O estado da arte na pesquisa de modelos qLle implementam
medidas de desempenho no desenvolvimento de sistemas e no estudo
dos fatores que influenciam tal atividade é discutido por Kemerer
[1987J, Abdel-Hamed e Madnick [1987J, Adrangi e Harrisson [1987J,
Tom Gilb [1986J, Jeffery [1987J, Boehm e Papaccio [1988J, e Lind e
Vairavam [1989J. Muitos destes estudos foram realizados na forma
de pesquisa de campo.
Pressman [1987J estabelece a seguinte categoriza~.o para
as diversas métricas existentes:
métricas de produtividade que focalizam a eficiência
do processo de engenharia de software;
métricas de qualidade fornecendo uma indica~:3o de qLI:30
próximo o projeto chegou em rela~.o aos requisitos do
Llsuário, implicitos e eHplícitos;
métri cas técni cas qLle observam mai s as caracter í st i cas
do software (por exemplo: compleHidade lógica, grau de
modularidade) qLle o processo de desenvolvimento do
mesmo;
ffi?tricas orientadas para o tamanho, utilizadas na co-
leta de medidas diretas dos produtos ("output")
qualidade da engenharia de software;
e da
métricas orientadas parca a funç;â\o, .que podem s.er , .. con-
sideradas medidas indiretas e
métricas orientffi\das para os aspectos humanos, as quais
recolhem as informaç;5es sobre o modo de desenvolvimen-
.9.
to utilizado pelas pessoas e as percepçôes humanas da
efetividade das ferramentas e métodos que lhes s~o co
locados à disposiç~o.
No livro "PrincipIes of Productive Software Management",
Evans, Piazza e Dolkas [1983] destacam a grande qc\antidade de fa
tores que podem influenciar no desempenho relativamente ao desen-
volvimento de software. Estes fatores s§o agregados em três gru-
pos, enfatizando que o processo de desenvolvimento de um software
é altamente sensivel
sendo desenvolvido.
ao ambiente total no qual o software está
Apesar de considerarem que podem existir cen-
tenas de itens envolvidos neste processo, eles apresentam alguns
fatores mostrando a realidade complexa relacionada ao desempenho:
Ambiente Técnico
metodologia do projeto
técnicas e ferramentas do projeto
requisitos de confiabilidade
requisitos de desempenho
interface da aplicaç~o
ambiente do usuário
ambiente de hardware
requisitos de teste
habilidade de desenvolvimento
definiç§o dos requisitos
definiç~o das interfaces
complexidade da aplicaç§o
• 1 (I.
Ambiente do Pr"ojeto
ambiente de apoio (suporte)
estrutura do projeto
fluxo de trabalho
demonstra~.o das tarefas
espírito de solidariedade
controle do projeto
objetivo do projeto
desenvolvimento do projeto
interpreta~.o das tarefas
desenvolvimento da gerência
lIover-head" técnico
Motiva~.o do pessoal
objetivos
eficiência
satisfa~.o
apoio ao projeto
interesse
comprometimento
mo·ti va~.o
Os estLldos já citados conduzem a um grande número de fa
tores relacionados com o desempenho no desenvolvimento de siste-
mas. A identifica~go de tantos fatores que influenciam no desem-
penho das equipes de desenvolvimento de sistemas dificulta a aná
lise estatística e conseqUente interpreta~.o dos resultados, LIma
vez que vários destes fatores freqUentemente est.o correlac:iona-
.11.
dos.
Adicionalmente, a maioria dos pesquisadores sugere que
os fatores considerados nos modelos que medem o desempenho no de
senvolvimento de sistemas sejam ajustados, de modo a refletirem,
com maior precisâo, o ambiente de desenvolvimento de sistemas na
empresa [Symons, 1988; Dummond, 1985 , DeMarco, 1982J.
A e,;colha dos modelos utilizados nesta pesquisa, além da
relevAncia apontada por citações de diversos autores de artigos
e/ou 1 i vros, cDnsi der·Du a di versi dade dos fatores que influenciam
o desempenho. Deste modo, foram selecionados modelos que tratam
de di fel"entes fatores na composi çâo desta i nf I LI I!!n c i a e qLle tem
servido de base para e5tudos realizados nesta área, visando a me
l hor compreensâo destes f atores e de como el es I"ef 1 etem o desempe
nho do pessoal de desenvolvimento de sistemas.
Assim sendo, os modelos Análise de Pontos ge Funçâo.(Al-
brecht, 1979J e COCO MO ICOnstructive COst MOdel) [Boehm, 1981 J,
considerados como modelos clássicos por Côté et alli [1988J, foram
dois dos escolhidos. A métrica apresentada no Modelo de Análise
de Pontos de Funçâo, além da contagem dos pontos de funçâo, consi
dera 14 características para estabelecer o Fator de complexidade
técnica (FCTI imposto sobre a equipe de desenvolvimento. Já no Mo
delo COCOMO sâo anal i sados 15 Atri butos Di rec i onadores de CLlsto,
os quais sâo diferentes dos refel"enciados pelos Pontt,s de Funl;;Ao.
o terceiro Modelo selecionado foi o proposto por Tom DeMarco
[1982J e denominado, genericamente, de BANG (decorrente da e){pres-
.12.
sgo "Bang per Buck"l. Na utilizaçgo de tal modelo considerou-se
como premissa o fato de todos os projetos constituintes do estudo
serem orientados para dados, uma vez que pertencem ao grupamento
de sistemas de apoio à gestgo das atividades da empresa. Esta pre
missa balisou a utilizaçgo especifica da métrica BANGDADOS para
sistemas orientados para dados.
Finalmente, incluiram-se nesta pesquisa os resultados
oriundos da avaliaçgo dos sistemas a partir do nOmero de Linhas de
Código Fonte (LCFI. Tal medida, apesar de n.o se constituir em um
modelo isoladamente, tem servido de base para diversos modelos e é
considerada uma das medidas de software mais familiares dentre as
existentes [Conte, 1986].
· 13. '.
2. ANÁLISE DE PONTOS DE FUNCAO
A medida desenvolvida por Albrecht [1979], utilizando
PONTOS DE FUNCf.\O ("Function Points"ou PF), foi apresentada em ou
tubro de 1979 no GUIDE/SHARE MEETING, em Monterey, na CalifÓrnia.
Albrecht concluiu que para medir produtividade em um
sistema seria necessário definir e medir um produto e um custo. O
produto foi analisado como o valor da função entregue ao usuário.
O número de entradas, consultas, saídas, arquivos internos e ar-
qui vos de interface entregues foram contados, ponderados, somados
e ajustados segundo a comple:ddade de cada projeto. O objetivo
era desenvolver uma medida relativa do valor da função entregue ao
usário, que fosse independente da tecnologia usada. O custo base-
aLI-se no número de horas trabalhadas ("work-hours") no projeto, em
todas as fases, tanto pelo pessoal da IBM, quanto pelo pessoal dos
cl i en'tes.
SeLI trabalho, em conjunto com Gaffney [Albrecht, 1983],
apresenta três razôes que apoiam a utilização de PONTOS DE FUNÇf.\O
como uma medida do esforço de desenvolvimento, a saber:
(a) o cálculo dos pontos pode ser desenvolvido com rela
tiva facilidade em discussôes com o usuário/cliente;
(b) a informação necessária para a medida está disponí
vel no início do processo de desenvolvimento, uma
vez que o estabelecimento dos requisitos básicos in
clui a identificação da. entradas utilizadas e das
saídas produzidas por uma aplicação, do ponto de
2.1.
. 14.
vista externo do Llsuário;
(c) e o fato de que os PONTOS DE FUN(;:/,\O podem ser apli
cados como uma medida geral de produtividade de de
senvolvimento (por e>,emplo: "PONTOS DE FUN(;:/,\O por
Homem-mes" ou "Homem-hora por PONTOS DE FUN(;:/,\O"), a
qual pode ser Llsada na demonstraçgo de tendências de
produti vi dade.
DESCRICAO DO M~TODO
Symons [1988J, em sua análise sobre o método de PONTOS
DE FUNCI'\O, apresenta esta medida de maneira bastante simples e
clara, como se segue:
"No método de PONTOS DE FUNCI'\O, os dois componentes re
lativos ao tamanho intrínseco de um sistema sgo calcula
dos da seguinte forma:
1) O Tamanho do Processamento da Informação é determina
do pela identificação inicial dos componentes do sis-
tema, do ponto de vista do usuário final, e pela
classificação destes componentes em um dos 5 tipos, a
saber: entradas, saídas, consultas externas ou lógi
cas, i nterf aces ex ternas com outros si stemase ar qLIi--
vos internos lógicos. Cada componente é, entgo,
cl assi f i r.:ado como IIsi mpl es", II médi 0" OLt "compl e>~o'll ~
dependendo do nómero de elementos de dados, em cada
tipo além de outros fatores, a serem detalhados pos-
teriormente. Em seguida, dá-se a cada componente um
•
.. 15 ..
nómero de pontos referente a seu tipo e complexidade
(QUADRO 11.1), calcLllando-se, entt;!o, a soma dos pon-
tos de todos os componentes, ou sej a, "Pontos de FLm-
(UnadjLlsted Function Points ou
PFNA's).
QUADRO 11. 1
Contagem de PONTOS DE FUNCAO nao ajustados
Nível da funç:t;!o
Descriç:t;!o Simples Médio Complexo Total
Entrada externa -- >: 3 -- x 4 -- x 6 ----
Satda externa -- x 4 -- x 5 -- }: 7 --~_.
Arquivo lógico interno -- x 7 -- x 10 -- }: 15 ----
Arquivo de interface e>:terno -- x 5 -- x 7 -- >: 10 ____ M
Consulta e>:terna -- >: 3 -- }: 4 -- >: 6 ---- 1 ,
Total de PONTOS DE FUN(;j:\O N:;\o Ajustados ----
fonte: rSymons, 1988J
2) O "Fator de Complexidade Técnica" (Technical Comple-
xity Factor ou FCT> é determinado a partir da estima-
tiva do "Grau de Influência" (Degree Df InflLlence ou
GI) de algumas das 14 "Características Gerais da
Apl i caç:âo" (QUADRO 11. 2) . A escala do grau de in-
\
• 16.
fluência varia de zero (ausente ou não influente) a
cinco (fortemente influente em todo o tempo).
dos valores das 14 características, ou seja,
A soma
o GraL'
de InflL,ência Total lTotal Degree of Influence OL'
GITI, é utilizado no cálculo do FCT através da se
guinte fórmula:
FCT = 0,65 + 0,01 x BIT
Deste modo, cada grau de influência vale um por cento
(1/1001 de um FCT, o qual pode variar entre 0,65 e
1,35 ..
31 O tamanho relativo intrínseco do sistema, em termos
de PONTOS DE FUNC:!,\O (PF'sl, calcula-se pela e>:pres
são:
PF's = PFNA's x FCT
Fica claro que os PONTOS DE FUNC:!,\O são números sem
dimens5es, pertencentes a uma escala arbitrária."
+
• 17.
QUADRO 11.2
Fator de Complexidade Técnica
Gr- aLl de Ident. Car-acter-1stica Influêndia
(GI>
Cl ComLtni ceç:go de dados - ..... ------C2 Funç:ôes distr-ibuídas --------C3 Desempenho --------C4 Configur-aç:go usada pesadamente --------C5 Ta>:a de tr-ansaç:ôes --------C6 Entr-ada de dados lIon-line ll --------. C7 Efi ci ênci a do usuár-io final .""'------- ..... C8 AtLlal i z aç:go lIon-line ll . ---_....:._--C9 Pr-ocessamento complexo --------CiO Reapr-oveitamento --------Cll Facilidade de i nstal ecoªo --------C12 Facilidade de oper-ac;;go -------- .~. -,',
C13 "Si tes l1 múltiplos --------C14 Mudanc;;as faci 1 i tadas --------
Gr-au de influência t.otal (BIT) --------
Valor-es par-a GI:
(> = ausente ou sem inflLlência 1 = influência insignificante 2 = influência moder-ada 3 = inflLlência média 4 = influência significativa 5 = forte influência, todo o tempo
FCT = 0,65 + 0,01 x GIT
fonte: rSymons, 1988]
· 18.
2.2. FUNCOES DO USUARIO
A primeira etapa no cálculo dos PONTOS DE FUNÇAO compre
ende o estabelecimento das funç5es do usuário, classificando-as e
contando-as. Segundo Albrecht [1979 e 1984 J,
ponderadas de modo a ,'-efletir o valor da função para o usuário e
os pesos utilizados foram estabelecidos através de debates e expe-
rimentaçôes sucessivas. O QUADRO I I. 1 apresenta o resul·tado f i naI
obtido, no que concerne à ponderação de tais funç5es. Segue a de
finição de cada tipo de função a ser contada e seus respectivos
niveis de complexidade, além dos quadros de referência nos quais
Albrecht [1984J passou a classificar os níveis de complexidade da
função de processamento da informação usando as express5es BAIXO,
M~DIO e ALTO, correspondendo, respectivamente aos níveis SIMPLES,
M~DIO e COMPLEXO, apresentados em [Albrecht, 1983J:
1) Entradas externas - Contar cada tipo de dado ou de
controle do usuário provenientes do lado externo das
fronteiras da aplicaç.o que está sendo medida. Um
tipo de dado difere dos demais por seu formato ou pe
lo modo como é processado. Cada tipo de entrada ex
terna pode ser classificada em um dos seguintes nive
is de complexidade:
Baixo: poucos tipos de elementos de dados s.o in
cluídos no tipo de entrada externa, e pou
cos tipos de arquivos internos s.o referen
ciados pelo tipo de entrada externa. As
consideraç5es do usuário referentes aos fa-
· 19.
tores humanos ngo s&o significativas no
prOjeto destas entradas.
Médio: o tipo de entrada externa ngo claramente
definida como sendo simples ou complexa.
IH to: muitos tipos de elementos de dados sgo in-
cluídos no tipo de entrada eHterna~ e mui-
tos tipos de arquivos internos sgo refaren-
ciados pelo tipo de entrada externa. Neste
nível de comple>,idade, as considerações do
usuário a respeito dos fatores humanos afe-
tam significativamente o projeto dos tipos
de entradas externa.
QUADRO 11.3
Nível da Função de Processamento para o Tipo de Entrada Externa
N!'! de El emant.os de Dados N!'! de
Arquivos Referenciados 1 a 4 5 a 15 16 o~\ mais
O ou 1 Baixo Bai }'O Médio
2 Bai>,o Médio Alto
~
-' ou mais Médio Alto Alto
Potencialmente, podem-se ter os seguintes tipos de en-
trada:
Documentos
Telas
.. 20.
Transa~5es em fitas
Transaç5es em disquetes
Transa~5es de outro sistema
Sensor digital
Sensor Analógico
Faixa (lista) magnética
Teclas "PF"
Canetas luminosas ("Light pen")
2) Saídas externas - Contar cada tipo de dado ou de con
trole que atravessa, de dentro para fora, a fronteira
da aplicaç~o sendo medida. Como no tipo de entradas
externas, este difere dos demais por seu formato ou
pela maneira como é processado. Devem ser incluídos
neste tipo os relatórios, mensagens e arquivos envia-
dos a outras aplicaç5es. No que diz respeito. com-
ple"idade, este tipo obedece aos mesmos critérios
apresentados para ° tipo de entrada externa. Para os
relatórios, as seguintes consideraç5es adicionais po
dem ser usadas:
Baixo: uma ou duas colunas~ com tr'ansformaç5es
simples de elementos de dados.
Médio: múltiplas colunas com sLlbtotais e transfor
mações multiplas em elementos de dados.
IH to: transforma~5es intrincadas de elementos de
dados, ai ém de )"eferênci as a arqui vos múl
tiplos e comple"os a serem correlacionadas.
Consideraç5es significativas de desempenho.
.21.
QUADRO II.4
Nível da Função de Processamento para o Tipo de Saída Externa
N9 de Elementos de Dados N9 de
Al"'qllivos -Refe..-enc i ado;;~ 1 a 5- 6 a 19 20 ou mais
O ou 1 Bai>:o Baixo Médio
2 ou ~
'-' Bai>:o Médio Alto
r" 4 ou mais Médio Alto Alto
Podem-se aponta..- os seguintes ítens como sendo tipos po-
tenciais de saída:
Relató..-io em tela
Rel,.tó..-io em te..-minal
- Relató..-io "batch"
T..-ansaçgo de fita
- T..-ansaçgo de disquete
T..-ansaçgo de fita de papel
- Mensagem em tela
- T..-ansacao de out..-a aplicaçao
L.inha digital
- Acionado..- digital
Acionador analógico
Faixa (listal magnética
- Documentos gerados
3) A'-guivps internos lógicos - Contar os principais gru-
pos lógicos de informaç5es de dados e de controles,
do ponto de vista do usuário, na aplicaç.o. Devem ser
contados os arquivos, como descritos no projeto ex-
terno e não os arquivos fisicos. No que diz respeito
à comple}:idade, os arquivos podem ser classificados
como!
Baixo: poucos tipos de registros, poucos tipos de
elementos de dados e sem consideraç5es re-
levantes acerca de desempenho e recupera-
ç:~o ..
Médio: o tipo de arquivo interno lógico nao está
claramente categorizado como simples ou
compl e}:o.
IH to: muitos tipos de registros, muitos tipos de
elementos de dados e consideraçBes relevan-
tes sobre desempenho e recuperaç80u
QUADRO II.5
Nivel da Função de Processamento para Arquivo Interno Lógico
""",""'---- _.'--- , ..... -Ne de Elementos de Dados
Ne de Tipos de Registros 1 a 19 20 a 50 51 ou mais
1 Bai):o Bai }:o Médio
2 a 5 Bai }:o Médio Alto
6 ou mais Médio Alto Alto
Potenciais tipos de arquivos lógicos:
Arquivos lógicos internos
Bancos de dados
Tabelas de usuário
Arqui vos OLI tabel as de mensagens
Arquivos de controle de processamento sequen-
cial IIbatch"
Arquivos para "Query" de usuários
4) Arquivos de interfaces externas - Arquivos passados
ou compartilhados entre aplica~Bes devem ser contados
em cada uma das aplica~Bes. Contar cada grupo lógico
de informa~Bes de dados e de controles, do ponto de
vista do usuário, que entra ou sai da aplica~go, como
um tipo de arquivo de interface externa. Estes arqui-
vos devem ser classificados nos três níveis de com-
plexidade usando defini~Bes similares às dos arquivos
internos lógicos (ítem anterior"). Os arqLlivos gerados
internamente e enviados para outra aplica~go devem
ser contados duas vezes: como arquivos internos 1Ó9i-
cos e como arquivos de interfaces e>:ternas.
.24.
QUADRO Il.6
Nível da Funçgo de P~ocessamento pa~a A~qLlivo de Inte~faces Exte~nos
N2 de Elementos de Dados NSl de
Tipos de Registr-os 1 a 19 20 a 50 51·ou mais
1 Bai >'0 Bai ><0 Médio
2 a 5 Bai >'0 Médio Alto
6 OLt mais Médio Alto Alto
Têm-se, potencialmente, os seguintes tipos de arqL\ivos
de interfaces exter-nas:
Ar-quivo lógico inter-no acessável de outr-o sis-
tema
Ar-quivo lógico interno acessável por- outro
sistema
Bancos de dados compar-tilhados
5) Consultas externas ("Inquir-y") - Contar cada combina-
çBo única de entr-ada/saída, onde uma entrada gera LIma
saída imediata, como um tipo de consulta externa. Um
tipo de consulta deve ser- considerado único, caso te-
nha um for-mato diferente dos outr-os tipos de consul-
tas, quer- na entr-ada quer- na saída, ou ainda se ele
exige LIma lógica de pr-ocessamento diferente da e><igi-
da por- um tipo do mesmo for-mato. No que diz r-espeito
ao nível de complexidade de cada consulta, conside-
ram-se os niveis de complexidade da entrada e da sa1-
da, sendo escolhido o maior dos niveis como o do tipo
de consulta externa. A distinçlo entre um tipo de
consulta externa e um tipo de entrada externa pode
ser feita considerando-se que o dado de entrada de um
tipo de consulta externa serve apenas para orientar
uma pesquisa (consulta) e nlo para atualizar um ar-
quivo interno lógico. Nlo se deve confundir, também,
um tipo de consulta externa com uma facilidade de
"QUERY" que contempla toda uma estrutura organizada
de tipos de entrada, saida e de consulta, compondo um
grande conjunto de possíveis consultas através de vá-
rias operaç5es. O tipo de consulta externa é uma pes-
quisa direta a um dado especifico, geralmente usando
somente uma tecla.
.. 26.
QUADRO lI.7
Nível da Função de Processamento para o Tipo de Consulta Externa
UlnquiryU
Parte de Entrada
N2 de Elementos de Dados N2 de
Arquivos Referenciados 1 a 4 5 a 15 16 aLI mais
(I aLI 1 Bai }:o Bai }(o Médio
2 Bai>:o l'1édi o Alto
-" 7
-' ou mais I"lédio Alto Alto
Parte de Saída
N9 de ElementDs de Dados N9 de
Arquivos Referenciados 1 a 5 6 a 19 20 ou mais
O ou 1 Baixo Bai >:0 MédiD
~ aLI - Bai )(0 Médio Alto .L "
"
4 ou mais Médio Alto Alto
,; ,
.. 27.
Potencialmente, têm-se os seguintes tipos de consulta
e>,terna:
Consulta do usuério sem nenhuma atualiza~ão de
arqui '10
Telas e mensagens de auxílio ("Help"l
Telas de menu de seleção
2.3. COMPLEXIDADE DO PROCESSAMENTO
A comple>:idade do procesamento ou o "fator de comple,:i-
dade técnica", como denominou Symons [1988J ou, ainda, a Função
Geral de Processamento da Informação, conforme Albrecht [1984J,
em uma aplic~,~ão, depende da estimativa do grau de influência das
14 características gerais sobre a referida aplicação.
Cada característica geral recebe um valor, com relaç,\\o
ao seu grau de influência, conforme a seguinte lista:
o N,\\o presente ou, em Cl::\50 de pr-esenç;;a, nli.\o in-
fluente
1 Influência insuficiente
2 Influência moderada
"" -' Influência média
4 -- Influência significativa
5 Grande infIL\ência, em todo o projeto
Segue uma descricli.\o das 14 características utilizadas
por Albrecht na avaliaçgo da comple>:idade do processamento:
.28.
1) Comunicaçgo de dados - os dados e as informaç5es de
controle usadas na aplicacão sgo enviados e recebidos
utilizando facilidades de comunicações. Tais facili
dades também sAo consideradas para terminais conecta
dos localmente.
2) Funções distribuídas - fLtnções de processamento ou
dados distribuídos sAo uma característica da aplica
cAo.
3) Desempenho - objetivos de desempenho da aplicaçao, no
que concerne à resposta ou "throughput", afetam o
projeto, desenvolvimento,
aplicaçgo.
instalaçAo e suporte da
4) Configuraçgo usada pesadamente
operacional utilizada em demasia é uma característica
da apl icaç_o. O Llsuário quer e>:ecutar a apl icaçAo so
bre Llm equipamento existente ou reservado,o qual será
utilizado pesadamente.
5) Taxa de transaç5es - a taxa de transaç5es também in
fluencia o projeto, desenvolvimento, instalaçAo e O
suporte da aplicacAo.
6) Entrada de dados "on-line" - funç5es de controle e
entrada de dados "on-line" fornecidas na aplicacao.
.29.
7) Eficiéncia do usuário final - as funç;5es "on-line"
fornecidas enfatizam a eficiéncia do usuário final.
8) Atualizaç;ão "on-line" - a aplicacão fornece os proce-
dimentos de atualizaç;ão "on-line"
internos lógicos.
para os arquivos
9) Processamento comple:<o - esta característica pode sei'
e>:emplificada como se segue:
muitas interae5es de controle e pontos de decisgo
extensas equaç;5es matemáticas e lógicas
muito processamento de exceeão result~ndo em
saç;(jes i ncompl etas que devem ser pl'ocessadas
mente.
tran-
nova-
10) Reaproveitamento - a aplicacgo e o código usado na
aplicaç;ão têm sido especificamente projetados, de
senvolvidos e suportados de modo a Serem reutiliza
dos em outras aplicaç;5es e em outros "sites".
11) Facilidade de instalação - facilidade de conversgo e
de instalaeão sgo características da aplicacgo. Um
plano de conversão e de instalaego foi fornecido e
testado durante a fase de teste do sistema.
12) Facilidade de operaçgo procedimentos de "start-
.30.
up", "back-up" e> de> re>cupe>raç:âo foram forne>cidos e>
te>stados durante a fase de> teste do sistema. A apli
caç:go diminui a ne>cessidade de atividades manuais,
tais como: montar fitas e manipular formulários.
13) "Sites" múltiplos - a aplicaç:âo foi especificamente
proje>tada, de>senvolvida e suportada para se>r insta-
lada em múltiplos "sites" de 6rganizaç:ões múltiplas.
14) Mudanças facilitadas - a aplicaç:go foi especifica-
mente projetada, desenvolvida e suportada de> modo a
facilitar as mudanças, por e>xemplo:
foi fornecida uma capacidade> para consultas fle>x1-
veis;
foram grupadas, e>m tabe>las manute>n1veis pelo usuá
rio, as informaç:ões SUjeitas a mudanç:as.
.31.
3. O MODELO COCOMO
Em 1981, Bar-ry Boehm r 1981 J apresentou uma séri e de mo
delos de estimativas de softwares, aos quais deu o nome genérico
de COCOMO, sigla de "COnstructive COst MOdel". Segundo ele, COCOMO
é uma "hi erar qL.i a de três modelos, detal hados de forma crescente,
variando de um modelo escalar simples de macro-estimativa como
uma funç~o do tamanho do produto até um modelo de micro-estimativa
com uma estrutura analítica do trabalho em três níveis e com um
conjunto de multiplicadores sensíveis em relaç.o às fases
sensitivel para cada atributo que orienta os custos"
1984J.
3.1. AS VERSOES DO MODELO COCOMO
(phase
[Boehm,
o modelo COCOMO foi desenvolvido tendo como base uma
amostra de 63 projetos concluídos, pertencentes a Areas tais como:
negócios, controle, científica,suporte e sistema operacional. Ele
é apresentado em três vers5es:
aI Modelo COCOMO BAsico é um modelo estAtico de valor único que
calcula o esforço (e o custaI do desenvolvimento de software
como uma funç~o do tamanho dos programas. Este tamanho é ex
presso através do número de instruç5es fontes entregues (DSI
delivered source instructionsl.
bl Modelo COCOMO IntermediArio - calcula o esforço de desenvolvi-
.32.
mento de software como uma funcâo do tamanho dos programas e de
um COnjLtnto de fatores que incluem aspectos subjetivos do pro
duto, além de atributos do hardware, pessoal e do projeto.
c) Modelo COCOMO Detalhado - incorpora todas as caracteristicas da
versâo intermediária, com a determinacâo do impacto dos fatores
em cada passo do ciclo de vida de um sistema (análise, projeto,
etc) •
3.2. o CICLO DE VIDA
Um aspecto i mportante a ser consi del'·ado no modelo COCOMO
é o que diz respeito à definic.o das fases e atividades do ciclo
de vida de um sistema. Boehm reserva todo um capitulo ao tratamen-
to desta questâo e basei a seLI estudo no model a "casc:a"\:a ll (FIGURA
11.1), apresentado em sua versâo original por Royce [1970].
A partir dele, discutem-se várias alternativas e refina
mentos, incluindo os conceitos de desenvolvimento incrementaI, do
cumentacâo antecipada ("anticipatory documentacion") e andaimaria
de software ("software scaffolding").
No desenvolvimento incrementaI, o sistema é visto por
seus diversos módulos funcionais. o desenvolvimento do sistema
como um todo se dá a partir do incremento de cada módulo funcional
identificado, um a um.
A documentaçao antecipada consiste da preparaçao prévia
de partes da documentaç.o do sistema visando:
Definir os objetivos e planos detalhados para ativida-
des futuras no desenvolvimento do sistema (planos de
desenvolvimento, planos de teste, planos de conver-
sâo) ;
Produzir vers5es preliminares da documentaçao do usuá-
rio (por exemplo, um esboço do manual do usuário fica
disponível para revisao ao término da fase de Projeto
do Produto), dando a ele uma chance de verificar como
o sistema irá afetá-lo, em seus próprios termos, e fa-
cilitando as negociaç5es para as mudanças necessárias,
antes que estas se tornem muito dispendiosas.
o termo "soft.,are scaffolding" se r"efere aos prodL.tos
e>:tras que devem ser elaborados para permitir que o desenvolvimen-
to do sistema principal e sua verificaç.o/validaç.o ocorram t.o
fácil e eficientemente quanto possível. Estes produtos podem in-
cluir componentes "dummy" (vazios) do sistema, arquivos miniatu-
ras, ou outras partes simuladas do futuro ambiente operacional.
Adicionalmente, podem ser considerados os programas auxiliares ge-
radares de dados de teste, geradores de referência cruzada, con~
versares de dados e verificadores de padrees, dentre outros.
.34.
FIGURA II.l
Modelo Cascata do Ciclo de Vida de um Sistema
Vi abi li dade do Sisteaa
Plano5 e Requisitos do 50fhare
Projeto do Produto
Projeto Detalhado
Codi ficaç30
fonte: [Boehm, 1981 J
Integração
llplementaçao
Operaçao e "anutenç~o
As fases componentes do ciclo, confo~me abo~dado po~ Bo-
ehm, obedecem à segui n'te desc~i ç,ªo:
Viabilidade do sistema
Oefiniç,ªo p~elimina~ do escopo do sistema, dete~minan-
do sua viabilidade e supe~io~idade em ~elaç,ªo a con-
cepç8es alte~nativas.
Planos e requisitos do software
Especificaç,ªo completa e validade das funções, inte~-
faces e desempenho desejados pa~a o p~oduto de softwa-
re.
Projeto do produto
Especificaçlo completa e ve~ificada da estrutura geral
de ha~dware/software. da est~utu~a de controle e da
est~utura de dados para o p~oduto.
Projeto detalhado
Especificaçlo completa e verificada da estrutura de
cont~ole, est~utu~a de dados, ~elações de interface,
volumes, algo~itmos chaves e de cada componente de
programa (~otinas com até 100 instruções no código
fonte).
Codificação
Codificaçlo e teste dos p~ogramas individualmente.
3.3.
.36.
Integrac;:ão
Integraçgo dos componentes individuais do sistema.
Implementac;:ão
Implantação completa do sistema (hardware/software),
incluindo conversão de programas e dados, instalação e
treinamento.
Operacão e manutenc;:ão
Operação e atualização dos componentes do sistema.
OEFINICOES BÁSICAS DO COCOMO
Além do ciclo de vida, o método COCOMO apoia-se em algu
mas definiç:5es, como se segue:
1. O fator primário do método é o n6mero de instruç:5es
fontes entregues ("OSI - Del i vered So~.rce Instruc-
ti ons" l no desenvol vi mento de ~.m proj eto.
melhor, tem-se:
Detalhando
Entregues - Este termo não inclui os softwares de
apoio que não são entregues, tais como os utiliza
dos somente na fase de teste. Entretanto, se estes
são desenvolvidos com o mesmo cl..idado que um soft
ware entregue C"delivered"l, com suas próprias re
vis5es, planos de testes, documentaçgo, etc., então
.37.
devem ser considerados.
InstFuç5es fontes - Esta expFessgo inclui todas as
instFw;:5es de pFogFama cFiadas pelo pessoal do p,-o-
jeto e pFocessadas em código de máquina pOF alguma
combinaçâo de pFé-pFocessadoi"es, compiladoFes e
montadores. Ela exclui 0$ comentários e>:istentes
nos pFogFamas e inclui as linguagens de contFole
(JCL, WFL, etc), comandos de fOFmataçgo e declaFa
ç5es de dados.
InstFuç5es sgo definidas como linhas de códi
go, onde uma linha contendo duas ou mais de
claFaç5es fonte seFá contada como uma instFu
çgo. POF outFO lado, uma declaFaçgo de dados
com cinco linhas seFá contada como cinco ins
tFuç5es.
2. O peFíodo do desenvolvimento atingido pelas estimati
vas de custo do COCOMO começa no início da fase de
pFOjeto do pFoduto, após a validaçâo bem sucedida dos
planos e Fequisitos do softwaFe, e teFmina com a in
tegFaçgo e teste do sistema.
3. O COCOMO abFange somente a mâo-de-obFa diFeta empFe
gada em um pFOjeto.
4. Um HOMEM-MtS do COCOMO consiste de 152 hOFas de tempo
de tFabalho. PaFa conveFteF esta estimativa em ou-
tFas unidades, utilizaF as seguintes fÓFmulas:
3.4.
.. 38.
HOMEM--HORA = HOMEM-M~S x 152
HOMEM-D I A = HOMEM--MtS >, 19
HOMEM-ANO = HOMEM-MtS / 12
5. As estimativas COCOMO pressupBem que o projeto será
"bem gerenciado" tanto do lado do usuário como do la
do dos qL\e desenvol vem.
6. As especificaç:Bes dos requisitos ngo sergo alteradas
substancialmente após a fase de Planos e Requisitos
do Software.
7. A influência dos fatores de custo de L.m software é
dependente de cada fase do ciclo de vida.
MODOS DE DESENVOLVIMENTO
o modelo COCOMO parte da e>:i stênci a d .. di v .. rsos modos de
desenvolvim .. nto cUJos relacionamentos, do ponto de vista das esti
mativas de custo, assemelham-se em alguns aspectos, revelando, po
rém, .. stimativas de custo significativamente diferentes para pro-
dutos de software do mesmo tamanho. Boehm concentrou seLO estudo
em três modos, por ele considerados como os mais relevantes: modo
orgânico ("Organic Mode"), modo difuso ("Semidetached Mode") e mo-
do restrito ("Embedded Mode"). Os nomes dos modos, em português,
seguem o pad,c go apresentado por Fernandes e ~~ugl er [1989].
.39.
3.4.1. MODO ORGANICO
No modo orgânico, o desenvolviment.o se faz por equipes
relativamente pequenas e em um ambiente familiar. A e>:peri€mcia
da maioria das pessoas envolvidas no projeto é boa e está calcada
em p~ojetos simila~e5 na organização. Além disso, as pessoas têm
um completo entendimento de como o sistema em desenvolvimento con
tribuirá para os objetivos da empresa.
Uma vez que a maioria das pessoas engajadas no projeto
pode contribuir para o mesmo em seus estágios iniciais, minimiza-
se a sobrecarga de comunicaç:.';\o normalmente existente neste per:(o
do.
Um projeto do modo orgânico é relativamente flexível so
bre como o software atenderá às especificaç:ões dos requisitos e
das interfaces. o conheci mento da eqL.i pe de desenvol'/i mento per-
mite que sejam negociadas modificaç:ões nas espec~ficaç:5e., de modo
a que o desenvolvimento seja facilit~do. Esta é uma das razões
para a alta produtividade em projetos do modo orgânico.
Outros fatores car,3cterizam este modo, a saber:
Um ambiente de desenvolvimento geralmente estável, com
muito pouco desenvolvimento concorrente, associado a
novos procedimentos de hardware e operacionais.
Necessidade mínima de novas arquiteturas de processa
mento de dados ou novos ai gori t·mos.
·40.
Um prêmio relativamente baixo para o término do proje
to antes do prazo.
Tamanho do projeto relativamente pequeno. Pouqu1ssi-
mos projetos do modo orgAnico têm produtos desenvolvi
dos com mais de 50 KDSI (50.000 instruç5es fontes en-
tregues) de software novo. Muitos produtos neste mo-
do freqUentemente podem Ser desenvolvidos utilizando
se software já existente.
Estes fatores apresentam boa correlação com uma produti
vidade maior do projeto e com uma "deseconomia" de escala menor.
3.4.2. MODO RESTRITO
A principal característica que distingue um projeto de
software desenvolvido no modo restrito é a necessidade de operar
sob severas restri~8es. Restriç5es de software, hardware, regras
e procedimentos operac.ionais. Pode-se citar o sistema de transfe-
rência eletrenica de valores e o sistema de controle do tráfego
aéreo como e>:emplos de sistemas deste modo.
Em um projeto do modo restrito geralmente não se tem op
ção para negociar mudanças que o tornem mais simples, pela modifi
cação dos requisitos e da especificação de interfaces. ~ necessá
rio despender um grande esforço para assegurar que o software re
almente atenda às especificaç5es e que qualquer mudança exigida
seja executada corretamente. Estes fatores contribuem tanto para
•
.41.
uma baixa produtividade quanto para a falta de economia de escala
em projetos maiores.
Uma vez que o projeto neste modo caminha, geralmente,
por um terreno desconhecido e cuja e,(tenslilo é maior que a dos pro-
jetos no modo orgAnico, utili2a-se, nos estágios iniciais, uma pe-
quena equipe de analistas, de modo a minimizar os problemas de co-
municaçga ('Icommunications overhead"). Já na fase de projeto do
produto, a melhor estratégia é a de alocar um grande número de
programadores para a elaboraçlilo detalhada dos programas, codifica
çlilo e teste unitário em paralelo.
Em geral, a recompensa pelo término antecipado do siste
ma é muito maior em dec:or"l""ênc:ia de haver, freqUentemente, necessi
dade de operaçgo do complexo hardware-software tlilo logo seja pos
sível.
3.4.3. MODO DIFUSO
o modo difuso de desenvolvimento de sistemas representa
um estágio intermediário entre o modo orglnico e o restrito, si g--
nificando que tanto pode ser um nível intermediário das caracte
rísticas de projeto quanto uma mistura das características dos mo
dos orglnico • restrito.
Deste modo~ no que diz respeito à caracteristica qlAe in
dica a "e,·(peri~ncia em tr-abalhal~ com sistemas semelhantes", po-
~42.
dem-se ter as seguintes alternativas no modo difuso:
Todos 05 membros da equipe tem um nível
de e>:periência com sistemas 5emelhantes~
intermediário
A equipe tem uma mistura de pessoas com experiência e
outras sem experiência.
- Os membros da equipe têm experiência4
relativa a alguns
aspectos do sistema em desenvolvimento~ mas nâo a ou
tros.
Todas as características de projeto no modo
guem o mesmo comportamento.
difuso se-
o tamanho de um produto no modo difuso geralmente se es
tende até 300 KDSI.
.. 43.
3.4.4. SUMÁRIO DOS MODOS DE DESENVOLVIMENTO
As características dos modos de desenvolvimento podem
ser sL.marizadas na QUADRO 11.8, que apresenta os at.-ibL.tos que os
distinguem.
QUADRO 11.8
Características que distinguem os modos de desenvolvimento de software
Kodo
Car act er' sti c a Organico Difuso Restri to
Entendiaento de como o sisteea contribui· rá para os objetivos da Empresa Cor.pleto Consi derável Geral
Experiência e. trabalhar com si steeas se-melhantes E.tensa Considerável "oderada
Necessidade de ajustar o softoare cal re-quisitos pré-estabelecidos Básica Consi derAvel COlpleta
Necessidade de ajustar o softoare cal es-pecificaç6es e.ternas de interface Básica ConsiderAvel COlpleta
Desenvolvimento sieultAneo de procedimen-tos associados a novas operaç6es e a novo hard.are Algum Moderado E.tenso
Necessidade de algoritoos e de arquitetu-ras de processalento de dados inovadores Mínima Algu.a Considerável
Reco.pensa pelo término antecipado Bai.a "édia Alta
Variaç!o do ta.anho do produto < 50KDSI < 300 KDSI Todos 05
talanhos
fonte: [Boehm, 1981)
·44.
3.5. o MODELO COCOMO INTERMEDIARIO
Como descriç~o básica do modelo COCOMO, será utilizada a
do modelo COCO MO Intermediário, onde o cálculo do esforço de de
senvolvimento de software varia em funç~o n~o só do tamanho dos
programas mas também de um conjunto de fatores que incluem aspec
tos subjetivos do produto, além de atributos do harware, pessoal e
do projeto.
3.5.1 ATRIBUTOS DIRECIONADORES DE CUSTO NO COCOMO INTERMEDIARIO
De modo a reduzir o número de fatores candidatos a serem
atributos direcionadores de custo, tornando-os mais fáceis de se
rem utilizados na estimativa de custo de software, Boehm submeteu
os fatores candidatos a dois testes principais:
. Signific~ncia geral
Independência
este teste tenta eliminar fatores que
s~o significativos apenas em parcelas
relativamente pequenas de determinadas
situações, tais como o número de viagens
necessárias ao pessoal do projeto.
este teste tenta eliminar fatores qL,e
estejam fortemente relacionados
tamanho do produto (por exemplo,
com o
ne de
entradas e saídas), e comprimir um núme-
ro de fatores que tendem a estar alta-
.45.
mente correlacionados nos projetos em um
único fator (tais como, uso de programa
~~o estruturada, inspe~ees, etc., em um
únj,co fator denominado "uso de práticas
modernas de progl"amaç:~o").
Os quinze fatores ou atributos direcionadores de custo
resultantes neste modelo foram grupados em quatro categorias:
atributos de produto de software, atributos de computador, atribu-
tos de pessoal e atributos de projeto. Segue a lista dos atribu-
tos, antecedidos de seus respectivos códigos identificadores:
Atributos de produto
RELY
DATA
CPLX
Confiabilidade requerida do software
Tamanho da base de dados
Compl e>:i dade do produto
Atributos de computador
TIME
STOR
VIRT
TURN
Restriç:~o de tempo de eMecuç:~o
Restriç:~o de memória principal
Volatilidade da máquina virtual
Tempo de resposta
Atributos de pessoal
ACAP
AEXP
PCAP
VEXP
LEXP
Capacidade dos analistas
Experiência na aplica~~o
Capacidade dos programadores
Experiência na máquina virtual
Experiência na linguagem de programaç:âo
.46.
Atributos de projeto
MODP
TOOL
SCED
Técnicas modernas de programaçâo
Uso de ferramentas de software
Prazo requerido para o desenvolvimento
Cada um destes atributos direcionadores de custo deter-
mina um fator multiplicador que estabelece o efeito do atributo
sobre o esforço no desenvolvimento do software.
3.5.1.1. Atributo RELY: Confiabilidade requerida do software
Este atributo identifica o grau de confiabilidade que o
software deve possuir de modo a desempenhar
suas funç5es.
11 sat i sf c:\tor i amente"
A escala dos pesos para o atributo RELY é a seguinte:
Muito bai>:o
. Bai><o
o efeito de uma falha do software é
simplesmente uma inconveniência obri
gatória, de modo que O pessoal de de-
senvolvimento corrija a falha. E><em-
pIos típicos sgo protótipos de siste
mas ou modelos de simulaçâo de sotfwa
re no início da fase de viabilidade.
o efeito de uma falha do software cau
sa perdas aos usuários facilmente re
cuperáveis. E><emplos típicos sgo um
modelo de planejamento a longo PI'- az o
ou um modelo de previsgo climática.
3.5.1.2.
. Nominal
Alto
. Muito alto
.47.
o efeito de uma falha do software é
uma perda moderada aos usuários; no
entanto, pode ser recuperada sem gran
de sacrifício do usuário. Exemplos tí
picos s~o sistemas de informaç~o ge
rencial ou sistemas de controle de es
t.oque.
a falha do software pode ser o princi
pal causador de grandes perdas finan
ceiras ou de inconveniências/dificul
dades para um número grande de pesso
as. Exemplos típicos sgo sist.emas ban
cários ou sist.emas de distribuiç~o de
força elét.rica.
o efeito de uma falha do software é a
perda de vidas humanas. Exemplos s~o
os sistemas de controles e comandos
militares ou sistemas de controle de
reatores nucleares.
Atributo DATA: Tamanho da base de dados
o esforço requerido para desenvolver um software é, se
gundo Boehm, claramente influenciado pelo tamanho e pela complexi
dade da base de dados.
A escala dos pesos deste atribut.o está baseada em funç~o
do resultado da seguinte raz~o:
.48.
Tamanho da base de dados em bytes ou caracteres D/P = -----------------------------------------------
Tamanho do programa em DSI
onde DSI representa o número de instrLU;:t3eS fontes
entregues.
A partir do valor resultante nesta razâo obtém-se a se-
guinte escala de pesos:
Bc:\i>:o D/P < 10
Nominal 10 =< D/P < 100
Alto 100 =< D/F" < 1000
Mui to AI to D/F" 1000
3.5.1.3. Atributo CPLX: Complexidade do produto
Este atributo, que indica o nivel de complexidade do mó-
dulo a ser gerado, é analisado considerando o tipo de módulo.
Os tipos de módulos podem ser:
(a) operacBes de controle;
(b) operacBes compLltaci onai sI
(c) operacBes dependentes de dispositivos ou
(d) operacBes de gerenciamento de dados.
A cada tipo de módulo corresponde um peso conforme a es-
cala que se segue:
. Muito bai>,o (a) Código linear com poucos operado-
res de programacâo estruturada nâo
,
. Bai>:o
.49.
aninhados: OO's, CASE's, IF-THEN-
ELSE's. Predicados simples.
(bl Avaliaçâo de expressões simples,
por e>:emplo:
A = B + C * (O - E).
(c) Comandos de leit~tra e gravaçâo
simples com formatos também sim
ples.
(d) Vetores simples na memória princi
pal.
(al Operadores de programaçâo estrutu
rada aninhados de modo direto. A
maioria dos predicados sâo sim
ples.
(bl Avaliaçâo de e>:pressões de nível
moderado, por e>:emplo:
O = SQRT (B * * 2 - 4. * A * C)
(c) Nâo e>:iste a necessidade de conhe
cimento de características de dis
positivos de I/O ou de um proces
sador específico. Entradas e saí-
das sâo l"eal i zadas nO nivel
GET /PUT. Nent1Ltma noçâo de "over-
1 ap 1\ •
(d) Manipulaçâo de subconjuntos de ar-
quivos simples, sem mudanças na
estrutura de dados, nem edições e
• Nominal
. Alta
.. 50 ..
sem arquivos intermediários •
(a) A maior parte contendo aninhamen
tos simples. Algum controle entre
módulos. Uso de tabelas de deci
são.
(b) Uso de rotinas padrão de matemáti
ca e estatistica. Operações bási
cas com matrizes/vetores.
(c) O processamento de I/O inclui se
leção de dispositivos, verificação
do estado dos dispositivos e pro
cessamento de errOS.
(d) Entrada de vários arquivos e sa1da
de um único arquivo. Mudanças eS
truturais simples e edições sim
ples.
(a) Operadores de programação estrutu
rada altamente aninhados e com
mui tos predi cados compostos. Con-
trole de filas e de pilhas. Consi
derável controle entre módulos.
(b) Análise numérica básica: interpo-
laçâo multivariada, equações dife-
reneiais ordinárias. Preocupação
com truncagem e arredondamentos
básicos.
. Muito alta
. E>: tra AI ta
.51 ..
(c) Operações de I/O no nível físico
(transações com endereçamento fí-
sico de memória: "seeks", "reads ll,
etc). Superposiçgo de I/O otimiza
da.
(d) Subrotinas de propósitos especiais
ativadas pelo conteódo de um fluMo
de dados. ReconstrL\çgo complexa de
dados no nível de registro.
(a) Codificaçgo reentrante e recursi
va. Manipulaçgo de interrupções de
prioridade fixada.
(b) Análise numérica estruturada porém
com dificuldades: equações com ma
trizes singulares, equações dife
renciais parciais.
(c) Rotinas para diagnose de interrup
ções, atendimento. Manipulaçgo de
linhas de comunicaçgo.
(d) Uma rotina generalizada de estru
turaçgo de arquivos orientada por
parAmetros. Construção de arqui
vos, processamento de comandos e
otimizaçgo de pesquisa.
(a) Programaçgo de recursos móltiplos
com mudanças dinâmicas de priori-
3.5.1.4. Atributo TIME:
.52.
dades. Controle ao nível de micro
código.
Ib) Análise numérica nªo estruturada e
com grande dificuldade: análise de
turbulências com alta precisgo,
dados estocásticos.
(c) Codifica~ªo de dispositivos depen-
dente de temporiza~go,
micro-programadas.
opera~ees
(d) Estruturas relacionais din~micas,
altamente aclopadas. Gerenciamento
de dados em linguagem natural.
Restriç30 de tempo de execuç30
o grau de restriçªo de tempo de execuçgo imposto sobre
um software é expresso em termos do percentual de tempo disponível
de execução a ser usado pelo sistema,
escala de pesos:
Nominal
Alto
Muito Alto
Extra Alto
=< 501.
701.
85%
95i.
caracterizado na seguinte
3.5.1.5. Atributo STOR: Restriç30 de memória principal
o grau de restri~lo da memória principal imposta sobre
um sistema é e>:presso, também, em termos de percentual da memória
.. 53.
que se espera que o sistema L,tilize e corresponde à seguinte esca
la de pesos:
3.5.1.6.
Nominal
Alto
Muito Alto
Extra AI to
Atributo VIRT:
=< 50%
70%
85%
95%
Volatilidade da máquina virtual
Este atributo identifica o nível de volatilidade da má-
quina virtual básica em rela~âo aO software a ser desenvolvido.
Para um dado sistema, a máquina virtual considerada como básica é
o comple>:o de hardware e software que o sistema utiliza para e>:e
cutar suas tarefas. Por e>:emplo:
Se o software a ser desenvolvido é um sistema opera
cional, a máquina virtual básica é o hardware do com
putador.
Se o software a ser desenvolvido é L,m sistema de ge
rência de banco de dados (SGBDI, a máquina virtual bá
sica geralmente consiste do hardware de computador ma
is um sistema operacional.
Se o software a ser desenvolvido é um sistema de apli
ca~âo para uSLlários, orientados pa .... a banco de dados, a
máquina virtual básica freqUentemente consiste em um
hardware de compLltador, um si stema operaci onal e um
SGBD.
Adicionalmente, a máquina virtual básica inclui alguns
.54.
compiladores ou montadores que apoiam as linguagens sobre as quais
o software será escrito.
Os pesos slo definidos em termos da freqüência relativa
de grandes e pequenas mudanças na máquina virtual básica. Eles slo
definidos do seguinte modo:
3.5.1. 7.
Uma grande mudança afeta de maneira significativa
aproximadamente 10X da. rotina. em desenvolvimento.
Uma pequena mudança afeta de maneira significativa
aproximadamente IX das rotinas em desenvolvimento.
Segue a escala de pesos para este atributo:
· Bai>:o
· Nomi nal
· Alta
• Muito Alta
Atributo TURN:
Uma grande mudança a cada 12 meses.
Uma pequena mudança a cada mês.
Uma grande mudanca a cada 6 meses.
Uma pequena mudança a cada 2 semanas
Uma grande mudança a cada 2 meses.
Uma pequena mudança a cada semana.
Uma grande mudança a cada 2 semanas ..
Uma pequena mudança a cada 2 dias.
Tempo de resposta
Mede o nível de tempo de resposta do computador viven
ciado pela equipe de desenvolvimento do sistema. Os pesos slo de
finidos em termos do tempo de resposta médio, em horas (período de
tempo que dura desde o momento em que o pessoal de desenvolvimento
submete um serviço para ser executado até o momento em que este
.55.
result.do está de volt. em su.s mãos). Excepcion.lmente, o peso
para sistema interativos Ilon-linell~ nos quais o desenvolvimento de
softw.re pode ser feito de modo convers.cion.l pelo pessoal de de
senvolvimento, reflete clm tempo de respost., p.ra ope .... ç5es sim
ples, n. faixa de O • 5 segundos.
c ... itérios:
3.5.1.8.
A esc.l. de pesos deste atributo obedece aos seguintes
BaiHO
Nominal
• AI to
Interativo
Tempo de ... esposta médio abai),o de 4 ho-
ras.
Tempo de resposta médio entre 4 e 12 ho
ras.
• Muito Alto - Tempo de resposta médio acima de
r.s.
12 ho-
At ... ibuto ACAP: Capacidade dos analistas
ACAP indica os pesos correspondentes aos cinco níveis de
capacid.de dos .n.listas em tr.b.lhar no desenvolvimento de soft
ware. Os pesos rel.tivos aos níveis de capacidade dos analistas
são expressos em te ... mos percentu.is em relação ao total de analis-
tas. Os .t ... ibutos p ... incipais considerados n. ponderação são:
H.bilidade de análise;
Eficiência e eficácia;
Habilidade de se comunicar e de cooperar.
Em termos gerais, estes atributos devem ser ponder.dos
igualmente na av.liação. A avaliação não deve considerar o nível
.. 56.
de experiência dos analistas; os efeitos decorrentes da experiên-
cia elos analistas sgo cobertos por outros fat.ores. A avaliaç;:á\o de-
ve basear-se sobre a capacidade dos analistas como um grupo, e n:ao
como indivíduos.
A escala de pesos é a seguinte:
Muito Bai>:o 152 percentil
BaiHo 359: percentil
Nominal 55Q percentil
Alto 759 percenti I ! Muito Alto 909 percentil
3.5.1.9. Atributo AEXP: Exper~jência na apllcaç110
Tal atribl~rto apresenta o nível de e>'periência na aplica-
ç;:go do grupo dl4 prOjeto que desenvolverá o software. Os pesos sgo
definidos em termos do tempo equivalente de experiência do grupo
de projeto com este tipo de aplicação:
~lLÜ to Baixo Menos de 4 meses de e}'per i ênci a média
Baixo 1 ano de e>:periência média
Nominal .,. ~, anos de e>'periência média
Alto 6 anos de e~{peri ênc:i ê\ média
Muito Alto 12 anos de experiência média
3.5.1.10. Atributo PCAP: Capacidade dos programadores
Este atribL,to mostra o nível de capacidade dos programa-
dores que trabalharão nos diversos módulos do software. Da mesma
forma como os analistas, os pesos sgo expressos em t.ermos de per-
.57.
centil com respeito ao total de programadores. Os fatores princi
pais considerados na pondera~go sgo:
aplicadas
3.5. 1. 11.
Habilidade do programador;
Eficiência e eficácia;
Habilidade de se comunicar e de cooperar.
As considerações realizadas em rela~go a ACAP sgo também
a PCAP, e temos a seguinte escala de pesos:
Muito BaiNo 15'Q percenti I
Baixo 35g percentil
Nominal 559 percentil
Alto 759 percentil
Muito Alto 90Q percentil.
Atributo VEXP: Experiência na máquina virtual
Este atributo ressalta o nível de experiência do grupo
de projeto na máquina virtual básica onde o software será desen
volvido. o. pesos .go definidos em termos do tempo de experiência
equivalente do grupo do projeto com a máquina virtual a ser usada,
como segue:
Muito Baixo
Bai >:0
Nominal
Alto
Menos de 1 mês de experiência média
4 meses de experiência média
1 ano de experiência média
3 anos de experiência média
.. 58.
3.5.1.12. Atributo LEXP: Experi~ncia na linguagem de programação
LEXP identifica o nivel de experiência na linguagem de
programa;go do grupo de projeto no desenvolvimento do software. Os
pesos sgo definidos em termos de tempo de experiência equivalente
com a linguagem de prDgramação a ser utilizada, conforme se segue:
Muito Bal,·,o
Bai>:o
Nominal
Alto
3.5.1.13. Atributo MODP:
Menos de 1 mês de experiência média
4 meses de experiência média
1 ano de experiência média
3 anos de experiência média
Técnicas modernas de programação
o atributo MODP se refere ao grau em que as modernas
práticas de programaçgo slo utilizadas no desenvolvimento do soft
ware. As práticas especificas incluídas aqui sgo:
Análise e projeto de requisitos "Top-Do~m"
Nota;go de projeto estruturado
Desenvolvimento incrementa1 11 Top-D<:l!,l-Jn11
Revis5es do projeto e da codificaçgo
Codifica;lo estruturada
Uso de bibliotecas de programas
Os pesos sgo definidos em ter-mos do grau do uso de tais
técnicas no desenvolvimento do sistema, e da experiência relativa
do grupo de projeto em utilizá-las. A escala dos pesos é a seguin
te:
3.5.1.14.
.59.
Muito Baixo - NBo usa
Bai ~·:o
· Nom;, naI
· Alto
· Muito Alto
Iniciando, uso experimental
t.écnicas
- Razoavelmente experiente no uso de algu
mas técnicas
Razoavelmente exper"iente no uso da maio-
ria das técnicas
Uso rotineiro de todas as técnicasa
Atributo TOOL: Uso de ferramentas de software
Este atributo mostra o grau com que ferramentas de soft
ware sgo usadas no desenvolvimento da aplicaç80w Cinco níveis de
ferramentas sâa identificados:
Muito 8ai,,,0
Nominal
. Alto
. Muito Alto
3.5.1.15. Atributo SCED:
Ferramentas bésicas de microprocessador
Ferramentas básicas de minicomputador
Ferr~mentas potentes para minicomputado
res ou ferramentas básicas para computa
dores de grande porte.
Ferramentas potentes para computadores
de grande porte
Ferramentas avançadas para computadores
de grande porte
Prazo requerido para o desenvolvimento
o atributo SCED explicita o nivel de restriç5es de prazo
impostas sobre o grupo de projeto dedicado ao desenvolvimento do
.60.
software. Os pesas sgo definidas em termas da percentual de exten
sgo ou aceleraçgo do prazo da projeto relativamente a um prazo no
minal para um projeta que requer uma certa quantidade de esforça.
O prazo nominal para um projeta (PRAZO) é dado pelas equações de
prazo do COCOMO Básico:
~lodo Orgg,ni co:
Modo Difuso:
Moda Restr i to:
PRAZO = 2,5 (HM)o.3e
PRAZO = 2,5 (HM)o.35
PRAZO = 2,5 (HM)o.32
onde (HM) corresponde ao número de homens-mês requeridos
para desenvolver o software, desde o inicio da fase de
projeta da produto até a final da fase de
teste, e PRAZO é O número de meseS compreendidas entre
estes dois eventos. Uma aceleraçgo da prazo abaixa de
75% da nominal é considerada impossivel pelo modela CO-
COMO.
A escala de pesas é a segui nte:
l'1uito Baixa 75% da nominal
Baixa 85% do nominal
Nominal 100%
Alta 130% do nominal
MI.IÍ ta Alto 160% da nominal
.61.
3.5.2. EQUACõES DO COCOMO INTERMEDIARIa
Uma estimativa do esforço de desenvolvimento no modelo
COCOMO Intermediário se inicia na geraçgo de Ltma estimativa nomi-
nal do esforço. A TABELA 11.1 apresenta as eqLtaç5es que servem de
base para esta estimativa.
TABELA 11.1
Equações de estimativa nominal do esforço no COCOMO Intermediário
Modo de desenvolvimento Equaçgo de esforço nomi nal
Org&nico
DifL\sO (HMI NOM - 3,0 (KDSI)·.·2
Restrito (HM)NOM - 2,8 (KDSI)··20
onde HM significa HOMEM-MES e
KDSI significa Mi lhares de Instr"u<;5es Fontes Entregues
fonte: [Boehm, 1981]
A aplica<;go das equa<;5es da TABELA 11.1 resulta em uma
estimativa nominal, a qual deve ser ajustada em funçgo dos atribu-
tos direcionadores de custo. o QUADRO 11.9 mostra os pesos rece-
bidos por cada atributo.
ATRIBUTOS
DE PRODUTO - RELY - DATA - CPU
DE CO"PUTADOR - TlHE - STOR - VIRT - TURN
DE PESSOAL - ACAP - AEXP - PCAP - VEXP - LEXP
DE PRllJETO - "DDP - TOOL - SCED
.62.
QUADRO II.9
Multiplicadores de esforço no desenvolvimento de software
PESOS
Huito Bailo Baixo Nominal Alto
0,75 0,88 1,00 1, 15 0,94 1,00 1,08
0,70 0,85 1,00 1,15
1,00 I, 11 1,00 1,06
0,87 1,00 1, 15 0,87 1,00 1,07
1,46 1,19 1,00 0,86 1,29 1,13 1,00 0,91 1,42 1,17 1,00 0,86 1,21 1,10 1,00 0,90 1,14 1,07 1,00 0,95
1,24 1,10 1,00 0,91 1,24 1, 10 1,00 0,91 1,23 1,08 1,00 1,04
fonte: [Boehm, 1981 J
"uito E~tra
Alto Alto
1,40 1,16 1,30 1,65
1,30 1,66 1,21 1,56 1,30 1,15
0,71 0,82 0,70
0,82 0,83 1,10
,,63.
o cálculo do prazo obedece às equaç8es apresentadas na
TABELA 11.2, como se segue:
TABELA 11.2
EquaçBes para estimativa do prazo de desenvolvimento
Modo de desenvolvimento Eq~lação do
Orgânico PRAZO = ..., ~
L,.o
Difuso PRAZO = 2,5
Restri to PRAZO = ') ., -,'"
fonte: [Boehm, 1981]
prazo
(HM) o."',,
(HM)o.",,,,
(HM) o."''''
Vale dizer que, neste cálcLllo dos prazos, o valor do HO-
MEM-MES (HM) já se encontra devidamente ajustado pelos multiplica-
dores de esforço.
A partir dai, calcula-se o tamanho da equipe (TE) com a
TE = HI'I / PRAZO
Sintetizando, a seguinte rotina deve ser aplicada para
estimar-se o esforço de desenvolvimento de um sistema, prazo e ta-
manho da equipe:
.64 ..
12) Ca .... acte .... iza .... o pF'ojeto, se ORGANICO, DIFUSO
ou RESTRITO (QUADRO 11.8);
22) Dete .... mina .... o tamanho do p .... ojeto em te .... mos de
I<DSI (milha .... es de inst .... uc;;;8es fontes ent, .... e
gues) ;
32) A pa .... ti .... do tipo do p .... ojeto e do KDSI, apli-
ca .... a equaçgo de esfo .... ço nominal
dente (TABELA 11.1);
co ........ espon-
42) Definir quais multiplicadores de esfo .... c;;;o sgo
aplicáveis ao p .... ojeto;
52) Multiplica .... a estimativa HOMEM-MES nominal
po .... cada um dos multiplicado .... es de esfo .... c;;;o
(QUADRO 11.9), ou seja:
(HM)NoM " RELY " DATA>: CPLX >: TIME>: STOR "
VIRT >, TURN >: ACAP " AEXP >, PCAP >,
VEXP >, LEXP >: MODP >: TOOL >: SCED
Esta multiplicaçgo fornece a estimativa de
esfo .... c;;;o de desenvolvimento ajustada;
62) Aplica .... a equac;;;.opa .... a cálculo do prazo,
conforme TABELA 11.2;
72) Dividi .... HM ajustado pelo valo .... do p .... azo do
p .... ojeto, obtendo-se o tamanho da equipe.
.65 ..
3.5.3. DISTfUBUIÇI\O DO ESFORÇO E PRAZO NAS FASES DO PROJETO
o resultado anterior considera o sistema como um todo
único. No entanto, COCOMO permite que se distribuam tais valores
ao longo das fases do projeto, em funçâo do seu tamanho e tipo.
Os QUADROS 11.10, 11.11 e 11.12 apresentam a distribui
çâo percentual a ser aplicada aos valores do esforço e do prazo,
para os modos orgAnico, difuso e restrito, respectivamente. Vale
lembrar que, como premissa, o COCOMO cobre as fases de projeto do
produto até SLla integraçâo e teste. Adicionalmente, as estimati-
vas de esforço e prazo correspondentes a valores de KDSI nâo per
tencentes às referidas tabelas devem ser estabelecidas por inter
polaçâo.
.66.
QUADRO II. 10
Distribuiç~o. por fase, do esforço e do prazo no Modo Orgânico
Tatanho do Produto
Pequeno Inter.ediêrio "édio F A S E 2 KDSI 8 KDSI 32 KDSI
ESFOR~O -------Planos e requisitos (lI 6 6 6
Projeto do Produto 16 16 16 Progralaç30 68 65 62
projeto detalhado 26 25 24 codificaç30 e teste 42 40 38
IntegraçSo e Teste 16 19 22
Total 100. 1001 100%
PRAZO -----
Planos e requisitos (Xl 10 11 12
Projeto do Produto 19 19 19 Prograla~So 63 59 55 IntegraçSo e teste 18 22 26
Total 1001 1001 1001
Grande 128 KDSI
6
11 59
23 3.
25
100%
13
19 51 30
1001
.67.
QUADRO I I • 11
Distribuição, por fase, do esforço e do prazo no Modo Difuso
Ta.anho do Produto
Pequeno IntermedUri o "édio Grande Muito Grande F A S E 2 KOSI 8 KOSI 32 KDSI 128 KOSI 512 KDSI
ESFORÇO ------Planos e requisitos (X) 1 1 1 7 7
Projeto do Produto 17 17 17 17 17 Progralaç30 á4 ál 58 5S 52
projeto detalhado 27 2á 25 24 23 codificaç30 e teste 37 35 33 31 29
Integração e Teste 19 22 25 28 31
Total 1001 100% 100% 1001 1001
PRAZO -----
Planos e requisitos lI) lá 18 20 22 24
Projeto do Produto 24 25 2. 27 28 Progralação 5. 52 48 44 40 IntegraçSo e teste 20 23 2. 29 32
Total 1001 100'l. 1001 1001 1001
.68.
QUADRO I 1. 12
Distribuiç~o, por fase, do esforço e do prazo no Modo Restrito
ra.anho do Produto
-Pequeno Inter.ediário "édio Grande Muito Grande
F A S E 2 KDSI 8 KDSI 3Z KDSI 128 KDSI 512-13151--
ESFORÇO -------Planos e requisitos (Xl 8 a 8 8 8
Projeto do Produto 18 18 la 18 18 Programação 60 57 54 51 48
projeto detalhado 28 27 26 2S 24 codificaç!o e teste 32 30 28 26 24
IntegraçSo e reste 22 2S 28 31 34
Total 1001 1001 100X 1001 I()OX
-,- p- ---' PRAZO -----
Planos e requisitos (X) 24 28 32 3. 40
-Projeto do Produto 30 32 34 36 38 Pr ogr aaaç 30 48 44 40 36 32 lntegraç!o e teste 22 24 26 28 30
Total 100% 100X 100% 1001 100%
-
.69.
4. O MODELO BANG
DeMarco [1982J estabeleceu uma função métrica partindo
do fundamento de que "qualquer que seja a meta de um projeto, pre
cisamos inventar algum meio de medí-lo e tornar os resultados vi
sí vei s para os membros da eqeli pe".
Isto daria ã equipe condições para manter o projeto di
recionado ã meta específica.
Adicionalmente, DeMarco sugere que "para a maioria dos
projetos, a meta deve ser qualquer coisa assim:
Maximizar a quantidade de funç6es entregues
<medida ao longo dos anos de vida útil do sis
tema) por dólar de custo na duraç~o do sistema
como um todO IlI•
Ao se referir a custo total, DeMarco está considerando o
custo de desenvolvimento mais o custo de produção mais o custo de
manLltençào. Em seguida, ele apresenta um "procedimento mecánico"
que ajudará a realizar a meta estabelecida:
1. Estipular um único indicador de sucesso para compa-
rá-lo com a meta. Esse indicador é uma medida da
funçBo total dq projeto entregue por dólar investido
desde o início do_prOjeto até gue o sistema seja des
cartado. O nome dado a essa métrica fundamental é
"Bang per Buck" (BPBl.
2. Coletar os dados de uma amostragem de projetos para
4.1.
" 70.
estabelecer padrões para o desempenho de BPB.
3. Procurar obter e aval i ar os previ sares para aquel as
partes da medi da BPB que dependem do f~,t~lI"o. Usar os
previsol"es para manter os membros do projeto cientes
da qualidade de seu desempenho durante o projeto.
4. Incentivar os membros do projeto a maximizar o BPB do
Proj eto. Certi f i caro-se de que el es sabem q~le o BPB do
Projeto real será medido e tornado público, e que o
sucesso deles será uma fun;_o daquele valor encontra-
do, e n_o de uma parte dele. Certificar-se de que
eles saibam ÇQ!!!Q o BPB do Projeto será calculado.
5. Tornar público os números do BPB do projeto durante
seu andamento e os números reais seis meses após a
entrega do Projeto. (As características do custo de
manutenç_o durante os seis primeiros meses após a en
trega fornecem um forte previsor do custo de manuten
;_0 durante a sua vida útil).
A MODELAGEM DO PROBLEMA
"O modelo inicial de um sistema-alvo 11> aquele que está
enfocado sobre as necessidades" [DeMarco, 1982J. DeMarco ressalta
a importância de um modelo que explicite claramente os requisitos
do sistema, pois este modelo "é a fonte ideal para as indicações
preliminares" que servem de base no processo de estimativa/previ
s_o.
.71.
Ele sugere que os reqLlisitos do sistema sejam analisados
a partir de três perspectivas, que juntas constituirao o modelo de
especificações do sistema. Estas perspectivas correspondem aos se
guintes modelos:
- Llm modelo da funçao - perspecti va do que o si stema
faz;
- um modelo de dados retidos - perspectiva do que o sis
tema memorizaI
- um modelo de transição de estado - perspectiva dos di
ferentes estados comportamentais
que car-ac:teri2am o sistema.
DeMarco faz uma analogia entre esta abordagem e a espe
cificação de um corpo sólido em três perspectivas (esquema ortogo-
nal). "Aplicando alguns dos termos usados na analogia, podemos
agora considerar cada um dos componentes do modelo de requisitos
uma projeçao em um espaço diferente. Deste modo, o modelo de fun
Çao (o particionamento em funções integrantes e interfaces entre
as funções) pode ser considerado uma projeçao sobre o espaço da
funçao; o modelo de dados retidos pode ser considerado uma proje
Çao no espaço da informaçao; e o modelo de transiçao de estado,
uma p,Cojeçlo no "-"paço do "-,,tado".
.72.
A partir desta analogia, pode-se esperar que LIma ou mes-
mo duas dessas projeç5es sejam nulas, por exemplo, um modelo de
estado significativo pode não existir quando o sistema permanece
sempre no mesmo estado; da mesma forma uma entidade bidimensional
pode não ter projeção em uma ou duas das três perspectivas do es
qLlema de proj eção Ol"togonal. Si mi 1 armente, um si stema qLle carece
de uma dimens.o pode ser perfeitamente descrito por menos do que
três perspectivas.
Segundo DeMarco, a maioria dos sistemas, e, basicamente,
todos os sistemas pequenos podem ser especificados adequadamente
utilizando-se duas perspectivas ou mesmo apenas uma.
A FIGURA 11.2 ilustra o modelo composto de requisitos,
um COnjUnto combinado de modelos componentes n.o-nulos.
.73.
FIGURA 11.2
Modelo Composto de Requisitos
I I
I
I
x
I I I I I
ESPAÇO DA FUNÇAO
';--_-4-----r-------------~ I
O SISTEMA
__ / ________ '--______ --1
I I
I "ESPAÇO DA INFORMA~O rl--------------,./
ESPAÇO DO ESTADO
~------_.------~
.74.
Sintetizando, "a especifica~go é entgo construi da sobre
um esqueleto formado pelo modelo composto,
final consiste de:
onde a especificaçgo
um modelo de funçgo (rede de funções e dicionário de
interfacesl, junto a uma miniespecificaçgo que descre
ve cada funçgo elementar, onde uma miniespecificaç~o
consiste de uma declaraçgo concisa das politicas do
usuário que regem uma determinada funç.,\'lo elementar;
um modelo de dados retidos (diagrama de objetos mais
relacionamentosl junto com um levantamento de todos os
elementos dos dados alocados a cada objeto;
um diagrama de transiçlo de estado, junto com uma des
criçlo comportamental de cada um dos estados."
Para obtençlo de maiores detalhes sobre as ferramentas
utilizadas na especificaçlo dos modelos de funçlo, de dados reti
dos e de transiçlo de estado, DeMarco sugere a consulta à seguinte
bi bli ograf i a: [DeMarco, 1978], [FI avi n, 1981] e [IEEE, 1978],
pectivamente.
res-
o uso de tal modelo formal de especificações apresenta
três beneficios:
o modelo de especificações nlo é restrito; pode ser
refinado e corrigido pela equipe do projeto e pelos
usuá .... ios.
o modelo de especificações tem caracteristicas mensu
ráveis, as quais podem ser correlacionadas ao desempe-
.75.
nho observado.
O modelo de especifica~5es fica pronto no inicio do
proj eto; mesmo qLle sej am necessári as previ s5es ante-
riores a este prazo, o modelo permite qLle se fa~a
qual quer corre~ão das previ s5es em tempo hábi 1.
Deste modo, uma análise quantitativa do modelo fornecerá
uma 1!Jedida da verdadeira fun~ão a ser elaborada, confor1!Je percebi
da pelo usuário. A esta medida DeMarco deu o nome de "BANG", defi
nindo-a como "uma métrica de fun~ão, uma indicação do tamanho do
si stema, i ndependente da i mpl ementação".
4.2. OS COMPONENTES PRIMITIVOS DE UM MODELO
o modelo BANG baseia-se no tamanho (conteúdo informati
vo) do 1!Jodelo de especifica~5es, ou seja, é uma medida direta da
quantidade de fun~5es utilizáveis (componentes) do sistema a serem
entregLles.
Segundo DeMarco, é requisito indispensável para o uso de
qualquer métrica derivada do modelo não haver redundância em todo
o conjunto de seus c01!Jponentes pri1!Jitivos, isto é, no nivel mais
baixo (detalhado) do modelo. Um componente do modelo de especifi
ca~5es é considerado pri1!Jitivo se não for dividido em componentes
subordinados.
Cada parte do modelo (fLIn~aes, dados retidos e transi~go
.76.
de estado) é dividido e subdividido até o nível primitivo. 8ao su
geridos seis diferentes tipos de primitivos, dependendo do modelo
que estive," sendo particionado, como se segue:
1. PRIMITIVO FUNCIONAL - sao as partes de nível mais ba
ixo nas quais sao divididos os
requisitos através do uso da
2. ELEMENTO DE DADOS
3. OBJETO
4. RELACIONAMENTO
5. ESTADO
F'ede de funç;ôes
fIL"'os de dados
(diagramas de
DFD'8). Os
primitivos funcionais sao parte
do modelo de funç;ôes.
sao os itens de dados primiti-
vos, ou SEja: nómeros, cadeias
e variáveis indívisiveis. Ele-
mentos de dados estao contidos
no dicionário de dados do mode
lo de funçôes.
é um agrupamento dnico de itens
de dados, os quais caracterizam
a mesma entidade. Objetos sao
parte do modelo de dados reti
dos.
é o componente primitivo da in
terconectividade dos dados re-
tidos. Relacionamentos também
fazem parte do modelo de dados
retidos.
é parte do modelo de transiçao
.77.
de estado e representa a carac-
terística de controle exigida
pelo sistema.
6. TRANSIÇ,!\O componente adicional da carac-
teristica de controle exigida e
que também se encontra no mode-
lo de transiçgo de estado.
estao resumidos na TABELA 11.3, a seguir:
TABELA 11.3
Os seis primitivos do modelo de especificaçgo
PRIMITIVO
Primitivos funcionais Ele.ento de dados Objetos Relaciona.entos Estados Transi~Be5
ORIGEM DO PRIMITIVO
Rede de funç6es IDFDl Dicionário de dados Diagrala de objetos Diagrama de objetos Diagr'la de estados Diagrama de estados
adaptado de DeMarco [1982]
CARACTERíSTICA DIVIDIDA
Requisitos do sistema Dados do 5istela Dados retidos Dados r eti dos Controles do siste~a Controles do sis! •• a
A partir destes componentes primitivos, efetuam-se as
contagens que fornecem as qL.antidades básicas (contadores) para o
cálculo da medida BANG. Doze contadores essenciais sao identifica-
dos e definidos a seguir:
PR Contador dos primitivos funcionais que se encon-
tram dentro do limite homem-máquina
.78.
PFM Contador de primitivos funcionais manuais modifi
cados (funções que se encontram fora dos limites
homem-máquina, que devem ser alteradas para acomo
dar a instalação do novo sistema automatizado)
ED Contador de todos os elementos de dados existentes
nos limites homem-máquina
EDE Contador dos elementos de dados de entrada, que se
movimentam de primitivos manuais para primitivos
aL.tomat i z ados
EDS Contador dos elementos de dados de saída,
movimentam de primitivos automatizados para primi-
tivos manuais
EDR Contador dos elementos de dados retidos (armazena
dos) de maneira automatizada
OB Contador de objetos no modelo de dados retidos
Isomente a parte automatizada)
RE Contador dos relacionamentos do modelo de dados
retidos Isomente a parte automatizada)
ES Contador dos estados do modelo de transição de es
tado
" 79"
TR Contador das transi~ees no modelo de transi~ªo de
estado
, CTi Contador dos tokens de dados em torno da frontei-
ra do enésimo primitivo funcional (avaliados para
cada primitivo); um token é um item de dados que
nªo precisa ser subparticionado dentro do primi-
tivo
REi Contador dos relacionamentos que envolvem o ené-
simo objeto do modelo de dados retidos (avaliados
para cada objeto).
Deste modo, assim que os modelos componentes do modelo
de especifica~ªo estiverem completos, os contadores dos primitivos
devem ser calculados.
4.3. CLASSIFICACAO DOS PROJETOS
Teoricamente, a fun~~o métrica proposta (BANG) seria
calculada a partir de todos os contadores de primitivos, cada um
ponder ado por seu f ator e>, c I usi vo, como se SegLte:
BANG provisório = PF >, (Fator-de-pondera~ªo-para-PF) +
PFM x (Fator-de-pondera~ªo-paf-a-PFM) +
ED x (Fator-de-pondera~ªo-para-PRM) +
.80.
No entanto, o próprio DeMarco [1982J considera pouco
prática esta abordagem uma vez que "estatísticamente, ela é intra
tável e alguns contadores sobrep5em-se a outros, gerando redundAn
cia na medic;;:âo ll•
Para sanar esta deficiência, ele sugere a classificação
dos projetos em llm pequeno número de domínios, estabelecendo uma
medida diferente de BANG para cada domínio. o efeito colateral
desta ação é que não se poderá comparar convincentemente projetos
pertencentes ia domí n i os d i f erentes. Entretanto, na mai or i a das em
presas, os projetos farão parte de somente um Oll dois domínios,
restringindo o número de contadores a serem utilizados na medida
BANG.
Adicionalmente, é necessário ter consciência de que,
usando um determinado contador (por exemplo: PF) como o principal
indicador, este estará sintetizando componentes primitivos que não
são 19>( atamente i guai s - ai guns e}( i gem mui to mai s esforço para i m
plementação do que outros - e>dgindo uma correção efetiva de tais
variaç5es.
Deste modo, o contador ajustado torna-se praticamente
uma quantidade direta do BANG.
DeMarco identifica três grandes domínios onde a
totalidade dos projetos podem Se enquadrar:
.81.
Domínio de projetos orientados p·ara funçÕes - onde os
sistemas podem ser analisados quase que totalmente em
termos das operações que desempenham sobre os dados;
Domínio de projetos orientados para dados onde oS
sistemas precisam ser analisados, especificados e im
plementados em termos dos dados sobre os quais eles
atuam, além dos grupamentos de dados e seus interrela
cionamentos, ao invés das operações.
Domínio de projetos híbridos - onde o tamanho e a com
ple>:idade dos sistemas são fortemente determinados pe
la sua ligação tanto às funções quanto aos dados.
o modo proposto para alocar os projetos a um ou oLltro
domínio baseia-se na relação entre os contadores de primitivos PF
(contador de primitivos funcionais), RE (contador de relacionamen
tos inter-objetos) e EDS (contador de elementos de dados que saem
da área automatizada).
A relação RE/PF fornece uma medida da solidez dos dados.
Para DeMarco:
RE/PF < 0,7 indica Llm sistema orientado para fLlnções
RE/PF > 1,5 indica um sistema orientado para dados
0,7 <= RE/PR <= 1,5 indica um sistema híbrido.
A relação EDS/PF mede o quanto o sistema ocupa-se com a
movimentação dos dados, em oposição aos cálculos efetuados. Siste-
.. 82 ..
mas comerciais tendem a ter uma alta proporção EDS/PF, e sistemas
científicos, uma baixa proporção.
DeMarco não fornece nenhum valor real desta relação para
marcar a transiçªo de um domínio para o outro~ uma vez que a maio
ria das empresas utiliza linguagens de programaçgo diferentes para
os sistemas qL\e variam nesta dimensão, alocando os sistemas nos
domínios a partir da linguagem utilizada,
EDS/PF. Apesar disso, tal proporção é útil
e não da proporção
na identificação de
projetos que devam ser classificados em um domínio diferente da
quele indicado pela linguagem.
4.4. BANG PARA SISTEMAS ORIENTADOS PARA FUN~OES
Nos sistemas orientados para f Llnç/3es , o principal compo
nente do BANG é o PF (contador dos primitivos funcionais). No en
tanto, tal contador necessita de um ajuste, pois alguns primitivos
funcionais têm implementação mais dispendiosa do que outros. Deste
modo são sLlger i dos doi s aj ustes referentes ao tamanho do pri mi t i vo
e um relativo a sua complexidade.
4.4.1. REGRA DA PARTI~AO UNIFORME
o probl ema de acei tal' Llm determi nado componente como
primitivo ou particioné-Io em outros componentes pode ser resolvi
do aplicando-se a seguinte regra:
.83.
"Um componente só deve permanecer como primi-
tivo se ngo for possível uma partiç:êlo sL.bse-
qL.ente OL' se esta parti ç;go sL.bseqL.ente nêlo re-
Nesta regra, o contador de "Tokens" médio (CTm .. d .",) pode
ser calculado através da seguinte equaç:go:
SOMAT (CTi) CTm~d~O = ----------------
PF
onde SOMAT representa a funç:go somatório.
A aplicaç;go desta regra depende da verificaç;go dos dados
de entrada e de saída em cada nado do modelo de funçêlo. Marca-se,
em cada fluxo de entrada de dados, a quantidade de "tokens" que
ele carrega para o nado. Um "token" pode ser um elemento de dados
ou um conjunto de elementos de dados que a funç:êlo trata como um
todo. Utiliza-se o mesmo esquema para o flu,:o de saída de dados.
A FIGURA 11.3 ilustra uma aplicaç;êlo desta regra no auxí-
lia à decisêlo de particionar ou nêlo um primitivo funcional com ba-
gura:
.84.
FIGURA 11.3
Aplicação da Regra de "Partição Uniforme
A
8
fonte [DeMarco,1982J
Algumas observaç5es podem ser feitas a partir desta fi-
o número de "tokens" pode ser diferente nos e>:tremos
de um mesmo fluxo de dados (vide fluxo I na FIGURA lI.
31. Isto ocorre em virtude de um primitivo funcional
necessitar dividir o fluxo mais minuciosamente que ou
tro;
não é necessário calcular a média do CT para avaliar
cada candidato à partição. O CT m • d • o será sempre redu
zido quando os componentes da partição que o substitui
possuirem, individualmente,
primitivo original.
CT's inferiores ao do
.85.
DeMarco observa que esta regra pode tornar os primitivos
do modelo de especifica<;;t'les demasiadamente pequenos para os obje
tivos e necessidades dos analistas. Neste caso, ele sugere que es
te det.al hamento, vi sando atender ao cál cul o do BANG, sej a efetuado
pelo pessoal do Grupo Métrico. Este grupo, separado totalmente do
grupo de desenvolvimento, é responsável por todas as proje<;;éles de
planejamento relacionadas aos sistemas.
4.4.2. AJUSTE NO TAMANHO DAS FUNCOES
As diferen<;;as noS tamanhos das fun<;;ões primitivas não
são totalmente resolvidas com a aplica<;;ão da Regra de Parti<;;ão
Uniforme. Assim sendo, DeMarco apresenta Ltma maneira de ajustar o
tamanho relativo de uma transforma<;;ã'o em ·fLtn<;;ão de CTi, ou seja, o
número de "tokens" envolvidos na transformaç:ão, baseada na análise
realizada por Halstead [1977J, que conduz à seguinte formula<;;ão:
TAM (Pil é proporcional a CTi X 109,., (CTil
onde TAM (Pil é o tamanho de um determinado primitivo.
A TABELA 11.4 fornece os valores ponderados,
a partir desta fórmula.
cal CLtl ados
.86.
TABELA 11.4
Pondera,30 de Dados Para correç30 do Ta~anho de Primitivos funcionais
CTi
2 3 4 5 6 7 8 9
10 11 12 13 14 15 16 17 18 19 20
-
Inc~emento PF Cor~igido (IPFC)
1, O 2,4 4,0 5,8 7,8 9,8
12,0 14,3 16,6 19,0 21,5 24,1 26,7 29,3 32,0 34,7 37,6 40,4 43,2
Aplicando-se este ajuste, tem-se que o Primitivo Funcio-
nal co~~igido (PFC) é e"p~esso por:
PFC = SOMAT <IPFCi)
4.4.3. AJUSTE NA COMPLEXIDADE DAS FUNC6ES
Uma vez que a va~iac;~o dos p~imitivos funcionais, no que
diz ~espeito à complexidade, pode ser cont~olada at~ibuindo a cada
p~imitivo uma catego~ia bem definida, o ajuste dos p~imitivos pode
se~ efetivado aplicando-se um fato~ e"clusivo de cor~eç:~o a essa
catego~ia. DeMarco conside~a as categorias abaixo como ~elevantes
à maiD~ia dos sistemas:
Separação
AmaI gamação
Direção de
dados
Atualização
simples
Gerenciamento de
armazenagem
Edição
Verii'icação
Manipulação de
texto
Sincronização
Geração de
saídas
.87.
primitivos que dividem os ítens de
dados de entrada.
primitivos que combinam os ítens de
dados de entrada
primitivos que orientam os dados de
acordo com um controle variável.
primitivos que atualizam um ou mais
ítens de dados armazenados.
primitivos que analisam os dados ar
mazenados e agem com base no estado
desses dados.
primitivos que avaliam os dados de
entrada nos limites homem-máquina.
primitivos que verificam e relatam a
inconsistência interna~
primitivos que tratam de cadeias de
te>:to.
primitivos que decidem quando agir ou
fazer outros agi rem.
primitivos que formatam os fluxos de
dados de saída (outras que não as sa
í das tabul ares) .
Display
Análise tabular
Aritmética
Iniciaclilo
Computaclilo
Gerenciamento de
dispositivos
.88.
primitivos que constroem saídas bidi
mensionais (gráficos, imagens, etc).
primitivos que executam a formatação
e o relatório tabular simples.
primitivos que e><ecutam cálculos sim
ples.
primitivos que estabelecem valores
iniciais para dados armazenados.
primitivos que e><ecutam cálculos com
pl e><os.
primitivos que controlam os disposi
tivos periféricos do computador.
Adicionalmente, ele apresenta um conjunto inicial (TABE
LA 1I.5) de fatores de ajuste para os casos relacionados. Tal con
junto é considerado inicial, uma vez que para ele os fatores de
ponderaçlilo de complexidade dependem do ambiente de software onde
as funç5es serlilo implementadas.
4.5.
.89.
TABELA 11.5
Fatores de ponderaç30 de Complexidade Por Categoria Do Prilitivo
-Classe
Separaç;go AmaI gaç:go Direç:go de Dados Atualizaç;go Simples Gerenciamento de Armazenagem Ediç:go Verificaçgo Manipulaç:go de Texto Sincronizaç;go Geraç;go de Saída Display Análise Tabular Aritmética Iniciaç;go Computaç;go Gerenciamento de Dispositivos
BANG PARA SISTEMAS ORIENTADOS PARA DADOS
Peso
0,6 0,6 0,3 0,5 1, O 0,8 1, O 1, (I 1,5 1, (I 1,8 1, O 0,7 1, (I 2~O 2,5
Nos sistemas orientados para dados, a maior parcela de
esforço está direcionada para as tarefas relativas à implementaçgo
do própr"io banco de dados. Para estes sistemas, o cont"'dor básico
a ser utilizado na análise métrica é o OB (contador dos objetos no
banco de dados). Também este contador receberá um ajuste, visto
que alguns objetos têm implementaçgo mais dispendiosa do que ou-
tros. A TABELA 11.6, a segLlir, fornece os pesos para cada objeto,
em fLInç;go de seu inter-relacionamento com outros objetos.
Dado o nOmero de relacionamentos no limite do objeto
(REi), obtem-se o Incremento de OB Corrigido (10B8).
.90.
TABELA 11.6
Pondera~~o dos Relacionamentos dos Objetos
REi Incremento OB Corrigido nOBC)
-1 2 3 4 5 6
-
1, O 2,3 4,0 5,8 7,8 9,8
o BANG para este tipo de sistema será representado pela
soma dos IOBC's de todos os objetos.
DeMarco alerta para o fato de que os pesos inseridos
nesta tabela precisam estaI'" convenientemente ajustados ao ambiente
dos sistemas, em funç.o das ferramentas de gerência do banco de
dados que se utilizam.
4.6. BANG PARA SISTEMAS HíBRIDOS
Para o caso dos sistemas híbridos, onde as func;;ões e oS
dados se consti t~\em em fortes determi nantes de seu tamanho. e com-
pl e>: i dade, s~\gere-se o cál cul o do BANG para ambos os modos (" BANG
de F~mções" e "BANG de Dados"), ressal tando .• entretanto, que ambos
sejam mantidos separados. Na prática, esta sugest.o leva a separar
as atividades mais preocupadas com a implemen'taçAo das funções do
sistema daquelas mais preocupadas com a implementaçAo do banco de
dados, como se fossem dois projetos distintos.
.91.
4.7. SUMARIZANDO O MODELO BANG
Os algbritmos a seguir (QUADROS 11.13 e 11.14) resumem a
aplicação do cálculo do BANG: o primeiro para o ambiente orientado
para funções e o segundo para o ambiente orientado para dados.
QUADRO 11.13
Algoritmo de Cálculo do BANG para Sistemas Orientados para Fun~Oes
Zere o valor inicial do BANGFUNÇAO
Para cada primit.ivo funcional no modelo de função: Calcule O Número de Tokens na fronteira do primitivo funcional (CTi) Para cada fILl>:o de entrada OLl saída de dados:
1. Determine quantos tokens separados de dados são visíveis dentro do primitivo. Isto nem sempre é igual à contagem de elementos de dados: se um grupo de elementos de dados puder ser convertido de entrada em saída sem consulta interna será apenas um único token.
2. Registre-se o NúmerCi de Tokens no." ponto de encontro cio flu>:o de dados com o· primitivo. (Note que um flu>:o de dados pode envolver uma quant i dade de tokens percebi da pelo pr-ocesso recebedor diferente daquela percebida por seu cr-i ado.")
O valor de CTi será igual ao somatório dos tokens registrados em torno do limite.
Use o Número de Tokens (CTi) para entrar na TABELA 11.4 e registrar o IPFC correspondente.
Aloque o primitivo a uma classe, conforme sua compl e>: idade.
Acesse a TABELA 11.5 por Classe e anote o Peso respec:tivo.
Multiplique o IPFC pelo peso acessado.
Adicione o IPFC Ponderado ao BANGFUNÇAO.
.92.
QUADRO I 1. 14
Algoritmo de Cálculo do BANG para Sistemas Orientados para Dados
Zere o valor inicial do BANGDADOS.
Para cada objeto do modelo de dados retidos: Calcule a contagem dos relacionamentos que envolvem aquele objeto. Use a contagem de relacionamentos para acessar a TABELA I1.6 e anote o IOBC acessado. Adicione o IOBC ao BANGDADOS.
Segundo DeMarco, o modelo BANG é bom para algumas ativi-
dades do prOjeto. A métrica derivada do modelo de especificações
é tflo boa quanto o próprio modelo. Se ela especific:a outra coisa
que não o sistema necessário, será igualmente desnecessária. Mais
i mpor-tante ai nda, se as aI teraç:ões de requi si tos e e medel e nflo
forem revisados e requantificados, a métrica ficará desatualizada,
e será inútil.
.93.
5. LINHAS DE CODIGO FONTE
5.1. CONSIDERAÇõES INICIAIS
A facilidade de cálculo do número de linhas de código
fonte de um sistema após sua conclclsgo tem levado inúmeros profis
sionais a utilizarem este valor como uma medida do tamanho do sis-
tema. Pressman [1987] a classifica como uma das medidas diretas
de um software e ressalta SUa grande utilizaçgo e simplicidade.
Esta medida resulta da contagem das Linhas de Código Fonte de to-
Os autores, em geral, a identificam dos os programas do sistema.
como Linhas de Código Fonte LCF ("Soctr"ce Line of Code
SLOC") ou simplesmente Linhas de Código LC ("Li nes of Code
LOC") [Pressman, 1987J, [Conte, 1986J, [Jeffery,
mond, 1985].
1987J e [Drum-
Conte et alii [1986] se referem ainda à medida KLOC (mi
lhares de linhas de código) para ser utilizada em sistemas de
grande porte.
Boehm (1981) utiliza a medida DSI ("Delivered Source
Instructions") para contar a quantidade de instruç5es fonte entre-
gues ao usuário. Ele considera todas as linhas de código fonte
dos programas, exceto as que constituem os comentários e as que
estgo em branco. Adicionalmente, uma linha com mais de uma ins-
truçgo é contada uma só vez e uma instruçgo que ocupe várias 1i-
nhas será contada pelo número de linhas que a compôe.
ração é considerada como uma instruçgo.
Cada decla-
.94.
Uma das primeiras tentativas sistemáticas de coletar da
dos de projetos de software sob condições semi-controladas foi
efetuada por Walston e Felil< [1977J na "IBM Federal Systems Divi-
sion l1, no início dos anos 70. Uma análise destes dados foi publi-
cada em um a,-tigo no "IBM Systems Journal". Neste trabalho, os
programas (escritos em 28 lingL,agens diferentes) foram medidos em
linhas de código fonte entregues ("Delivered Source Lines
DSL") cUja definiçâo é semelhante ao DSI utilizado por Boehm, e>:
ceto que as linhas de comentários sâo incluidas na contagem das
DSL.
Segundo Conte et alii [1986J, o tamanho de um programa
se constitui numa medida importante, pois:
é fácil de se calcular após a confecção dos progra-
mas;
é o fator mais importante para muitos modelos de de
senvolvimento de software;
produtividade, normalmente, baseia-se em uma medida
de tamanho.
Pressman [1987J aponta as seguintes vantagens no uso de
Linhas de Código Fonte como medida:
é algo que pode ser contado facilmente em qualquer
software;
é utilizada por muitos modelos de estimativas de
softwares como valor básico de entrada;
já el<istem farta literatura e dados sobre esta medi-
.95 ..
da.
Por outro lado, é o próprio Pressman que ressalta as
críticas efetuadas a esta medida ou aos modelos nelh calcados,
destacando-se:
510 dependentes da linguagem de programaçlo utiliza-
da;
penalizam os programas bem projetados e que têm menor
tamanho;
nlo podem ser facilmente ajustados às linguagens nlo
procedurais;
o seu uso como estimador requer um nível de detalhe
que pode ser difícil de alcançar, ou seja, quem pla
neja deve estimar o nómero de LCF a serem produzidas
muito antes que a análise e o projeto do sistema te
nham sido completados.
Apesar das críticas, um indicador da aceitaçlo de Linhas
de Código Fonte como medida de produtividade pode ser encontrado
observando-se o modo como slo vendidas ferramentas de produtivida-
Com freqUência tais produtos slo promovidos aos
clientes baseando-se especialmente no aumento da taxa de LCF por
profissional EDrummond, 1985J.
.96.
5.2. A TABELA DE CARPERS JONES
Carpers Jones [1988], considerando as diferenças exis
tentes entre as diversas linguagens de programaçâo, no que se re~
fere à "porÇ:âo" de sistema qLle um detel"minado número de linhas de
código fonte pode implementar, sugere uma tabela qL\e possibilite a
comparação entre as diversas linguagens. Na verdade, Jones, dire-
tor da Software Productivity Research, Inc., propõe uma nova abor
dagem de avaliaçâo das linguagens de programaçâo a partir da quan
tidade de linhas de código fonte necessária para implementar 1
(um) ponto de funçâo, conforme definido por Albrecht [1984].
Segundo Jones, a utilização disseminada da métrica base
ada em Pontos de Função possibilitará a construção de uma tabela
de avaliação das linguagens, que teria para a área de informática
valor semelhante ao que tem a Tabela Periódica de Elementos par.;\
a Química.
Baseando-se na experiência já adquirida por sua empresa,
ele propõe uma primeira versão desta tabela, ressaltando que seus
valores poderão sofrer alterações no sentido de melhorar a relação
entre as diversas linguagens.
de Jones.
A TABELA 11.7 reproduz a proposição
.97.
TABELA 11.7
Linguagens selecionadas e seus níveis de PONTOS DE FUNCAO
LINGUAGEM
Baixo nível - default Linguagem de máquina Primeira Geraçgo - default BASIe assembly MACRO assembly C - default BASIC interpretado FORTRAN 11 FORTRAN 66 Segunda GeraçAo - default Linguagem Procedural - def. FORTRAN 77 ALGOL 68 ALGOL W CHILL ANSI COBOL 74 MUMPS JOVIAL "TYPED" fortemente - default ANSI COBOL 85 PASCAL - default BASIe Compilado PL/S Alto nível - default Terceira GeraçAo - default REPORT GENERATOR - default PL/l MODULA 2 Orientada p! problema - def. ADA "TYPED" fracamente - default PROLOG - default LISP - defaLllt FORTH - default ANSI BASIC Baseada no Inglês - default NATURAL AL SHELL - default SimulaçAo - default Tabela de decisAo - default DATABASE - default N.o-Procedural - default Apoio à decisAo
NíVEL
1 1 1 1
1,5 2,5 2,5 2,5 2,5
3
3 3
7 '" ..... , ~ ..J
7 '" ...... , .J
7 '" ..... ' 11 ..J
3,5 7 cc ..... ', ~
4 4 4 4 4
4,5 4,5
5 5 5 5 5 6 6
6,5 7 7 8 9 9
COMANDOS FONTE POR PONTO DE FUNÇ~O
320 320 320 320 213 128 128 128 128 105 105 105 105 105 105 105 105 105
91 91 91 91 91 80 80 80 80 80 71 71 64 64 64 64 64
49 46 46 40 35
.98.
TABELA 11.7 (continuaç:30)
Linguagens selecionadas e seus níveis de PONTOS DE FUNCAO
COMANDOS LINGUAGEM
Estatística - default APL Orientada p/ Objeto - default C Objetivo C + + SMALLTALK Quarta Geraç:3o - default Gerador de Programa - default QUERY LANGUAGE - default SQL Planilha - default Quinta Geraç:3o - default
fonte: CJones, 1988]
NíVEL
10 10 12 12 12 15 16 20 25 27 50 75
POR PONTO DE
32 32 29 29 29 21 20 16 13 11
6 4
FONTE FUNCf.\O
Em seu trabalho, Jones critica a falta de rigor na clas-
sificaç:3o das linguagens de programaç:3o. Expressôes como lingua-
gens de primeira, segunda, terceira e quarta geraçôes, linguagens
p,-ocedLlrais e n3o-procedurais, orientadas para objetos, associati-
vas, n30 conseguem exprimir a capacidade da linguagem de gerar um
sistema, muito menos fornecer um bom parêmetro de compar"aç:3o entre
as diversas linguagens.
Além disso, como comparar uniformemente sistemas que s30
desenvolvidos através de combinaç:ões de diversas linguagens?
A TABELA 11.7 contém uma proposta de equalizaç:3o de al-
.99.
gumas linguagens de pr-ogr-amaç:go selecionadas.
baseia-se no númer-o de comandos da linguagem necessár-ios par-a im
plementar- um ponto de funç:go, fazendo com que se possa compar-ar- as
linguagens entre si e os sistemas ger-ados por- linguagens difer-en
teso
Como exemplo, consider-emos as lingL.agens CaBaL (ANSI 74)
e NATURAL. Par-a compar-ar--se unifor-memente sistemas desenvolvidos
utilizando-se estas duas linguagens em pr-opor-ç:ôes as mais diver-
sas, bastar-ia obser-var- na TABELA 11.7 o nível das linguagens. CO-
BOL cor-r-esponde a uma linguagem no nível 3, isto é, a implementa-
ç:âo de um ponto de funç:go requer- cer-Ca de 105 comandos fonte, e
NATURAL inclui-se no nível 6, ou seja, sgo necessár-ios 53 comandos
fonte par-a implementar- um ponto de funç:âo. Caso CaBaL fosse esco-
lhida como linguagem básica par-a a equalizaç:go, o númer-o de coman
dos fonte dos pr-ogr-amas escr-i tos em NATURAL dever-i a ser- dL.pl i cado.
Deste modo, poder--se-ia compar-ar- os sistemas como se todos utili
zassem somente a linguagem COBOL, anulando os possíveis desvios na
análise compar-ativa causados pelo uso de duas linguagens.
Vale dizer- que a Tabela de Jones contempla apenas 55
linguagens e seus pr-incipais dialetos, de um univer-so estimado em
mais de 500 linguagens de pr-ogr-amaç:âo. A constr-uç:âo de uma tabela
única par-a todas as linguagens demandar-. um enor-me esfor-ç:o e uma
maior- disseminaç:âo do modelo de Pontos de Funç:âo, já com 10 anos
de e>:istência.
.100.
5.3. DEFINICAO DE LINHAS DE CODlGO FONTE
Conforme visto anteriormente, é necessária uma definic;:âo
clara e precisa do que sâo linhas de código fonte. Neste estudo
foram consi deradas dL,as medi das deri vadas di retamente do número de
linhas de código fonte, a saber:
LCF Total de Linhas de Código Fonte - é a soma das
linhas de todos os programas fonte pertencentes a
um sistema, independentemente se esta linha con
tém mais de um comando ou somente parte do coman
do. Sâo exclutdas deste total as linhas dos co
mentários e as linhas em branco.
LCFC - Total Corrigido de Linhas de Código Fonte - é a
soma LCF corrigi-da conforme a TABELA 11.7, de Jo
nes, tendo o COBOL como linguagem básica para
equalizac;:âo.
Pela definic;:âo dada à medida LCF conclui-se ser a mesma
idêntica à DS! ("Delivered Source Instructions"), conforme estabe
lecida por Boehm (1981).
· 101.
6. S1NTESE DOS MODELOS
Os modelos básicos apresentados neste capitulo (Pontos
de Funçªo, COCOMO e BANG) comportam-se de modo semelhante quanto
à sua aplicaçao. Todos estabelecem L\m valor inicial para o porte
de um sistema, ajustando este valor por diferentes critérios a fim
de obterem uma medida final.
O modelo de Análise de Pontos de Funçao , conforme defi
nido por Albrecht [1979J, parte da contagem dos pontos de funçgo
existentes nas entradas externas, saídas externas, arquivos lógl-
cos internos, arquivos de interface e consultas externas. Após a
contagem destes componentes de um sistema, ponderados pela comple-
xidade da funçgo que atua sobre eles, o resultado (PFNA Pontos
de Funçgo Nâo Ajustados) sofre uma correç;go baseada no total do
grau de influência (graduado de ausente, zero, até forte influên
cia, cinco, por característica) registrado a partir de 14 caracte
rísticas gerais do sistema: comunicaçgo de dados, funções distri
buídas, desempenho, configuraçgo usada pesadamente, taxa de tran
saçBes, entrada de dados "on-line", eficiência do usuário final,
atualizaG~o "on-line", processamento complexo, reaproveitamento,
facilidade de instalaçgo, facilidade de operaçgo, múlti-
pIos e mudanças facilitadas. O resultado fornece, entgo, o número
de PONTOS DE FUNÇAO do sistema.
O modelo COCOMO Básico utili2a o número de linhas de có-
digo fonte do sistema como valor inicial. Em seguida, aplica uma
de Suas equaçBes, geradas empiricamente por Boehm [1981J, depen-
· 102.
dendo do modo de desenvolvimento adequado aO sistema (o ... gânico,
difuso ou ... est ... ito) , que fo ... nece o nOme ... o de HOMEM-MES NOMINAL ne-
cessá ... ios ao seu desenvolvimento. Este valo ... se constitui na me-
dida do tamanho do sistema pa ... a o modelo COCOMO Básico.
Já o modelo COCOMO Inte ... mediá ... io ... ep ... esenta uma extensAo
do COCOMO Básico, uma vez que, sob ... e a quantidade de HOMEM-MES NO
MINAL, calculada neste, é aplicada uma co ...... eç:Bo conside ... ando 15
at ... ibutos di ... ecionado ... es de custo: confiabilidade ... eque ... ida do
softwa ... e, tamanho da base de dados, complexidade do p ... oduto, tempo
de execuçAo, memó ... ia p ... incipal, volatilidade da máquina virtual,
tempo de ... esposta pa ... a a equipe de desenvolvimento, capacidade dos
analistas, experiência da equipe na aplicaç:Ao , capacidade dos pro-
gramadores, experiência da equipe na máquin~ virtual, expe~'iência
na linguagem de programaç:Ao, uso de técnicas mode ... nas de p ... ograma-
çAo, uso de ferramentas de softwa ... e e p ... azo ... eque ... ido pa ... a o de-
senvolvimento. Esta ope ... aç:Bo gera o valor final do COCOMO Inte ... -
mediário pa ... a o tamanho do sistema, qL.e é o HOMEM-MES AJUSTADO.
No modelo COCOMO Detalhado tem-se uma extensBo do COCOMO
Intermediário, uma vez que é avaliado o impacto dos atributos di
... ecionadores de custo em cada passo do ciclo de vi.da de um siste
ma.
Finalmente, o modelo BANG propõe a mediçAo de um sistema
através de duas medidas, conforme sua o ... ientaç:Bo básica, se para
as fLtnções (BANGFUNÇI'\O) ou para os dados (BANGDADO>. Na ve ... dade,
DeMarco [1982J propõe a observaç:Ao de um sistema a partir de três
.103.
modelos que, juntos, constituem o modelo de especificac;8es, ou se
ja: um modelo de funçgo, um modelo de dados e um modelo de transi-
ção de estados. Baseando-se nestes modelos, a função métrica rea-
liza a contagem de seus componentes primitivos para estabelecer as
medidas do sistema. Especificamente no cálculo do BANGDADOS, a
métr-ica utiliza o modelo de objetos de um sistema" sobre o q\..tal
sgo contados os objetos, ponderando esta contagem segundo a com
plexidade da implementação dos objetos em função de seus interre
I aci onamentos.
A TABELA 11.8 sumariza as informaç8es básicas dos mode-
los deste estudo. Somente o COCOMO Intermediário aparece destaca-
damente, uma vez que o COCOMO Básico é seu componente, conforme
item 3 da tabela. Vale dizer que seis das oito maneiras de se me-
dir um sistema, analisadas neste trabalho, derivam diretamente
destes modelos, isto é: Pontos de Função, BANGDADOS, COCOMO Bási-
co, COCOMO Básico a partir do total corrigido de LCF, COCOMO In-
termediário e o COCOMO Intermediário a partir do total corrigido
de LCF. As duas maneiras restantes de se medir um sistema base-
iam-se diretamente nos valores de LCF e LCFC.
• 104.
TABELA 11.8
Características dos modelos escolhidos
CARACTERjSTICAS PONTOS DE FUNCAO COCOMO BAHSDADOS
- Autor/Ano Allan Albrecht/1979 Barry Boeha/J981 Tom DeHarco/J982
2 - Base para coleta - Entradas externas - Linhas de código fonte - Diagralas de Objeto de dados - Saldas Externas entregues ao usu~rio
- Arquivos Lógicos - Modo de desenvolvimento - Arquivos de Interface - Consultas ('inquiries")
3 - jndice calculado Pontos de Funç~o Não HD"E"-KES Nooinal - (HHlnoa HOmero de Objetos - 08 inicialmente Ajustados - PFNA's
4 - Fatores considerados • C06unicaçãode dados • Confiabilidade requerida • COlplexidade da no ajuste • Funç6es distribuídas do software imple.entação dos
• Desempenho • Tamanho da base de objetos em função • Configuração usada dados de seus inter-
pEsadamente • Complexidade do produto rei acionalentos • Taxa de transaç6e. • Tempo de Execução • Entrada de dados • MemÓria principal
I!tm-line' • Volatilidade da • Eficiência do mAqui na virtual
usuário final • Teopo de resposta • Atualização 'on-line" • Capacidade dos analista • Processa lento • Experiência na aplicação
complexo • Capacidade dos prog. • Reaproveita.ento • Experiência na • Facilidade de máquina virtual
instalação • Experiência na ling. • Faei Iidade de de progra.aç30
operação • Técnicas oodernas • 'Si te.' lóltiplos de progralação • Hudanças facilitadas • Uso de ferramentas
de sofhare • Prazo requerido para
o desenvolvimento
5 - "edida final PontDs de Funçao - PF HOKE"-HES Ajustado - BAH6DADDS ajustada (H"lajust
• 105.
CAF"1'. TULD III
METDLDGIA DA PESQUISA
.106.
1. I NTRODUÇAO
o objetivo principal do presente estudo foi determinar
qual medida de desempenho no desenvolvimento de sistemas, dentre
as detalhadas no capítulo anterior, apresentou a melhor correlaçâo
com o esforço efetivamente verificado no desenvolvimento de siste-
mas da EMBRATEL.
Os modelos apresentados no capítulo 11 estabelecem cri
térios diferentes no que diz respeito à determinaçâo do tamanho
dos sistemas (softwares). o desempenho no desenvolvimento de 5is-
temas foi medido pela razâo entre o produto obtido (tamanho do
software segundo o modelo utilizado) e o esforço efetivamente rea
lizado em seu desenvolvimento (medido em homem-mês) (Conte, 1986],
Oeste modo, foram avaliadas hipóteses que relacionaram o que cada
um dos modelos define como medida do tamanho do sistema e o esfor
ço para desenvolvê-lo.
Uma vez que os pesquisadores têm buscado um modelo que
melhor avalie a verdadeira dimensâo dos softwares produzidos vi
sando, inclusive, o aprimoramento das previsões referentes aos
prazos e recursos envolvidos no desenvolvimento destes softw~res,
consi deroLl-se oportuna a real i z ação de estudo de natureza e>:plora
tória que apresente, no universo estudado, a validação destes mo-
delas.
Neste capítulo descreve-se a metodologia utilizada para
testar as hipóteses estabelecidas com o objetivo de responder à
• 107.
pergunta da pesquisa. Uma vez apresentadas as hipóteses, defi-
nem-·se as medi das oper "ilC i onai s das var i ávei s dependente e i ndepen-
dentes e os métodos de teste empregados. Finalmente, detalham-se
a unidade de análise e os procedimentos utilizados na coleta de
dados.
.108.
2. PERGUNTA DA PESQUISA
E.ta pesquisa pretendeu identificar, no ambiente especi
fico de desenvolvimento de sistemas da EMBRATEL S/A, que medida de
desempenho apresentou a maior correlaçªo com o eSforço dispendido
no desenvolvimento de sistemas.
Neste sentido, determinou-se o porte (tamanho) dos pro
jetos estudados, segundo cada modelo, contrapondo-os com o esforço
efetivamente realizado para desenvolvê-los.
• 109.
3. HIPOTESES
Para responder à pergunta da pesquisa estabeleceram-se
hipóteses cUJo objetivo é avaliar o grau de relacionamento e>:is
tente entre o esforço realizado pela equipe de desenvolvimento de
um sistema e o tamanho do sistema gerado, segundo cada medida
apresentada. Para tanto, as hipóteses foram operacionalizadas
testando-se o coeficiente de correlaçgo (R) existente entre suas
variáveis, uma vez que o valor encontrado para este coeficiente
indica a extensgo da relaçgo [Wonnacott, 1980].
Os testes de carrel açgo foram efetLt.;\dos entre a vari ável
que representa o esforço efetivamente realizado no desenvolvimento
de um sistema, correspondendo ao número total de homens-mes neces
sários tanto para as tarefas de análise quanto para as de progra
maçgo (HMREAL), e as variáveis decorrentes da aplicaçgo das diver
sas métricas no estabelecimento do tamanho dos sistemas (uma para
cada hipótese)"
Os testes realizados sobre aS hipóteses operacionaliza
das têm como objetivo rejeitar a hipótese nula (Rm.t~.c_ = O), in
dicando a existência de um relacionamento linear, estatisticamente
significativo, entre as variáveis.
" ~.'I
.110.
3.1. H I P O T E S E 1
3.1.1. OBJETIVO
Testar a associaçao entre o esforço realizado no desen
volvimento de um sistema e O nOmero total de linhas de código fon
te do sistema.
3.1.2. OPERACIONALIZACAO
Variável - NOmero total de linhas de código
fonte do sistema.
Medida Operacional - Nómero total de linhas de códi~o
Identificaç;ao
3.1.3. TESTE
fonte do sistema, desconsiderando-
se as linhas em branco e as de co
mentário.
LCF.
As seguintes hipóteses nula (Ho ) e alternativa (H.) se
rao utilizadas no teste da hipótese 1 ao nível de significAncia de
1%:
Ho: RL..cF" = (I
H.: RL..CF <> O
.111.
3.2. H I P O T E S E 2
3.2.1. OBJETIVO
Testar a associaçâo entre o esforço realizado no desen
volvimento de um sistema e o nOmero total de linhas de código fon
te do sistema corrigido pela tabela de Carpers Jones.
3.2.2. OPERACIONALIZACAO
Variável
Medida Operacional
Identificaç;âo
3.2.3. TESTE
NOmero total de linhas de código
fonte do sistema corrigido pela ta
bela de Carpers Jones.
NOmero total de linhas de código
fonte do sistema, desconsiderando
se as linhas em branco e as de co
mentário. Neste total, o nOmero de
linhas escritas em NATURAL será du
plicado numa tentativa de equipara
ção com a linguagem COBOL conforme
observado por Jones [1988J.
LCFC.
As seguintes hipóteses nula (HQ ) e alternativa (H,> se
rão utilizadas no teste da hipótese 1 ao nível de significência de
1%:
Ho: RL.CFC = (I
• 112.
3.3. H I P O T E S E 3
3.3.1. OBJETIVO
Testar a associaçgo entre o esforço realizado no desen
volvimento de um sistema e o tamanho do sistema conforme medido
pelo modelo COCOMO Básico.
3.3.2. OPERACIONALIZACAO
Variável Tamanho do sistema conforme medido
pelo modelo COCOMO Básico.
Medida Operacional - Número de HOMEM-MES NOMINAL cal cu-
Identi fica-f.ft\o
3.3.3. TESTE
lado conforme descrito no modelo
COCOMO Básico, a partir da variável
LCF.
CB.
As seguintes hipóteses nula lHo' e alternativa IH.' se
rão utilizadas no teste da hipótese 1 ao nível de significAncia de
1%:
Ho: Rc:.. = O
H1 : RCEf <)- ()
.. 113.
3.4. HIPOTESE 4
3.4.1. OBJETIVO
Testar a associaçgo entre o esforço realizado no desen
volvimento de um sistema e o tamanho do sistema conforme medido
pelo modelo COCOMO Básico, tendo como base o número total de li
nhas de código fonte corrigido pela tabela de Carpers Jones.
3.4.2. OPERACIONALIZAÇAO
Variável
Medida Operacional
Identificac;;:go
3.4.3. TESTE
Tamanho do sistema conforme medido
pelo modelo COCOMO Básico, tendo
como base o número total corrigido
de linhas de código fonte, segundo
Jones.
NÚmero de HOMEM-MES NOMINAL calcu
lado conforme descrito no modelo
COCOMO Básico, a partir da variável
LCFC.
CBC.
As seguintes hipóteses nula lHo) e alternativa eH.) se
rgo utilizadas no teste da hipótese 1 ao nivel de significAncia de
1%:
H",: Rose = (I
· 114.
3.5. HIPOTESE 5
3.5.1. OBJETIVO
Test.ar a associaç:i'io entre o esforç:o realiz ... do no desen-
volvimento de um sist.ema e o tam ... nho do sistema conforme medido
pelo modelo COCOMO Intermediário.
3.5.2. OPERACIONALIZACAO
Variável Tamanho do sistema conforme medido
pelo modelo COCOMO Intermediário.
Medid ... Operacional Número de HOMEM-ME:S AJUSTADO cal cu-
lado conforme descrito no modelo
COCOMO Básico, a partir da variável
CB.
Identificaç;&\o ex.
3.5.3. TESTE
As seguintes hipóteses nula (H",) e alternativa (H~) se-
ri'io utilizadas no teste da hipótese 1 ao nível de significância de
1%:
Ho: ReI = o
(I
.115.
3.6. H I POTE S E 6
3.6.1. OBJETIVO
Testa~ a associa~go ent~e o esfo~~o ~ealizado no desen
volvimento de um sistema e o tamanho do sistema confo~me medido
pelo modelo COCOMO Inte~mediá~io, tendo como base o n6me~0 total
de linhas de código fonte co~~igido pela tabela de Ca~pe~s Jones.
3.6.2. OPERACIONALIZAÇAO
Va~ i ável_ Tamanho do sistema confo~me medido
pelo modelo· COCOMO Inte~mediá~io,
te~do como base o n6me~o total co~
~igido de linhas de código fonte,
segLlndo Jones.
Medida Ope~acional - Nóme~o de HOMEM-MES AJUSTADO calcu-
ldentificaç;go
3.6.3. TESTE
lado confo~me desc~ito no modelo
COCOMO Inte~mediá~io, a pa~ti~ da
va~iável CBC.
- CIC.
As seguintes hipóteses nula (Ho ) e alte~nativa (H,) se
~Io utilizadas no teste da hipótese 1 ao n1vel de significlncia de
1%:
Roxo
Rc'Jc <>
(I
(I
• 116.
3.7. H I P ri T E S E 7
3.7.1. OBJETIVO
Testar a associaçgo entre o esforço realizado no desen
volvimento de um sist.ema e o tamanho do sistema conforme medido
pelo modelo de Análise de Pontos de Funçgo.
3.7.2. OPERACIONALIZA~AO
Variável
Medida Operaciona)_
Identificaç;go
3.7.3. TESTE
Tamanho do sistema conforme medido
pelo modelo de Análise de Pontos de
FLlnçgo.
Nómero de Pontos de Funçgo que re-
present.am o sistema,
brecht [1984J.
PF.
conforme Al-
As seguintes hipót.eses nula (Ho ) e alt.ernativa IH.) se
rgo utilizadas no teste da hipótese 1 ao nivel de significAncia de
1%:
Ho: R,.,. = (l
H 1 : RF'F <> O
.117.
3.8. H I P O T E S E 8
3.8.1. OBJETIVO
Testar a associa~~o entre o esforço realizado no desen
volvimento de um sistema e o tamanho do sistema conforme medido
pelo modelo BANG.
3.8.2. OPERACIONALIZACAO
Vari ável
Medida Operacional
Ident.ifica~~o
3.8.3. TESTE
Tamanho do sistema conforme medido
pelo modelo BANG.
NOmero de BANGDADOS que representam
o sistema, conforme DeMarco [1982].
BD.
As seguintes hipóteses nula CHo) e alt.ernat.iva CH,) se
r~o utilizadas no test.e da hipótese 1 ao nivel de significAncia de
1%:
H 2.: Rao <> O
· 118.
4. TESTE DE HIPCTESES
No teste das hipóteses propostas neste trabalho foi em
pregado o que Wonnacott [1980J chama de "Processo tradicional",
onde é efetuada análise de regresslo, obtendo-se estimadores dos
coeficientes dos modelos, seguindo-se testes de sua validade.
A regresslo simples é um método utilizado para estimar
uma equaçlo cuja representaçlo geométrica seja equivalente ao
ajuste de cIma reta aos vários pontos dispersos oriundos do rela-
cionamento de duas variáveis. A variável dependente (Y) é rela-
cionada a uma variável independente (X) que supostamente a estaria
e}'plicando. Tal técnica estatística fornece uma equaçlo para a
va~iével dependente em análise, possibilitando infer~ncias sobre a
populaçlo, a partir do estudo da amostra.
forma:
onde:
A equaçlo resultante da regresslo linear tem a seguinte
Y = a + b X
Y = variável dependente
a = intercepto Y
b = coeficiente angular
X = variável independente
a b = par.metros da equaçlo
O método é desenvolvido matematicamente, de modo que a
• 119.
eqL.aç:.'3o resul tante da anál i se de regress.'3o com a vari ável expl i ca
tiva produza o menor erro en'tre os valores reais históricos e os
valores estimados pela regress.'3o.
Para a estimativa dos parâmetros da equaç:.'3o de r-egres
sgo, aplica-se o critério dos "mínimos quadrados", conforme deta
lhado em Wonnacott [1980J.
A adequaç:.'3o dos resultados obtidos com a equaç:.'3o de re
gress.'3o é avaliada através de procedimentos estatísticos que de
terminam os limites de confianç:a no teste das hipóteses. No estudo
em quest.'3o s.'3o analisados o valor do coeficiente de correlaç:.'3o
(R), a estatística t e o coeficiente de determinaç:.'3o da regress.'3o
(R"') •
Conte [1986J afirma que o grau de relacionamento entre
dois conjuntos de medidas pode ser freqUentemente avaliado através
do coeficiente de correlaç:.'3o R. A hipótese nula operacionalizada
(R = O) é usualmente testada pais tal valor in-
dicaria a ausência de relacionamento entre as variáveis indepen
dente e dependente.
A estatística t indica a significância da variável inde
pendente em prever o comportamento da variável dependente. O valor
de t é confrontado com o seu valor crítico, ou valor de pr-ova,
conforme o nível de significância estabelecido para a regressão.
o coeficiente de determinaç:ão (R2) indica o quanto da
.120.
variaç~o da variável dependente pode ser e>:plicada pelo comporta
mento da variável independente, sendo que, quanto maior o valor de
R2, melhor a equaçgo.
Adicionalmente, analisaram-se os diagramas de dispersgo
das variáveis envolvidas em cada hipótese, dando uma idéia gráfica
do grau de correlaçgo e>:istente entre elas.
utilizou-se, para o processamento dos dados, o software
SAEG (Sistema para análises estatísticasl, versão 3.0, desenvolvi
do pela Universidade Federal de Viçosa, Minas Gerais, para apoiar
análises estatísticas uni e multivariadas, disponível na Empresa
Brasileira de Telecomunicações S/A - EMBRATEL.
Empregou-se o procedimento REGRELIN, obtendo-se, em um
sÓ tempo, estatísticas simples (média, desvio-padrgo e número de
observações), matri z de correi ação entre as vari, ávei s, parâmetros
da regressgo (coeficiente, constante, desvio, estatística t, BETA,
significância e coeficiente de determinacgo R2) e análise de va-
riância (graus de liberdade, soma dos quadrados,
estatística F e significâncial.
quadrado médio,
A aplicac~o de tal programa necessitou, ainda, de um mi
crocomputador compatível com o IBM-PC possuindo alguma memória au
>:iliar em disco rígido (especificamente foi usado um equipamento
MEDIDATA MXT, COM 604 KBytes de memória principal e um disco rígi
do de 10 MegaBytesl.
· 121.
S. UNIDADE DE ANALISE
A pOpLII aç:fAo do estLldo consti tui LI-se de si stemas desen
volvidos na EMBRATEL S/A.
A EMBRATEL - Emp.-esa B.-asilei.-a de Telecomunicaç:8es S/A
se enquad.-a no setor- público de p.-estaç:fAo de se.-viç:os, atuando em
todo o B.-asil, com sede no Rio de Janei.-o. Os se.-viç:os de teleco-
municaç:8es p.-estados pela EMBRATEL têm ab.-angência tanto doméstica
quanto inte.-nacional.
A seleç:lo dos sistemas integ.-antes deste t.-abalho aten
deu aos seguintes c.-ité.-ios básicos:
o sistema deve.-ia possui.- documentaç:fAo completa, es
pecialmente do "p'-ojet.o ope.-acional", OLI "p,-ojeto do
p.-oduto" e II projeto detalhado", confo.-me Boehm
[1981J, fundamental na determinaç:lo dos PONTOS DE
FUNÇ,!'\O;
o sistema deve.-ia possui.- o diag.-ama de objetos, fun
damental na dete.-minaç:lo do BANG;
o .-esponsável pelo desenvolvimento do sistema deve.-ia
se.- facilmente contatado, pe.-mitindo o levantamento
de info.-maç:8es r-elativas ao HMREAL e info.-maç:ôes com
plementa.-es aos modelos COCOMO e PONTOS DE FUNÇ,!'\O.
.. 122.
o segundo requisito foi o grande limitador da amostra.
Pode-se dizer que isto deveu-se ao fato de que a função de Admi
nistração de Dados existe efetivamente na empresa somente a partir
de 1985.
Assim sendo, dos 218 projetos catalogados na biblioteca
de sistemas e>,istentes na empresa, somente 31 possuiam diagramas
de objeto. Destes, 4 não atendiam a pelo menos uma das outras
condiç5es básicas, resultando 27 projetos em plenas condiç5es de
integrarem a unidade de análise.
N 123.
6. O PROCESSO DE COLETA DE DADOS
o instrumento de pesquisa utilizado por este estudo foi
o questionário contido no ANEXO 1. Objetivou-se levantar todas as
informaç5es necessárias ao estabelecimento das medidas de produti
vidade de cada sistema, de acordo com os modelos objetos desta te
se: COCOMO, Pontos de FLlnçgo, BANG e Linha de Código Fonte.
Visando agilizar o processo de coleta de dados, bem como
assegurar a homogeneidade das informações coletadas, o próprio
pesqui sador entrevi stou cada anal i sta responsável pelos si stemias.
Nas entrevistas, sempre marcadas com antecedência, o pesqLli sador
apresentava o qLlesti onári o, estabel ecendo cl aramente os obj et i vos
da pesquisa e, em seguida, passava a aplicar o questionário, ex
plicando cada um dos modelos aos entrevistados, de modo a obter
com o má,:imo de precisSo a resposta às questões nele contidas.
A informaçSo sobre o esforço efetivamente realizado para
o desenvolvimento do sistema, medido em HOMEM-M~S, ou seja,
(HM)"'EA1... foi obtida, quando possivel, do Relatório de Acompanha
mento do Desenvolvimento e Manutenç.go dos Sistemas, por equipe de
desenvolvimento, sendo que tal informaçgo era submetida à ratifi-
caçgo dos entrevistados. Quando o sistema em análise ngo constava
de tal relatório, o próprio analista responsável fornecia este da
do. Deve-se ressal tar que· foi enfati z ada sobremanei ra a i mportân
cia da precisgo desta informaç.go no estabelecimento da produtivi
dade obtida nos diversos modelos e em sua posterior análise esta
tísticaa
.124.
No modelo COCOMO, o QUADRO 11.8 serviu de base para a
identificaçao do modo de desenvolvimento utilizado pelo sistema em
questao.
Foi necessária a elaboraçao de dois programas para o le
vantamento do número de linhas de código fonte entregL\es (Udelive
red source instructions - DSI") pelos sistemas desenvolvidos na
instalaçao central da empresa, isto é, nO equipamento IBM 3090,
que Llt i I i zaram as 1 i nguagens CaBaL e NATURAL na SLla confecçâo. Os
sistemas desenvolvidos em outros "sites ll da empresa, dada a impos
sibilidade momentãnea da elaboraçâo de programas semelhantes, ti
veram suas linhas contadas manualmente.
o modelo de Pontos de Funçao teve como base de levanta-
mento o Projeto Operacional (Físico) dos sistemas,
estabelecimento exato do número de pontos de funçâo
pelo sistema.
garantindo o
i mp I ement ados
No modelo BANG, o próprio pesqLtisador calculou o BANGDA
DOS dos sistemas a partir de seus Diagramas de Objeto, ratificando
o cál CLII o efetuado com os anal i stas responsávei s pelos si stemas.
A maior dificuldade encontrada no processo de coleta de
dados foi a falta de disponibilidade de tempo de alguns analistas
para serem entrevistados sobre os sistemas, Lima vez que, em média,
gastou-se de 3 a 4 horas na apl icaçâo do qLlestionário sobre cada
sistema. Esta dificuldade agravou-se ainda mais com a descentra-
.125.
li zação dos r"ecu'-sOs de desenvol vi mento de si stemas (analistas e
p.-og.-amado.-es) pa.-a as á.-eas .-esponsáveis pelos sistemas, du.-ante
a elabo.-ação desta tese. Tal fato t,-oL\Xe um .-eta.-do neste p.-oces-
so, não p.-evisto inicialmente, de modo que o levantamento começou
em agosto de 1989, t.e.-minando apenas no meado de dezemb.-o.
.126.
CAP-J:.TULO IV
RESULTADOS
.127.
1. RESULTADOS DESCRITIVOS
EMBRATEL.
As hipóteses desta tese foram testadas em 27 sistemas da
O desenvolvimento de tais sistemas se deLI exclusivamen-
te na EMBRATEL, utilizando os recursos internos disponíveis, tanto
no que diz respeito ao pessoal (analistas e programadores) como ao
hardware e software que apoiaram o desenvolvimento.
As seguintes áreas funcionais podem ser identificadas na
EMBRATEL:
Area Admi.nistrativa
Area Financeira
Area de Opera<;ões Nacionais
.Area de Opera<;ões Internacionais
Area de Desenvolvimento
Area da Presidência
Os analistas e programadores, que compÕem as equi.pes de
desenvolvimento, se encontram localizados nas diversas áreas res
ponsáveis pelos respectivos sistemas, ou seja, a EMBRATEL mantém
uma estrutura descentralizada para o desenvolvimento das aplica
<;ões necessárias.
· 128.
Adicionalmente, e>:iste um Setor de Planejamento e Con
trole dos Sistemas de Informa~ão, para toda a empresa, pertencente
à area da Presidência, isto é, atua de modo centralizado contem
plando o ambiente descentralizado de desenvolvimento de sistemas.
Os projetos estudados nesta tese foram desenvolvidos ao
longo dos ':'1 ti mos 8 anos par a LtSO nas di versas áreas da empresa.
O QUADRO IV.1 apresenta as caracteristicas gerais dos projetos
componentes da amostra. A seguir, detalham-se as várias colunas
desta tabela:
- NQ DO PROJETO -
Numeração seqUencial para identificação dos
projetos componentes da amostra.
- ÁREA RESP. -
Sigla da Área Funcional da PRODUTIVA S.A. res
ponsável pelo projeto:
PRE Presidência
ADM Administrativa
FIN Financeira
INT Opera~8es Internacionais
NAC Operaç5es Nacionais
LINGUAGENS DE PROG. -
Linguagens de programa~ão utilizadas no proje
to:
COB COBOL
NAT NATURAL
.129.
HOMENS-M~S -
- LCF -
Esforço efetivamente realizado no desenvolvi
mento do projeto medido em HOMENS-M~S.
Número total de linhas de código fonte do pro-
jeto, isto é, somatório das linhas de todos
os programas do produto efetivamente entregue
aos usuários, desconsiderando-se as linhas em
branco e as de comentário.
.130.
QUADRO IV.l -----------
Características Gerais dos Projetos
N! DO ~REA LINGUAGENS HOHENS- lCF PROJETO RESP. DE PROG. m
01 INT coa 12,6 5 .. 594 02 INT COB/NAT 14,5 11.358 03 PRE COB 16,8 5.610 04 NAC COB/NAT 52,7 76.709 05 INT COB/NAT 21,7 5.800 06 NAC COB/NAT 55,6 40.143 07 PRE COB 24,8 9.864 08 FIN COB/NAT 13,5 4.996 09 FIN COB/NAT 19,3 39.469 10 FIN COB/NAT 28,1 24 .. 635 11 ADM NAT 14,5 10.192 12 FIN COB/NAT 32,0 17.748 13 FIN COB/NAT 31, 1 20.398 14 INT COB/~lAT 51,6 40.819 15 PRE NAT 14,5 3 .. 983 16 PRE NAT 23,8 16.493 17 NAC NAT 17,5 7 .. 356 18 PRE COB/NAT 54,5 39.544 19 FIN COB/NAT 36,5 43.661 20 PRE NAT 54,0 17 .. 055 21 ADM COB/NAT 16,0 5.710 22 ADM COB/NAT 15, 1 16.006 ..,.,. 4_' INT COB/NAT 17,6 15.829 24 INT COB/NAT 25~4 9.945 25 INT COB 38,5 40.734 26 NAC NAT 31,0 35.990 27 NAC COB 60,0 25.537
o QUADRO IV.2 reune as características dos projetos es-
pecificamente ligadas aos modelos deste estudo. Os valores apre-
sentados nesta tabela se encontram com O maior grau de precisâo
possível. As colunas incluidas no QUADRO IV.2 têm a seguinte des-
criç:âo:
.131.
- N2 DO PROJ. -
Numera~lo seqUencial para ident fica~lo dos
projetos componentes da amostra.
- LCF CORRIGIDO -
Número total de linhas de código fonte do pro
jeto, desconsiderando-se as linh s em branco e
as de comentário. Este valor.s receberam,
quando necessário, a corre~lo co forme indica-
da por Jones [1988J. Especific
ro total de linhas de programa
NATURAL foi duplicado de mod
o núme
escritos em
a tornar-se
equivalente. quantidade de lin as dos progra
mas escritos em COBOL.
- MODO DESENV. -
Modo de desenvolvimento utiliz do em cada pro
jeto, conforme definido por Bo hm [1981):
ORG modo orgênico
DIF modo difuso
RES modo restrito
HOMEM-MES NOMINAL
Valor do Homem-me,;; Nominal ca cLtlado conforme
indicado no modelo COCOMO Básico
1981), tendo com base o valor de LCF
IV.21 e o de HOMEM-MES (QUAD O IV.ll.
HOMEM-MES AJUSTADO -
[Boehm,
(QUADRO
Valor do Homem-mes Aj LIstado ai cul ado conforme
indicado no modelo O Intermediário
[Boehm, 1981), tendo como b se o valor de LCF
· 132.
(QUADRO lV.2) e o de. HOMEM-MES (Q ADRO IV.1).
_ HM NOMINAL CORRIGIDO -Valor do Homem-mes Nominal cal·cLtlado conforme
indicado no modelo COCOMO Básico, tendo como
base o valor de LCF CORRIGIDO (Q ADRO lV.2l e
o de HOMEM-MES (QUADRO IV.1).
_ HM AJUSTADO CORRIGIDO -Valor do Homem-mes Ajl-lstado cal L.,lado conforme
indicadO no modela COCOMO Inter ediário, tendo
como base o valor de LCF COR 'IGIDO (QUADRO
1\1.2) e o de _HOMEM-MES (QUADRO V.U.
_ PONTOS DE FUNÇAO -NQmero total de pontos de FI-ln~ o do projeto,
conforme definido por Albrecht [1984J.
_ BANGDADOS -Nómero do BANGDADOS do projeto como estabele-
cido por DeMarcO [1982J.
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
.133.
QUADRO IV.2 -----------
Características específicas dos proje os
N~ DO LCF MODO HOME"-m HOHEH-m H" NOMINAL "" AJUSTA0 PONTOS DE BANGDADOS PROJ. CORRIGIDO DESEHV. tlOHINAL AJUSTADO CORRIGIDO CORRI SIDO FUNCAO
01 5.594 DIF 20,63338 14,99144 20,63338 14,9914 93,45 46,8 02 17.687 ORG 41,04091 27,54855 65,34116 43,8600 358,56 158,0
03 5.610 DIF 20,69949 23,47708 20,69949 23,4770 175,68 30,6
04 120.411 RES 511 ,65075 . 431,15316 87E,93b3S 740,6540 519,40 223,8
05 9.163 RES 23,08190 25,72388 39,95796 44,53160 292,32 82,1
06 42.310 ORS 154,50420 109,70904 163,27329 115,93572 604,80 186,8
07 9.864 DIF 38,94581 38,30457 38,94581 35,30457 265,50 40,6
08 5.307 ORS 17,32621 17,29996 18,46042 18,43245 172,02 23,8
09 49.179 ORS 151,78152 100,72499 191,21355 121.,89281 883,28 245,7
10 37.299 ORS 92,52949 . 55,92789 143,03161 86,45305 418,46 24,6
11 20.384 DIF 40,39911 52,12415 87,80624 113,29027 195,20 67,6
12 24.658 DIF 75,19148 51,63118 108,67110 74,62038 407,68 64,0
13 33.604 ORE 75,89566 79,93543 12B, !918B 135,01528 316,35 86,6
14 43.485 RES 239,98984 237,18883 258,91988 255,89793 384,18 125,8
15 7.966 ORS 13,65749 13,88089 28,27823 28,74079 276,12 60,8
16 32.986 DIF 69,26229 45,72655 150,53950 99,38528 460,52 62,3
17 14.712 DIF 28,03884 27, 577t8 60,94156 59,93816 392,85 41,6
18 59.057 ORG 152,08438 102,52787 231,73142 156,22202 635,55 21,6
19 53.251 DIF 206,07541 124,55881 257,39989 155,58103 503,98 53,0
20 34.110 DIF 71,91098 70,30301 156,29633 152,80146 1318,24 65,0
21 9.653 D!F 21,11318 15,72141 38,01395 28,30615 236,22 28,0
22 31.438 RES 78,03643 52,2172'1 175,43002 117,38722 291,04 203,7
23 18.816 ORS 58,15354 66,2983. 69,72743 79,49326 353,10 146,3
24 12.436 DIF 39,30417 39,24461 50,48515 50,40865 390,87 45,9
25 40.734 ORS 156,89348 159,45988 156,89348 159,45988 696,46 119,0
26 71.980 DIF 165,97586 123,21323 360,74350 267,80021 1033,20 199,3
27 25.537 RES 136,69791 455,69927 136,69791 455,69927 278,40 58,S
As figuras seguintes evidenciam o comport mEnto dos pro-
jetos, em relação às características agrupadas nos .UADROS IV.1 e
IV.2. Esta análise descritiva visa estabelecer um bom nível de
entendimento sobre os dados incluídos neste estudo, facilitando a
co~preensão de seus resultados.
.134.
A FIGURA IV.l mostra a distrí.buic;âo dos rojetos estucj,a-
dos por área responsável na empresa.
FIGURA IV.1
Distribuição dos projetos por· Area Responsáv~l
11. 11.% 18.52X
22.22.%
25.93X
11 ADf1
11 PRE
UI FUi
rn INT
O NAC
• 135.
A FIGURA IV.2 apl'"esent-a a distl'"ibuic;;:l':\o dos sistemas pOI'"
linguagem de pl'"ogra~ac;;:l':\o utilizada. Observa-se que a maiol'" parte
dos pl'"ojetos fui desenvolvida com as linguagem COBOL e NATURAL,
usadas em conjunto.
FIGURA IV.2
Distribuic;;:âo dos projetos por Linguagem de Programaçâo Utilizada
18.52.'%
2.22?-
59. 26-?-
o COBOL
Ull INlIAlT UIRAL
BlI COB./NAT
.. 136 ..
A distribuiç;go dos projetos, segundo o modo de desenvol-
vimento aplicado conforme definido no modelo COCOMO, encontra-se
na FIGURA IV.3. Observa-se que quase metade dos projetos estuda-
dos foram desenvolvidos no modo difuso.
FIGURA IV.3
Distribuiç;30 dos projetos por Modo de Desenvolvimento
13.52.%
37.04.%
o I[]!lRGAIM I C I[)
1II DIIFUSO
m RIESlrRIlr O
As FIGURAS IV.4 a IV.12 apresentam LIma nítida visgo dos
valores assumidos pelas características dos projetos contidas_ nos
QUADROS IV.l e IV.2, adicionando estatísticas descritivas básicas
(os valores destas estatísticas foram apresentados pelo programa
SAEG de análises estatísticas).
-!
60
50
40
20
10
.137.
FIGURA IV.4
Homem-Mes Real por projeto
-
-+ 123456739111111111122222222
012345673901234567 NUMero dos ProJe~os
Valor- mínimo Valor- má" i mo Amplitude Média Aritmética Desvio Padrâo Vari'\\ncia
12,6 60,0 47,4
29,37778 15,56051 242,1296 '.
400
200
100
o
• 138.
FIGURA IV.5
Homem-Mes Nominal por projeto
• I ... .11 .1" .11 . n 1.11 I.J lI! 1 2 3 "'-8 !5 oS 7 3 '9 li. 11 1 li. li. 1. li. li. 1 2 2 2 2 2 2 2 2
012345673901234567 i'lulMe,-o dlos P,-o..ii e"t os
Valor mínimo ValorH má>! i mo Amplitude Média Aritmética Desvio F'adr!3o Vari g.,nci a
13,65749 511,6507 497,9932 100,0324 104,0454 10825,45
HOl"llel"llfies:
A ... ;' ... :s:-t a.dlo
500
450
350
300
250
200
150
1.00
.139.
FIGURA IV.i>
Homem-Mes Ajustado por projeto
-• 11 '" ----
I .. !!I 11 111 Im 18 n rI •.•. 11 LJ.~JI.I :11.23·"'56789111 II ]l11 J. 1122222222
012345678901234567 NUl"lle,-oo dloos: P,-ooJ e-t oos:
Valor mínimo Valor mtl>! i mo Amplitude Média Aritmética Desvio Padrâo Vari.:l.ncia
13,88089 455,3993 441,8184 94,89513 112,8738 12740,5
900
700
600
HOMeM- 500 Mes
NOMina, 1 Co,.....-ig. 400
200
100
o
. 140.
FIGURA IV.7
Homem-Mes Nominal Corrigido por projeto
E
.1 _ • 11 _ nJ ,E .6 ,111 .1,11 123456789:11.11:11.11111:11.22222222
012345673901234567 NUMe.-o dos P.-oJe~os
Valor mínimo Valor má>: i mo Ampl i tLlde Média Aritmética Desvio Padrão Variânc:ia
18,46042 878,9363 860,4759 149,5282 169,6967 28796,96
300
700
500 HOMe ... -
tr"lles _ • ...,..,.", Ajus.... ....~.
Coa-,- ig.
200
100
(1)
• 141.
FIGURA IV.8
Homem-Mes Ajustado Corrigido por projeto
~
.111 ... .11 11_ I le .•. 1 .• .81 In 1234567391 1 1 1 1 1 1 :Il 1 122222222
012345673901234567 NUMe,-o dos P,-oj ei' os
Val ar mí ni mo Val ar máx i mo Amplitude Média Aritmética Desvio Padrl'lo Variênci a • • •
14,99144 740,654
725,6625 134,9474 154,0482 23730,83
· 142.
FIGURA IV.9
Total de Linhas de Código Fonte por projeto
:1 I. H lI! .1 li! D -
B I 123456739111111112122222222
012345673901234567 lNul"llepo dos P,-o,Jef-os
Valor mínimo Valor má>:imo Amplitude Média Aritmética Desvio Padrl:\o Variância
.. 3983 76709 72726
21895,48 17445,42
304342500
To1-<fl CO~-~-1g .
de Linhas:
de Codigo Foni'e
.143.
FIGURA IV.IO
Total Corrigido de Linhas de Código Fonte por projeto
140000
120000 .
,
o 'II.I.R .1 .1.11 ' .11 e .1 .1 123456739111111111122222222
012345673901234567 NUMe,-o dos: Pro"'; e1" os
Valor mínimo VaI ar máx i mo Amplitude Média Aritmética Desvio Padrgo Vari&ncia
• 5307 120411 115104
31008,55 25346,62
642451000
Pon1'-os de
Funca.o
.144.
FIGURA IV.l1
Pontos de Funçao por projeto
1200
800
400
200
(() I I I I· 12345ô789111111111122222222
012345ô789012345ô7 NUMepo dos P.-o,Je1'-os
Valor mínimo Vai or máx i mo Amplitude Média Aritmética Desvio Padrgo Vari~ncia
93,45 1318,24 1224,79
442,7197 276,7157 76571,59
BANO DADOS
250
200
150
100
50
o
.145.
FIGURA IV.12
BANGDADOS por projeto
.-- ~
I E I & I ,I 1:23456.7391111111111112222:2222
0123456.73901234567 NUMero dos ProJe~os
Valor mínimo VaIo,.- má>: i mo Amplitude Média A,.-itmética Desvio Pad,.-1'!o Va,.-i~ncia
. 21,6 245,7
,224,1 93,02962 68,28118 4662,319
.146.
2. TESTE DE HIPOTESES
2.1. DIAGRAMAS DE DISPERSA0
A observaç:ao dos diagramas de dispersálo objetivou, caso
possível fosse, identificar, através da análise gráfica, a medida
de tamanho de sistemas de melhor correlaçálo linear com o esforço
realizado no desenvolvimento dos projetos.
A análise destes diagramas CANEXO 2) forneceu subsídios
para concluir que várias medidas possL,em "bom" grau de correlaçálo
com o esforço realizado. No entanto, nálo foi possível determinar
a melhor, apenas pela análise gráfica.
Por outro lado, observou-se que a medida BANGDADOS mos-
trou o menor nível de correlOlçálo.
esta conclusao.
A FIGURA 8 do ANEXO 2 ratifica
.147.
2.2. REGRESSAO LINEAR
As hipóteses foram efetivamente testadas a partir da
análise de regressão linear simples sobre cada uma das medidas de
tamanho de sistema (variável independente) em relação ao esforço
realizado no seu desenvolvimento (variável dependente).
Neste teste utilizou-se o coeficiente de correlação R.
As distribuiç5es t de Student foram usadas como estatís·ticas de
teste visando a rejeição das hipóteses nulas a um nível de signi-
ficência de 1%. o valor critico de t a este nível de significên-
cia, com 25 graus de liberdade, é de 2,485.
Os valores da regressgo foram obtidos através do proce
dimento "REGRELIN" do programa estatístico SAEG.
O QUADRO IV.3 sumariza os valores obtidos a partir da
regressgo linear efetivada para cada uma das hipóteses.
.148.
QUADRO IV.3
Resultados das regressOes lineares
VARIÁVEL SIGNI-HIPOTESE INDEPENDENTE R FICANCIA t R2
1 LCF 0,69622 0,0000 4,84952 0, 4~3473
2 LCFC 0,60261 0,0004 3!,77558 0,36314
3 CB ü,64935 0,0001 4,26926 0,42165
4 CBC 0,53824 0,0019 3,19320 0,28970
5 CI (),72551 0,0000 5,27097 0,52636 ,
6 ClC 0,65943 0,0000 4,38581 0,43484
7 PF 0,48840 0,0049 2,79845 0,23853
8 BD 0,13713 0,2476 0,69219 0,01880
Pelos valores do QUADRO lV.3, embasado nos procedimentos
para teste das hipóteses, conforme ítem 4 do Capitulo con-
cluiu-se:
HIPOTESE 1 R"'CF = O)
Hipótese nula rejeitada. O valor de t calculado
(4,84952) e>,cedeu o valor crítico de t (2,485) ..
Deste modo, R é estatisticamente diferente de ze-
r-o, ou seja, existe um relacionamento linear, es-
tatisticamente significativo, entre o número total
de linhas de código fonte de um sistema (LCF) e o
esforço efetivamente realizado para desenvolvê-lo
(HMREAL> .
.149.
HIPOTESE 2
Hipótese nula rejeitada. o valor de
(3,77558) e>:cedeu o valor critico de
t
t
calculado
(2,485) .
Deste modo, R é estatisticamente diferente de ze
ro, ou seja, existe um relacionamento linear, es
tatisticamente significativo, entre o número total
de linhas de código fonte de um sistema corrigido
pela tabela de Carpers Jones (LCFC) e o esforço
efetivamente realizado para desenvolvê-lo (HMRE-
ALl •
HIPOTESE 3 Roa = O)
Hipótese nula rejeitada. o valor de t calculado
(4,26926) e>:cedeu o valor critico de t <:2",485) ..
Deste modo, R é estatisticamente diferente de ze
ro, ou seja, existe um relacionamento linear, es
tatisticamente significativo, entre o tamanho do
sistema (HOMEM-MES NOMINAL) conforme medido pelo
modelo COCOMO Básico (CB) e o esfol~ço efetivamente
realizado para desenvolvê-lo (HMREAL).
.150.
HIPOTESE 4 Rese = O)
Hipótese nula rejeitada. o valor de t calculado
(3,19320) excedeu o valor crítico de t (2,485).
Deste modo, R é estatisticamente diferente de ze
ro, ou seja, existe I..\m relacionamento linear, es
tatisticamente significativo, entre o tamanho do
sistema (HOMEM-MES NOMINAL) conforme medido pelo
modelo COCOMO Básico, tendo como base o número to-
tal de linhas de código fonte, corrigido segundo
Jones (CBC) e o esforço efetivamente realizado pa
ra desenvolvê-lo (HMREAL).
HIPOTESE 5 Rc. = O)
Hipótese nula rejeitada. O valor de t calculado
(5,27097) excedeu o valor crítico de t (2,485).
Deste modo, R é estatisticamente diferente de ze
r-o, ou seja, e>:iste um relacionamento linear,. es
tatisticamente significativo, entre o tamanho do
sistema (HOMEM-MES AJUSTADO) conforme medido pelo
modelo COCOMO Intermediário (CI) e o esforço efe
tivamente realizado para desenvolvê-lo (HMREAL).
· 151.
HIPOTESE 6 Rc%c = O)
Hipótese nula rejeitada. 'O valor de t calculado
C4,38581> e>:cedeu o valor critico de t (2,485) •
Deste modo, R é estatisticamente diferente de ze
ro, ou seja, existe um r-elac:ionamento linear, es
tatisticamente significativo, entre o tamanho do
sistema CHOMEM-MES AJUSTADO) conforme medido pelo
modelo COCOMO Intermediário, tendo como base o nú
mero total de linhas de código fonte, corrigido
segundo Jones CCIC) e o esforço efetivamente rea
lizado para desenvolvé-Io (HMREAL).
HIPOTESE 7
Hipótese nula rejeitada. o valor de t calculado
(2,79845) e>:cedeu o valor crítico de t (2,485).
Deste modo, R é estatisticamente diferente de ze
ro, ou seja, existe um relac·ionamento linear, es
tatisticamente significativo, entre o tamanho do
sist.ema (PONTOS DE FUNÇI'\O) conforme medido pelo
modelo de Análise de Pontos de Funçgo CPF) e o
esforço efetivament-e I"ealizado para desenvolvé-lo
(HMREAU.
.. 152.
HIPOTESE B RSD = O)
Não foi rejeitada a hipótese nula. o valor de t
calculado (0,69219) localizou-se no interior do
intervalo do valor crítico de t (entre - 2,485 e
2,485) .. Deste modo, não se pode afirmar que R se-
ja estatisticamente diferente de zero, isto é, ngo
existe Llm relacionamento linear, estatisticamente
significativo ao nível de 1%, entre o tamanho do
sistema (BANGDADOS) conforme medido pelo modelo
BANG (BD) e o esfor~o efetivamente realizado para
desenvol vê--l o (HMREAL).
• 153.
CAP:f.TULCl V
CClNCLUSeiES
.154.
CONCLUSOES
A pesquisa realizada visou identificar, em um conjunto
de sistemas desenvolvidos na EMBRATEL, que medida de desempenho se
constituia a mais aderente ao esforço realizado para desenvolvê-
los.
Deste modo, numa primeira análise dos resultados obtidos
pela aplicação dos diversos métodos, foi avaliada a existência ou
nlo de uma associação entre o tamanho (porte) do sistema, conforme
mensur,õ\do por cada método, e o esforço real i z ado para desenvol vê
lo.
Observou-se qL.e somente no modelo BANGDADOS (Hipótese 8)
não houve condições de se rejeitar a hipótese nula. Uma vez que
as hipóteses 1 a 7 demonstraram existir correlaçlo entre tamanho e
esforço, a um alto nível de significAncia, pode-se concluir que:
OL' os modelos de objetos que serviram de base para o estabeleci
mento do BANGDADOS nlo foram construídos de forma homogênea pelas
equipes de desenvolvimento, ou a medida proposta por DeMarco
[1982] n:;lo consegue sintetizar o conjunto de fatores que determi-
nam o porte de um sistema. São necessários estL.dos adicionais pa-
ra que se possa firmar uma opinião conclusiva.
o segundo passo da anál i se dos resL.l tados concentroL.-se
nas medidas que efetivamente indicaram a existência de uma asso
ciação entre tamanho e esforço, visando apontar a medida mais ade-
rente à realidade da EMBRATEL. Neste sentido, foram comparados os
.155.
coeficientes de determinaçgo decorrentes das regressões lineares
realizadas nos testes das hipóteses 1 a 7 (QUADRO IV.3). Con-
cluiu-se, entgo, que a medida de tamanho de sistema especificada
pelo modelo COCOMO Intermediário (R2 = 0,52636) é a mais ajustada
ao ambiente de desenvolvimento de sistemas da EMBRATEL, onde 521.
da variação ocorrida no esforço efetivamente realizado para o de
senvolvimento dos sistemas da empresa conseguem ser explicados pe
lo comportamento da variável CI, que representa o tamanho dos sis
temas pela quantidade de HOMEM-MES AJUSTADO necessários ao seu de
senvolvimento.
Este fato, porém, ngo garante que esta medida possa ser
utilizada como previsora do tempo e dos reCL.rsoS humanos necessá-
rios ao desenvolvimento de L.m sistema. Isto porque o item básico
para a determinaçgo da quantidade de HOMEM-M~S AJUSTADO é o n~.mero
total de linhas de cÓdigo fonte do sistema (LCF). E este nOmero
somente será obtido, com precisgo, ao final do projeto, havendo,
portanto, total dependência do "feeling" de quem está estimando
este valor antecipadamente, com o objetivo de usar o modelo COCOMO
Intermediário para realizar as previsões necessárias.
Associada ao estabelecimento prévio do número de linhas
de código fonte está a definiçgo da linguagem de programaçgo a ser
utilizada na construção dos sistemas. ~ bastante "razoável!!, <:on-
forme Jones [1988], que o número de linhas varie segundo a lingua-
gem de programaçgo em uso. Deste modo, os especi ai i stas que f ar-go
as previsões devem levar em consideraçgo tal fato. A dificLlldade
de termos este modelo como previsor aumenta ainda mais se conside-
.156.
rarmos que uma boa parte dos sistemas slJo construídos com mais de
uma linguagem de programa~lJo (na amostra estudada, cerca de 60%'.
Um resultado importante ocorreu com as hipóteses 2, 4 e
6, que tiveram o total de linhas de código fonte corrigido pela
TABELA 11.7, levando em considera~go as observa~aes de Jones
[1988J. Esperava-se, inicialmente, uma melhora nos valores de R'"
obtidos nas hipóteses 1, 3 e 5, respectivamente. o que se regis-
trou foi exatamente o contrário. Nos três casos reduziu-se o po-
der de explica~lJo da varia~ão do esfor~o efetivamente realizado no
desenvolvimento dos sistemas.
Pesquisas futuras poderão verificar com maior profundi
dade a proposi~ão de Jones neste contexto.
A observa~lJo das hi póteses 1, 3 e 5 revel aLI um i nteres-
sante resultado. Na popula~lJo considerada, a aplica~lJo das equa-
~5es fundamentais do COCOMO Básico sobre o número total de linhas
de código fonte dos sistemas reduz a capacidade de explicaçlJo da
variac;:lJo do esforço realizado (48% na hipótese 1 e 42% na hipótese
3'. Corrigindo os valores calculados no COCOMO Básico através dos
atributos direcionadores de custo do COCOMO Intermediário, conse
gue-se aumentar o poder de explica~ão em 10% (de 42% na hipótese 3
para 52% na hipótese 5'. Este fato é uma forte indicação de que
os atributos direcionadores de custo do COCOMO Intermediário re
presentam aspectos do desenvolvimento de sistemas que realmente
estão relacionados à produtividade das equipes.
.157.
o modelo de Análise de Pontos de FunçAo proposto por AI
brecht [1979], com grande aceitaçAo em várias empresas, principal
mente na IBM, apesar de bem definido conceitualmente e aceito no
teste de hipóteses, foi o que menos se aproximou do ambiente de
desenvolvimento da EMBRATEL (somente 23% da variaçâo do esforço é
por ele explicada). Entretanto, como está calcado em informaçé:\es
que se tornam disponíveis mais cedo, no ciclo de vida de um siste-
ma, poderá servir, se aperfeiçoado, como bom previsor. Alguns
trabalhos já têm sido elaborados criticando e sugerindo alteraçé:\es
no modelo proposto, objetivando dar maior consistência à contagem
dos pontos de funçAo [Symon, 1988]. Neste sentido, sugere-se que
estudos posteriores aprofundem a questAo. Vale ressaltar que para
esta medida já e>:istem atualmente alguns "pacotes" que a implemen-
taram:
ESTIMACS, desenvolvido por Howard Rubin e fornecido
pela COMPUTER ASSOCIATES, Jericho, NY, USA.
FUNCTION POINTS SYSTEMS, desenvolvido por Clark Dar
cher e fornecido pelo DEVELOPMENT SUPPORT CENTER,
Brookfield, Wisconsin, USA.
SPQR/20, desenvolvido por Carpers Jones e fornecido
pela SOFTWARE F'RODUCTIVITY RESEARCH,
USA.
Cambrigde, MA,
PAFÚNCio,
UNICAMP,
[ 1987],
desenvolvido por Cláudia Bauzer Medeiros, da
e Luiz AntOnio Iaderoza, da IBM Brasil
.158.
Evidentemente, as conclus5es obtidas neste estudo se
restringem ao conjunto de projetos avaliados e nlo devem ser es-
tendidas para outro conjunto. Uma vez que cada empresa proporcio-
na a sua área de desenvolvimento de sistemas um contexto organiza
cional especifico, tais conclus5es ser lo de grande valor para a
EMBRATEL. Os resultados aqui observados servirlo de base para uma
comisslo interna responsável pelo estabelecimento de padr5es de
porte de sistemas e de desempenho no desenvolvimento dos mesmos.
Esta comisslo tem como objetivo principal a efetivaçlo de padr5es
que possibilitem a todos os envolvidos no desenvolvimento dos sis
temas da empresa uma vislo adequada quanto ao tamanho dos produtos
gerados e ao desempenho de cada equipe de desenvolvimento, além de
viabilizar a identificaçlo dos diversos fatores que influenciam de
modo significativo este desempenho.
Espera-se que este estudo contribua decisivamente nõ; me
lhoria da gerência de desenvolvimento de sistemas nas empresas
brasileiras, nlo somente pela revislo atualizada da literatura so
bre o assunto em questlo, comO também pela metodologia apresentada
no teste das diversas medidas.
Entretanto, é sabido que ainda existe um longo caminho a
percorrer no aprofundamento do tema, de modo a que beneficios rea
is possam ser observados pelas empresas.
.159.
Sugere-se a aplicaçg(o de pesquisas similares em outros
ambientes, confrontando estes e outros modelos, enriquecendo o co
nhecimento sobre a produtividade no desenvolvimento de sistemas e
os fatores que efetivamente a influenciam.
.160.
BIBLIOGRAFIA
· 161.
BIBLIOGRAFIA
1. ABDEL-HAMID, T.K. ~< MADNICK, S.E. On the po~tability of
quantitative softwa~e estimation models.
Management, v. 13, p. 1-10, 1987.
Information and
2. ADRANGI, B. & HARRISON, W. Effo~t estimation in system
development p~oject.
21-23, Ago. 1987.
Journal of Systems Management, p.
3. ALBRECHT, A.J. Measuring application development productivity.
In: IBM APPLICATIONS DEVELOPMENT SYMPOSIUM. Proceedi ngs .••
Monterey, CA, GUIDE Inte~national, Oct. 1979, p. 83-92.
4. ALBRECHT, A.J. & GAFFNEY, J.E. Software function, source lines
of code, and development effort prediction: A software
science validation. IEEE Transactions on Software
Engineering, v. 9, n. 6, p. 639-648, Nov. 1983.
5 .. ALBRECHT, A.J. AD/M productivity meaSlJrement and estimate
6.
vaI i dati on. Guidel ine, n. 313, p. 1-50, Nov. 1984.
BASILI, V. & ZELKOWITZ, M. Analyzing mediLlm scale software
development. In: INTERNATIONAL CONFERENCE ON SOFTWARE
ENGINEERING, 3. Proceedings ... Washington, DC, IEEE,
p. 116-123.
1978,
.162.
7. BOEHM, Barry W. Software Engineering Economics. Englewood
Cliffs, NJ: Prentice-Hall, 1981.
8. BOEHM, Ba .... y W. 80ftwa .. e engineering economics. IEEE
Transactions on Software Engineering, v. 10, n. 1, p. 4-21,
Jan. 1984.
9. BOEHM, B.W •• PAPACCIO, P.N. Unde .. standing and cont .. olling
softwa .. e costs. IEEE Transactions on So-l'tware Engineering,
v. 14, n. 10, p. 1462-1477, OLlt. 1988.
10. CONTE, 8.0.; DUNSMORE, H.E.; SHEN, V.Y. So-l'tware engineering
metrics and models. Menlo Pa .. k, CA: The Benjamin/Cummings
Publishing Company, 1986.
11. COTt, V. et alii. Software met .. ics: an ove .. view of .. ecents
.. esults. The Journal 0-1' Systems and Software, v. p.
121-131, 1988.
12. DEMARCO, Tom. Structured analysis and system specification.
New Yo .. k, NY: Yourdon Press, 1978.
13. DEMARCO, Tom. Cont .. olling software projects. Englewood Cliffs,
NJ: P .. entice-Hall, 1982.
14. DRUMMOND, S. Measu .. ing applications development pe .. for"mance.
Datamation, v. 15, n. 2, p. 102-108, 1985.
• 163.
15. EVANS, M.W .. ; PIAZZA, P.; DOLKAS, ,J.B. PrinC:iples of produc:tive
software management. New York, NY: John Wiley, 1983.
16. FERNANDES, Aguinaldo A. & KUGLER, José L. C. Gerência de
projeto de sistemas; uma abordagem prática. Rio de Janeiro:
Livros Técnicos e Cientificos, 1989.
17. FISHER, D. Software costs in the Departament of Defense. IDA
Report, n. 1079, 1974.
18. FLAVIN, M. Fundamental concepts of information modeling. New
York, NY: Yourdon Press, 1981.
19. GILB, Tom. Estimating software attributes: some unconventional
points of view. ACM SI6S0FT Software Engineering Notes, v.
11, n. 1, p. 49-59, J an • 1986.
20. HALSTEAD, M.H. Elements of software scienc:e. New York, NY:
Elsevier North-Holland, 1977.
21. IEEE standard digital interface for programmable
instrumentation. New Vork: Institute of Electrical and
Electronics Engineers, 1978.
22. JEFFERY, D.R. A software development productivity model for
MIS environments. The Journal of Systems and Software, v.
7, p. 115-125, 1987.
.164.
23. JONES, Carpers. Demographic and technical trends in the
compLlting indLlstry. Software Productivity Research,
1983.
24. JONES, Carpers. A new look at languages.
1988.
Computerworld,
Jul.
Nov.
25. ~:EMERER, Chris F. An empirical validation of software cost
estimation models. Communications of the ACM, v.
p. 416-429, May 1987.
30,
26. LIEBLEIN, E. STARS program overview. DoD/lndustry
Workshop. Proceedings .•. ElA, May 1985.
n.5,
STARS
27. LIND, R.K. & VAIRAVAN, K. An ·e>:perimental investigation of
software metrics and their relationship
development effort. IEEE Transactions
to
on
software
Software
Engineering, v. 15, n. 5, p. 649-653, May 1989.
28. MEDEIROS, Cl áudi a B. & IADEROZA, Lui" A. PAFUNCi o: uma
ferramenta de avalia~âo de desempenho de aplica~f3es.
SIMPCSIO BRASILEIRO DE ENGENHARIA DE SOFTWARE,
Petrópolis, RJ: Sociedade Brasileira de CompLlta~go,
1987, p. 45-54.
out.
29. PRESSMAN, Roger S. Software engineering a practitioner's
aproach. New York, NY: McGraw-Hill, 1987.
·165.
30. RAMAMOORTHY, C.V.; GARG, V.; PRAKASH, A. Programming in the
large. IEEE Transactions on So-ftware Engineering, v. SE-12,
p. 769-783, 1986.
31. ROYCE, W.W. Managing the development of large software
systems: concepts and techniques. Proceedings WESCON, Ago.
1970.
32. RUBEY, R.J. & HARTWICk, R.D. Quantitative measurement of
progr"am quality. In: ACM NATIONAL CONFERENCE. Proceedings .•
• p. 671-677, 1968.
33. SYMONS, C.R. Function point analysis: dif-ficulties and
improvements. IEEE Transactions on So-ftware Engineering, v.
14, n. 1, p. 2-11, Jan. 1988.
34. WALSTON, C.E. 8, FELI X, C.P. A method of programming
measurement and estimation. IBM System Journal, v.
1, p. 54-73, 1977.
16, n.
35. WONNACOTT, Thomas H. g, WONNACOTT, Ronal d J. Introduç30 à
estat1stica. Rio de Janeiro: Livros Técnicos Cientificos,
1980.
.166.
ANEXO 1
QUESTIONÁRIO
.167.
INFORMAÇOES SOBRE SISTEMAS PARA AVALIAR 'MEDIDAS DE DESEMPENHO =~==============================================================
Sistema: Código: Situação: ____________ _
Nome:
Analista para contato: ________________________________________ _ Responsável: __________________ Area: _____________ _ Hardware utilizado: ____________________________________________ _ Software utilizado: ____________________________________________ _
Linguagem de programação (n9 de programas):
Esforço efetivamente medido em HOMEM-MtS:
(HM)".EAL.:
realizado para o desenvolvimento do
MODELO COCOMO INTERMEDIARIO
sistema,
Modo de desenvolvimento: _______________________________________ _ N!! de instruç5es fontes entregues (em milhares): _____________ KDSI
Esforço nominal previsto para o desenvolvimento do sistema:
(HM)NOM: (baseado no modo de desenvolvimento e no I<DSI)
Atributos direcionadores de custo: - de produto
RELY Confiabilidade requerida do software: DATA - Tamanho da base de dados: CPLX - Complexidade do produto:
- de computador TIME Restrição de tempo de execução: STOR Restrição de memória principal: VIRT Volatilidade da máquina virtual: TURN Tempo de resposta:
- de pessoal ACAP Capacidade dos analistas: AEXP Experiência na aplicação: PCAP Capacidade dos programadores: VEXP Experiência na máquina virtual: LEXP Experiência na ling. de programação:
- de projeto MODP Técnicas modernas de programação: TOOL Uso de ferramentas de software: SCED Prazo requerido para o desenvolvimento:
Esforço previsto no desenvolvimento do sistema, dos atributos direcionadores de custo:
ajustado através
(ajustado pelos atributos)
.168.
MODELO DE PONTOS DE FUNCAO
1 - Contagem de PONTOS DE FUNç:/,\O não ajLlstados - PFNA
Ní vel da fLtnção
Descrição Simples Médio Complexo Total
Entrada externa Saída e>:terna Ar qLli vo 16gi co
interno Arquivo de interface
externo Consulta externa
x 3 }~ 4
>~ 7
)( 5 x 3
>: 10
>: 7 >: 4
Total de PONTOS DE FUNç:AO Não Ajustados (PFNA)
2 - Fator de Complexidade Técnica - FCT
Ident.
Cl C2 C3 C4 C5 C6 C7 C8 C9 CiO Cll C12 C13 C14
Característica
Comunicação de dados Funções distribuídas Desempenho Configuração usada pesadamente Taxa de transações Entrada de dados "on-line" Eficiência do usuário final Atualização "on-line" Processamento complexo IIRe-useability" Facilidade de instalação Facilidade de operação I'Sites" móltiplos Mudanças facilitadas
x 6 x 7
x 15
x 10 x 6
Grau de influência total (6IT)
Valores para GI: O = ausente ou sei inllu~ncia I = inllu~ncia insignilicante 2 = inlluência loderada
3 = inllu~ncia lédia 4 = inlluência significativa S = forte influência, todo o tempo
FCT = 0,65 + 0,01 x GIT = 3 Número de Pontos de Função - PF
PF = PFNA x FCT =
GraLI de Influêndia
(GI)
.169.
MODELO BANB de sistemas orientados para DADOS
1 - Número de objetos contidos no Diagrama de Objetos: ________ _
2 - Cálculo do BANBDADOS através da pondera~ão dos Objetos em rela~ão ao número de Relacionamentos (RE.> que possue um determinado Objeto.
RE. Incremento 08 Corrigido !108CI
1 2 3 4 5 6 7 8 9
10 1 1 12 13 14 15 16 17 18 19
1, O 2,4 4,0 5,8 7,8 9,8
12,0 14,3 16,6 19,0 21,5 24,1 26,7 29,3 32,0 34,7 37,6 40,4 43,2
T O T A I S
BANGDADOS =
9tde de Objetos CDI o .eslo REi IOBRI IOBC >: OBR
.170.
CALCULO DO DESEMPENHO A PARTIR DOS MODELOS
1 - Modelo COCOMO
(HM) A.:IU
Desempenho = ----------- =
2 - Modelo de PONTOS DE FUNÇAO
PF Desempenho = ----------- =
(HMl .. e:AL-
"" - Modelo BANG
BANGDADOS Desempenho = ----------- =
(HM),.e:AL.
.171.
ANEXO 2
DIAGRAMAS DE DISPERSA0
60
55
50
45
40
HOMeM-fies 35 Real
30
25
20
1St •
10 0
•
DiOíjromo dE Dispersoo - LCF X HM REol
. .
. . •
•
'. :
. .
10tl)1l)0 20000 30000 40000 50000 60@00 70000 30000 L inha.s de Cod igo Fonte
I I t::I ... 111 .c
r' nll> "113
11> "11 I I ...
X C. Cil .. 10 c: -.J
:ti ~J I I xc. l> .
3 ... :tIiII ... rrI"C l>1O
I I r' iII 110 o
Diagroma de Dispersa0 - LCrC x HM Real
60
55
501 • 11 'o ....
45+ fi>
I I roe 0"'1 'Tlfl>
40+ 09 • IIJ 'Tl .... ' .
HOMeM-Hes 351 x Q. Gl ...
Real 1\1 c: '-J
• :l:l r.A
30 • • 1:Q. J) . ::l ....
• :l:llll N 1Tl'tl
25+ .. J)fD r "'I • 111
20+ IIJ> C . .
• 151 ., 10: I I I I I I I
o 20000 40000 60000 80000 100000 120000 140000 Tota.l Cm'rigido de Linha.s de Codigo
Fonte
Diagrama de Dispersa0 - CB x HM Real 60
55! •
• • •
50 I'l t::I ,.. III
45.J. 1I n~ ,tIllll
40.J. I I ~ .." x .....
C. Gl .... HOMeM-Mes • m c '-l 351 :t ::ti "'" Real ::J:c. 1> • . :o ...
30 . •
lT1111 (,.I 1>'0 rm
25.J. : I I ~ 110
20' I I o
15 t .: . 10" I I I I I I I I I I I
o 50 100 150 200 250 300 350 400 450 500 550 IfUi Notüna.l - COCm10 Ba.sico
20
15
•
•
Diagrama de Dispersa0 - CSC x HM Real •
•
•
• •
• .. •
10 1 I I I I I I I I I o 100 200 300 400 500 600 700 800 900 Hf1 Nmüna.l Corrigido - COC0ll10 Ba.sico
o .... 00 ..c n,
'li 00 n51 00 'TI .....
x o. Cil ,... 10 c: -..J
;o lq :to. I> • 3: ...
~.jg .j>
I> 10 r' Itl
11/1 o
'. 1,?!
Diagramo de Dispersa0 - CI x HM Real 60-
551 • • •
50 I I o .... I»
45.J- 11 n~ ... 111
40+ II ~ " x .... a. ü.I ....
HOMeM-Mes 351 lU c: '" Real :x: :o o-
3a. J> . 30 • • :o ....
mUI UI J>'C rIU
25.J- . 1 1 ,
• UI 1»1
20+ I I o • . • •
15 + .: . , .
101 I I I I I I 0 50 100 150 200 250 300 350 400 450 500
Hf1 AJusta.dó - COCOtiO InferMedia.rio
60T 55
50
45
40
HoMeM-fies 35 Real
30
25·' •
20· o. I I
15t :": c
10 0
Diagramo de Dispersa0 CIC x HM Real
c"
•
~
100
•
200 300 400 500 600 HM AJusta.do Corrigido - COCOf10
InterMediario
700
, ,
II
800
1:1 ... Il> \O n,
""111 n3 Il> ." ...
xc. til .... 111 c: '-l
)l '-l ::tc. J> . :3 ... )lUl o-In" J>III r'
UI lJjI o
.178.
FIGURA 7
Diagrama de dispersão . . PF " HMREAL
D $ OJ
N ... a:: ::2
I I X ...
ll.... O Q.. ti)
. $ g O) :::I U.
O D 41 Vl "'O !...
-~$ ~ OJ • D... '()+-Vl !=: ,- O
O O-
OJ $ 'TI
• • '0:1" O •
E • • O • !... • ~$ !TI . D IN ,-
O
. • • !$I 1$1 LI) I$) LI) (il .n $ LI) I$) LI) (il '() LI) LI) ":f ":f t") M IN IN ... ...
r.n 41 ..... ........ 'tti &(11 (lia: f: O
:::t:
60
55-
50
45
40
HOMeM-fies 35+ Rea.l
30t
25
20
15
10 0
Diagrama de Dispersa0 - BD x HM Real
. •
•
•
• , ,
50
•
•
•
-, , , 100 150 200
BANGOAOOS
t:I ... ~ I.C
Iil' t:I~
::I 111 " x .... a. ül .... 111 c: '-.I
:I: ;o -CJ ::ia. li • ;o ... ITlIII OJ 11"0 íl1l ,
111 l1li o
250