"

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 si­tos 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 da­dos: se um grupo de elementos de dados puder ser convertido de entrada em saída sem con­sulta 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 com­pl e>: idade.

Acesse a TABELA 11.5 por Classe e anote o Peso res­pec: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 TA­BELA 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"ll­fies:

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 re­la~ão ao número de Relacionamentos (RE.> que possue um deter­minado 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