uma ferramenta de estimativa de custos para o ...din.uem.br/~mestrado/diss/2010/pagno.pdf · dados...
TRANSCRIPT
RODRIGO TOMAZ PAGNO
UMA FERRAMENTA DE ESTIMATIVA DE CUSTOS PARA O DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
MARINGÁ
2010
RODRIGO TOMAZ PAGNO
UMA FERRAMENTA DE ESTIMATIVA DE CUSTOS PARA O DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação. Orientadora: Profa. Dra. Tania Fatima
Calvi Tait
MARINGÁ
2010
Dados Internacionais de Catalogação-na-Publicação (CIP) (Biblioteca Central - UEM, Maringá – PR., Brasil)
Pagno, Rodrigo Tomaz P139f Uma ferramenta de estimativa de custos p ara o
desenvolvimento distribuído de software / Rodrigo T omaz Pagno. -- Maringá, 2010.
150 p. : il., figs., tabs. Orientadora : Profª. Drª. Tania Fatima C alvi Tait. Dissertação (mestrado) - Universidade Es tadual de
Maringá, Programa de Pós-Graduação em Ciência da Computação, 2010.
1. Software - Custos do desenvolvimento distribuído -
Ferramenta de apoio. 2. Gerência de software - Esti mativa de custo - Ferramenta de apoio. 3. Ferramenta de so ftware - Gerenciamento de projetos. 4. Modelo COCOMO II. 5. Ambiente de desenvolvimento distribuído de software. 6. Dist ributed Software Engineering Environment (DiSEN). I. Tait, Tania Fatima Calvi, orient. II. Universidade Estadual de Maringá. Programa de Pós-Graduação. III. Título.
CDD 21.ed. 005.276
RODRIGO TOMAZ PAGNO
UMA FERRAMENTA DE ESTIMATIVA DE CUSTOS PARA O DESENOLVIMENTO DISTRIBUÍDO DE SOFTWARE
Dissertação apresentada ao Programa de Pós-Graduação em Ciência da Computação da Universidade Estadual de Maringá, como requisito parcial para obtenção do grau de Mestre em Ciência da Computação.
Aprovado em 26/02/2010.
BANCA EXAMINADORA
Profa. Dra. Tania Fatima Calvi Tait Universidade Estadual de Maringá – DIN/UEM
Profa. Dra. Maria Madalena Dias Universidade Estadual de Maringá – DIN/UEM
Prof. Dr. Giancarlo Lucca Faculdade UNISSA de Sarandi
Dedico este trabalho à minha mãe
Eulália (in memoriam), por me
mostrar que é possível olhar além
da dor.
i
Agradecimentos
Primeiramente gostaria de agradecer aos meus pais, que me deram todo incentivo e
apoio para concluir mais essa etapa nos meus estudos.
Gostaria de agradecer ao meu Amor, Mara Luciane, por sempre estar do meu lado
tanto nos momentos felizes como nos momentos tristes, por me resguardar, incentivar,
aconselhar, apoiar, alegrar e iluminar os meus caminhos, amo-te.
À minha orientadora Professora Tania Tait, por direcionar os meus estudos no
mestrado e orientar o desenvolvimento desta dissertação.
À Inês, secretária do PCC, por ser essa pessoa doce e atenciosa que sempre resolveu
de maneira eficiente nossos problemas burocráticos no curso.
Aos membros da banca, Professora Madalena e Professor Giancarlo, que contribuíram
para o trabalho.
Aos Professores do departamento de Informática, que sempre foram atenciosos quanto
aos esclarecimentos das dúvidas, em especial a Professora Elisa, que acreditou e ajudou nas
minhas pesquisas e ao Professor Airton, que sempre me ajudou nos momentos em que eu
mais precisei.
Agradecer aos participantes da avaliação da ferramenta, desenvolvida neste trabalho,
por terem contribuído para esta pesquisa.
Aos colegas do mestrado, Tiago, Ana, Aldo, Bart, André, Carlos, Roberto, Jesus,
Hufo, Cassolato entre outros que me foge a memória, em especial ao Rosefran que foi meu
irmão de mestrado e sempre esteve disposto a me ajudar e ao Gustavo, que foi meu “braço
direito” no planejamento e desenvolvimento da ferramenta.
À Gruba, por aparecer de última hora e trazer muitas felicidades no dia-a-dia.
Em fim, gostaria de agradecer a todos que de alguma forma contribuíram no
desenvolvimento deste trabalho.
ii
iii
Resumo
Em busca de vantagem competitiva e maiores lucros, atualmente, as empresas
desenvolvedoras de software buscam melhorar sua forma de produzir software. Uma solução
encontrada foi a distribuição do desenvolvimento de software. As estimativas de custos de
desenvolvimento de software sempre foram um grande desafio, devido as suas incertezas e
grandes diferenças entre o custo do produto final e o valor estimado. Este desafio torna-se
ainda maior quando se refere ao desenvolvimento distribuído de software, onde equipes
geograficamente distantes interagem em cooperação para desenvolver produtos de software.
Diante desta situação, este trabalho apresenta uma ferramenta de software para apoiar os
gerentes durante a realização de estimativas de custos de projetos de software. Para isso, a
ferramenta leva em consideração os custos contábeis de cada equipe e implementa três
maneiras diferentes de estimar produtos de software; i) estimativa por analogia (onde projetos
concluídos que apresentem similaridade em determinadas características são consultados); ii)
o uso de modelos empíricos (nos quais equações matemáticas são combinadas com algumas
variáveis de características para estimar projetos); iii) estimativa por especialista (na qual
pessoas especialistas estimam projetos). Desta forma, a ferramenta fornece bases de dados
para o gerente de projeto, permitindo realizar estimativas de custos para o desenvolvimento
distribuído de software.
iv
v
Abstract
In search of competitive advantage and higher profits, companies now are trying improve
their way of producing software. One of the solutions is the distribution of software
development. The cost estimates of software development have always been a challenge due
to their large uncertainties and differences between the cost of the final estimated value. This
challenge becomes even greater when we refer to the distributed development of software,
where geographically dispersed teams interact together to develop software products. In this
situation, this paper presents a tool to support managers during the realization of cost
estimates for software projects. To this end, the tool takes into account the cost accounting of
each team and implements three different ways of estimating software products; i) estimation
by analogy (which completed projects which have similarities in certain features are found),
ii) the use of models empirical (in which mathematical equations are combined with some
variable characteristics to estimate projects), iii) estimate by an expert (in which experts
estimate projects). Thus, the tool provides support to the project manager to realize cost
estimates for distributed development of software.
vi
vii
Lista de Ilustrações
Lista de Figuras
FIGURA 1.1 – METODOLOGIA PARA O DESENVOLVIMENTO DA FERRAMENTA DE CUSTOS PARA
O DDS. ....................................................................................................................................4
FIGURA 2.1. FLUXO COMPARATIVO ENTRE EMPRESAS COMERCIAIS E INDUSTRIAIS (CREPALDI,
2004).......................................................................................................................................8
FIGURA 2.2 – CONE QUE REPRESENTA AS INCERTEZAS DAS ESTIMATIVAS (SOMMERVILLE ,
2004).....................................................................................................................................19
FIGURA 3.1 – CONTAGEM DA TÉCNICA APF (PETERS, 2001).................................................37
FIGURA 4.1 - OS EFEITOS DAS “DESECONOMIAS” NO ESFORÇO (COCOMO, 2000)...................45
FIGURA 5.1 – ARQUITETURA DO DISEN (PASCUTTI, 2002). ..................................................55
FIGURA 7.1 – ARQUITETURA DA FERRAMENTA COSTDDS. ...................................................73
FIGURA 7.2 – DIAGRAMA GERAL DE PACOTES DA FERRAMENTA COSTDDS. .........................74
FIGURA 7.3 – DIAGRAMA DE CASOS DE USO DA FERRAMENTA COSTDDS. ............................76
FIGURA 7.4 – DIAGRAMA DE ATIVIDADES “ESTIMAR PROJETO” DA FERRAMENTA COSTDDS.
..............................................................................................................................................78
FIGURA 7.5 – DIAGRAMA DE ATIVIDADES DO CASO DE USO “ESTIMAR POR ANALOGIA” DA
FERRAMENTA COSTDDS. ......................................................................................................81
FIGURA 7.6 – DIAGRAMA DE ATIVIDADES “ESTIMAR POR MODELO” DA FERRAMENTA
COSTDDS..............................................................................................................................83
FIGURA 7.7 – INTERFACE PRINCIPAL DA FERRAMENTA COSTDDS.........................................85
FIGURA 7.8 – INTERFACE GRÁFICA “ESTIMATIVA MÓDULO”.................................................87
FIGURA 7.9 – INTERFACE GRÁFICA “ESTIMATIVA LOCAL”. ...................................................90
FIGURA 7.10 – INTERFACE GRÁFICA “ESTIMATIVA PROJETO”. ..............................................91
FIGURA B.1 – INTERFACE GRÁFICA “PRINCIPAL”. ...............................................................117
FIGURA B.2 – INTERFACE GRÁFICA “A TUALIZAÇÃO MENSAL DOS CUSTOS LOCAIS”. .........118
FIGURA B.3 – INTERFACE GRÁFICA “A TUALIZAÇÃO MENSAL DOS DADOS LOCAIS”. ..........119
viii
FIGURA B.4 – INTERFACE GRÁFICA “ESTIMATIVA MÓDULO”. ............................................ 121
FIGURA B.5 – INTERFACE GRÁFICA “CÁLCULO DE PONTOS POR FUNÇÃO”. ........................ 123
FIGURA B.6 – INTERFACE GRÁFICA “CÁLCULO DO EXPOENTE (FATORES DE ESCALA)”. .... 124
FIGURA B.7 – INTERFACE GRÁFICA “CÁLCULO DOS DIRECIONADORES DE CUSTOS”. ......... 125
FIGURA B.8 – INTERFACE GRÁFICA “CONSULTA ESTIMATIVA POR ANALOGIA”................... 127
FIGURA B.9 – INTERFACE GRÁFICA “OBSERVAÇÕES SOBRE A ESTIMATIVA REALIZADA”. ... 129
FIGURA B.10 – INTERFACE GRÁFICA “ESTIMATIVA LOCAL”. .............................................. 130
FIGURA B.11 – INTERFACE GRÁFICA “ESTIMATIVA PROJETO”. ........................................... 131
FIGURA B.12 – INTERFACE GRÁFICA “CADASTRO DADOS REAIS DE MÓDULOS CONCLUÍDOS”.
............................................................................................................................................ 132
FIGURA B.13 – INTERFACE GRÁFICA “CADASTRO CLASSIFICAÇÃO”. .................................. 133
FIGURA B.14 – INTERFACE GRÁFICA “TAMANHO DO MÓDULO EM LINHAS DE CÓDIGO”. ... 133
FIGURA B.15 – INTERFACE GRÁFICA “CADASTRO FUNCIONALIDADE”................................ 134
FIGURA B.16 – INTERFACE GRÁFICA “CADASTRO GERENTE”. ............................................ 135
FIGURA B.17 – INTERFACE GRÁFICA “CADASTRO LINGUAGEM”......................................... 136
FIGURA B.18 – INTERFACE GRÁFICA “CADASTRO LOCAL”. ................................................ 137
FIGURA B.19 – INTERFACE GRÁFICA “CADASTRO PROJETO”. ............................................. 138
FIGURA B.20 – INTERFACE GRÁFICA “CADASTRO CUSTO GLOBAL”. .................................. 139
FIGURA B.21 – INTERFACE GRÁFICA “CADASTRO ESPECIALISTA(S)”. ................................ 140
FIGURA C.1 – DIAGRAMA DE CLASSES DA FERRAMENTA COSTDDS. ................................. 142
FIGURA D.1 – DIAGRAMA DE SEQUÊNCIA “CALCULARTOTALPROJETO()”. ........................ 144
FIGURA D.2 – DIAGRAMA DE SEQUÊNCIA “CALCULARESTIMATIVA LOCALPORMODELO()”.
............................................................................................................................................ 146
FIGURA D.3 – DIAGRAMA DE SEQUÊNCIA “CALCULARESTIMATIVA LOCALPORANALOGIA()”
............................................................................................................................................ 148
Lista de Quadros
QUADRO 2.1 – TÉCNICAS DE ESTIMATIVAS DE CUSTOS (ADAPTADO DE SOMMERVILLE , 2004).
.............................................................................................................................................. 27
QUADRO 5.1 – CLASSIFICAÇÃO DOS CUSTOS......................................................................... 58
QUADRO 6.1 – COMPARAÇÃO ENTRE AS FERRAMENTAS DE ESTIMATIVAS DE CUSTOS. ......... 65
ix
Lista de Tabelas
TABELA 3.1 – PESOS REFERENTES À COMPLEXIDADE PARA OS PONTOS POR APLICAÇÃO
(KAUFFMAN E KUMAR, 1993 APUD PFLEEGER, 2004). ..........................................................33
TABELA 3.2 – CÁLCULO DE ESTIMATIVA DE PRODUTIVIDADE (BANKER ET AL., 1992 APUD
PFLEEGER, 2004). ..................................................................................................................34
TABELA 3.3 – PESOS DOS ITENS DE APF................................................................................36
TABELA 3.4 – FATORES DE COMPLEXIDADE TÉCNICA. ...........................................................37
TABELA 3.5 – VALORES PADRÕES PARA CONVERSÃO DE CNF PARA SLOC (COCOMO, 2000).
..............................................................................................................................................38
TABELA 4.1 – FATORES DE ESCALA (COCOMO, 2000). ..........................................................46
TABELA 4.2 – DIRECIONADORES DE CUSTOS DO MODELO POST-ARCHITECTURE (COCOMO,
2000).....................................................................................................................................48
TABELA 4.3 – MAPEAMENTO DOS DIRECIONADORES DE CUSTOS. ..........................................51
x
xi
Sumário
LISTA DE ILUSTRAÇÕES................................................................................................VII
LISTA DE TABELAS........................................................................................................... IX
1. INTRODUÇÃO ....................................................................................................................1
1.1 CONSIDERAÇÕES INICIAIS............................................................................................1
1.2 OBJETIVOS...................................................................................................................2
1.3 OBJETIVOS ESPECÍFICOS: .............................................................................................2
1.4 JUSTIFICATIVA .............................................................................................................3
1.5 METODOLOGIA E DESENVOLVIMENTO DA PESQUISA....................................................3
1.6 CONTRIBUIÇÕES DO TRABALHO...................................................................................5
1.7 ORGANIZAÇÃO DO TRABALHO.....................................................................................6
2. ESTIMATIVA DE CUSTOS...............................................................................................7
2.1 VISÃO GERAL DA CONTABILIDADE DE CUSTOS.............................................................7
2.1.1 Classificação dos custos.................................................................................................... 9
2.1.2 Departamentalização ...................................................................................................... 10
2.1.3 Sistemas de acumulação de custos .................................................................................. 10
2.1.4 Métodos de custeio .......................................................................................................... 11
2.2 TIPOS DE CUSTOS DE SOFTWARE................................................................................12
2.3 PLANEJAMENTO DE PROJETOS....................................................................................13
2.3.1 Definição do escopo e viabilidade do projeto ................................................................. 14
2.3.2 Definição dos recursos.................................................................................................... 14
2.4 ESTIMATIVAS DE PROJETOS DE SOFTWARE.................................................................17
2.4.1 Opções de estimativas ..................................................................................................... 18
2.4.2 Técnicas de estimativas de custos ................................................................................... 27
2.5 CONSIDERAÇÕES FINAIS............................................................................................30
xii
3. MÉTRICAS ........................................................................................................................ 31
3.1 MEDIÇÃO DE SOFTWARE........................................................................................... 31
3.2 PONTOS POR OBJETO................................................................................................. 33
3.3 NÚMERO DE LINHAS DE CÓDIGO-FONTE.................................................................... 34
3.4 PONTOS POR FUNÇÃO................................................................................................ 35
3.5 CONSIDERAÇÕES SOBRE AS MÉTRICAS DE TAMANHO................................................ 39
4. MODELO COCOMO II ................................................................................................... 41
4.1 MODELO COCOMO II.............................................................................................. 41
4.2 MODELO DE COMPOSIÇÃO DA APLICAÇÃO................................................................. 42
4.3 MODELO EARLY DESIGN E MODELO POST-ARCHITECTURE.......................................... 43
4.4 DIRECIONADORES DE CUSTOS DO MODELO EARLY DESIGN......................................... 51
4.5 DURAÇÃO DE PROJETO E PESSOAL............................................................................. 51
4.6 CONSIDERAÇÕES FINAIS............................................................................................ 52
5. AMBIENTES DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFT WARE .......... 53
5.1 AMBIENTES DE DESENVOLVIMENTO DE SOFTWARE...................................................53
5.2 AMBIENTES DE DESENVOLVIMENTO DISTRIBUÍDO DE SOFTWARE.............................. 54
5.3 CUSTOS NO DDS....................................................................................................... 56
5.4 CONSIDERAÇÕES FINAIS............................................................................................ 58
6. TRABALHOS RELACIONADOS................................................................................... 59
6.1 GESTÃO DE CUSTOS EM EMPRESAS DE DESENVOLVIMENTO DE SOFTWARE................ 59
6.2 FERRAMENTAS UTILIZADAS PARA A ESTIMATIVA DE CUSTO...................................... 61
6.3 COMPARATIVO ENTRE AS FERRAMENTAS.................................................................. 64
6.3.1 Análise das ferramentas................................................................................................... 66
6.4 CONSIDERAÇÕES FINAIS............................................................................................ 67
7. FERRAMENTA COSTDDS............................................................................................. 69
7.1 CONSIDERAÇÕES INICIAIS......................................................................................... 69
7.2 DESCRIÇÃO DA FERRAMENTA................................................................................... 70
7.3 PRINCIPAIS CARACTERÍSTICAS.................................................................................. 70
7.4 ESPECIFICAÇÃO FUNCIONAL...................................................................................... 70
7.5 DESENVOLVIMENTO DA FERRAMENTA...................................................................... 72
7.6 APRESENTAÇÃO DA FERRAMENTA............................................................................ 72
xiii
7.7 CONSIDERAÇÕES FINAIS............................................................................................92
8. AVALIAÇÃO DA FERRAMENTA COSTDDS .............................................................93
8.1 CONSIDERAÇÕES INICIAIS..........................................................................................93
8.2 DESENVOLVIMENTO E AVALIAÇÃO DO QUESTIONÁRIO..............................................94
8.3 ESCOLHA DAS EMPRESAS PARA APLICAR O QUESTIONÁRIO........................................94
8.4 APRESENTAÇÃO DA FERRAMENTA.............................................................................94
8.5 APLICAÇÃO DO QUESTIONÁRIO..................................................................................95
8.6 ANÁLISE DOS DADOS COLHIDOS NA APLICAÇÃO DO QUESTIONÁRIO..........................95
8.7 CONSIDERAÇÕES SOBRE A AVALIAÇÃO DA COSTDDS...............................................97
9. CONCLUSÕES...................................................................................................................99
9.1 CONSIDERAÇÕES FINAIS............................................................................................99
9.2 DIFERENCIAL DA FERRAMENTA COSTDDS..............................................................100
9.3 TRABALHOS FUTUROS.............................................................................................101
REFERÊNCIAS BIBLIOGRÁFICAS ...............................................................................103
ANEXO A..............................................................................................................................109
ANEXO B ..............................................................................................................................117
ANEXO C..............................................................................................................................141
ANEXO D..............................................................................................................................143
xiv
1
Introdução
1.1 Considerações iniciais
As inovações tecnológicas juntamente com o intenso uso da Internet modificaram o cenário
atual dos negócios. O software se tornou um item vital de negócios. O sucesso de uma
organização depende cada vez mais da utilização de software como um diferencial
competitivo. Ao mesmo tempo, a economia tem convertido os mercados nacionais em
mercados globais, criando novas formas de competição e colaboração (Herbsleb e Moitra,
2001).
No entanto, o mercado global de software vem atravessando diversas crises, tanto por
inúmeras falhas em projetos como por uma grande demanda de requisições por produtos de
software de alta qualidade, agravado ainda mais com profissionais com pouca experiência no
mercado. Uma alternativa para resolver esses problemas é a adoção do conceito de produzir
software remotamente com a prática do desenvolvimento distribuído de software (DDS)
(Prikladnicki et al., 2003).
O DDS traz questões características desse tipo de ambiente de desenvolvimento de
software, tais como: controlar os participantes que se encontram em outros locais, lidar com
as diferenças culturais, fazer melhor uso do trabalho cooperativo, e otimizar a distribuição de
informações dos projetos para futuras consultas (Enami, 2006). Ferramentas de apoio ao
gerenciamento de DDS auxiliam a gerenciar estas características. Segundo (Pressman, 2006),
as ferramentas devem ajudar nas estimativas de custos, esforço e duração do projeto de
1
Capítulo
2
software, assim como na definição de uma estrutura de divisão de trabalho, no planejamento
de uma programação viável de projeto e no acompanhamento dos mesmos.
As empresas precisam conhecer os custos envolvidos em suas atividades para poder
identificar o seu resultado (lucro) (Crepaldi, 2004; Bruni e Fama, 2004; Vanderbeck e Nagy,
2003; Beulke e Bertó, 2006).
O custo envolvido em um Ambiente de Desenvolvimento de Software (ADS) pode ser
estimado com a utilização de ferramentas existentes tais como Cost Expert (Cost, 2008),
USC-COCOMO II (Usc, 2008), Calico 5.06 (Calico, 2008) e Costar 7.0 (Costar, 2008). Mas,
tratando-se de um Ambiente de Desenvolvimento Distribuído de Software (ADDS), não estão
disponíveis ferramentas que abordam os custos envolvidos nesta prática de desenvolvimento.
Neste contexto, este trabalho apresenta uma ferramenta que possibilita aos gerentes de
projetos estimarem os custos envolvidos no desenvolvimento distribuído de projetos de
software, levando em consideração as características apresentadas neste tipo de ambiente.
1.2 Objetivos
O objetivo geral é desenvolver e apresentar uma ferramenta que auxilie os gerentes durante a
estimativa dos custos do desenvolvimento de software em um ADDS. Desta forma, auxiliar o
processo decisório e possibilitar aos gerentes conhecerem mais intimamente os custos
envolvidos nesta prática de desenvolvimento.
1.3 Objetivos específicos:
• Realizar uma análise comparativa das ferramentas de estimativas de custo de projetos
de software utilizadas no mercado por meio dos critérios estabelecidos por esta
pesquisa;
• Levantar as características das ferramentas analisadas que melhor se adequarão ao
DDS e incorporá-las a ferramenta de estimativas de custos proposta por este trabalho;
• Apresentar características relativas aos custos envolvidos no gerenciamento de custos
em DDS;
• Projetar e implementar a ferramenta proposta utilizando as ferramentas, linguagens e
padrões de programação estabelecidos no ambiente DiSEN (Distributed Software
Engineering Environment);
3
• Avaliar a ferramenta de custos desenvolvida nessa pesquisa junto a gerentes de
projetos e à equipe do projeto DiSEN;
• Colaborar com o projeto DiSEN com uma ferramenta que possibilite estimar custos
nesse tipo de ambiente;
• Contribuir para a contabilidade de custos na produção de software, como um
instrumento útil ao processo de gestão de custos em empresas que realizam o DDS.
1.4 Justificativa
A necessidade que as empresas têm em conhecer seu lucro em determinada atividade, as leva
em direção ao conhecimento de seus custos (Crepaldi, 2004; Bruni e Fama, 2004; Vanderbeck
e Nagy, 2003; Beulke e Bertó, 2006). As empresas desenvolvedoras de software não fogem a
esta regra, pois, também apresentam esta necessidade de conhecer os seus custos. Entretanto,
em relação a uma empresa com atividades de manufatura, a sua forma de avaliar os custos é
ainda mais complexa, devido a suas características de desenvolvimento do produto de
software (Sommerville, 2004).
A estimativa do custo envolvido no desenvolvimento de software é muito complexa;
por isso, torna-se necessária a utilização de ferramentas como auxílio durante a realização das
estimativas dos custos (consenso encontrado em Pressman (2006) e Sommerville (2004)).
Mas, para tratar de um Ambiente de Desenvolvimento Distribuído de Software (ADDS), não
estão disponíveis, ainda, ferramentas que abordam os custos envolvidos nesta prática de
desenvolvimento. As ferramentas encontradas na literatura corrente tratam os custos clássicos
(tais como, hardware, software e treinamentos, como apresentados em Sommerville (2004))
de uma forma local, além de não abordarem a parte contábil do assunto.
Neste contexto, este trabalho aborda as principais características relacionadas ao
ADDS, bem como, identifica alguns dos principais custos envolvidos, para que seja possível a
elaboração de uma ferramenta que auxilie, de maneira automatizada, a realização de
estimativa de custos de projetos de software desenvolvidos de forma distribuída.
1.5 Metodologia e desenvolvimento da pesquisa
A metodologia proposta envolve as seguintes etapas: Fundamentação teórica; Análise dos
custos em DDS; Análise das ferramentas de custos; Elaboração da ferramenta para o DDS;
Avaliação da Ferramenta; e, Apresentação da Ferramenta. A Figura 1.1 permite a melhor
4
visualização e detalhamento da metodologia.
Figura 1.1 – Metodologia para o desenvolvimento da ferramenta de custos para o DDS.
1) Fundamentação teórica: Consiste no estudo de temas relacionados à ferramenta de
estimativa de custos proposta; estudos sobre os custos contábeis, sobre os tipos de
custos, sobre as técnicas de estimativas de custos, métricas utilizadas para realizar as
estimativas, sobre o modelo empírico COCOMO (Constructive Cost Model), e
também, sobre o DDS;
Fundamentação teórica
• Contabilidade de Custos • Tipos de custos do desenvolvimento de
software • Estimativas de custos do desenvolvimento de
software • Métricas • Modelo COCOMO
Análise das ferramentas de
custos
• Análise e comparação das ferramentas de estimativas encontradas
• Análise e extração de suas características pertinentes ao DDS
Apresentação da ferramenta
Elaboração da ferramenta para
o DDS
Avaliação da ferramenta
• Desenvolvimento da ferramenta de estimativa de custos para o DDS
• Avaliação da ferramenta desenvolvida
• Apresentação da ferramenta
Análise dos custos no DDS
• Estudos sobre DDS • Extração de alguns custos envolvidos no
DDS
5
2) Análise dos custos no DDS. Existem custos nesta prática de desenvolvimento que não
aparecem em um ambiente de desenvolvimento local;
3) Análise das ferramentas de custos tanto as encontradas na literatura como usadas na
prática por empresas que atuam no desenvolvimento de software. Foi realizado um
estudo comparativo entre elas e extraídas algumas características relacionadas com a
implementação da ferramenta proposta;
4) Elaboração da ferramenta foi concebida com a utilização de elementos das
ferramentas estudadas, juntamente com os elementos de custos que fazem parte da
prática do DDS extraídos das etapas anteriores. Foram utilizadas as mesmas
linguagens e padrões de desenvolvimento já estabelecidos no ambiente DiSEN para
viabilização e integração desta ferramenta;
5) Avaliação da ferramenta desenvolvida aconteceu por meio de aplicação de
questionários junto aos integrantes do grupo de estudos DiSEN e junto a gerentes de
projetos de software de empresas que atuam, também, com o desenvolvimento
distribuído de software;
6) Apresentação da ferramenta.
1.6 Contribuições do trabalho
As contribuições dessa dissertação englobam três itens:
1 - Incorporação de elementos da contabilidade de custos para a estimativa de custos
de projetos de software;
2 - Propiciar integração da área de contabilidade com a área de software;
3 - Produção de uma ferramenta de apoio à estimativa de software para um ADDS,
incorporada ao ambiente DiSEN.
Os itens (1) e (2) são relevantes para a área de software visto que incorporam a
abordagem da contabilidade, a qual extrapola a visão de custos básicos de hardware, software
e treinamento, indo em direção aos demais custos envolvidos no desenvolvimento.
O item (3) está dentro do contexto de gestão de projetos de software em DDS que traz
ferramentas de apoio aos gerentes para planejar e acompanhar os projetos distribuídos nas
equipes virtuais.
6
1.7 Organização do trabalho
Este trabalho está estruturado da seguinte forma:
Nos Capítulos 2, 3, 4 e 5 é oferecida uma revisão dos temas que contribuíram para
fundamentação da pesquisa, tais como: estimativas de custos; métricas, modelo empírico
COCOMO, ADDS e alguns custos envolvidos na prática do DDS;
No Capítulo 6 são apresentados alguns trabalhos relacionados quanto à gestão de
custos em empresas de desenvolvimento de software, bem como a descrição e comparação de
algumas ferramentas utilizadas para a realização de estimativas de custo de projetos de
software;
No Capítulo 7 é apresentada a ferramenta CostDDS com suas características,
especificação funcional, arquitetura e algumas interfaces gráficas;
No Capítulo 8 é descrito o processo de avaliação da ferramenta, considerando as
etapas de elaboração do questionário, seleção das empresas, apresentação da ferramenta,
aplicação do questionário e, por fim, a análise dos dados coletados para verificação da
aceitação do trabalho;
Por fim, no Capítulo 9 é apresentada a conclusão deste trabalho, o diferencial
apresentado pela CostDDS em relação às demais ferramentas encontradas e relacionados os
possíveis trabalhos futuros para evolução da ferramenta.
7
Estimativa de custos
Neste Capítulo é abordada a estimativa de custo de desenvolvimento de software como foco
principal. Inicialmente, é apresentada uma visão geral da Contabilidade de custos adotada por
empresas desenvolvedoras de produtos de software. Em seguida, são apresentadas algumas
opções e técnicas para a realização da estimativa de custos relacionados com os trabalhos
dessas empresas.
2.1 Visão geral da contabilidade de custos
A análise dos custos do processo de desenvolvimento de software é uma atividade que possui
características que a tornam muito complexa. Por isso, a contabilidade de custos apresenta-se
como uma técnica a ser utilizada para identificar, mensurar e informar os custos dos produtos
e/ou serviços. Ela tem a função de gerar informações precisas e rápidas para a administração,
auxiliando a tomada de decisões (Crepaldi, 2004; Bruni e Fama, 2004; Vanderbeck e Nagy,
2003; Beulke e Bertó, 2006).
Há algumas décadas a maioria das empresas somente se dedicavam ao comércio,
comprando e revendendo mercadorias. Para calcular os resultados das operações realizadas
com as mercadorias, bastava calcular o Custo das Mercadorias Vendidas (CMV) utilizando
uma simples fórmula, equação (2.1).
2
Capítulo
8
CMV = Estoque inicial + Compras líquidas – Estoque final (2.1)
Com o advento da Revolução Industrial, as empresas industriais passaram a produzir
em grande quantidade por meio de máquinas. Nesse momento, a Contabilidade de custos teve
seu desenvolvimento adaptando-se a nova realidade econômica, em que, a apuração dos
custos dos produtos vendidos deveria incluir todos os elementos empregados na fabricação
desses produtos (Crepaldi, 2004; Bruni e Fama, 2004).
Basicamente, os custos industriais podem ser resumidos em três elementos:
1. MD - Material direto aplicado (matéria-prima, material secundário e
embalagem);
2. MOD - Mão-de-obra direta empregada na fabricação do produto (incluindo o
valor dos salários e encargos sociais);
3. CIF - Custos indiretos de fabricação (demais gastos fabris).
A forma de cálculo dos Custos dos Produtos Vendidos (CPV) é derivada da fórmula
usada para apurar o CMV de uma empresa comercial. Existem diferenças no cálculo entre as
empresas comerciais e as empresas industriais. Esta diferença está nas entradas; na empresa
comercial, elas são representadas pelas compras líquidas, enquanto que na empresa industrial
elas são representadas pelo custo de produção, Figura 2.1.
Figura 2.1. Fluxo comparativo entre empresas comerciais e industriais (Crepaldi, 2004).
Essa diferença, na Figura 2.1, se deve às atividades que desempenham esses dois tipos
de empresas; enquanto a empresa comercial se limita a revender mercadorias utilizando o
CPV, as empresas industriais compram material direto (MD), transformam esse material
direto em um produto acabado com a aplicação de mão-de-obra direta (MOD) somada com os
custos indiretos de fabricação (CIF), para somente depois deste processo, vender o produto
produzido. As empresas que desenvolvem produtos de software possuem semelhanças às
atividades de uma empresa industrial (Gomes, 2004).
9
2.1.1 Classificação dos custos
Na Contabilidade de custos, os custos estão classificados em duas grandes divisões: Custos
diretos e Custos indiretos de fabricação (Crepaldi, 2004; Bruni e Fama, 2004; Vanderbeck e
Nagy, 2003; Beulke e Bertó, 2006), conforme descrito a seguir.
Custos diretos
Custos diretos são aqueles que podem ser apropriados diretamente aos produtos e
variam com a quantidade produzida. Sem estes custos o produto não existiria. Sua apropriação
pode ser direta, basta que exista uma medida de consumo, como quilograma, horas-máquinas,
material secundário e embalagens. Os custos diretos estão divididos em: material direto e
mão-de-obra direta (Crepaldi, 2004; Bruni e Fama, 2004).
Material direto (MD) é o custo dos materiais que se identificam diretamente com o
produto e que se torne parte integrante dele. Exemplos: matéria-prima, material secundário,
embalagens, etc.
Mão-de-obra direta (MOD) é o custo dos esforços produtivos das equipes relacionadas
à produção dos bens comercializados ou dos serviços prestados. É levado em consideração
apenas o pessoal que trabalha diretamente sobre o produto em elaboração, desde que seja
possível a mensuração do tempo despendido e a identificação de quem executou o trabalho.
Exemplos: salários, inclusive os encargos sociais (13º, férias, FGTS, INSS, etc.) dos
empregados que trabalham diretamente na produção.
Em resumo, MOD é a mão-de-obra empregada na transformação do material direto em
produto acabado.
Custos indiretos de fabricação
Custos indiretos de fabricação (CIFs) são os custos que não podem ser identificados
diretamente com os produtos, sendo necessário alguma forma de rateio para fazer sua
apropriação aos produtos. São gastos identificados com a função de produção ou elaboração
do serviço a ser comercializado (Crepaldi, 2004; Bruni e Fama, 2004).
Os CIFs são todos os custos que não estão vinculados diretamente ao produto, mas ao
processo produtivo. Exemplos: aluguel; depreciação das máquinas e ferramentas industriais;
energia elétrica consumida; gastos de manutenção; gastos com água; IPTU; mão-de-obra
indireta (demais funcionários da fábrica); materiais indiretos (lubrificantes, lixas, colas);
gastos com veículos da fábrica; material de escritório; conta telefônica; demais custos fabris.
10
A forma de transferir estes CIFs aos produtos é um dos maiores problemas da
contabilidade. O processo é genericamente chamado de rateio. O rateio é um artifício
(cálculo) empregado para distribuição dos custos. Os custos indiretos precisam ser rateados
antes de serem apropriados aos produtos. O que na maioria das vezes não é simples. Em
diversos tipos de empresas, assim como, as desenvolvedoras de produtos de software, são
fabricados vários produtos por meio de várias fases de processamento e que, muitas vezes,
passam por vários departamentos, tornando o processo do rateio muito complexo.
2.1.2 Departamentalização
A departamentalização consiste em dividir a empresa em segmentos, chamados
departamentos, aos quais são debitados os custos de produção neles incorridos. Departamento
é uma unidade mínima administrativa na qual sempre há ou deveria haver um responsável
(Crepaldi, 2004; Bruni e Fama, 2004).
O objetivo da departamentalização é melhorar a determinação do lucro e o controle
das operações de uma empresa. Com isso, facilita o controle dos custos incorridos e
possibilita melhorar o processo de alocação dos gastos aos produtos.
Algumas empresas são divididas em unidades, centros de custos, com os mesmos
objetivos da departamentalização (Crepaldi, 2004).
2.1.3 Sistemas de acumulação de custos
A forma de como os custos são acumulados e apropriados aos produtos é chamada de
Sistemas de Acumulação de Custos (Crepaldi, 2004; Bruni e Fama, 2004). Dois sistemas
básicos de acumulação de custos são regularmente empregados. O que determina qual dos
dois sistemas vai ser usado é o processo produtivo da empresa. Estes sistemas são
mecanismos utilizados nas transferências de valores aos produtos ou serviços ofertados pelas
empresas. São eles:
• Produção por ordem ou encomenda: quando a empresa fabrica produtos diferentes, em
pequenas quantidades, geralmente atendendo a encomendas (pedidos específicos) dos
clientes. Exemplo: indústria de software por encomenda, indústria naval,
equipamentos, aviões, etc.
• Produção contínua ou em série: quando a empresa opera na fabricação de produtos
iguais, produzidos de maneira contínua. Geralmente, ela produz para o estoque.
11
Exemplo: indústria de software em pacote, óleos vegetais, produtos farmacêuticos,
produtos químicos, etc.
Muitas empresas combinam os dois sistemas de acumulação de custos para atribuir os
custos aos produtos.
2.1.4 Métodos de custeio
A forma utilizada para a apropriação de custos aos produtos e/ou serviços é chamado de
Métodos de Custeio.
Existem dois métodos básicos de custeio: Custeio por absorção e Custeio variável ou
direto. Eles podem ser utilizados em qualquer sistema de acumulação de custos (Crepaldi,
2004). Além desses, tem-se o método de Custeio por Atividade ou ABC – Activity Based
Costing (Beulke e Bertó, 2006).
Custeio por absorção
O método de custeio por absorção foi derivado da aplicação dos princípios
fundamentais de contabilidade e é adotado no Brasil pela legislação comercial e pela
legislação fiscal.
Nesse método de custeio, todos os custos de produção (tanto gastos variáveis como
fixos, ou então diretos ou indiretos) são apropriados aos produtos do período. Os custos de
produção podem ser apropriados diretamente, como é o caso do material direto e mão-de-obra
direta, ou indiretamente, como é o caso dos custos indiretos de fabricação.
Custeio variável (ou marginal)
Conhecido também como custeio direto, é um tipo de custo que considera como custo
de produção apenas os custos variáveis incorridos em um período, desprezando os custos
fixos.
A expressão gastos variáveis designa os custos que, em valor absoluto, são
proporcionais ao volume da produção, isto é, oscilam de forma direta em relação aos
aumentos ou reduções das quantidades produzidas.
Custeio por atividade (ABC)
A característica básica do custeio por atividade (ABC) é a apropriação de todos os
custos e despesas diretas (fixas ou variáveis) possíveis aos produtos e/ou serviços.
12
Este sistema de custeio surgiu recentemente em razão de alterações que ocorreram no
mundo empresarial, dentre as quais pode-se destacar o ingresso da informática nos cenários
empresariais, o que provocou profundas alterações nos sistemas gerenciais de informações
para as decisões.
Neste método de custeio, os custos são constituídos pela soma dos custos das
atividades executadas para concepção do produto e/ou serviço. Como o volume de informação
é muito grande, justifica-se o uso da informática para auxiliar a sua execução.
No entanto, para que seja possível a utilização da informática, existem os custos
relativos à aquisição e manutenção dos produtos de software utilizados. Estes custos são
tratados na próxima seção.
2.2 Tipos de custos de software
Existem três parâmetros envolvidos no cálculo do custo total de um projeto de
desenvolvimento de software (Sommerville, 2004), são eles:
1. Custos de hardware e software
o Custos de hardware: são os custos de aquisição de componentes físicos
(por exemplo, fax, modem, computador, impressora, etc.) que serão
utilizados para auxiliar o desenvolvimento. Para Pressman (2006) o
hardware é uma ferramenta para o desenvolvimento de produtos de
software que está divido em três categorias:
� Hardware de desenvolvimento - fazem parte desta categoria os
computadores e os periféricos utilizados durante o desenvolvimento
do produto de software;
� Hardware de produção - são os computadores em que o sistema
residirá depois de pronto em seu tempo de vida útil;
� Outros elementos de hardware - pode ser necessário por exemplo,
uma máquina específica para executar uma determinada ferramenta
em uma determinada etapa de desenvolvimento;
o Custos de software – nesta categoria incluem-se os custos com a aquisição
de produtos de software privados, mensalidades e anuidades, cujo papel
destes é auxiliar no desenvolvimento de novos produtos de software. Existe
uma gama muito grande de ferramentas que auxiliam em diversas
finalidades na produção de produtos de software. Dentre elas destacam-se
13
ferramentas para: Gerenciamento de Projetos, Integração e Testes,
Programação, Manutenção, Framework, entre outras.
2. Custos de viagens e treinamentos – estes custos são relativamente pequenos em
empresas que atuam localmente. Mesmo em empresas que atuam em cidades
próximas, o custo é declarado como baixo, devido ao uso da tecnologia de
comunicação, tais como: e-mail, videoconferências, telefone, fax, etc.
3. Custos relativos ao esforço empregado – estes são os principais custos de uma
empresa desenvolvedora de produtos de software, pois, os custos que os compõem
diz respeito ao esforço empregado. Estes custos são formados pela soma dos
salários dos engenheiros desenvolvedores em conjunto com os encargos sociais
(13º, férias, FGTS, INSS, etc).
As organizações desenvolvedoras de software calculam os custos de esforço em
termos dos custos gerais, considerando o custo total de operação da organização, dividindo-o
pelo número de pessoas produtivas (Sommerville, 2004).
Os gastos de uma empresa não são constituídos somente destes itens citados acima, a
empresa também deve levar em consideração os gastos com: fornecimento de energia elétrica;
pessoal de apoio (contadores, secretárias, técnicos e pessoal de limpeza); rede e comunicação;
instalações centrais; como bibliotecas; instalações recreativas; previdência social; e benefícios
aos funcionários (pensões, planos de saúde e seguros de saúde).
Os custos de uma empresa, de um modo geral, são em média duas vezes o salário dos
engenheiros de software, dependendo do tamanho da organização e de suas despesas gerais
associadas (Sommerville, 2004). As empresas precisam conhecer os custos de seu trabalho
para poder avaliar o seu lucro (Crepaldi, 2004; Bruni e Fama, 2004;Vanderbeck e Nagy,
2003; Beulke e Bertó, 2006). Desta forma, as empresas desenvolvedoras de software precisam
conhecer os seus custos para poder estimar o preço de seu produto para os clientes.
Na próxima seção é abordado o planejamento de projetos, o qual fornece a base para a
realização das estimativas de custos.
2.3 Planejamento de projetos
Nesta seção é descrito um conjunto de atividades chamadas de “Planejamento de projetos”
para que a gestão do projeto possa ser colocada em prática. A estimativa de projeto
(estimativa de recurso, esforço, custo e tempo) é uma das atividades que compõem o
14
planejamento de projeto. O Planejamento de projeto, por sua vez, faz parte de outro nível de
hierarquia de atividades, chamada “gestão de projetos”.
Pressman (2006) indica uma sequência de atividades relacionadas ao planejamento de
projeto de produtos de software, as quais permitem realizar estimativas precisas do projeto em
questão. Estas atividades são: definição do escopo e viabilidade do software; definição dos
recursos (humanos, hardware e software); decomposição do problema para realização das
estimativas de esforço e custo; análise dos riscos envolvidos; por fim, o desenvolvimento do
cronograma.
2.3.1 Definição do escopo e viabilidade do projeto
O escopo do software é a primeira atividade do planejamento de projeto a ser definida. O
escopo descreve a função, o desempenho, as restrições e/ou limitações, a complexidade, as
interfaces e a confiabilidade do produto de software a ser desenvolvido. Esta descrição deve
ser clara tanto para o nível técnico como para o administrativo.
A viabilidade do projeto é verificada ao se obter respostas afirmativas das seguintes
perguntas: é possível satisfazer o escopo do projeto? O projeto é exequível?
2.3.2 Definição dos recursos
Uma vez definido o escopo, os responsáveis pelo projeto devem estimar os recursos
necessários para seu desenvolvimento, os quais estão divididos em recursos humanos, de
ambiente e de software reusável.
Recursos humanos
Recursos Humanos diz respeito às pessoas envolvidas para a realização do projeto. A
quantidade de pessoas necessárias em um projeto pode ser determinada depois de realizada
uma estimativa de esforço exigido para o seu desenvolvimento. Após o(s) planejador(es)
avaliar(em) o escopo do produto de software a ser desenvolvido, deve-se extrair as
características do projeto e relacioná-las com as habilidades exigidas para o desenvolvimento.
Neste momento, são especificados os postos organizacionais (gerentes, engenheiro de
software sênior, etc.) e também as especialidades (banco de dados, redes, processadores, entre
outras).
Quanto as características de cada recurso humano, deve-se analisar as habilidades, a
disponibilidade e o tempo de utilização do recurso.
15
Recursos de ambiente
O ambiente que incorpora o hardware e software é conhecido como Software
Engineering Environment – SEE (Ambiente de Engenharia de Software). Ele fornece a
estrutura necessária para boas práticas de desenvolvimento de software. O planejador deve
especificar o uso dos componentes de hardware, software e de rede antecipadamente, durante
o planejamento, para que estes estejam disponíveis de acordo com o cronograma.
Recursos de hardware
O hardware é uma ferramenta essencial para o desenvolvimento de um produto de
software. Este está dividido em três categorias conforme descrito em Pressman (2006): i)
hardware de desenvolvimento; ii) hardware de produção; e, iii) outros elementos de hardware.
Nesta etapa o planejador relaciona as necessidades de hardware do projeto e estima a
quantidade de cada tipo de hardware necessária para o desenvolvimento.
Recursos de software
Ferramentas de software são utilizadas para o desenvolvimento de um produto de
software e, na maioria das vezes, utiliza-se um conjunto de ferramentas de software. Essas
ferramentas são destinadas a auxiliar tanto no setor administrativo do projeto como no
desenvolvimento automático de códigos que compõem o produto que se está desenvolvendo.
Atualmente, os engenheiros de software usam um conjunto de ferramentas que
auxiliam a engenharia como a CAD – Computer-Aided Design (design auxiliado por
computador) ou mesmo a CASE – Computer-Aided Software Engineering (engenharia de
software auxiliada por computador).
De acordo com Pressman (2006), essas ferramentas estão divididas em várias
categorias. Dentre elas citam-se:
• Ferramentas de planejamento de sistemas de informação – ferramentas que
auxiliam a modelagem estratégica da informação em uma organização, desta
forma, elas podem encaminhar os dados para àqueles que o necessitam, não
encaminhando informações irrelevantes para estes, auxiliando assim o processo
de tomada de decisão;
• Ferramentas de gerenciamento de projetos – essas ferramentas auxiliam os
gerentes de projetos a planejar e/ou acompanhar as atividades de um projeto,
realizar estimativas de esforço, custo e duração do projeto de software,
também, com o uso dessas ferramentas, é possível definir uma estrutura de
16
divisão de trabalho (Work Breakdown Structure – WBS), pode-se, também,
programar e realizar o acompanhamento das atividades do projeto;
• Ferramentas de apoio – auxiliam os desenvolvedores na produção de
documentos, na comunicação em rede, na administração de banco de dados, no
gerenciamento de configuração, entre outras;
• Ferramentas de análise e projeto – auxiliam os engenheiros de software a criar
modelos do sistema a ser construído, possibilitando-os analisar a consistência
da validade de cada modelo;
• Ferramentas de programação – auxiliam os programadores a desenvolver o
código, permitem editar, compilar e depurar o código-fonte escrito, muitas
delas geram parte do código-fonte automaticamente;
• Ferramentas de integração e testes - são utilizadas para facilitar a execução da
integração e testes, diminuindo assim o esforço aplicado para estas tarefas;
• Ferramentas de construção de protótipo e simulação – auxiliam a construção de
interfaces e relatórios que possibilitem o usuário entender o domínio de entrada
e saída de dados no sistema. Já as ferramentas de simulação executam os
modelos de sistemas, analisando o comportamento dos mesmos antes mesmo
que o sistema seja construído;
• Ferramentas de manutenção - essas ferramentas são usadas para a
decomposição do programa, auxiliando assim para um processo de melhor
esclarecimento por parte do engenheiro, o que facilita o seu trabalho;
• Ferramentas de framework – essas ferramentas oferecem uma capacidade de
gerenciamento de configurações e de banco de dados, algumas também
permitem a integração entre diferentes ferramentas de diferentes vendedores.
As categorias citadas fazem parte das principais categorias de ferramentas utilizadas
para auxiliar o desenvolvimento de produto de software.
Recurso de software reusável
Ao tratar de recursos de software, deve-se também abordar a reusabilidade de códigos.
A reusabilidade é o desenvolvimento de “parte” de um produto de software com o foco na
reutilização desta mesma “parte” para outros produtos. Essas “partes” podem ser chamadas de
blocos de construção ou componentes de produtos de software, onde, com a reutilização de
blocos já prontos, constrói-se um novo produto completo. A Engenharia de software baseada
em componentes enfatiza a reusabilidade de componentes de software. Esses blocos
17
padronizados e já validados (testados e verificados se realmente executam suas funções) são
catalogados com a descrição do seu funcionamento, para poder ser facilmente consultados, de
forma a facilitar a sua aplicação e integração.
Quatro categorias de recurso de software sugeridas por Bennatan (1992) apud
Pressman (2006) devem ser consideradas no planejamento:
1. Componentes de prateleira – são componentes de software já desenvolvidos
que muitas vezes é construído por terceiros e que são utilizados no projeto em
questão.
2. Componentes de experiência plena – são componentes em que a equipe
envolvida no desenvolvimento já possui plena experiência para tal
desenvolvimento. Nesses componentes, os riscos envolvidos são relativamente
baixos.
3. Componentes de experiência parcial – são componentes em que a equipe
envolvida no desenvolvimento possui alguma experiência para tal
desenvolvimento. Nesses componentes, os riscos envolvidos são categorizados
como “consideráveis”.
4. Componentes novos – componentes que precisam ser desenvolvidos para o
projeto.
Durante o trabalho de planejamento, os responsáveis precisam lidar, além das
ferramentas de software necessárias, com os componentes reutilizáveis se o projeto utilizar
algum desses componentes.
Na próxima seção, são expostas outras atividades de planejamento de projetos. Nela
são apresentadas as opções (decomposição, analogias e modelos empíricos) para realização de
estimativas de custos. São expostos, também, alguns riscos envolvidos nas estimativas.
2.4 Estimativas de projetos de software
“Ainda que a realização de estimativas seja em grande parte tanto arte como ciência, essa
importante atividade não precisa ser conduzida ocasionalmente. Existem técnicas para estimar
o tempo e o esforço exigidos em um projeto para o desenvolvimento de um produto de
software” (Pressman, 2006).
As estimativas lançam as bases para outras atividades de planejamento de projetos,
constituindo um mapa do caminho a ser seguido, para que o projeto com base na engenharia
de software seja bem sucedido (Pressman, 2006).
18
A realização de uma estimativa correta e precisa é fundamental para a viabilidade das
atividades de uma organização e para sua sobrevivência. As estimativas exercem uma grande
influência no processo de desenvolvimento de software, por isso, muita atenção é exigida no
momento de estimar o tempo e custo de um projeto de desenvolvimento (Monteiro, 2004).
Para Sommerville (2004), não existe uma maneira simples de fazer uma estimativa
precisa do esforço necessário para desenvolver um produto de software. O autor aponta,
ainda, uma série de fatores que dificultam a produção de uma estimativa exata dos custos de
desenvolvimento de um sistema em um estágio inicial do projeto, entre eles:
� algumas vezes as estimativas iniciais são feitas a partir de um esboço em alto nível
dos requisitos do sistema, realizado pelo cliente;
� é possível que o software tenha que ser executado em computadores que não sejam
familiares;
� uma tecnologia de desenvolvimento nova é utilizada;
� as habilidades das pessoas envolvidas no projeto não são conhecidas.
Por sua vez, Pressman (2006) indica outros fatores que dificultam as estimativas dos
custos, tais como: esforço, política, técnicas ambientais e humanas. Estes fatores contribuem
para que a estimativa de custo de software não seja uma ciência exata. Entretanto, é possível
seguir uma série de passos para se estimar o custo de um produto de software que oferece
riscos aceitáveis. Ainda, Pressman (2006) apresenta quatro alternativas para estimar o custo e
o esforço de um projeto de desenvolvimento de um produto de software:
•••• Quanto mais atrasar as estimativas, obviamente pode-se conseguir estimativas
100% precisas quando o projeto tiver sido concluído;
•••• A segunda opção baseia-se em analogias de estimativas de projetos
semelhantes, anteriormente já concluídos.
•••• A terceira opção consiste na utilização das técnicas de decomposição;
•••• A quarta opção indica-se o uso de um ou mais modelos empíricos e/ou
aquisição e/ou desenvolvimento de ferramentas (software) de estimativas
automatizadas para auxiliar o processo de estimativa.
2.4.1 Opções de estimativas
1 - A primeira alternativa é atraente, mas não praticada, pois as estimativas devem ser
realizadas no início do projeto e sabe-se que quanto mais tarde for estimar o custo, mais
preciso ele será. Ao observar o cone de incertezas Figura 2.2 demonstrado em Sommerville
19
(2004) tem-se a certeza da defesa desta primeira opção.
Figura 2.2 – Cone que representa as incertezas das estimativas (Sommerville, 2004).
Na Figura 2.2 tem-se parte de um plano cartesiano o qual o eixo Y representa a
quantidade de incertezas ao realizar estimativas sobre o projeto em questão, onde o marco
zero (0X) representa a maior quantidade de certeza nas estimativas. Já o eixo X representa o
tempo em fases da engenharia de software. Pode-se observar que na fase inicial do projeto
“Especificação dos requisitos”, as estimativas podem ser, aproximadamente, quatro vezes
para mais ou para menos diferentes da quantidade de esforço, tempo, recursos, e custos
realmente necessários para conclusão do projeto. Esta incerteza vai diminuindo (linha se
aproximando ao marco 0X) ao passar do tempo (fases) e ao alcançar a fase final, “Entrega” do
produto, a linha está sobre o marco 0X, o que significa que é possível, naquele momento,
“estimar” o custo do produto final com 100% de certeza.
Desta forma, esta primeira opção de estimativa não é praticada, pois as estimativas de
um projeto devem ser realizadas o quanto antes, inclusive para verificar se o desenvolvimento
de um determinado projeto é viável.
2 – A segunda opção baseia-se na analogia com a utilização de projetos semelhantes,
anteriormente já concluídos. É necessário que haja uma taxionomia para os projetos. Desta
forma, classificam-se projetos quanto sua complexidade, tamanho, tempo etc. para auxiliar
futuras pesquisas nos dados históricos e facilitar comparações entre projetos.
Durante a comparação devem ser observadas as semelhanças de esforços, bem como,
as influências do projeto (por exemplo, as semelhanças entre as condições do negócio,
20
ambiente de engenharia de software, os prazos e também os clientes envolvidos). No entanto,
nem sempre a experiência entre projetos anteriores é um bom indicador de resultados futuros.
3 - A terceira opção de estimativa de custos de software consiste na utilização das
técnicas de decomposição. As estimativas de projetos de produtos de software são problemas
muito complexos. Essas técnicas de decomposição consistem em dividir o problema em
subproblemas menores, utilizando a abordagem “dividir para conquistar”, com isto, é possível
decompor um projeto em funções importantes e/ou atividades de engenharia de software.
Utilizando a técnica “dividir para conquistar”, o planejador do projeto começa a partir
do escopo do software e divide o projeto em partes menores. Estas partes podem ser em nível
de funções e/ou de atividades de engenharia de software, as quais podem ser estimadas quanto
a seus tamanhos individualmente.
O planejador deve estimar a produtividade das pessoas envolvidas e, logo após a
realização da estimativa do tamanho do produto de software a ser desenvolvido, relacionam-
se os dados referentes à produtividade e de tamanho para se obter o tempo necessário para o
desenvolvimento.
Estimativa de produtividade
Para obter uma boa estimativa de esforço e custo, é preciso estimar a produtividade da
equipe. Essas estimativas de produtividade geralmente baseiam-se em medir alguns atributos
de software e dividir o resultado pelo esforço total exigido para o desenvolvimento. Há dois
tipos de medidas utilizadas (Sommerville, 2004):
a) As medidas relacionadas ao tamanho – essas medidas estão relacionadas ao
tamanho da saída de alguma atividade, a mais comum delas é a contagem de
número de linhas de código-fonte desenvolvida. Também pode-se utilizar outras
medidas, tais como o número de instruções de código-objeto ou número de páginas
de documentação do sistema. As estimativas de tamanho constituem a base para a
derivação das estimativas de custo e de esforço. Sua precisão de tamanho é de
essencial importância para a preparação de um cronograma e orçamento realistas
(SEI, 2002).
b) Medidas relacionadas a funções – Estão relacionadas à funcionalidade geral do
software. As medidas utilizadas são os pontos por função (Pressman, 2006;
Sommerville, 2004; Albrecht, 1979 apud Sommerville, 2004; Albrecht e Gaffeney,
1983 apud Sommerville, 2004; IFPUG, 2009; Braga, 1996), pontos de objeto
21
(Banker et al., 1992 apud Sommerville, 2004) ou pontos de casos de uso (Vieira,
2005; Andrade, 2004; Clemmons, 2006). A produtividade pode ser expressa em
termos de número de funcionalidades produzidas em um certo tempo decorrido
para o desenvolvimento.
A variável tempo leva em consideração a soma de todos os tempos ocorridos nas fases
de análise, projeto, codificação, testes e documentação.
Pressman (2006) menciona algumas métricas de produtividade de baselines, como por
exemplo: LOC/mês (número de linhas de código geradas em um mês) ou PF/mês (número de
pontos por função que são desenvolvidos em um mês).
Sommerville (2004) cita uma série de fatores que podem afetar a produtividade dos
engenheiros de software. Alguns desses fatores são:
• Experiência no domínio da aplicação – os engenheiros que já conhecem o domínio
da aplicação, provavelmente, serão mais produtivos;
• Qualidade do processo – um processo de boa qualidade, certamente, terá um efeito
positivo na produtividade dos engenheiros;
• Tamanho do projeto – quanto maior o projeto, mais tempo será despendido para
seu desenvolvimento;
• Suporte à tecnologia – com a utilização das tecnologias CASE e/ou CAD, pode
melhorar a produtividade;
• Ambiente de trabalho – um ambiente de trabalho tranquilo, com áreas privativas,
também contribui para a melhoria da produtividade.
Com as estimativas da produtividade das pessoas envolvidas no projeto em mãos, o
planejador deve decompor e estimar o tamanho do projeto, desta forma, combinando o tempo
(produtividade) com as estimativas de tamanho, obtém-se uma estimativa da quantidade de
tempo e esforço total exigidos para a conclusão do projeto.
Dimensionamento do software
O dimensionamento do software consiste em estimar o tamanho do software como um
todo, através do dimensionamento do tamanho de cada função que o software deverá
apresentar e/ou do dimensionamento do tamanho de cada atividade necessária para a
elaboração do produto de software. Se uma abordagem direta for utilizada, o tamanho pode
ser medido em número de linhas de código (LOC – Lines Of Code). No caso da utilização de
uma abordagem indireta, o tamanho pode ser representado por pontos por função (PF).
Putnam e Myers (1992) apud Pressman (2006), sugerem quatro abordagens para o
22
problema do dimensionamento: dimensionamento de “lógica nebulosa”, dimensionamento de
pontos por função (PF), dimensionamento de componentes padrão e dimensionamento de
modificação. Segundo os autores, as abordagens devem ser combinadas estatisticamente para
criar uma estimativa.
Na próxima subseção são abordadas três formas de estimativas para a realização da
decomposição e dimensionamento do software.
Estimativa baseada no problema
As estimativas baseadas no problema realizam a divisão do software (problema), a ser
desenvolvido, em termos de funções. Por conseguinte, são estimados os tamanhos dessas
funções por meio de duas principais técnicas distintas:
• Número de linhas de código (LOC) – o planejador do projeto utiliza esta técnica
para estimar o tamanho das funções. A medida desta técnica é dada em termos de
quantidade de número de linhas de código, geralmente esta medida é fornecida em
KLOC, onde, K = 1000 linhas de código;
• Número de pontos por função (PF) – nesta técnica o tamanho da funcionalidade é
dado em termos de combinação de entradas, saídas, arquivos de dados, consultas e
interfaces externas, bem como, os valores de ajuste da complexidade (Pressman,
2006; Sommerville, 2004; Albrecht, 1979 apud Sommerville, 2004; Albrecht e
Gaffeney, 1983 apud Sommerville, 2004).
Além disso, as técnicas LOC e PF podem ser usadas de duas maneiras distintas: 1)
“classificação de tamanhos” de cada funcionalidade do software; 2) como métricas baselines
(linha base) de produtividade, nas quais representam dados passados, e, também, em conjunto
com outras variáveis para futuras projeções de estimativas.
O planejador do projeto pode utilizar uma e/ou outra técnica para estimar o tamanho
das funções que o software deverá apresentar.
Através da utilização dos dados históricos, da intuição e da experiência, o planejador
calcula o tamanho de cada funcionalidade agregando estes valores (dados) por meio da
equação Três pontos ou Valor esperado, equação (2.2):
Valor esperado = (Sot+ 4Sm + Spess)/6 (2.2)
Nesta fórmula, a variável “Valor esperado” representa o tamanho estimado em LOC
ou PF para cada funcionalidade que é obtido pela soma ponderada dos valores Otimista,
23
Médio, e Pessimista, estimados pelo planejador. A variável Sot representa um valor otimista
para o tamanho da funcionalidade, 4Sm representa o valor do tamanho médio multiplicado por
quatro, já a variável Spess representa o valor pessimista para o tamanho.
Com as estimativas do tamanho de cada função prontas, o planejador aplica os dados
históricos de produtividade que refletem a realidade da equipe envolvida e, assim, estima-se o
esforço exigido para desenvolvimento de cada função do produto de software, também, com a
combinação destas estimativas, tem-se a estimativa de esforço e custo para a realização de um
determinado projeto.
Estimativa baseada em processo
Esta técnica de estimativa é a mais comum. Ela baseia-se no processo de software que
será utilizado para o desenvolvimento do produto de software.
Assim como na técnica baseada no problema, a estimativa baseada no processo
começa com o delineamento das funções do software a partir do escopo do projeto. Em
seguida, para o desenvolvimento de cada função é preciso atribuir a execução de uma série de
atividades (comunicação com o cliente, planejamento, análise de risco, engenharia e
construção/entrega).
Da mesma forma que a estimativa baseada no problema, o planejador consulta dados
históricos da equipe envolvida no desenvolvimento e estima o esforço/custo necessário para
cada atividade envolvida.
Combinando as funções do problema com as atividades do processo envolvidas, são
realizadas as estimativas de tamanho e esforço necessário para a realização de cada atividade
do processo de software e, por fim, estimativas para cada função do software. Assim, o
tamanho do produto de software (projeto) é dado pela soma do esforço necessário para
executar todas atividades de cada função, em seguida, soma-se o tamanho e o esforço de todas
funções que o software deverá apresentar obtendo o total do tamanho e/ou esforço exigido
para a conclusão do projeto.
Estimativa baseada nos casos de uso
Para Smith (1999) apud Pressman (2006), deve-se estabelecer alguns pré-requisitos
antes de realizar as estimativas utilizando casos de uso. Esses pré-requisitos incluem a
definição de: nível de hierarquia estrutural; tamanho médio de números de páginas de cada
caso de uso; tipo de software (software de tempo real, negócio, engenharia/científico,
embutido); e um esboço da arquitetura do sistema.
24
Após a definição destes pré-requisitos, utilizam-se dados empíricos para se estabelecer
o número estimado de LOC ou PF para cada caso de uso em cada nível da hierarquia. Ao
agregar os tamanhos de todos os casos de usos envolvidos no projeto, tem-se o tamanho total
do projeto.
Acomodação das estimativas
Após a realização de mais de uma das estimativas de decomposição e
dimensionamento recém discutidas, o planejador deve combiná-las para gerar uma única
estimativa de cada função e/ou atividade. Em seguida, deve combinar essas estimativas para
originar uma estimativa geral de esforço para o projeto em questão.
Quando houver muita desigualdade entre as diferentes estimativas geradas, deve-se: i)
rever o entendimento/interpretação do escopo; ii) verificar a aplicação adequada dos dados de
produtividade usados para as estimativas.
4 - A quarta opção de estimativa utiliza um ou mais modelos empíricos para
estimativa de custo e esforço do software. Esses modelos usam fórmulas empiricamente
derivadas de dados de uma amostra limitada de projetos a fim de prognosticar as informações
de planejamento do projeto. Podem ser usados como complemento às técnicas de
decomposição e oferecem estimativas valiosas através de seu próprio método.
Nesses modelos, os dados gerados de LOC ou PF são inseridos no modelo na tentativa
de prever dados referentes ao planejamento do projeto. Os modelos são derivados de amostras
limitadas de projetos já concluídos, desta forma, não são adequados para todas as classes de
software e/ou para todos os ambientes de desenvolvimento. Por isso, deve-se calibrar o
modelo a ser utilizado para refletir as condições de trabalho locais.
Estrutura dos modelos de empíricos
Os modelos empíricos são derivados por análise de regressão de dados coletados de
projetos de software anteriores. Segundo Mat (94) apud Pressman (2006), os modelos
apresentam uma estrutura geral, representada na equação (3.3).
E = A + B x (ev)c (3.3)
Onde, o esforço em pessoas/mês é representado por E. As constantes A, B e C são
derivadas empiricamente e a variável ev representa a variável de estimativa (LOC ou PF).
Além desta estrutura geral, equação (3.3), existem outros modelos orientados a LOC e
a PF propostos na literatura em que é possível adequar outras características do projeto (por
25
exemplo, complexidade do problema, experiência da equipe, ambiente de desenvolvimento).
Entre os modelos de estimativas orientados a LOC, propostos na literatura
apresentados em Pressman (2006), estão:
E = 5,2 x (KLOC)0,91 Modelo de Walston-Felix
E = 5,5 + 0,73 x (KLOC)1,16 Modelo de Bailey-Basili
E = 3,2 x (KLOC)1,05 Modelo de Boehm simples
E = 5,288 x (KLOC)1,047 Modelo de Doty para KLOC > 9
Os modelos de estimativas orientados a FP são:
E = -91,4 + 0,355 FP Modelo de Albrecht e Gaffney
E = -37 + 0,96 FP Modelo de Kemerer
E = -12,88 + 0,405 FP Modelo de regressão para pequenos projetos
Modelo COCOMO
O modelo COCOMO (Constructive Cost Model) é um modelo empírico de estimativa
mais amplamente utilizado, tanto no meio acadêmico como no meio comercial. O modelo
busca medir esforço, prazo, tamanho de equipe e custo necessários para o desenvolvimento de
um projeto de software, desde que se tenha a dimensão do projeto (Boehm et al., 2000 apud
Cocomo, 2000).
Além das estimavas do tamanho, do esforço e do custo, os planejadores também
precisam estimar o tempo necessário para o desenvolvimento e o número de desenvolvedores
necessários. O modelo COCOMO calcula, também, as estimativas de tempo necessário para o
desenvolvimento por meio de fórmulas derivadas empiricamente e condicionadas em sua
estrutura. No Capítulo 4 é detalhada a estrutura do modelo COCOMO.
Uso de ferramentas de estimativas automatizadas
Essas ferramentas implementam uma ou mais técnicas de decomposição e/ou modelos
empíricos para auxiliar o processo de estimativa, e permitem o planejador estimar os custos e
o esforço, como, também, realizar análises importantes de variáveis de projetos.
Com a utilização de dados do projeto, o modelo implementado por algumas
ferramentas oferece estimativas do esforço exigido para conclusão do projeto, cálculos dos
custos, composição do pessoal, e, em certos casos, a definição do cronograma de
26
desenvolvimento e identificação dos riscos associados.
Existem algumas ferramentas disponíveis para utilização, que apresentam as mesmas
características gerais e realizam funções genéricas demonstradas em seis passos apresentados
em Pressman (2006):
1. Dimensionamento do produto de projeto. O tamanho do produto é estimado
pelas ferramentas, este tamanho pode ser representado por telas, relatórios,
KLOC, PF, documentação, entre outras;
2. Seleção das atividades de projeto. Um processo é especificado e um conjunto
de atividades da engenharia de software é definido.
3. Previsão dos níveis da equipe. Previsão do número de pessoas envolvidas é
especificada.
4. Previsão do esforço de software. O esforço exigido para o desenvolvimento do
projeto é obtido pela implementação de um ou mais modelos empíricos.
5. Previsão do custo do software. Com o passo 4 já determinado, essas
ferramentas calculam o custo envolvido pela alocação da taxa de trabalho com
relação às atividades de engenharia de software.
6. Previsão de cronogramas de software. Quando as atividades do projeto (passo
2), os níveis da equipe (passo 3) e o esforço exigido (passo 4) são conhecidos,
é possível rascunhar o cronograma, de forma a distribuir o esforço às
atividades de engenharia de software.
Sobre as estimativas
Ao utilizar mais de uma técnica de estimativa na tentativa de prever dados referentes
ao projeto de software a ser desenvolvido, provavelmente, diferentes resultados serão obtidos
com a aplicação de diferentes técnicas de estimativas. Quanto maior o número de técnicas de
estimativas utilizadas, tendo como resultado da aplicação destas técnicas a obtenção de dados
relativamente parecidos, mais precisa a estimativa será da realidade do projeto.
As opções viáveis de estimativas são tão boas quanto os dados históricos usados para
fundamentá-las. Caso não existam dados históricos, o levantamento dos custos repousará
sobre uma base muito instável (Pressman, 2006).
Na próxima seção são apresentadas algumas técnicas para realizar estimativas de
custos, estas incorporam ou não uma ou mais das técnicas de estimativas já citadas.
27
2.4.2 Técnicas de estimativas de custos
Na literatura de engenharia de software, são encontradas algumas técnicas utilizadas para
medir os atributos de um software. Em geral, essas técnicas são classificadas em: i) estimativa
baseada no julgamento de um especialista; ii) estimativa baseada em analogias; e, iii)
estimativa baseada em modelos algorítmicos (Lee et al., 1998; Lederer e Prasad, 1995;
Boehm, 1981 apud Sommerville, 2004).
Boehm (1981) apud Sommerville (2004) contribui com a exposição de duas técnicas,
além dessas já citadas acima. De um modo geral, todas essas técnicas de estimativas são
aplicáveis a partir de um documento de requisitos do sistema. Um breve resumo das técnicas é
apresentado no Quadro 2.1.
Quadro 2.1 – Técnicas de estimativas de custos (adaptado de Sommerville, 2004). Técnica Descrição
Estimativa por analogia
A estimativa do custo de um novo projeto é realizada por meio de analogias de projetos que já estejam concluídos com o mesmo domínio de aplicação.
Julgamento de especialistas
São consultados vários especialistas nas técnicas de desenvolvimento de software e no domínio da aplicação, os resultados de suas estimativas são comparados e discutidos até que se chegue a uma estimativa em comum.
Modelagem algorítmica de custo
É implementado um modelo utilizando-se informações sobre o custo histórico que relacione a métrica (geralmente de tamanho) ao custo do software. É feita uma estimativa dessas métricas, e o modelo prevê o custo e/ou esforço requerido.
Lei de Parkinson
O trabalho de desenvolvimento do projeto se amplia para preencher o tempo disponível, no caso de um projeto que tenha 5 pessoas disponíveis e um prazo de 12 meses para sua conclusão, o esforço requerido será de 60 homens/mês.
Preço definido para ganhar
O custo será o mesmo valor que o cliente tiver disponível para gastar no projeto.
Uma ou mais das técnicas descritas no Quadro 2.1 pode(m) ser utilizada(s) para
produzir estimativas na produção de software (Boehm, 1981 apud Sommerville, 2004).
Cada técnica apresenta pontos positivos e negativos e, ao se tratar de projetos grandes,
é necessário utilizar mais de uma técnica de estimativas de custos e comparar seus resultados.
Abordagens para aplicação das técnicas de estimativa
Para (Sommerville, 2004), as técnicas de estimativas de custo podem ser aplicadas
utilizando-se uma ou as duas abordagens:
28
• Top-down – Esta abordagem tem início no nível do sistema, as funções que o
produto deverá apresentar são examinadas de um modo geral e o esforço
necessário para o desenvolvimento de cada uma. Nesta abordagem são levados em
conta os custos de integração entre as funcionalidades, gerenciamento de
configuração e documentação;
• Bottom-up – Esta abordagem tem início no nível do componente. O sistema é
decomposto em componentes e é calculado o esforço necessário para desenvolver
cada um desses componentes, em seguida, esses custos são somados para definir o
esforço exigido para o desenvolvimento do sistema completo.
Tanto a abordagem Top-down como a Bottom-up apresentam vantagens e
desvantagens. As desvantagens que a abordagem Top-down apresenta são as vantagens da
Bottom-up, e vice-versa.
• As desvantagens da estimativa Top-down:
� Pode acontecer uma subestimação dos custos da resolução de
problemas técnicos difíceis associados com componentes específicos,
como, por exemplo, interfaces para hardware não padronizadas;
� Por ser uma abordagem de um nível mais superficial, pode não existir
uma justificativa detalhada para a estimativa produzida.
• As desvantagens da estimativa Bottom-up:
� É mais dispendiosa para sua elaboração, devido a quantidade de
detalhes que devem ser levados em consideração;
� Um projeto inicial do sistema deve existir para identificar os
componentes a serem custeados.
Riscos envolvidos nas estimativas
Muitos riscos podem comprometer os resultados das estimativas, Pressman (2006)
destaca três principais características que podem aumentar os riscos do projeto e que devem
ser estimadas:
1. O grau de estrutura do projeto: à medida que o grau da estrutura aumenta, a
capacidade de se avaliar com precisão é melhorada e os riscos diminuem.
Estrutura aqui refere-se a facilidade com que as funções podem ser dispostas
em compartimentos e quanto a hierarquia das informações que devem ser
processadas;
29
2. Tamanho do projeto: à medida que o tamanho do projeto aumenta, a
interdependência entre os vários elementos do software cresce rapidamente.
Sabendo que a decomposição do problema é uma importante abordagem para
realização das estimativas, alguns dos elementos decompostos ainda podem ser
complexos;
3. Complexidade do projeto: é uma medida relativa que é alcançada através da
familiaridade de projetos já realizados, por exemplo, uma aplicação em tempo
real é extremamente complexa para um grupo de desenvolvimento de
aplicações batch, mas para um grupo de desenvolvimento de software que
desenvolve aplicações rápidas (como por exemplo, envolvendo controle de
processos), a aplicação terá um parecer trivial quanto à sua complexidade.
Os riscos também são estimados pela disponibilidade de informações históricas.
Ferramentas, tais como a “Risc” (Leme, 2007) tratam estes dados históricos e auxiliam os
gerentes de projetos a determinar e prever os riscos envolvidos em projetos de
desenvolvimento de software.
Ao olhar para o passado, podem-se repetir as atitudes que deram certo e consertar as
que deram errado. Quando se tem um histórico das atitudes passadas, é possível realizar
estimativas com maior segurança, estabelecendo prazos com maior precisão, e evitar
dificuldades passadas e, por consequência, a diminuição dos riscos globais. Os riscos são
medidos pelo grau de incerteza das estimativas quantitativas estabelecidas para recursos,
custos e prazo. Sendo assim, se o escopo de um projeto for mal compreendido ou os requisitos
de projeto estiverem sujeitos a mudanças, podem tornar os riscos perigosamente elevados
(Pressman, 2006).
Além dos riscos e incertezas das estimativas em um projeto, o preço estimado para o
desenvolvimento do projeto pode ser afetado por alguns fatores de mercado.
Fatores que podem afetar o preço do software
Alguns fatores podem exercer influência na hora da comercialização do software no
mercado, entre eles (Sommerville, 2004):
• Oportunidade de mercado – As empresas, principalmente iniciantes em um novo
segmento do mercado de software, aceitarão menores lucros até obterem
experiência, e, se preocuparem em aumentar seus lucros somente depois de um
determinado período;
30
• Incerteza da estimativa de custo – Quando a empresa não se sente segura de quanto
realmente gastará para o desenvolvimento, então, julgará um valor maior,
assegurando assim não ter prejuízos para o desenvolvimento do produto de
software;
• Condições contratuais – Faz com que o preço do software diminua, por exemplo, o
cliente permite que o desenvolvedor tenha propriedade sobre o código-fonte,
podendo ser reutilizado em qualquer outro projeto;
• Volatilidade dos requisitos – A empresa, ciente da probabilidade de alterações dos
requisitos, pode diminuir o valor do preço em um primeiro momento para ganhar
um contrato e/ou um cliente, depois é cobrado as mudanças realizadas nos
requisitos;
• Saúde financeira – A empresa que não tiver trabalhos a desenvolver, aceitará um
lucro menor para cobrir pelo menos suas despesas e manter-se ativa no mercado.
Portanto, não há uma relação simples entre o custo do desenvolvimento e o preço
definido para o cliente, o que geralmente envolve a gerência sênior da organização e gerentes
de projetos de software.
Classicamente, o preço não é nada mais que o custo somado com o lucro
(Sommerville, 2004).
2.5 Considerações finais
Neste Capítulo foi realizada uma introdução sobre alguns dos principais conceitos contábeis
utilizados na contabilidade de custos, também, foram abordados temas relacionados à
estimativa de custos de projetos de desenvolvimento de software, tais como: os tipos de
custos envolvidos; as opções para realização das estimativas de custos; as técnicas de
estimativas de custos; por fim, alguns fatores que podem influenciar o preço final do produto
de software.
31
Métricas
No cenário atual, a crescente demanda pela qualidade dos serviços oferecidos pelas empresas,
o aumento da competitividade e a oferta de produtos e serviços diferenciados, se tornaram
fatores críticos para se determinar o sucesso ou fracasso de uma organização. Para se manter
competitiva no mercado, a organização precisa ter conhecimento sobre o seu funcionamento.
Empresas de desenvolvimento de software utilizam os conceitos de medição, medida e
métrica como uma das formas de obter esse conhecimento.
Neste Capítulo são detalhadas algumas métricas de tamanho de software que podem
ser utilizadas em estimativas de custos de projetos de software.
3.1 Medição de software
No contexto da engenharia de software, a medida fornece uma indicação quantitativa da
extensão, quantidade, dimensão, capacidade ou tamanho de algum atributo de um produto ou
processo. Medição é o ato de determinar uma medida. Métrica é definida por IEEE Standard
Glossary (IEEE, 1993) como “uma medida quantitativa do grau em que um sistema,
componente, ou processo possui um determinado atributo”.
Na engenharia de software a medição é um processo chave, utilizada para entender
melhor os atributos dos modelos criados e para avaliar a qualidade dos produtos ou sistemas
submetidos à engenharia (ajudando a projetar e avaliar o produto). As métricas de produto
3
Capítulo
32
auxiliam os engenheiros de software a ganhar profundidade na visão que têm do projeto e do
processo de construção desses produtos de software (Pressman, 2006).
Para Humphrey (1995), os principais papéis de medições de software são:
� Entender – métricas ajudam a entender o comportamento e funcionamento de
processos, produtos e serviços de software;
� Avaliar – métricas podem ser utilizadas para tomar decisões e determinar o
estabelecimento de padrões, metas e critérios de aceitação;
� Controlar – métricas podem ser utilizadas para controlar processos, produtos e
serviços de software;
� Prever – métricas podem ser utilizadas para prever valores de atributos.
Por sua vez, Pressman (2006) divide as métricas de produtos de software da seguinte
maneira:
• Métricas para o modelo de análise (funcionalidade entregue, tamanho do sistema,
qualidade da especificação);
• Métrica para o modelo de projeto (métrica arquitetural, métrica de nível de
componente, métrica de projeto de interface, métrica especializada em projeto
OO);
• Métrica para código-fonte (métricas de Halstead, métrica de complexidade, e
métrica de comprimento);
• Métrica de teste (cobertura de comando e desvio, relacionadas aos defeitos,
efetividade de teste e métricas de processo).
Ao se tratar de modelagem algorítmica de custo, um modelo é implementado com a
utilização de informações sobre o custo histórico de produtos de software relacionados com
métricas (geralmente de tamanho). Desta forma, este trabalho utiliza o tamanho do software a
ser construído como entrada para o modelo de estimativa de custo. Assim, dá-se a devida
importância para métricas relacionadas ao tamanho de software, que pode ser medido usando
uma ou mais das seguintes técnicas: pontos por objeto, número de linhas de código-fonte e
pontos por função, descritas a seguir.
33
3.2 Pontos por objeto
Pontos por objeto é uma métrica relacionada ao tamanho do software, na qual o tamanho do
software é medido pela soma da quantidade de pontos por aplicação que ele apresenta, ou
também chamado de pontos por objeto.
Para calcular a quantidade de pontos por objeto do produto de software a ser
desenvolvido, é necessário contar os elementos (quantidade de telas, relatórios e o número de
componentes em linguagem de terceira geração). Após a contagem, classifica-se cada
elemento em: simples, médio ou difícil. Estas classificações refletem o esforço relativo
necessário para implementar o elemento com um certo nível de dificuldade. Para cada
classificação um peso é assumido, conforme mostrado na Tabela 3.1:
Tabela 3.1 – Pesos referentes à complexidade para os pontos por aplicação (Kauffman e Kumar, 1993 apud Pfleeger, 2004).
Tipo de elemento Simples Médio Difícil
Formulário 1 2 3
Relatório 2 5 8
Componente 3gl - - 10
Em seguida, soma-se a quantidade de um tipo de elemento de uma certa classificação,
depois, multiplica-se o resultado da soma pelo peso referente na tabela. Após a multiplicação
de todos os tipos de elementos com suas respectivas classificações, soma-se todos os
resultados obtidos, produzindo o número de Pontos por Objeto (PO).
A reutilização também pode ser calculada para os cálculos da quantidade de pontos
por objeto. Por meio da equação (3.1) é possível calcular a quantidade de Novos Pontos por
Objeto (NOP):
NOP = (Pontos por Objeto) X [(100 – r)/100] (3.1)
onde: r representa a porcentagem de reuso a partir de projetos anteriores.
Para derivar uma estimativa de esforço, com base no valor de novos pontos por objeto,
uma “taxa de produtividade” precisa ser derivada. Essa taxa de produtividade é derivada com
base na experiência e na capacidade dos desenvolvedores, associada com a maturidade e a
capacidade do ambiente CASE, conforme Tabela 3.2.
34
Tabela 3.2 – Cálculo de estimativa de produtividade (Banker et al., 1992 apud Pfleeger,
2004). Experiência e capacidade dos desenvolvedores
Muito baixa Baixa Média Alta Muito alta
Capacidade e maturidade do ambiente CASE
Muito baixa Baixa Média Alta Muito alta
Fator produtividade 4 7 13 25 50
Quando ocorre diferenças de classificação entre a experiência e capacidade dos
desenvolvedores (Linha 1 da Tabela 3.2) e a capacidade e maturidade do ambiente CASE
(Linha 2 da Tabela 3.2) é realizado um cálculo de média para se chegar a um valor comum.
Uma vez determinada a taxa de produtividade, a estimativa de esforço do projeto pode
ser derivada pela equação (3.2).
Esforço estimado = NOP/PROD (3.2)
A variável “Esforço estimado” é o resultado de quantas pessoas serão necessárias para
o desenvolvimento de um determinado produto de software.
3.3 Número de linhas de código-fonte
A métrica “número de linhas de código-fonte” calcula o tamanho do software a ser
desenvolvido por meio da quantidade de linhas de código-fonte (SLOC) que o software terá
depois de pronto. A quantidade de linhas de código é expresso em milhares (K). Ao combinar
as duas expressões temos (KSLOC) milhares de linhas de código-fonte.
A contagem de linhas de código-fonte é a forma mais dominante na classe de medidas
de software orientadas ao tamanho (Peters, 2001).
Apesar de sua forma conceitual simples, há certas ambiguidades em relação à forma
de contagem dessas linhas devido à forma com que elas são quantificadas. Para Braga (1996),
essas ambiguidades se referem às diferenças de contagens, tais como: a consideração ou não
das linhas de comentários; diferentes visualizações sobre a qualidade do software, e; o
incentivo a documentações mais completas. Desta forma, é preciso estabelecer critérios para
padronizar o processo de contagem.
35
3.4 Pontos por função
A técnica Análise de Pontos por Função - APF (Function Point Analysis) foi desenvolvida em
1974 por Allan Albrecht (Long, 2002) e, posteriormente, refinada pela International Function
Point Users Group (IFPUG). Consiste em uma técnica que mede o software por meio das
funções que ele apresenta. A técnica se baseia em medir e ponderar características do software
visíveis ao usuário, de modo a produzir uma pontuação geral.
O objetivo é disponibilizar uma média de tamanho do produto logo no início do
processo de desenvolvimento. Muitas vantagens referentes ao uso desta técnica são citadas em
Braga (1996), tais como: ser uma unidade de medida padrão para software; ser uma técnica
que provê recursos de estimativa de software; é independente da tecnologia e ferramentas de
modelagem/desenvolvimento/construção; é de simples assimilação e empregabilidade; possui
métricas não técnicas, transparentes e inteligíveis a todos os envolvidos (Stakeholders) no
projeto; entre outras.
A APF está baseada em medidas indiretas sobre a complexidade do software, onde a
IFPUG é o grupo responsável pela padronização (IFPUG, 2009). Além disso, o método de
contagem é independente de tecnologias e é visível ao usuário.
O ponto inicial da contagem consiste em determinar a quantidade de itens que ocorrem
no sistema. Estes itens, segundo (IFPUG, 2009) estão divididos em funções de dados e
funções de transações:
• Funções de dados
� Arquivos internos (os arquivos internos são arquivos-mestres do sistema);
� Arquivos externos (tratam de todas as interfaces interativas com outros
sistemas que sejam legíveis por máquina);
• Funções de transações
� Entradas externas (são entradas do usuário, as quais fornecem dados
distintos orientados à aplicação. Por exemplo, nomes de arquivos e as
seleções de menus);
� Saídas externas (são dirigidas ao usuário e se apresentam na forma de
diversos relatórios e mensagens);
� Consultas do usuário (são entradas interativas que requerem uma resposta
do sistema).
Estes itens são classificados com três níveis de complexidade: simples, médio ou
complexo. O mapeamento sugerido para estes três níveis em uma escala numérica é mostrado
36
na Tabela 3.3.
Tabela 3.3 – Pesos dos itens de APF.
Item Simples Médio Complexo Entrada externa 3 4 6 Saída externa 4 5 7 Consulta do usuário 3 4 6 Arquivo externo 7 10 15 Arquivo interno 5 7 10
A Contagem Não-ajustada de Funções (CNF) é determinada pela somatória do número
de itens que correspondem a essas categorias, multiplicado pelos respectivos pesos (pi),
equação (3.3):
CNF = Σ itemi pi (3.3)
A contagem não-ajustada de funções consiste na primeira fase da contagem. Durante a
segunda fase, a contagem dos Pontos por Função (PF) é refinada pela inclusão de um fator
denominado Fator de Complexidade Técnica (FCT), o qual multiplica o valor original da
(CNF), produzindo a contagem ajustada de pontos por função (PF), equação (3.4):
PF = CNF * FCT (3.4)
O FCT é constituído de 14 características do projeto e os cálculos do FCT são
realizados utilizando a equação (3.5) como fórmula experimental derivada:
FCT = 0,65 + 0,1 ΣFi (3.5)
Onde: Fi = soma total dos graus de influência das 14 características (Tabela 3.4). Os
fatores (características) são detalhados e contribuem para a noção geral de complexidade.
Cada fator é classificado em uma escala de 0 até 5, onde 0 corresponde à classificação
“irrelevante” e 5 corresponde a “essencial”.
Os cálculos de FCT implicam que a faixa dos valores possíveis fica restrita ao
intervalo de 0,65 (todos os fatores classificados como “irrelevantes”) até 1,35 (todos os
fatores considerados “essenciais”). Com isso, as modificações dos valores do FCT ficam na
faixa de +ou- 35% dos valores nominais.
37
Tabela 3.4 – Fatores de complexidade técnica.
Fatores (características)
F1 - Comunicação de dados F8 - Atualizações on-line F2 - Funções distribuídas F9 - Processamento complexo F3 - Desempenho F10 - Usado em outras aplicações F4 - Configuração altamente utilizada F11 - Fácil instalação F5 - Volume de transação F12 - Fácil operação F6 - Entrada de dados on-line F13 - Múltiplos locais F7 - Eficiência do usuário Final F14 - Modificação facilitada
O processo de contagem da técnica APF é ilustrado na Figura 3.1.
Figura 3.1 – Contagem da técnica APF (Peters, 2001).
A contagem dos pontos por função começa com a contagem do número de cada tipo
de item. Fatores de ponderação (pesos dos itens Tabela 3.3) são aplicados a essas contagens,
produzindo a contagem não-ajustada de funções (CNF). Logo em seguida, fatores de
complexidade técnica são aplicados a CNF, a qual produzirá a contagem de funções (CF).
É possível utilizar a contagem não-ajustada de funções (CNF) para se determinar o
tamanho em linhas de código-fonte (SLOC) de um determinado software. Esse processo de
conversão da CNF para SLOC é chamado de Backfiring (BFPUG, 2009). A Tabela 3.5 é
utilizada para auxiliar a conversão de CNF para SLOC. Esta tabela apresenta uma média da
conversão geral, ela pode ser alterada para atender as características de programação local.
38
Tabela 3.5 – Valores padrões para conversão de CNF para SLOC (Cocomo, 2000). Linguagem Padrão Linguagem Padrão
SLOC/CNF SLOC/CNF Access 38 Jovial 107 Ada 83 71 Lisp 64 Ada 95 49 Machine Code 640 AI Shell 49 Modula 2 80 APL 32 Pascal 91 Assembly - Basic 320 PERL 27 Assembly - Macro 213 PowerBuilder 16 Basic - ANSI 64 Prolog 64 Basic - Compiled 91 Query – Default 13 Basic - Visual 32 Report Generator 80 C 128 Second Generation Language 107 C++ 55 Simulation – Default 46 Cobol (ANSI 85) 91 Spreadsheet 6 Database – Default 40 Third Generation Language 80 Fifth Generation Language 4 Unix Shell Scripts 107 First Generation Language 320 Fortran 77 107 Forth 64 Fortran 95 71 High Level Language 64 Fourth Generation Language 20 HTML 3.0 15 Visual Basic 5.0 29 Java 53 Visual C ++ 34
Uma observação importante é a utilização da contagem não-ajustada funções para
realização da conversão em linhas de código. A pesquisa de Kitchenham e Känsälä (1997)
apud Vieira (2007) mostrou que o fator de ajuste das funções não melhora a estimativa da
Análise de Pontos por Função, tanto é que o IFPUG tornou-o opcional para adequar-se ao
padrão ISO/IEC de medição funcional.
No Brasil, diversas empresas públicas têm adotado a métrica de pontos por função
(PF) como unidade padrão de medida de tamanho em editais de licitação para contratação de
serviços de desenvolvimento de software, devido às seguintes razões: I) é um método padrão
de estimação funcional; II) centenas de empresas e profissionais têm usado; III) tem um órgão
responsável pela padronização do uso em nível mundial; IV) é um fator que facilita a
comunicação; e V) é um instrumento eficaz na medição de contratos (Andrade e Oliveira,
2005).
A quantidade de pontos por função é uma das métricas de estimativa de tamanho mais
sedimentadas no mercado e que proporciona resultados cada vez mais precisos à medida que
artefatos da fase de análise e projeto são gerados (Caldiera et al., 1998 apud Andrade e
Oliveira, 2004).
39
3.5 Considerações sobre as métricas de tamanho
A técnica de contagem de pontos por objeto pode ser utilizada na fase inicial de projetos, onde
são importantes: (i) a construção de protótipos para resolver questões de alto risco envolvendo
interfaces com o usuário; (ii) a interação entre software e entre sistema; (iii) o desempenho;
ou (iv) a maturidade tecnológica. Neste momento, pouco se sabe sobre o provável tamanho
final do produto de software a ser desenvolvido (Pfleeger, 2004).
As técnicas LOC e PF, podem ser utilizadas tanto nas fases iniciais como nas fases
mais avançadas do desenvolvimento. Elas diferenciam-se por apresentarem níveis de detalhes
distintos. Neste caso, a técnica APF, por apresentar uma visão mais macroscópica, exige um
nível de detalhamento mais ameno (Pressman, 2006).
No contexto deste trabalho, as estimativas são realizadas depois da decisão de
continuar o desenvolvimento, quando os projetistas estão na fase de exploração de alternativas
de arquiteturas e conceitos de operação. Por esse motivo, dá-se a importância especial para as
métricas de tamanho utilizadas em modelos algorítmicos de custos, como é o caso do número
de linhas de código-fonte (SLOC) e pontos por função (PF) depois convertida em número de
linhas de código-fonte.
Independente da(s) técnica(s) utilizada(s), o planejador fornece um limite de valores
para cada função decomposta. Tomando como base projetos antes desenvolvidos ou a própria
intuição, o planejador estima um valor otimista, um valor provável e um valor pessimista,
para cada função do software.
40
41
Modelo COCOMO II
É apresentado, nesse Capítulo, o modelo COCOMO II, estabelecido originalmente em Boehm
(1981).
4.1 Modelo COCOMO II
Barry Boehm (Boehm, 1981) introduziu uma hierarquia de modelos de estimativa de
software denominada COCOMO (COnstrutive COst MOdel) - Modelo Construtivo de Custo,
conhecido como COCOMO 81. Para elaborar e calibrar o modelo foram necessárias
informações de um considerável número de projetos concluídos.
O Modelo COCOMO II, descrito em Software Cost Estimation with COCOMO II
(Boehm et al., 2000 apud Cocomo, 2000), é uma atualização e extensão do bem conhecido
modelo de estimativa de custo COCOMO 81. Esta atualização tornou-se necessária devido à
incapacidade do modelo COCOMO 81 em lidar com ciclos interativos e com a utilização de
componentes Commercial-Off-The-Shelf (COTS1) e, também, por ser elaborado a partir de
projetos de software considerados antigos.
O modelo COCOMO II está centrado em: questões de modelos de processos de
1 Comercial-off-the-shelf (COTS) são componentes de software prontos para utilização, de terceiros, comercialmente disponíveis, e que se tornam importantes durante a criação do novo software, devendo ser utilizados preferencialmente durante a fase de pré-desenvolvimento do produto (software), segundo Boehm et al., (2000).
4
Capítulo
42
desenvolvimento rápidos e não sequenciais; abordagem de reutilização envolvendo pacotes
COTS; reengenharia; composição de aplicações; efeitos da maturidade do processo de
software; e qualidade das estimativas.
As pesquisas sobre o modelo COCOMO II foram conduzidas pelo Diretor Barry
Boehm do Centro de Engenharia de Software na USC (University of Southern California),
com auxílio de outros pesquisadores (Cocomo, 2000).
O COCOMO II é composto de três modelos. Dois modelos são detalhados em
Cocomo (2000): (1) Modelo Early design; e (2) Modelo Post-architecture. Em Pressman
(2006) e Pfleeger (2004), além dos dois modelos, encontra-se detalhado um modelo anterior,
mais simples, conhecido como Modelo de composição da aplicação. Estes três modelos são
explicados na sequência:
1. Modelo de composição da aplicação – este primeiro modelo é usado nos
primeiros estágios da engenharia de software, quando é importante a
prototipagem das interfaces com o usuário, interação do software com o
sistema, avaliação de desempenho e o julgamento da maturidade tecnológica;
2. Modelo Early design – este modelo é mais utilizado para trabalhar em alto
nível, na exploração de alternativas de arquiteturas ou estratégias para o
desenvolvimento interativo. Este modelo apresenta um nível de detalhe
consistente com o nível geral de informações disponíveis e um nível geral de
precisão necessária para realizar as estimativas;
3. Modelo Post-architecture – é o nível mais detalhado dos modelos e é utilizado
desde que a arquitetura do software a ser desenvolvido já esteja pronta, este
modelo oferece informações mais detalhadas para as entradas dos valores dos
direcionadores de custos, permitindo melhor precisão nas estimativas de custo.
4.2 Modelo de composição da aplicação
Este modelo é utilizado em estágios iniciais da engenharia de software, quando há pouco ou
nenhum conhecimento do tamanho do produto final. Sob estas circunstâncias, este modelo
estima o tamanho a partir de pontos por aplicação (Pfleeger, 2004) ou também chamado de
pontos por objeto (Pressman, 2006). Esta técnica obtém o tamanho do software, a ser
desenvolvido, em termos de geradores de esforço de alto nível. Esses geradores de esforço
estão classificados quanto ao número de telas, número de relatórios e o número de
componentes em linguagem de terceira geração.
43
Assim, neste modelo, para se estimar o tamanho do produto a ser desenvolvido,
utiliza-se uma extensão da abordagem de ponto por objeto, sugerida por (Kauffman e Kumar
1993 apud Pfleeger, 2004), e dados de produtividade, relatados por (Banker et. al., 1994 apud
Pfleeger, 2004). A forma de calcular a quantidade de pontos por objeto encontra-se no
Capítulo 3 deste trabalho.
Nos modelos mais avançados (Early design e Post-architecture) do COCOMO II, são
utilizados uma variedade de fatores de escala, direcionadores de custos e procedimentos de
ajustes para se chegar a uma estimativa mais precisa.
4.3 Modelo Early design e Modelo Post-architecture
Estimativa de esforço
Tanto o modelo Early design como o modelo Post-Architecture apresentam a equação
de esforço como uma de suas principais equações. O resultado desta equação é uma
estimativa da quantidade necessária de esforço para realizar o desenvolvimento de um projeto
de software. Este resultado é dado em Pessoas-Mês (PM). Desta forma, a variável PM
representa a quantidade de pessoas necessárias para desenvolver um determinado software no
período de um mês de trabalho. A equação (4.1) do modelo permite calcular o esforço para
desenvolver o produto de software.
PM = A x (Size)E x EAF (4.1)
onde: A = 2,94 (para COCOMO II)
Para melhor entendimento dos modelos tratados, em seguida, a equação 4.1 é
detalhada com explicações sobre o significado de cada constante ou variável que a compõe.
Constante (A)
A constante (A) aproxima-se de uma produtividade constante em PM/KSLOC, para
casos onde o expoente (E) for igual a 1,0. Inicialmente, a constante (A) é fixada com o valor
2,94, o qual representa o valor médio das estimativas da produção global. Deve-se salientar
que esta variável pode ser calibrada para os dados locais e estes devem refletir a produtividade
local, possibilitando uma maior precisão do modelo.
44
Dimensionamento do produto (Size)
Uma boa estimativa do tamanho é muito importante para a aplicação de um modelo de
estimativa. No entanto, determinar tamanho pode ser um desafio. Os projetos são geralmente
compostos de novos códigos, códigos reutilizados a partir de outras fontes (com ou sem
modificações) e de códigos gerados automaticamente.
Tanto o modelo Post-architecture como o modelo Early design usam a mesma
abordagem para o dimensionamento do produto (Size) e para o cálculo dos Fatores de escala
(expoente E).
O dimensionamento (Size), nestes modelos, pode ser realizado contabilizando-se as
métricas de pontos por função e/ou número de linhas de código-fonte.
Nestes dois modelos, o KSLOC (milhares de linhas de código-fonte) é a medida de
base utilizada para se realizar os cálculos. Assim, a quantidade de linhas de código-fonte
representa o tamanho do software a ser construído.
A variável de tamanho “Size” é uma das entradas mais significantes para o modelo
COCOMO. A variável de tamanho está relacionada com o expoente “E” . Este expoente é
composto por uma associação de cinco fatores de escala.
Cálculo do expoente “E” (Fatores de Escalas)
O Expoente “E” da equação do esforço, Equação 4.1, é composto de cinco fatores de
escala “SF” (Scale Factors), ele é o responsável pelas economias e “deseconomias” (gastos)
de escala encontradas em projetos de software de diferentes dimensões (Banker et al., 1994).
O valor da variável “E” é calculado utilizando-se a equação (4.2).
(4.2)
onde: B=0,91 (para o COCOMO II)
Se E<1,0, o projeto apresenta economia de escala. Neste caso, se o tamanho do projeto
dobrar, o esforço relativo ao projeto será menor que o dobro. Assim, a produtividade no
projeto aumenta à medida que o projeto aumenta. Também é possível alcançar algumas
economias de escala do projeto com o auxílio de ferramentas de projetos específicas.
Se E=1,0, as economias e as “deseconomias” estão em uma escala balanceada. Este
modelo linear é frequentemente usado para estimar custos de pequenos projetos.
45
Se E>1,0, o projeto exibe “deseconomias” de escala. Em geral, é causado por dois
principais fatores: 1) elevada comunicação interpessoal entre os membros das equipes. Em
projetos que envolvem muitas pessoas tem-se um “gasto” maior quanto a comunicação e
interação entre estas; 2) a integração de grandes sistemas. A integração de pequenos produtos
(partes) de um produto maior, requer não somente o esforço do desenvolvimento, como
também o esforço adicional de projetar, manter, integrar e testar suas interfaces com o
restante do produto maior.
O efeito exponencial que o expoente “E” tem sobre os cálculos de esforço de um
projeto pode ser facilmente visualizado na Figura 4.1.
SLOC
Figura 4.1 - Os efeitos das “deseconomias” no esforço (Cocomo, 2000).
Na Figura 4.1, os eixos X e Y representam o tamanho do projeto e a quantidade de
esforço necessária para desenvolvimento do projeto, respectivamente.
Os cinco fatores de escala possuem um intervalo de classificação que vai de “Muito
Baixo” até “Extra Alto”. Cada classificação possui um peso (valor SF – Scale Factors)
associado, conforme Tabela 4.1.
Pessoas-mês
46
Tabela 4.1 – Fatores de escala (Cocomo, 2000). Fator
de Escala
Muito Baixo Baixo Nominal Alto Muito Alto Extra Alto
PREC Totalmente
sem procedência
Pouca precedência
Alguma precedência
Geralmente familiar
Muito familiar Total-mente
familiar
SFj: 6,20 4,96 3,72 2,48 1,24 0,00
FLEX Rigorosa Ocasional
relaxamento Algum
relaxamento Conformi- dade geral
Alguma conformidade
Objetivo geral
SFj: 5,07 4,05 3,04 2,03 1,01 0,00
RESL Pouca (20%) Alguma (40%)
A rigor (60%)
Geralmente (75%)
Em sua maior parte (90%)
Por completo (100%)
SFj: 7,07 5,65 4,24 2,83 1,41 0,00
TEAM Iterações
muito complicadas
Alguma dificuldade
nas iterações
Iterações basicamente cooperativas
Bastante cooperativas
Altamente cooperativas
Interações completas
SFj: 5,48 4,38 3,29 2,19 1,10 0,00 Nível de Maturidade de Processo Equivalente estimado (EPML) ou
PMAT SW-CMM Nível 1 Baixo
SW-CMM Nível 1 Alto
SW-CMM Nível 2
SW-CMM Nível 3
SW-CMM Nível 4
SW-CMM Nível 5
SFj: 7,80 6,24 4,68 3,12 1,56 0,00
4.2.2 Precedência
Este fator de escala “PREC” representa o grau de precedência do produto de software
a ser desenvolvido. Se o produto a ser desenvolvido é familiar a vários produtos já
desenvolvidos previamente na empresa em questão, então, o grau de precedência,
provavelmente, será classificado como “Alto”. Uma tabela para auxiliar a classificação dos
níveis de familiaridade está disponível em Cocomo (2000).
4.2.3 Flexibilidade do desenvolvimento
O fator de escala “FLEX” representa a flexibilidade do desenvolvimento do produto
de software, tais como o quanto o produto terá de conformidade com os requisitos pré-
estabelecidos e a necessidade de conformidade com especificações de interfaces. Uma tabela
de níveis de flexibilidade, disponível em Cocomo (2000), pode ser usada para auxiliar a
estimativa do grau de flexibilidade do desenvolvimento.
47
4.2.4 Arquitetura/Resolução dos riscos
O fator de escala “RESL” representa o nível de riscos envolvidos no desenvolvimento
do produto de software. Para se chegar ao resultado deste nível é necessário utilizar uma
tabela de índice de níveis RESL (Cocomo, 2000) e extrair a média das características
subjetivas que o projeto apresenta.
4.2.5 Coesão da equipe
O fator de escala “TEAM” é responsável pela turbulência e pela entropia (medida do
nível de desordem no sistema) causadas pelas dificuldades de sincronização dos stakeholders
(usuários, clientes, desenvolvedores, mantenedor, interfaces, e outros). Estas dificuldades
podem surgir devido a algumas diferenças de objetivos e cultura entre os stakeholders;
dificuldades em reconciliar os objetivos; stakeholders com falta de experiência ou
familiarização na operação como uma equipe. Uma tabela, disponível em Cocomo (2000),
auxilia a estabelecer o nível de risco do projeto em questão.
4.2.6 Maturidade no processo
O processo de determinar o “PMAT” é organizado na Engenharia de Software pelo
Institute’s Capability Maturity Model (CMM). Existem duas formas de classificação da
Maturidade do Processo. A primeira utiliza o resultado de uma avaliação organizada com base
na CMM. A segunda forma está organizada em torno de 18 áreas de processo chave (KPAs)
dentro do Software Engineering Institute - SEI (Paulk et al., 1995 apud Cocomo, 2000)
também disponível em SEI (2002).
Após as classificações dos fatores de escala do projeto em questão, os (SFs)
selecionados são multiplicados e o resultado desta operação será multiplicado por 0,01 e
somado com a constante “B” a qual terá o valor de 0,91 quando aplicado no COCOMO II, o
resultado destas operações dará o valor do expoente “E”, conforme equação (4.2). A constante
“B” da equação pode ser calibrada dependendo das características do local (Cocomo, 2000).
Depois da realização do cálculo do valor do expoente “E”, é necessário calcular o
somatório dos Direcionadores de Custos (EAF - Effort Adjustment Factor).
Direcionadores de Custos e Multiplicadores de Esforço
Os direcionadores de custos (EAF) refletem as características do projeto, do produto,
do pessoal envolvido e do hardware. O modelo Early design é composto por 7 direcionadores
48
de custos, já no modelo Post-architecture, por encontrar-se em um estágio mais avançado de
desenvolvimento, são necessários 17 direcionadores de custos para refletir as características
de desenvolvimento do produto.
Estes direcionadores de custos são utilizados para ajustar o esforço nominal do modelo
e refletir o desenvolvimento do produto. Os direcionadores de custos possuem uma
classificação entre “Extra Baixo” à “Extra Alto”. Em cada classificação de cada direcionador
de custos existe um peso associado, chamado de Multiplicador de Esforço (EM – Effort
Multiplier), conforme Tabela 4.2. Se a classificação do direcionador de custos for “Nominal”,
então o EM deste terá o valor 1,0, assim, não afetará o esforço do desenvolvimento do
produto. Se o direcionador de custos produz mais esforço de desenvolvimento do software,
então seu correspondente EM possui valor acima de 1,0. Caso contrário, EM abaixo de 1,0,
produzirá uma redução do esforço.
Tabela 4.2 – Direcionadores de custos do modelo Post-architecture (Cocomo, 2000). Direcionador de
Custo Descrição Muito
Baixo Baixo Nominal Alto Muito
Alto Extra Alto
Produto
RELY Confiabilidade do software 0,82 0,92 1,00 1,10 1,26 -
DATA Tamanho do banco de dados - 0,90 1,00 1,14 1,28 -
CPLX Complexidade do produto 0,73 0,87 1,00 1,17 1,34 1,74
RUSE Desenvolvimento para o reuso - 0,95 1,00 1,07 1,15 1,24
DOCU Documentação exigida 0,81 0,91 1,00 1,11 1,23 -
Computador
TIME Restrição do tempo de execução - - 1,00 1,11 1,29 1,63
STOR Restrição memória principal - - 1,00 1,05 1,17 1,46
PVOL Mudanças do ambiente - 0,87 1,00 1,15 1,30 -
Pessoal
ACAP Capacidade do analista 1,42 1,19 1,00 0,85 0,71 -
APEX Experiência na aplicação 1,22 1,10 1,00 0,88 0,81 -
PCAP Capacidade do programador 1,34 1,15 1,00 0,88 0,76 -
PLEX Experiência com hardware 1,19 1,09 1,00 0,91 0,85 -
LTEX Experiência na linguagem 1,20 1,09 1,00 0,91 0,84 -
PCON Continuidade da equipe 1,29 1,12 1,00 0,9 0,81 -
Projeto
SITE Desenvolvimento em multi-lugar 1,22 1,09 1,00 0,93 0,86 0,80
TOOL Ferramentas de Software 1,17 1,09 1,00 0,90 0,78 -
SCED Cronograma de desenvolvimento 1,43 1,14 1,00 1,00 1,00 -
49
Os direcionadores de custos da Tabela 4.2 estão detalhados na sequência:
RELY – Required Software Reliability (Confiabilidade requerida do software)
O direcionador de custo RELY reflete a confiabilidade que o software deverá
apresentar. Ele é usado para expressar o efeito das falhas ocorridas no software. Por exemplo,
caso aconteça um erro no software e, devido a isto, vidas humanas correrem perigo, sua
classificação, provavelmente, será “Extra Alto”.
DATA – Data Base Size (Tamanho do banco de dados)
Este direcionador de custo captura os efeitos de grandes testes de dados requisitados
pelo produto a ser desenvolvido. A classificação mais baixa corresponde a um menor tamanho
do banco de dados.
CPLX – Product Complexity (Complexidade do produto)
A complexidade é dividida em 5 áreas: controle de operações, operações
computacionais, operações de equipamentos dependentes, operações de gerenciamento de
dados, operações de gerenciamento de interfaces de usuários. Por exemplo, um código em
tempo real com diversas programações de recursos, provavelmente terá sua classificação
“Extra Alto”.
RUSE – Developed for Reusability (Desenvolvimento para o reuso)
Este direcionador de custo reflete o esforço adicional necessário para a construção de
códigos ou componentes com o pensamento de serem reutilizados em projetos presentes ou
futuros. O esforço adicional consiste em criar um projeto mais genérico do software, com uma
documentação mais detalhada e testes mais extensos. Desta forma, assegurar que os
componentes estarão prontos para serem utilizados na construção de outros produtos de
software.
DOCU – Documentation Match to Life-Cycle Needs (Documentação casada com as
necessidades do ciclo de vida)
Este direcionador de custo é avaliado em termos de adequação da documentação do
projeto às necessidades de seu ciclo de vida. A escala de valores varia desde “Muito Baixo”
(muitas necessidades do ciclo de vida sem cobertura) até “Muito Alto” (excesso para as
necessidades do ciclo de vida).
TIME – Execution Time Constraint (Restrição do tempo de execução)
TIME é o direcionador de custo que reflete a medida da restrição do tempo de
execução imposta em um sistema de software. A classificação “Nominal” corresponde ao
tempo de uso dos recursos menor que 50%, e “Extra Alto” quando 95% do tempo de
execução dos recursos forem consumidos.
50
STOR – Main Storage Constraint (Restrição de armazenamento principal)
O direcionador de custo STOR reflete a medida de restrição de memória principal do
software a ser desenvolvido. A classificação “Nominal” significa restrição menor que 50%, já
o uso de aproximadamente 95% significa uma classificação “Extra Alto”.
PVOL – Platform Volatility (Volatilidade da plataforma)
A plataforma inclui qualquer compilador que suporte o desenvolvimento do produto
de software. Os valores vão desde “Baixo”, onde a cada 12 meses há uma alteração
importante, até “Muito Alto”, onde existe uma alteração importante a cada 2 semanas.
ACAP – Analyst Capability (Capacidade de análise) e PCAP – Programmer Capability
(Capacidade de programação)
Estes direcionadores de custos refletem a habilidade dos membros da equipe de
desenvolvimento. Quanto maior é a habilidade, maior será a classificação dos direcionadores
de custos.
APEX – Application Experience (Experiência na aplicação),
PLEX – Platform Experience (Experiência na plataforma) e
LTEX – Language and Tool Experience (Experiência na ferramenta e na linguagem)
APEX, PLEX e LTEX refletem as experiências que a equipe apresenta diante das
aplicações, plataforma, ferramenta e linguagem. Quanto maior a experiência, mais alta será a
classificação destes direcionadores de custos.
PCON – Personnel Continuity (Continuidade da equipe)
A avaliação da classificação do PCON é determinada pela taxa de rotatividade anual
dos membros da equipe. Por exemplo, para um índice de 3% de rotatividade, a classificação
será “Muito alto”, e para 48%, “Muito Baixa”.
TOOL – Use of Software Tools (Uso de ferramentas de software)
Este direcionador de custo reflete a capacidade das ferramentas utilizadas para o
desenvolvimento. Os valores de TOOL vão desde edição de código simples, “Muito baixo”,
até ferramentas integradas com a gestão do ciclo de vida, “Muito Alto”.
SITE – Multisite Development (Desenvolvimento em multi-lugar)
Diante do aumento do desenvolvimento distribuído (realizado em lugares
geograficamente distintos), foi adicionado este direcionador de custo ao COCOMO II. Para
julgar a classificação deste direcionador de custo, deve-se calcular a média de dois fatores: i)
localização do lugar (a classificação varia desde totalmente localizado até uma distribuição
internacional); ii) suporte à comunicação (a classificação varia desde correio convencional e
algum uso de telefone até multimídia totalmente interativa).
51
SCED – Required Development Schedule (Desenvolvimento do calendário requisitado)
Este direcionador de custo reflete as restrições de tempo impostas à equipe de
desenvolvimento. Os valores são definidos por meio das porcentagens de estreitamento ou
alargamento do cronograma nominal. Quanto maior for a restrição de tempo, maior será o
valor do multiplicador de esforço (EM).
4.4 Direcionadores de custos do modelo Early design
Quando da utilização do modelo Early design, os direcionadores de custos, até então vistos,
estão diluídos em outros direcionadores de custos específicos, tornando o processo de
classificação do software em questão, mais “genérico”. Na Tabela 4.3 é realizado um
mapeamento dos direcionadores de custos do modelo Early design e Post-architecture
(Cocomo, 2000).
Tabela 4.3 – Mapeamento dos direcionadores de custos. Direcionadores de custos modelo
Early Design Direcionadores de custos modelo
Post-architecture PERS ACAP, PCAP, PCON RCPX RELY, DATA, CPLX, DOCU RUSE RUSE PDIF TIME, STOR, PVOL PREX APEX, PLEX, LTEX FCIL TOOL, SITE SCED SCED
Após as classificações dos direcionadores de custos diante do projeto a ser
desenvolvido, os multiplicadores de esforço (EM) são multiplicados e o resultado irá
influenciar na quantidade de esforço necessário para desenvolver o projeto.
Vale ressaltar que existem tabelas, bem detalhadas, para auxiliar a classificação de
cada um dos direcionadores de custos recém discutidos (Cocomo, 2000).
4.5 Duração de projeto e pessoal
Além de estimar o esforço exigido, o gerente de projeto precisa estimar o tempo necessário
para o desenvolvimento, chamado de prazo do projeto.
O COCOMO possui uma equação para estimar o tempo de calendário para completar
um projeto, este tempo é representado pela variável “TDEV” da equação (4.3). Os três
modelos do COCOMO II utilizam a equação (4.4) para estimar o prazo do projeto.
52
TDEV = C x (PMns)(D + 0,2 * (E - B)) (4.3)
onde: C = 3,67; D = 0,28; B = 0,91
O coeficiente “C” pode ser calibrado dependendo do local. A variável “PMns”
representa o esforço nominal, dado em pessoas/mês, calculado utilizando a equação de
esforço (equação 4.1) do modelo utilizado. O expoente “D” é a base do expoente da equação e
pode ser calibrado. O expoente “E” é o mesmo valor do “Expoente” (Fatores de escala)
previamente calculado na equação (4.2). O expoente “B” é um fator de calibragem do
expoente da equação.
Quando o prazo previsto para o projeto (prazo nominal) e o prazo solicitado pelo plano
de projeto não forem os mesmos, a variável “SCED” representará estas diferenças de
restrições de tempo impostas à equipe. Desta forma acontece uma alteração na equação do
tempo, conforme equação (4.4).
TDEV = [C x (PMns)(D + 0,2 * (E - B))] x (SCED%/100) (4.4)
A variável “SCED%” representa o percentual de aumento ou diminuição do prazo
nominal.
O gerente, ao utilizar a equação (4.3) ou a equação (4.4), terá como resultado o tempo
de desenvolvimento (TDEV), o qual representa a quantidade de meses necessários para
concluir o desenvolvimento de um determinado projeto de software. Um mês possui 152
horas de trabalho, devido aos feriados, férias, e licenças por motivo de doença (Cocomo,
2000). A quantidade de horas de trabalho também pode ser alterada para representar a
realidade da equipe local.
Esta estimativa de tempo leva em consideração somente as fases de “Elaboração” e
“Construção” do modelo RUP e as fases de “Projeto”, “Projeto detalhado”, “Codificação e
teste de unidade” e “Integração e testes” do modelo Cascata.
4.6 Considerações finais
Neste Capítulo, foram descritos os três modelos de estimativa que compõem o modelo
empírico COCOMO II, foram mostradas as características e variáveis que são utilizadas para
a realização dos cálculos, bem como as equações envolvidas para estimar o esforço, tempo e
custo em projetos de software.
53
Ambientes de desenvolvimento distribuído de software
Neste Capítulo são tratados os conceitos de Ambientes de Desenvolvimento de Software
(ADS) e Ambientes de Desenvolvimento Distribuído de Software (ADDS). É apresentado o
ADDS DiSEN e sua arquitetura, como também, abordados alguns custos relativos à prática do
desenvolvimento distribuído de software.
5.1 Ambientes de desenvolvimento de software
Um Ambiente de Desenvolvimento de Software (ADS) é definido como um sistema
computacional que fornece apoio ao desenvolvimento, melhorias ao gerenciamento e controle
das atividades de desenvolvimento (Moura e Rocha, 1992).
Um ADS deve se preocupar com o apoio às atividades individuais e ao trabalho em
grupo, ao gerenciamento do projeto, ao aumento da qualidade geral dos produtos e ao
aumento da produtividade. Desta forma, permitir aos engenheiros de software acompanhar o
projeto e medir, por meio de informações obtidas ao longo do desenvolvimento, a evolução
dos trabalhos (Travassos, 1994).
5
Capítulo
54
5.2 Ambientes de desenvolvimento distribuído de
software
Um Ambiente de Desenvolvimento Distribuído de Software (ADDS) pode ser entendido
como um Ambiente de Desenvolvimento de Software (ADS) em que existe o apoio para o
Desenvolvimento Distribuído de Software (DDS), nos quais os membros das equipes de
desenvolvimento estão separados geograficamente. Esta separação pode ser regional,
continental ou global (Prikladnicki e Audy, 2004).
Em busca de maiores vantagens competitivas, visando minimizar custos e utilizar
recursos geograficamente dispersos, várias organizações têm optado pelo DDS por diversas
cidades, regiões ou até mesmo ao redor do globo (Pilatti et al., 2007), (Prikladnicki e Audy,
2004) e (Huzita et al., 2007). Esta modalidade de trabalho traz benefícios como follow-the-
sun, mão-de-obra barata e de qualidade, proximidade do cliente, ganho de produtividade,
melhorias na qualidade, além de permitir tirar proveito da legislação local, dentre outros
(Prikladnicki et al., 2003).
Para Carmel (1999), existem forças centrípetas que exercem influências benéficas para
o DDS, são elas: infraestrutura de comunicação, arquitetura do produto, tecnologia de
colaboração, técnicas de gerência de projetos, processo de desenvolvimento e formação de
equipes. No entanto, existem diversas dificuldades encontradas nesta prática, tais como:
diferenças nas organizações dos grupos, divisão de responsabilidades da gerência, dificuldade
de liderança e motivação, diferenças da parte cultural, diferenças na linguagem de
comunicação, nos recursos humanos, nos materiais compartilhados e dificuldades de
comunicação (Enami, 2006). Para Carmel (1999) existem, também, as forças centrífugas que
prejudicam o DDS, citam-se: diferenças culturais, dispersão (geográfica e temporal), falta de
coordenação, comunicação ineficiente e perda de espírito de equipe. Desta forma, tratando-se
de um DDS, as dificuldades já encontradas em um ADS se intensificam e outras mais surgem.
Um destes ambientes que proporcionam apoio ao desenvolvimento distribuído de
software é chamado de DiSEN, que procura sanar ou mesmo amenizar os problemas
encontrados nesta prática de desenvolvimento.
O ambiente DiSEN
No departamento de Informática da Universidade Estadual de Maringá está em
desenvolvimento o projeto DiSEN – Distributed Software Engineering Environment. Trata-se
de um ADDS projetado para suportar o trabalho colaborativo, o qual busca combinar técnicas,
55
métodos e ferramentas para apoiar todas as atividades inerentes ao processo de construção de
produtos de software, tais como, gerência, desenvolvimento e controle da qualidade (Huzita et
al., 2004; Huzita et al., 2007). O presente trabalho de estimativa de custos em um ADDS está
inserido neste ambiente.
O DiSEN apresenta uma arquitetura composta de três camadas: (1) A camada
Dinâmica, a qual é responsável pelo gerenciamento de configuração do ambiente e permite a
manutenção dos componentes de software e serviços de forma dinâmica em tempo de
execução; (2) A camada de Aplicação dá suporte à metodologia de desenvolvimento de
software distribuído (Gravena, 2000) e ao repositório para armazenamento de informações
necessárias ao ambiente, aos objetos e agentes; (3) A camada de infraestrutura provê suporte
às tarefas de persistência, nomeação, além de incorporar o canal de comunicação. Estes
elementos são apresentados na Figura 5.1.
Figura 5.1 – Arquitetura do DiSEN (Pascutti, 2002).
A implementação da ferramenta proposta por este trabalho deve se apresentar de
forma integrada ao ambiente DiSEN (Huzita et al., 2007). Vários trabalhos relacionados ao
gerenciamento de projetos de software já foram desenvolvidos neste ambiente, dentre eles
cita-se: Pedras (2003), Lima (2004), Pozza (2006), Enami (2006), Leme (2007), Trindade
(2008) e Cibotto (2009).
56
5.3 Custos no DDS
Os custos envolvidos no DDS podem ser relacionados seguindo as características que fazem
parte deste tipo de prática de desenvolvimento. Essas características dão uma visão mais clara
de alguns custos envolvidos durante a execução de projetos de software neste tipo de
ambiente.
Características que influenciam os custos em DDS
Em geral, as características do DDS são provenientes de três categorias principais:
1. Forma de separação dos grupos (agrupamento, distância física e separação
temporal);
2. Regiões envolvidas (culturas regionais, idiomas e diferenças dos locais);
3. Organizações participantes (culturas organizacionais, infraestrutura e relação
legal) (Pilatti e Audy, 2006; Siqueira e Silva, 2004).
Estas características são discutidas a seguir:
Forma de separação dos grupos: nesta categoria a característica “distância física”
exerce influência em termos de custos para um projeto de DDS, pois as equipes podem
trabalhar com outras equipes separadas por uma grande distância, quer seja no mesmo país ou
até mesmo em outro continente.
Enami (2006) comenta a importância das equipes envolvidas em um projeto
realizarem “Encontros de formação” a fim de minimizar ou eliminar os problemas advindos
das diferenças culturais e da dispersão geográfica, fazendo com que os participantes do
projeto de um país entendam melhor os demais envolvidos pertencentes a outros países, o que
pode evitar problemas de comunicação entre os grupos de trabalho. Também, em alguns
casos, se faz necessário que um especialista pertencente a uma equipe se desloque até o local
de outra equipe para realizar manutenção ou por algum motivo específico. Neste caso, em um
projeto DDS deve-se levar em consideração os custos destas viagens.
Regiões envolvidas: quanto à categoria “Regiões envolvidas”, a característica
“Idioma” influencia nos custos em um projeto. A comunicação por meio de um idioma que
não seja o idioma natural das pessoas envolvidas pode ser uma tarefa complicada se não for
bem gerenciada (Favela e Peña-Mora, 2001). Ao se atuar em DDS, faz-se necessário
padronizar o idioma utilizado para comunicação entre as equipes, e inclusive com a
possibilidade de realização de cursos de proficiência para alguns gerentes de projetos que
ainda não dominam o idioma padrão. Ao padronizar o idioma é possível que toda equipe
esteja atualizada sobre os acontecimentos do projeto e a realização de reuniões entre os
57
gerentes com o restante da equipe ajudam a trabalhar as desavenças ou possíveis conflitos
(Pilatti et al., 2007).
Ao tomar os custos como foco, nesta mesma categoria a característica “Diferenças dos
locais” demonstra sua importância. As equipes podem estar sujeitas as diferentes legislações e
diferentes calendários. As legislações, sejam elas comerciais, civis, trabalhistas, etc., afetam o
desenvolvimento de diversas formas. Assim, deve-se ter cautela quanto às legislações
trabalhistas, incentivos fiscais ou de concentração de massa crítica existentes em
determinadas áreas, em alguns países ou regiões (Prikladnicki e Audy, 2004). Essa massa
crítica pode apresentar um salário que signifique menor custo para um desenvolvimento de
um ou mais projetos, aumentando o lucro de suas atividades. Também, em alguns locais
acontece a proibição da importação de hardware, já em outros é proibida a transferência de
dados em suas fronteiras nacionais e diversas restrições governamentais no mundo ao acesso à
Internet (Haywood, 2000).
Organizações participantes: nesta categoria estão incluídas as diferentes “Culturas
organizacionais”. Equipes podem pertencer a diferentes organizações que, por sua vez,
apresentam diferentes culturas organizacionais. Devido a isso, torna-se necessário investir em
treinamento aos gerentes para poder lidar com as diferentes culturas organizacionais, as quais
podem apresentar diferentes padrões de projetos (Prikladnicki et al., 2003), estilos de
trabalho, relações comercias (Olson e Olson, 2003) e, ainda, apresentar uma visão
diferenciada sobre a qualidade (Kobitzsch et al., 2001), etc. Ainda nesta categoria, as equipes
devem trabalhar com uma “Infraestrutrura” adequada, incluída na classe Processos
organizacionais na norma ISO/IEC 12207, a qual define as atividades para se estabelecer e
manter a infraestrutura necessária para qualquer processo, como hardware, software e
ferramentas para desenvolvimento e manutenção (ABNT, 1998). Independente da
organização ser voltada ou não para o DDS, ela precisa ter uma infraestrutura adequada para
permitir o trabalho das pessoas envolvidas. Kobitzsch et al. (2001) comentam, por exemplo,
sobre a necessidade de comprar geradores elétricos e linhas independentes de comunicação
para que seja possível a realização das atividades de desenvolvimento em alguns locais.
Com base na análise destas características do DDS e na abordagem sobre custos, foi
elaborado o Quadro 5.1, o qual contém alguns dos principais custos envolvidos nesta prática
de desenvolvimento.
58
Quadro 5.1 – Classificação dos custos. Custos diretos Custos indiretos
Mão-de-obra equipe desenvolvimento Mão-de-obra equipe administrativa Hardware Rede comunicação Software Telefonia Viagens programadas Energia elétrica Cursos e treinamentos de rotina Água Impostos municipais, estaduais e federais Viagens não programadas Cursos de proficiência
Móveis Imóveis Depreciação dos móveis e hardware Aluguel Seguros Diferenças salariais Diferenças cambiais
Pode-se observar no Quadro 5.1, a divisão entre custos diretos e indiretos, oriundos da
contabilidade de custos. Os custos diretos são aqueles que podem ser apropriados diretamente
aos produtos e variam com a quantidade produzida. Sem estes custos, o produto não existiria.
Já os custos indiretos de fabricação são os custos que não podem ser identificados diretamente
com os produtos, sendo necessário alguma forma de rateios para fazer sua apropriação aos
produtos.
5.4 Considerações finais
Neste Capítulo foram abordados os conceitos de Ambientes de Desenvolvimento de Software
(ADS) e Ambiente de Desenvolvimento Distribuído de Software (ADDS). Foi apresentado o
ADDS DiSEN e alguns, prováveis, custos que se apresentam na prática do desenvolvimento
distribuído de software. Estes custos contábeis devem fazer parte das estimativas de custos de
projetos desenvolvidos de forma distribuída, pois axiliarão os gerentes durante as estimativas
de custos.
59
Trabalhos relacionados
Neste Capítulo são apresentados os trabalhos relacionados com a forma de gestão de custos
em empresas de desenvolvimento de software e prestação de serviços na área de informática,
bem como as ferramentas utilizadas para realização de estimativa de custo em projetos de
desenvolvimento de software.
6.1 Gestão de custos em empresas de desenvolvimento
de software
Alguns trabalhos relacionados com a gestão de custos estão diretamente focados em empresas
de desenvolvimento de software.
Gomes (2004) realiza um estudo em uma pequena empresa de Informática utilizando o
método de custeio baseado em atividades (ABC) para gestão de custos em um sistema
integrado de gestão. O objetivo principal de seu trabalho é a configuração de um sistema de
contabilidade por atividades (SCPA) como um instrumento útil ao processo de gestão de
empresas de serviços em desenvolvimento de software.
O autor traz, em seu trabalho, um modelo genérico de plano de contas para aplicação
em empresas de desenvolvimento de software e, também, apresenta um estudo de caso
detalhado realizado em uma empresa prestadora de serviços que atua no mercado de sistemas
aplicativos empresariais (ERP) no estado de Santa Catarina.
Corrêa (2002) ressalta a falta de um custeamento preciso em empresas que atuam na
6
Capítulo
60
área de informática ou que prestam serviços. Ele apresenta alguns diferentes sistemas de
apuração de custos em sua fundamentação teórica.
Após uma análise em uma empresa desenvolvedora de software e que também presta
serviços na área, verificou-se a carência no custeamento dos custos indiretos neste tipo de
empresa. Em seguida, ele propõe um modelo de implantação do custeio baseado em
atividades (ABC), segundo ele, após análises, este sistema é o que melhor atende às
peculiaridades de uma empresa desenvolvedora de software.
Na conclusão do trabalho, para o autor, os métodos tradicionais de apuração dos
custos são inadequados e deficientes para apuração das despesas e dos custos indiretos em
empresas prestadoras de serviços de informática. Após a modelagem do sistema ABC na
empresa, o autor descreve os passos para sua implantação, a qual foi bem sucedida e atendeu
as necessidades desta empresa.
Souza (2002), da mesma forma que Corrêa (2002), defende o custeamento ABC para
empresas em que atuam com grande número de atividades indiretas, sendo que o sistema
ABC é um método de contabilidade gerencial onde o cálculo dos custos indiretos é bem mais
acurado do que o cálculo realizado pelos sistemas tradicionais.
Em seu trabalho, o autor propõe uma metodologia para a implantação do custeamento
ABC. A implantação da metodologia acontece em uma pequena empresa que comercializa
produtos de software administrativo-financeiros e de recursos humanos, e que também presta
serviços de implantação, manutenção e consultoria, localizada em Florianópolis.
Como conclusão da implantação de sua metodologia proposta, tem-se: a verificação de
todos os recursos consumidos na empresa; mapeamento das atividades executadas nos
processos operacionais, custeando-as e; a verificação da lucratividade de cada objeto de custo
abrangido pela pesquisa.
Estes estudos mostram que a grande vantagem proporcionada pelo sistema de custeio
ABC é a transparência obtida sobre as informações dos custos dos objetos de custo. Estas
informações permitem o gestor comparar as receitas obtidas e os recursos consumidos nos
objetos de custo, observando se estes são lucrativos ou não.
Quanto às estimativas, estes estudos também mostram a necessidade das empresas do
ramo de software com relação à realização de estimativas de custo adequadas com a realidade
destas empresas.
61
6.2 Ferramentas utilizadas para a estimativa de cus to
Algumas ferramentas são utilizadas por empresas desenvolvedoras de software para auxiliar
no desenvolvimento das estimativas de custos de seus produtos ou serviços prestados. Cita-se
as ferramentas:
APFplus – Análise de Pontos de Função
APFplus é uma ferramenta Freeware (gratuita), que pode ser facilmente encontrada
em mecanismos de busca na Internet, com ela é possível calcular a quantidade de pontos de
função para o desenvolvimento ou melhoria de um produto de software.
Esta ferramenta permite registrar aplicativos (produtos de software), projetos, recursos
(somente recursos humanos), equipes, usuários (para distinguir o nível de acesso na
ferramenta) e grupos.
Quanto aos registros das linguagens de programação, é permitido alterar a linguagem
em que o produto será desenvolvido e também a produtividade em cada uma das linguagens,
bem como incluir novas linguagens.
No que se refere às estimativas de custos dos projetos, esta ferramenta considera três
principais variáveis: i) quantidade de pontos por função estimados para um projeto;
ii) produtividade estimada em pontos por função por hora (PF/h) (varia de acordo com a
linguagem) e; iii) custo da hora dos recursos envolvidos para o cálculo.
Com esses dados, a ferramenta divide a quantidade estimada de pontos por função de
um determinado projeto pela produtividade estimada da linguagem. Como resultado tem-se a
quantidade de horas-esforço necessária para o desenvolvimento ou melhoria. Desta forma, a
ferramenta realiza uma estimativa de custo para um determinado projeto de desenvolvimento
ou melhoria de produto de software.
USC-COCOMOII
USC-COCOMOII é um software interativo que auxilia no planejamento orçamentário
e nas estimativas de cronogramas de desenvolvimento de produtos de software. Este software
foi desenvolvido pela University of Southern Califórnia (USC) e teve sua última atualização
no ano de 1999. É um software gratuito e está disponível em Cocomo (2000). Os cálculos são
realizados com a implementação das principais equações do modelo COCOMO II.
Na íntegra, o modelo COCOMO II possui três estágios. A ferramenta USC-COCOMO
62
II implementa as fórmulas do segundo e terceiro estágios para estimar o esforço, cronograma
e custos necessários para desenvolver um produto de software.
A ferramenta permite estimar projetos de desenvolvimento ou adaptação e reuso. Para
auxiliar a entrada do tamanho do produto de software a ser desenvolvido, a ferramenta
implementa a principal tabela do método de análise de pontos por função para estimar a
contagem não-ajustada de funções (CNF).
Como calibração do modelo implementado, a ferramenta permite editar: os principais
valores das equações do modelo COCOMO II; a tabela do processo de backfiring e; novas
linguagens podem ser cadastradas.
A ferramenta divide o projeto em módulos, onde, cada módulo possui uma estimativa
e a estimativa total do projeto é dada pela soma dos módulos.
O custo estimado pela ferramenta é dado pela estimativa da quantidade de horas de
esforço exigido para o desenvolvimento de cada módulo ou projeto, sendo que o valor da
hora-esforço é dado pela média dos custos dos funcionários envolvidos na implementação.
Os relatórios elaborados pela ferramenta USC-COCOMOII são relacionados com o
esforço exigido para cada módulo ou para o projeto completo. Nestes relatórios, a divisão do
esforço é feita por meio da porcentagem de esforço em que cada fase exige. As porcentagens
de esforço podem ser editadas para os processos MBase ou Cascata.
Costar
A Costar é uma ferramenta proprietária utilizada para realizar estimativas de
cronograma, de níveis do time (staffing levels) e de esforço para o desenvolvimento de um
produto de software. Foi desenvolvida pela empresa Softstar Systems e encontra-se na versão
7.0. É possível sua utilização gratuita com a restrição do tamanho do produto estimado ser
menor que 5000 linhas de código-fonte (Costar, 2008).
A ferramenta implementa as equações do modelo COCOMO. Ainda, é possível
escolher a versão do modelo COCOMO a ser usada.
A ferramenta implementa, também, as equações da contagem de pontos por função
com a opção de inclusão do processo de cálculo com os fatores de complexidade técnica.
É possível entrar com os valores médios dos salários dos empregados por fase de
desenvolvimento ou ratear os custos por cargos dentro da organização.
O projeto estimado pode ser dividido em componentes ou sub-componentes para
realização das estimativas, onde o custo final estimado é dado pela soma destas divisões.
63
Vários relatórios são disponibilizados para auxiliar o gerente no processo de
estimativa de custos do projeto de desenvolvimento.
Calico
O Calico é um software destinado para a calibragem das equações utilizadas nos
cálculos da ferramenta Costar, que também foi desenvolvido pela empresa Softstar Systems.
Com o Calico é possível ajustar a maioria das variáveis utilizadas nos cálculos, permitindo
uma calibragem nas estimativas de projetos, e, com isso, a obtenção de estimativas mais
precisas do produto de software a ser desenvolvido.
Com a utilização desta ferramenta, o gerente consegue modificar variáveis de qualquer
um dos modelos COCOMO utilizados, modificar os parâmetros das equações, a quantidade
de horas por pessoa-mês, as porcentagens de esforço para cada fase do processo utilizado, os
valores dos fatores de escala, bem como adicionar fatores de escala caso necessite (Calico,
2008).
Cost Xpert Tool Suite
A Cost Xpert Tool Suite é uma ferramenta de estimativa de custo de projetos de
desenvolvimento de software. É um software proprietário desenvolvido pela empresa Cost
Xpert – The Estimation Company (Cost, 2008). A versão da ferramenta de estimativa
disponível permite seu uso gratuito por um período de 10 dias e, após este período de tempo o
software perde suas funcionalidades caso não seja efetuado o pagamento para sua utilização.
A ferramenta Cost Xpert Tool Suite utiliza as fórmulas do modelo COCOMO para
realizar as estimativas de projetos de software. Durante a entrada dos dados, a ferramenta
classifica os tipos de projetos bem como permite a escolha do ciclo de vida e padrões de
processos. As entradas de tamanho do projeto a ser estimado podem ser classificadas por uma
grande diversidade de métodos. A análise de riscos faz parte das funcionalidades apresentadas
pela ferramenta e os valores da estimativa podem ser divididos por categoria de funcionários
envolvidos no desenvolvimento.
A ferramenta divide os projetos em módulos e calcula o custo total pela soma das
estimativas de cada módulo. Vários tipos de relatórios, tanto textuais como gráficos, fazem
parte das funcionalidades, bem como a exportação de arquivos em vários formatos.
Quanto aos ajustes nas estimativas, a ferramenta permite calibrar a maioria dos dados
com que ela trabalha, bem como as fórmulas utilizadas pelo modelo.
64
WICOMO
Um grupo de estudantes do instituto Wang, no ano de 1982, programou a ferramenta
de estimativa chamada WICOMO (Wang Institute Cost Model) (Fairley, 2006), a ferramenta
foi baseada no modelo COCOMO para realizar as estimativas de projetos de desenvolvimento
de produtos de software. Esta ferramenta não está disponível para o uso e ela foi a progenitora
da ferramenta Costar.
6.3 Comparativo entre as ferramentas
Uma comparação entre as ferramentas disponíveis foi realizada, para isso foram definidos
alguns critérios, que são os seguintes:
� Métricas: esse critério indica as métricas de tamanho de software implementadas
pela ferramenta;
� Plataforma: esse critério indica em quais sistemas operacionais a ferramenta pode
ser utilizada;
� Linguagem de programação: indica as linguagens de programação que a
ferramenta é capaz de trabalhar as conversões das métricas para o número de
linhas de código-fonte;
� Inclusão de novas linguagens de programação: indica se a ferramenta é capaz de
admitir a inclusão de novas linguagens para os cálculos das estimativas;
� Documentação/Help: indica se há documentação para auxílio da utilização da
ferramenta;
� Integração com outras ferramentas: indica se a ferramenta é capaz de trabalhar em
conjunto com outras ferramentas;
� Usuários: indica o nível (cargo ou capacitação) que é permitido para utilização da
ferramenta;
� Relatórios: indica as formas de relatórios que a ferramenta permite gerar;
� Apoio ao DDS: esse critério caracteriza se a ferramenta oferece apoio ao
desenvolvimento distribuído de software;
� Recursos: indicam quais são os recursos que cada ferramenta visa estimar.
Com a utilização destes critérios, foi montado o Quadro 6.1 para representar as
comparações entre as ferramentas de estimativas de custos estudadas.
65
Quadro 6.1 – Comparação entre as ferramentas de estimativas de custos.
Ferramentas
Critérios Cost Xpert Costar
7.0 Calico 7.0
USC- COCOMO
II APF PLUS
Métricas
SLOC, PF, Fast PF, Dominio
Points, Feature Points, GUI Metrics,
Internet Points, MK II Function
Pts, Object Metrics, UML Class Method, UML Use-Case Pts, Bottom Up,
Top Down
SLOC e PF SLOC e PF SLOC e PF SLOC e PF
Plataforma Windows Windows Windows Windows Windows
Linguagem de programação
C, Fortran, Cobol, PI/I, Basic, Ada
Pascal, e outras
C, Fortran, Cobol, PL/I,
Basic, Ada, C++, Java, Visual C++
e Pascal
C, Fortran, Cobol, PI/I, Basic, Ada Pascal, e outras
C, Fortran, Cobol, PI/I, Basic, Ada Pascal, e outras
C, Fortran, Cobol, PI/I, Basic, Ada Pascal, e outras
Admite a inclusão de
novas linguagens
SIM NÃO NÃO SIM SIM
Documentação/Help
SIM SIM SIM SIM SIM
Integração com outras
ferramentas ***
Calico 7.0 e USC-
COCOMO Costar 7.0 *** ***
Usuários *** *** *** *** SIM
66
Quadro 6.1 - Continuação
Ferramentas
Critérios Cost Xpert Costar
7.0 Calico 7.0
USC- COCOMO
II APF PLUS
Relatórios Gráfico e texto Gráfico e texto
*** Texto Texto
Apoio ao DDS *** *** *** *** ***
Recursos Esforço, pessoal, custo e duração
Esforço, pessoal, custo e duração
Esforço, pessoal, custo e duração
Esforço, custo e duração
Custo e duração
*** requisitos não encontrados
6.3.1 Análise das ferramentas
Com o estudo realizado nas ferramentas de estimativa de custo em projetos de software, pode-
se observar que são poucas as ferramentas disponíveis e estas possuem uma abrangência de
cálculos variável.
As ferramentas trabalham com conjuntos de métricas diversificadas, e, por utilizarem
o modelo COCOMO como a base dos seus cálculos, essas métricas são convertidas em
número de linhas de código-fonte para alimentação das equações. No Quadro 6.1 pode-se
perceber que a ferramenta “Cost xpert” implementa uma maior variedade de métricas de
tamanho do produto, porém, para realização dos cálculos, os resultados dessas métricas
também são convertidos em número de linhas de código-fonte.
Todas as ferramentas possuem documentação como auxílio para sua utilização e estão
vinculadas a um único sistema operacional.
Diferentes conjuntos de linguagens de programação são tratados em cada ferramenta,
algumas permitem a inclusão de novas linguagens e outras não.
A falta de apoio ao desenvolvimento distribuído de software, bem como a não
contabilização dos custos totais de uma determinada organização são características
marcantes apresentadas pelas ferramentas estudadas.
67
6.4 Considerações finais
Os trabalhos relacionados aqui apresentados foram agrupados em dois tipos: 1) trabalhos
relacionados com o sistema contábil das empresas produtoras de software, os quais fornecem
uma visão mais abrangente da área de custos; 2) ferramentas de estimativas de software
utilizadas para auxiliar a realização de estimativas de custos de projetos de software. Foi
realizada uma comparação entre as ferramentas analisadas a fim de expor suas características
e suas diferenças.
68
69
Ferramenta CostDDS
Neste Capítulo, é apresentada a ferramenta de estimativa de custos para um ambiente de
desenvolvimento distribuído de software, desenvolvida neste trabalho, a qual está integrada ao
DiSEN. Esta ferramenta pode ser utilizada como auxílio aos gerentes na realização de
estimativas de custos de projetos desenvolvidos de forma distribuída.
7.1 Considerações iniciais
Uma vez definido o objetivo e o escopo do produto de software a ser desenvolvido, o gerente
de projetos precisa dividir o trabalho entre as equipes geograficamente distribuídas. Para isso,
pode-se utilizar a técnica de decomposição para dividir o produto em partes menores, as quais
podem ser mais facilmente gerenciadas. Na ferramenta CostDDS, cada parte da divisão é
chamada de Módulo.
Neste momento, o gerente precisa de um apoio para tomar a decisão de qual módulo
cada equipe será encarregada de desenvolver. Esta decisão precisa levar em consideração o
conhecimento sobre as equipes diante do módulo a ser desenvolvido, e também os custos
contábeis relativos aos locais onde estas equipes se encontram.
Com base na fundamentação teórica sobre estimativas de custo em projetos de
software e por meio de análise de ferramentas utilizadas para realizar estimativas, foi possível
projetar e implementar a ferramenta CostDDS. Esta ferramenta está integrada ao ambiente
7
Capítulo
70
DiSEN e apoiará os gerentes na realização de estimativas de custos de projetos de
desenvolvimento de software.
7.2 Descrição da ferramenta
A CostDDS consiste em uma ferramenta de software que armazena estimativas e dados dos
projetos anteriores para auxiliar os gerentes a realizarem estimativas de custos de projetos de
software.
A ferramenta implementa a técnica de “decomposição” para divisão do projeto
(trabalho). Uma vez dividido o projeto, a ferramenta permite a utilização de três técnicas de
estimativas distintas: 1) estimativa por modelos empíricos; 2) modelo de estimativa baseado
em analogias; 3) estimativas baseadas no julgamento por especialista(s).
7.3 Principais características
As principais características da ferramenta CostDDS são:
� Possibilita a decomposição do projeto;
� Permite armazenar dados de estimativas e dados de projetos anteriores concluídos;
� Possibilita a realização de estimativa de tamanho do produto de software por meio
da quantidade de pontos por função;
� Possibilita realizar estimativas por utilização do modelo COCOMO II;
� Permite realizar estimativas por analogia com projetos concluídos;
� Permite realizar estimativas por especialista(s);
� Possibilita a inclusão dos custos contábeis no montante da estimativa, inclusive a
inclusão dos custos derivados da prática de desenvolvimento distribuído.
7.4 Especificação funcional
Para (Pressman, 2006) existem três opções de estimativas válidas. A ferramenta CostDDS
implementa estas três opções, o que possibilita o gerente combinar os resultados destas
estimativas tornando-as mais precisas, consenso encontrado em (Pressman, 2006;
Sommerville, 2004; Pfleeger, 2004; Peters e Pedrycz, 2001). As opções são:
1- Decomposição – a ferramenta utiliza a divisão do projeto em funcionalidades e depois
as divide novamente em módulos, porém, não chegando ao nível de divisão por
71
atividades executadas para cada módulo. Devido a este nível de divisão do projeto, a
ferramenta implementa um nível intermediário entre as técnicas de decomposição por
problemas e decomposição por processos, conforme explicado no Capítulo 2;
2- Analogia – A ferramenta implementa a técnica de analogia quando projetos concluídos
são resgatados por meio de suas características, tamanhos ou classificações. Na técnica
de estimativa por analogia, a ferramenta permite a consulta de projetos anteriores por
meio de suas classificações ou mesmo por meio de seus atributos ligados ao modelo
COCOMO II (por exemplo, desenvolvimentos anteriores que apresentem a mesma ou
parecida classificação da característica de precedência do módulo diante a equipe
local, ou mesmo, que apresentem uma combinação de algumas características);
3- Empírica – A utilização de modelos empíricos é a terceira opção tratada na
ferramenta. O modelo “Early-Design” do modelo empírico COCOMO II é
implementado na ferramenta. Este modelo é composto por um conjunto de equações
empíricas combinadas com os diferentes pesos dos níveis das características
apresentadas no desenvolvimento. Como resultado obtém-se a estimativa de custo, de
esforço e de tempo de um projeto de desenvolvimento de produto de software.
A ferramenta implementa a métrica pontos-por-função (PF) como uma técnica para se
estimar o tamanho dos (módulos). Quando a opção empírica for executada e o tamanho do
trabalho for estimado utilizando a métrica de PF, deve-se transformar a quantidade de PF em
número de linhas de código-fonte para alimentar o modelo empírico.
Pelo fato da ferramenta auxiliar na realização de estimativas de custos em um
momento inicial do projeto, optou-se por implementar na ferramenta o modelo “Early-
design”, pois o modelo mais “enxuto”, o modelo de “Composição da aplicação”, realiza as
estimativas sem levar em consideração as características dos locais e do desenvolvimento. Já
o modelo “Post-architecture” do COCOMO II deve ser usado somente depois que a fase de
definição da arquitetura do sistema já esteja concluída.
Além destas opções, no momento da realização da estimativa, a ferramenta leva em
consideração os custos contábeis tanto dos locais envolvidos como os custos peculiares
apresentados por projetos desenvolvidos de forma distribuída.
72
7.5 Desenvolvimento da ferramenta
A ferramenta CostDDS foi desenvolvida utilizando a tecnologia J2SE. A abordagem
orientada a objetos foi escolhida, pois facilita os futuros processos de manutenção e evolução
do sistema e, principalmente, pelo fato de que o ambiente DiSEN foi construído utilizando
abordagem de programação orientada a objetos. Para Fowler (2005), outros fatores também
são importantes na orientação a objetos, tais como: a reutilização de códigos-fonte,
mecanismos de herança, polimorfismo e encapsulamento.
A linguagem de programação Java foi utilizada para o desenvolvimento e a
representação dos dados foi baseada na UML (Unified Modeling Language), pois esta
modelagem aborda os principais conceitos de orientação a objetos.
O desenvolvimento seguiu o modelo de processo iterativo e incremental, o qual
permite refinar e melhorar pouco-a-pouco os detalhes e a qualidade do produto final
(Sommerville, 2004).
Para o desenvolvimento das interfaces da ferramenta, utilizou-se o Framework “FIB”
(Silva et al., 2008), o qual dá suporte ao desenvolvimento ágil de interfaces gráficas para o
usuário.
7.6 Apresentação da ferramenta
Para facilitar a compreensão da ferramenta e descrever melhor as relações existentes entre os
elementos estruturais e as suas interfaces, é apresentada, na Figura 7.1, a arquitetura da
CosDDS.
73
Figura 7.1 – Arquitetura da ferramenta CostDDS.
Na Figura 7.1, a arquitetura da ferramenta apresenta diferentes níveis de abstração.
Estes níveis estão divididos em camadas lógicas: Camada de aplicação, Camada de negócio e
Camada de infraestrutura. Esta divisão é necessária para facilitar o processo de evolução e
manutenção da ferramenta.
Na Camada de aplicação encontram-se as interfaces gráficas para interação com os
usuários, nas quais se podem citar, principalmente, a interface de estimativa por modelo,
interface de estimativa por analogia e interface de estimativa por especialista. Estas três
interfaces utilizam a interface de decomposição para realizar as estimativas. Por se tratar de
desenvolvimento distribuído, a ferramenta trabalha com módulos de desenvolvimento, o que
facilita a decomposição do software, e assim, com partes menores (decompostas), é possível
melhor dividir o trabalho entre as equipes como também melhor estimar o custo de cada uma
delas. Também, nesta camada, encontra-se a interface de inserção dos custos contábeis dos
diferentes locais.
Na Camada de negócio estão os principais objetos de negócio da ferramenta. Fazem
parte do núcleo desta camada: as equações e variáveis do modelo COCOMO II, os filtros
usados no resgate de projetos concluídos e as equações utilizadas no cálculo de pontos por
função.
74
A Camada de infraestrutura fornece serviço para a Camada de negócio, nela encontra-
se o serviço de persistência, local onde ficam armazenados os dados das estimativas e de
projetos concluídos.
Diagrama de pacotes
Na Fgura 7.2 é apresentado o diagrama de pacotes geral da ferramenta CostDDS.
Figura 7.2 – Diagrama geral de pacotes da ferramenta CostDDS.
Dentro do pacote de “aplicacao” do diagrama encontram-se dois pacotes:
� o pacote “gui.estimativa” engloba as funcionalidades usadas para realizar as
estimativas. Neste pacote encontram-se as interfaces gráficas para realização das
estimativas utilizando o modelo COCOMO II, estimativas por meio de analogias e
estimativas por especialista(s);
75
� o pacote “gui.contabeis” engloba as funcionalidades de atualização dos dados
locais. Dentro deste pacote encontram-se interfaces gráficas que devem ser
atualizadas mensalmente.
O pacote de “negocios” engloba os objetos de negócio e é constituído por três pacotes:
� o pacote “componente-cocomo” é o pacote responsável por implementar as
equações e variáveis que fazem parte do modelo COCOMO II;
� o pacote “componete-pf” engloba as funcionalidade que permitem calcular a
quantidade de pontos por função de um determinado módulo, auxiliando na
estimativa de tamanho;
� o pacote “modelo” engloba as funcionalidades de filtros utilizados pelas
estimativas realizadas por analogia, também possui algumas classes que serão
persistidas no banco de dados.
O pacote “infraestrutura” dá o suporte para a persistência do modelo na camada de
negócio, nela também são encontrados outros pacotes (Schiavone, 2007).
� A ferramenta utiliza o pacote “disen-persistencia” para armazenar dados das
estimativas e dados dos projetos concluídos.
Casos de uso da ferramenta
O diagrama completo de casos de uso da ferramenta CostDDS é mostrado na Figura
7.3.
76
Figura 7.3 – Diagrama de casos de uso da ferramenta CostDDS.
As responsabilidades dos atores identificados na ferramenta foram baseadas na
definição de responsabilidades de (Enami, 2006).
• Gerente geral: este ator representa a pessoa responsável por cuidar da parte
contratual com os clientes, supervisiona os gerentes de projetos e precisa de
informações sobre contratos com os clientes e fornecedores. Informações são
necessárias sobre o andamento dos projetos da organização para fazer a seleção
dos projetos, avaliação e distribuição entre as unidades geograficamente
distribuídas. O gerente geral, também, define quais projetos devem ser priorizados,
cancelados ou suspensos dentro da organização.
• Gerentes de projetos: ator que representa as pessoas que necessitam de
informações para o planejamento e controle dos projetos sob sua responsabilidade.
O gerente de projetos, em cooperação com os gerentes locais, é o responsável por
realizar as estimativas de cada local e definir os custos globais de um determinado
projeto. Com as estimativas dos locais concluídas e com o auxilio do gerente geral,
o gerente de projetos define os locais (equipes) onde cada módulo do projeto será
desenvolvido.
77
• Gerente local: este ator representa as pessoas responsáveis por cuidar de sua
equipe (unidade distribuída) e que precisam de informações para gerenciar o RH e
os materiais disponíveis para a sua unidade. Esses gerentes determinam quais
recursos da sua unidade estão disponíveis para cada projeto, supervisionam os
projetos alocados em sua unidade, motivam sua equipe e atualizam os dados
mensais na ferramenta CostDDS.
Os casos de uso mostrado na Figura 7.3 são:
• Estimar projeto: este caso de uso permite estimar o custo de projetos de
desenvolvidos de forma distribuída;
• Definir locais de produção: este caso de uso permite o gerente definir os locais em
que o software será desenvolvido;
• Definir custos globais: neste caso de uso, os custos relativos ao projeto como um
todo, são definidos e computados;
• Estimar local: neste caso de uso, os custos de desenvolvimento relativos a um local
(equipe) são computados;
• Atualizar custos contábeis: este caso de uso permite o gerente local introduzir na
base de dados da ferramenta os dados contábeis da equipe e do local onde se
encontra. Com os dados contábeis atualizados mensalmente, é possível realizar
estimativas mais realistas dos projetos;
• Estimar por modelo: este caso de uso permite realizar estimativas dos módulos dos
projetos por utilização do modelo COCOMO;
• Estimar por analogia: este caso de uso permite uma análise de projetos
anteriormente concluídos para auxiliar a elaboração de estimativas de custos de
projetos a serem desenvolvidos;
• Estimar por especialista: este caso de uso permite o gerente armazenar os dados
sobre os especialistas responsáveis por auxiliar a realização das estimativas.
Os diagramas de atividades permitem facilitar o entendimento dos projetos de
software. Neste trabalho foram discutidos alguns casos de uso por meio de diagramas de
atividades, de modo a explicar o funcionamento da ferramenta CostDDS.
Caso de uso “Estimar projeto”
Na Figura 7.4, o diagrama de atividades do caso de uso “Estimar projeto” é
apresentado para facilitar o entendimento sobre o funcionamento da ferramenta CostDDS.
78
Figura 7.4 – Diagrama de atividades “Estimar projeto” da ferramenta CostDDS.
Primeiramente, já com o escopo do projeto definido, o gerente, responsável por
realizar a estimativa do projeto, definirá as funcionalidades que este deverá apresentar. Esta
79
divisão do projeto, em funcionalidades, faz parte da primeira etapa de decomposição do
projeto e está representada pela atividade “Definir funcionalidades”.
Na atividade “Modularizar projeto”, o gerente conclui o processo de decomposição,
onde as funcionalidades anteriormente definidas são divididas em módulos.
Os módulos são selecionados na atividade “Selecionar módulo”. Estes módulos são
classificados na atividade “Definir classificação”, esta classificação é definida de acordo com
as características de implementação apresentadas pelo módulo.
Em seguida, a linguagem de programação utilizada no desenvolvimento é selecionada
na atividade “Definir linguagem”. A seleção da linguagem interfere nos cálculos da
quantidade de pontos por função estimada para o módulo. A técnica Backfiring fornece a
relação entre a quantidade de linhas de código-fonte por pontos por função para cada
linguagem.
O tamanho de cada módulo pode ser calculado pelo gerente de duas formas distintas:
1) estima-se o tamanho do módulo a ser desenvolvido utilizando a técnica de contagem de
número de linhas de código-fonte, representado na atividade “Estimar tamanho módulo por
SLOC”; 2) estima-se o tamanho do módulo a ser desenvolvido por meio da contagem de
pontos por função, representado na atividade “Estimar tamanho módulo por PF”.
Os possíveis locais de desenvolvimento são escolhidos em “Escolher local para
estimativa”. A escolha de um local faz com que a estimativa se refira a uma determinada
equipe e os dados sobre ela.
Uma vez definido o local da estimativa, o gerente pode optar entre utilizar as técnicas:
de estimativa por analogia; a técnica de estimativa por modelo, ou; uma combinação delas,
ou; simplesmente com base em sua experiência e domínio no assunto estima o projeto a ser
desenvolvido.
Se o gerente optar por utilizar a técnica de estimativa por analogia, dados de módulos
de projetos anteriormente concluídos são resgatados, representado na atividade “Estimar
módulo por analogia”. Esses dados são relacionados com as características do módulo a ser
desenvolvido e irão auxiliar a estimativa de custo.
Caso o gerente optar por utilizar a técnica de estimativa por modelo, representado na
atividade “Estimar módulo por modelo”, equações matemáticas são utilizadas para auxiliar a
estimativa do projeto a ser desenvolvido.
Ou ainda, a ferramenta permite o gerente estimar o projeto com base em um ou mais
especialistas, representado na atividade “Estimar módulo por especialista”.
80
Os custos contábeis do local escolhido podem ser importados de um software contábil
do local, entretanto, este processo de importação está sendo abordado como um trabalho
futuro e está representado na atividade “Importar dados contábeis”. Neste momento, na
ferramenta CostDDS, os custos são incluídos no sistema pelo gerente local, representado pelo
caso de uso “Atualizar custos contábeis” (Figura 7.3). Os custos do local estimado são
computados e relacionados com o módulo a ser desenvolvido na atividade “Quantificar custos
do local escolhido”. Como resultado desta combinação, obtém-se uma estimativa aproximada
dos possíveis custos para o desenvolvimento.
Neste ponto, o gerente pode retornar para a atividade “Escolher local para estimativa”
onde um outro local é selecionado para estimar o módulo em questão. Também, neste ponto, é
possível retornar para atividade “Selecionar módulo”, onde dará início a uma estimativa de
outro módulo selecionado.
Após o gerente ter estimado todos os módulos do projeto nos locais escolhidos para as
estimativas. O gerente define os locais de produção de cada módulo em “Escolher locais de
produção”. Lembrando que, as estimativas para estes locais já foram realizadas.
Após o gerente selecionar as estimativas dos locais estimados, os custos do projeto em
geral são computados em “Definir custos globais”. Esses custos são relativos aos prováveis
custos que o projeto como um todo apresentará no decorrer de seu desenvolvimento,
conforme exemplificado no Capítulo 5.
Dependendo da seleção de diferentes locais, o projeto pode apresentar alguns custos
globais diferentes do já estimado, por este motivo o fluxo das atividades é retornável e
direcionado novamente para a atividade “Escolher locais de produção”.
Uma vez definido os locais de produção com suas devidas estimativas, juntamente
com os custos globais do projeto, são computadas as estimativas para o projeto como um
todo. Desta forma, o gerente obtém uma estimativa aproximada do total do projeto a ser
desenvolvido.
Para realizar uma estimativa de um determinado local (representado com o caso de uso
“Estimar Local” na Figura 7.3) pode-se utilizar as seguintes técnicas de estimativa (casos de
uso da Figura 7.3): “Estimar por analogia”, “Estimar por modelo” e “Estimar por
especialista”. Pelo fato destes casos de usos serem de grande importância neste trabalho,
resolveu-se detalhá-los para uma melhor compreensão de seus funcionamentos.
81
Caso de uso “Estimar por analogia”
Na Figura 7.5 é apresentado o diagrama de atividades do caso de uso “Estimar por
analogia”.
Figura 7.5 – Diagrama de atividades do caso de uso “Estimar por analogia” da ferramenta CostDDS.
82
Quando uma estimativa for realizada utilizando a técnica de estimativa por analogia, a
ferramenta resgata os módulos que já foram desenvolvidos no local (equipe) onde a estimativa
se refere. A atividade “Buscar módulos com a mesma classificação” leva em consideração as
características do módulo, ou seja, utiliza filtros de busca para os módulos que apresentem
determinadas classificações ou uma combinação de variáveis (características).
Com os módulos já resgatados, os tamanhos dos módulos são analisados na atividade
“Analisar tamanho dos módulos buscados”.
O tempo decorrido para o desenvolvimento destes módulos é computado na atividade
“Analisar tempo dos módulos buscados”.
A produtividade de desenvolvimento dos módulos buscados é calculada na atividade
“Analisar produtividade dos módulos buscados”.
É realizado um cálculo de média das variáveis de tamanho, tempo e produtividade dos
módulos buscados (módulos já desenvolvidos) com a finalidade de se obter um valor
normalizado. Caso o gerente optar, é possível visualizar uma lista contendo o conjunto dos
módulos buscados com seus respectivos valores de tamanho, tempo e produtividade. Caso o
módulo buscado já tenha sido estimado anteriormente utilizando o modelo COCOMO, as
variáveis utilizadas nas equações também podem ser consultadas.
O tamanho do módulo a ser desenvolvido é computado com a atividade “Analisar o
tamanho do módulo a ser desenvolvido”.
Por meio de análise de dados anteriores, a ferramenta estima a produtividade da equipe
diante do módulo a ser desenvolvido por meio da atividade “Estimar produtividade local
selecionado”.
Com os dados dos módulos anteriormente desenvolvidos, a ferramenta realiza um
cálculo de proporções diante do tamanho e produtividade dos módulos anteriormente
buscados. Diante dos dados do módulo a ser desenvolvido, a ferramenta sugere valores para a
estimativa de produtividade, esforço, tempo e custo para o desenvolvimento de determinado
módulo. As estimativas de esforço e tempo são representadas pelas atividades “Estimar
esforço” e “Estimar tempo” respectivamente.
83
Caso de uso “Estimar por modelo”
Na Figura 7.6 é apresentado o diagrama de sequência do caso de uso “Estimar por
modelo”.
Figura 7.6 – Diagrama de atividades “Estimar por modelo” da ferramenta CostDDS.
Caso o gerente optar em realizar estimativas do módulo utilizando a técnica de
estimativa por modelo, é preciso estimar o tamanho do módulo (a ser desenvolvido) em
número de linhas de código-fonte (SLOC), representado na atividade “Estimar tamanho em
SLOC”. Caso o tamanho do módulo já tenha sido estimado em quantidade de pontos por
função, deve-se transformá-los em SLOC com a atividade “Transformar PF em SLOC”, para
introduzir o tamanho do módulo nas equações do modelo COCOMO.
O cálculo do expoente da equação do modelo é a primeiro passo para realizar as
estimativas. Este expoente é constituído da contabilização de cinco variáveis correspondentes
que representam características tanto da equipe como do módulo a ser desenvolvido,
84
conforme explicado no Capítulo 4. O cálculo é realizado com a atividade “Calcular fatores de
escala”.
A ferramenta utiliza o modelo Early-design do modelo COCOMO. Desta forma, a
atividade “Calcular multiplicadores de esforço” é constituída do cálculo de sete
direcionadores de custos. Os direcionadores de custos representam as economias e
deseconomias do desenvolvimento. Antes de realizar a estimativa por modelo, os sete
direcionadores de custos e, também, as cinco variáveis do fator de escala precisam ser
ajustados pelo gerente. Este ajuste irá refletir as características do produto, dos computadores
utilizados, do pessoal (equipe local) e do projeto, conforme explicado no Capítulo 4.
Com as variáveis ajustadas ao local, é possível utilizar equações do modelo COCOMO
para calcular a estimativa de esforço exigido para o desenvolvimento, representado pela
atividade “Estimar esforço”.
O tempo de desenvolvimento é calculado com a atividade “Estimar tempo”. O tempo é
determinado por utilização de equações matemáticas do modelo, estas possuem algumas
variáveis (também ajustáveis pelo gerente), onde o resultado dessas equações é influenciado,
principalmente, pela quantidade de esforço exigido.
Com o cálculo do tempo de desenvolvimento de determinada equipe sobre
determinado módulo, é possível contabilizar os custos locais (da equipe) e estimar
aproximadamente o custo para o desenvolvimento deste módulo.
85
As interfaces gráficas da ferramenta CostDDS
A interface gráfica principal da ferramenta é mostrada na Figura 7.7.
Figura 7.7 – Interface principal da ferramenta CostDDS.
Com a interface principal, o gerente tem acesso às principais funcionalidades e dados
armazenados pela ferramenta.
A seguir é dada uma breve descrição sobre as principais funcionalidades encontradas
nos menus da interface principal da CostDDS:
� “Arquivo”: possibilita o fechamento da ferramenta e possibilitará a importação de
dados contábeis;
� “Cadastro”: possibilita o cadastro de locais (equipes), projetos, módulos,
funcionalidades, classificações, tipo de custos locais, tipos de custos globais,
gerentes e linguagens de programação;
� “Custos”: possibilita a atualização dos custos mensais locais;
� “Projetos”: possibilita realizar estimativas de módulo e projetos;
86
� “Consultas”: possibilita a visualização de dados de projetos anteriores, valores das
variáveis COCOMO, custos locais e variáveis do Backfiring;
� “Ajuda”: possibilita a visualização de dados sobre a ferramenta e endereços para
encontrar material de apoio e endereços eletrônicos caso haja a necessidade de
contatos.
Entre as principais funcionalidades que a ferramenta implementa, com base no grau de
importância para o funcionamento do sistema como um todo, foi escolhido explicar algumas
interfaces gráficas e seu funcionamento. A interface gráfica “Estimativa Módulo” (Figura 7.8)
foi dividida pelos locais numerados para facilitar sua explicação.
87
Figura 7.8 – Interface gráfica “Estimativa Módulo”.
88
Quando o processo de decomposição do projeto e o cadastro de suas funcionalidades
já estiverem concluídos, o gerente precisa dividir estas funcionalidades em módulos. A
divisão do desenvolvimento em módulos acontece para melhor atender às necessidades do
desenvolvimento distribuído.
Um módulo pode conter parte de uma funcionalidade do projeto (casos nos quais a
funcionalidade é muito grande ou complexa para atribuí-la a somente uma equipe), pode
conter uma funcionalidade ou mais de uma funcionalidade (caso onde as funcionalidades são
pequenas ou simples).
Para realizar as estimativas do módulo em questão, o gerente utilizará a interface
“Estimativa Módulo” (Figura 7.8). Os locais sinalizados e numerados são:
1. O gerente seleciona os dados referentes ao módulo que se está realizando a
estimativa. Esses dados incluem o nome do projeto, a funcionalidade, o nome
do módulo, a classificação do módulo e a linguagem de programação que
deverá ser utilizada para o desenvolvimento;
2. Uma vez identificado, o gerente estima um tamanho para o módulo em
número de linhas de código-fonte. Para isso, ele pode utilizar técnica de
análise de pontos por função, as interfaces utilizadas para calcular a
quantidade de pontos por função encontram-se detalhadas no Anexo B;
3. No campo “Local”, o gerente escolhe o local no qual a estimativa do módulo
está se referindo;
4. Neste momento, o gerente pode optar em realizar estimativa por meio da
utilização do modelo empírico COCOMO (interfaces gráficas detalhadas no
Anexo B);
5. Neste campo “Estimativa por Analogia” é mostrado o resultado das
estimativas que o sistema realizou automaticamente com o uso de analogias
das características dos projetos concluídos para o local referido. Ao apertar o
botão “Consultar Módulos por Analogia” o sistema abre uma outra janela
onde contém os dados dos módulos utilizados para a realização da estimativa
em questão, nesta janela o gerente tem a possibilidade de filtrar outras
características dos projetos anteriores para melhor análise dos dados, melhor
explicado no Anexo B.
Ambas as estimativas por modelo COCOMO II e por Analogia levam em
consideração os custos do local referido. Os cálculos de custos são rateados por meio do
89
número de horas trabalhadas com base na quantidade total dos custos contábeis do local e
quantidade total de horas trabalhadas por mês.
6. Em “Estimativa Final” o gerente define os dados da estimativa realizada, estes
serão cadastrados e ficarão disponíveis para futuras comparações e análises.
Neste espaço numerado encontram-se três botões: 1) “Cadastrar Especialista”
utilizado para o cadastro de um ou mais especialistas consultados para
realização da estimativa; 2) “Observações sobre a estimativa” com o seu
acionamento abre-se uma nova janela para registrar observações sobre a
estimativa em questão; 3) “Concluir estimativa módulo” este botão conclui a
realização da estimativa para determinado módulo para determinado local.
Para cada local (equipe) (selecionado), o gerente realiza uma estimativa para cada
módulo (selecionado) a ser estimado. Neste caso, o gerente é quem decide onde (local) em
que cada módulo será estimado.
Após a realização destas estimativas, a interface gráfica “Estimativa Local”, Figura
7.9, é utilizada para atribuição de cada módulo para as equipes.
90
Figura 7.9 – Interface gráfica “Estimativa Local”.
Os locais sinalizados por retângulos numerados na Figura 7.9 são:
1. Este local sinalizado possibilita a visualização das estimativas realizadas nos
diferentes lugares. Esta lista pode ser ordenada segundo as estimativas de
custos, esforço, tempo ou produtividade, para facilitar ao gerente a tomada de
decisão do local (equipe) que será encarregado do desenvolvimento do módulo
tratado.
2. Uma vez decidido, o gerente efetiva a atribuição da estimativa do módulo para
o local (equipe) desejado.
Quando a atribuição de todas as estimativas dos módulos para os locais escolhidos e o
cadastro dos custos globais do projeto já estiverem concluídos, o gerente irá estimar o custo
do projeto como um todo, para isso, ele utiliza a interface “Estimativa Projeto” Figura 7.10.
1
2
91
Figura 7.10 – Interface gráfica “Estimativa Projeto”.
Os locais sinalizados por retângulos numerados da Figura 7.10 são:
1. Nesta região, o gerente pode visualizar um resumo das atribuições dos módulos
às equipes. Caso resolver mudar alguma estimativa de local, o botão “<--Voltar
para estimativa local” deve ser utilizado;
2. Nesta região, o gerente visualiza os custos globais do projeto. Vale ressaltar
que os custos globais dependem, também, dos locais selecionados, pois,
dependendo dos locais selecionados para o desenvolvimento, o projeto
apresenta diferenças nos custos globais. O botão “<--Voltar para custos
globais” retorna para a estimativa dos custos globais referentes ao projeto em
questão.
1
2
3
92
3. O somatório dos custos locais, globais e o total do projeto é mostrado na
interface e o processo de conclusão da estimativa de um projeto é concluída
com o botão “Concluir estimativa projeto”.
Ao terminar o desenvolvimento dos módulos estimados, o gerente irá cadastrar os
dados reais ocorridos durante o desenvolvimento (Anexo B, Figura B.12). Com este feedback,
é possível consultar e comparar os valores estimados com os valores reais e, com isso,
melhorar as estimativas com os ajustes necessários.
7.7 Considerações finais
Neste Capítulo foi apresentada a ferramenta CostDDS com suas principais características e
especificação funcional. Foi explicado sua arquitetura e diagrama de pacotes que a compõem.
Já o funcionamento da ferramenta foi esclarecido por meio da apresentação dos diagramas de
casos de uso inter-relacionados com diagramas de atividades e por fim algumas interfaces,
consideradas principais, foram apresentadas.
93
Avaliação da ferramenta CostDDS
Neste Capítulo, é apresentado a metodologia utilizada para a avaliação da ferramenta de
estimativa de custo CostDDS, realizada com gerentes de projetos de software e integrantes do
grupo de estudos DiSEN.
8.1 Considerações iniciais
A avaliação da CostDDS foi realizada em duas etapas: 1) com membros integrantes ao grupo
GESSD (Grupo de Engenharia de Software para Sistemas Distribuídos); 2) com gestores da
área de TI com mais de 10 anos de experiência.
Durante a fase de projeto da ferramenta, foi fundamental o auxílio dos membros do
grupo de estudos sobre o ambiente de desenvolvimento distribuído de software DiSEN. Os
resultados dessa interação possibilitaram a incorporação de idéias que melhoraram as
funcionalidades e a qualidade da ferramenta.
Uma metodologia foi estabelecida para realizar a avaliação da CostDDS. Esta
metodologia está dividida em cinco etapas: 1) Desenvolvimento e avaliação do questionário;
2) Escolha das empresas para aplicar o questionário; 3) Apresentação da ferramenta; 4)
Aplicação do questionário; 5) Análise dos dados colhidos na aplicação do questionário.
Nas próximas seções estão descritas as cinco etapas pertencentes à metodologia
utilizada para avaliação da ferramenta.
8
Capítulo
94
8.2 Desenvolvimento e avaliação do questionário
O questionário foi desenvolvido com questões divididas em cinco partes:
1) Sobre o respondente – questões de identificação do grau de escolaridade do
respondente e informações sobre a atuação profissional;
2) Sobre a empresa – questões que permitiram a identificação e extração de dados
importantes sobre a empresa estudada;
3) Sobre a contabilidade – questões especulativas referentes a parte contábil da
empresa;
4) Sobre as estimativas de custos – questões que envolvem informações sobre a
forma com que a empresa realiza as estimativas de custos dos produtos a serem
desenvolvidos;
5) Sobre a ferramenta CostDDS – estas questões foram desenvolvidas para obtenção
de um feedback da ferramenta, por parte dos respondentes. Estas questões buscam
extrair o grau de satisfação diante das características apresentadas pela ferramenta,
e, principalmente, sua utilidade como ferramenta de auxílio.
Versões do questionário (Apêndice A) foram desenvolvidas, a escolha e definição das
questões foram realizadas com o auxílio de integrantes do grupo de pesquisa, os quais
forneceram um feedback quanto algumas características, tais como: clareza e objetividade das
questões do questionário.
8.3 Escolha das empresas para aplicar o questionári o
Nesta etapa foram definidas as empresas para aplicação do questionário. Estas empresas estão
localizadas no município de Maringá-PR. As três empresas envolvidas atuam nos seguintes
segmentos: 1) uma instituição de ensino superior pública; 2) uma instituição de saúde; 3) uma
instituição de desenvolvimento de produtos de software.
8.4 Apresentação da ferramenta
A ferramenta foi apresentada aos gerentes de projetos de software, os quais se encontram no
nível estratégico na hierarquia das empresas em que atuam.
Para a introdução sobre o assunto, foi exposto o tema (estimativas) e realizada uma
breve caracterização sobre ambientes de desenvolvimento distribuído de software com suas
95
principais características. A apresentação da ferramenta foi realizada diante da ilustração do
funcionamento de suas principais funcionalidades e explicações sobre o funcionamento de sua
arquitetura.
8.5 Aplicação do questionário
Nesta etapa, após a apresentação da ferramenta, foram informados aos participantes alguns
aspectos importantes sobre a forma de preenchimento das questões e esclarecida a questão do
anonimato, onde suas informações e respostas colhidas permaneceriam em sigilo e os dados
publicados seriam divulgados em conjunto.
8.6 Análise dos dados colhidos na aplicação do
questionário
Participaram da avaliação cinco alunos do mestrado em Ciência da Computação e três
gerentes de projetos de desenvolvimento de software.
Sobre os participantes
Em média, os alunos do mestrado apresentaram uma média de seis anos de experiência
no desenvolvimento de produtos de software. Já os gerentes de projetos apresentaram uma
média superior a dez anos de experiência no gerenciamento de projetos de software. Com uma
média inferior, os gerentes de projetos apresentaram seis anos de experiência no
desenvolvimento distribuído de software.
Sobre as empresas
As empresas possuem entre vinte e cinco a oitocentos funcionários, dentre estes
apresentaram uma média 16 funcionários trabalhando no desenvolvimento de software. Estas
empresas já realizaram ou realizam a prática do DDS.
Sobre a contabilidade
Quanto à parte contábil, as empresas apresentaram produção por ordem ou por
encomenda e todas possuem software contábil para realizar a contabilidade de custos. A
forma de rateio das aquisições de novos produtos se dá por tempo de utilização ou não
realizam o rateio, onde os custos seriam atribuídos a determinados projetos.
96
Sobre as estimativas de custos e gerenciamento de projetos
Sobre o gerenciamento dos projetos, os gerentes utilizam a técnica de análise de
pontos por função como medida do tamanho do software a ser desenvolvido, alguns já
utilizaram ou utilizam algumas variações para medir o tamanho, como uma composição entre
pontos por função, funcionalidades e atividades.
A medida utilizada para estimar a quantidade de mão-de-obra necessária para um
projeto foi a quantidade de horas e dias.
Para a realização da decomposição do projeto prevaleceu a técnica de “Divisão por
atividade” no nível de gerenciamento interno e utilizada a técnica “Divisão por módulos ou
funcionalidades” já no nível de contrato com os clientes.
Sobre as estimativas de custos, as empresas, em sua maioria, utilizam a técnica de
“Estimativa por analogia” combinada com a técnica “Julgamento por especialista” para
realizar as estimativas dos projetos de software.
As empresas não utilizam ferramentas específicas para realizar as estimativas dos
projetos, sendo que duas delas utilizam planilhas eletrônicas para controlar e estimar projetos
de software.
Sobre a ferramenta CostDDS
Os participantes tiveram respostas unânimes afirmativas nas questões em que: a
apresentação da ferramenta permitiu a visualização de sua utilidade; acreditam que a
ferramenta auxiliará nas estimativas de custos de projetos de software; crêem que a técnica de
decomposição em “módulos” utilizada na ferramenta atende às necessidades de divisão do
projeto no DDS; o armazenamento dos custos locais auxiliará na tomada de decisão quanto a
distribuição de trabalhos entre as equipes.
A questão da utilização da métrica de pontos por função é prática, no entanto, um
gerente de projeto alertou sobre a complexidade deste tipo de quantificação.
Quanto à interface gráfica, a forma de consulta por filtragem dos dados armazenados
pela ferramenta foi considerada, pelos participantes, de fácil visualização.
Entre as três opções de técnicas que a ferramenta oferece para realizar as estimativas,
na visão de dois dos gerentes de projetos duas técnicas foram consideradas de maior
importância, a técnica de “Estimativa por analogia” combinada com a técnica de “Julgamento
por especialista”, e, somente um gerente de projeto considera interessante a combinação da
técnica de “Estimativa por analogia” com a técnica de “Estimativa por modelos empíricos”. Já
na visão dos demais participantes, o interesse prevaleceu sobre a técnica de “Estimativa por
97
analogia” combinada com o uso da técnica “Estimativa por modelos empíricos” bem
ajustados para cada local diante de cada classificação do módulo.
Também, de uma forma unânime, obteve-se respostas afirmativas diante das questões
sobre o atendimento das necessidades de estimativas de custos por meio da utilização das três
técnicas incorporadas na ferramenta.
Já na questão em que o foco é sobre a facilitação da realização da estimativa de custo
pelo uso da ferramenta, um gerente de projeto não soube responder se a ferramenta
“facilitaria” o processo de estimativa do custo final do produto, alegando que existem muitos
outros fatores que dificultam a estimativa de um preço exato. No entanto, concordou que a
ferramenta, neste caso auxiliaria sim na tomada de decisão diante da distribuição dos
trabalhos entre as equipes, uma vez que esta incorpora os dados de todos os locais envolvidos.
8.7 Considerações sobre a avaliação da CostDDS
O resultado da aplicação do questionário de avaliação da ferramenta CostDDS foi satisfatório,
uma vez que foram obtidas respostas afirmativas quanto ao potencial de auxílio na sua
utilização para realizar estimativas de custos de produtos de software desenvolvidos em um
ambiente de desenvolvimento distribuído, bem como auxiliar nas estimativas de custos em
ambientes de desenvolvimento local de software.
Algumas sugestões foram feitas por alguns participantes e podem contribuir para o
aperfeiçoamento e direcionar a evolução da ferramenta. As sugestões são:
� utilizar a técnica de decomposição por atividades;
� oferecer mais opções de variáveis para se estimar a quantidade de trabalho
necessária para o desenvolvimento;
� desenvolver interfaces gráficas contendo gráficos comparativos. Esses gráficos
podem representar, por exemplo: histórico dos custos de cada local, comparativos
de relação preço das horas trabalhadas com custo local; a quantidade de erros
cometidos nas estimativas entre determinadas datas;
� integrar na ferramenta os processos de desenvolvimento em que cada local pratica;
98
99
Conclusões
9.1 Considerações finais
Os avanços tecnológicos possibilitaram um aumento na disseminação da informação e maior
complexidade no desenvolvimento de software. A estimativa de custos tornou-se uma
atividade preponderante no gerenciamento de projetos, contribuindo inclusive para o sucesso
ou fracasso dos projetos (Huzita e Tait, 2006).
O setor de software possui características próprias ao seu processo produtivo. Algumas
de suas características, como a dificuldade em mensurar o esforço de produção,
intangibilidade do produto e a alta qualidade em atividades indiretas, exigem uma gestão de
custos muito complexa.
Pode-se considerar, a partir dos trabalhos analisados, que existem dois grandes grupos
ao tratar de estimativas de custos: 1) foco nas organizações de desenvolvimento de software, a
exemplo de Gomes (2004); 2) foco no produto de software, o que remete aos elementos
considerados por Boehm (1981) apud Cocomo (2000): atributos do produto, do hardware, do
pessoal e do projeto.
Entretanto, ao inserir a abordagem dos custos da área contábil, este trabalho uniu os
dois grupos, pois, além dos custos de software, acrescenta os custos gerais tratados na
organização, como os custos diretos e indiretos.
Assim, a incorporação dos elementos da contabilidade de custos para estimar custos
em projetos de software permite aos gerentes de projetos, responsáveis pelos custos, terem
9
Capítulo
100
uma visão mais detalhada e realista dos custos em questão. Com isso, propiciar a integração
da área de contabilidade com a área de informática.
Especificamente no DDS, foram levantadas as características particulares desse tipo de
desenvolvimento, as quais geram custos adicionais em termos de infraestrutura de
comunicação, padronização, entre outros vinculados à dispersão geográfica.
Vale salientar a necessidade de uma ferramenta de estimativa de custo para o DDS,
com a incorporação dos tipos de custos da área contábil, que possa auxiliar os gerentes de
projetos nesse sentido. Neste contexto, este trabalho dedicou-se ao desenvolvimento de uma
ferramenta de estimativa de custo vinculada a um ADDS (Huzita et al., 2007).
A avaliação da ferramenta desenvolvida obteve uma boa aceitação por parte dos
participantes e a aplicação dos questionários permitiu uma avaliação qualitativa da ferramenta
proposta. Concluindo-se que a ferramenta tem potencial para auxiliar as estimativas de custo
de projetos de software desenvolvidos de forma distribuída.
Ao tratar de DDS, tem-se como concreto a integração de várias áreas de conhecimento
e, no caso específico de estimativa de custos, a área contábil. No entanto, por se tratar de uma
abordagem recente, torna-se conveniente ressaltar as dificuldades em realizar estimativas de
custos no DDS, bem como, a dificuldade em restringir os tipos de custos inerentes ao
processo de desenvolvimento.
9.2 Diferencial da ferramenta CostDDS
Diante da falta de apoio ao desenvolvimento distribuído de software, bem como a não
contabilização dos custos totais de uma determinada organização, vislumbrou-se a
possibilidade de explorar estas lacunas com o desenvolvimento e apresentação da ferramenta
de estimativa de custo CostDDS.
As principais características que diferenciam a ferramenta CostDDS das demais são:
1. o apoio à realização de estimativas de custos no desenvolvimento distribuído
de software, de forma a auxiliar os gerentes a tomar decisões sobre o impacto
da distribuição dos trabalhos, entre as equipes, no custo final do projeto;
2. a vinculação dos custos contábeis dos diferentes locais envolvidos no
desenvolvimento, o que possibilita obter melhor conhecimento sobre os custos
e com isso melhorar o gerenciamento dos projetos;
3. a atualização mensal dos custos dos diferentes locais, proporciona a realização
de estimativas com valores atualizados;
101
4. a inclusão de um repositório onde são armazenados dados de projetos
anteriores. A ferramenta resgata de seu repositório os dados dos projetos
concluídos para realizar estimativas de um projeto. Estes dados são resgatados
segundo a presença de algumas características (selecionadas pelo gerente) em
comum. Esta funcionalidade permite que a ferramenta realize estimativas por
analogias;
5. o resultado, automatizado, da estimativa diante do tamanho e classificação do
módulo, possibilita que uma pessoa, sem experiência na área, realize uma
estimativa por meio da analogia implementada na ferramenta;
6. a classificação dos módulos do projeto, permitem uma melhor taxionomia
destes, facilitando o processo de analogias entre os projetos;
7. as filtragens implementadas na ferramenta permitem ao gerente combinar mais
de uma característica para o resgate de dados de projetos concluídos. Com isso,
analisar os dados dos projetos sobre diferentes aspectos;
8. as consultas implementadas na ferramenta possibilitam ao gerente visualizar
diferentes margens de erros cometidos nas estimativas de projetos anteriores,
diante da seleção das características do módulo;
9. a ferramenta apresenta uma arquitetura flexível, na qual podem ser incluídas
outras métricas para o cálculo do tamanho do produto de software.
9.3 Trabalhos futuros
Nesta seção, são apresentadas algumas considerações sobre trabalhos futuros que poderão ser
desenvolvidos, a fim de aprimorar a ferramenta apresentada. Estes trabalhos foram
identificados a partir das ferramentas estudadas, das sugestões do grupo de estudos e das
sugestões fornecidas pelos participantes da avaliação da ferramenta. Dentre os trabalhos
futuros destacam-se:
� Análise dos riscos – relacionar a ferramenta CostDDS com os riscos ocorridos.
Algumas estimativas podem apresentar uma margem de erro muito grande
devido a alguns acontecimentos (riscos), o que justificaria esta porcentagem de
erro apresentada na estimativa;
� Importação dos custos contábeis – uma vez desenvolvida uma ferramenta que
implemente um sistema de custeio contábil nos diferentes locais, um
mecanismo de importação de dados poderia ser adicionado à CostDDS, de
102
forma a não precisar atualizar manualmente a base de dados contábeis da
ferramenta;
� Novas métricas – incluir na ferramenta CostDDS, novas métricas de tamanho
dos módulos, tais como: Internet Points, Use-Case Points, entre outras. Uma
vez que a arquitetura da ferramenta permite a inclusão destas;
� Uso de gráficos nas consultas. Desta forma, facilitar a visualização dos dados
por parte dos gerentes.
103
Referências Bibliográficas
ABNT. Associação Brasileira de Normas Técnicas NBR ISO/IEC 12207 - Tecnologia de Informação: processos de ciclo de vida de software, 1998.
ALENCAR, A. A.; SCHMITZ, E. A. Análise de risco em gerência de projetos, Rio de Janeiro: Brasport, 2005.
ANDRADE, E.; OLIVEIRA, K. Uso combinado de análise de pontos de função e casos de uso na gestão de estimativa de tamanho de projetos de software orientado a objetos. In: III Simpósio Brasileiro de Qualidade de Software. Brasília, 2004. Disponível em: http://www.lbd.dcc.ufmg.br/bdbcomp/servlet/Evento?id=95. Acesso em: 20/04/2008.
BFPUG. Brazilian Function Point Users Group. Backfiring: um atalho ou uma estrada que não leva a lugar algum? Disponível em: http://www.bfpug.com.br/Artigos/Backfiring_Marcio_Mauricio.htm. Acesso em: 30/09/2008.
BOEHM. B. Software Engineering Economics. Prentice Hall, Englewood Cliffs, N.J., 1981.
BRAGA, A. Análise de pontos de função. Rio de Janeiro: Infobook, 1996.
BRUNI, A. L.; FAMA, R. Gestão de custos e formação de preços: com aplicações na calculadora HP 12C e Excel. 3a Ed. São Paulo: Atlas, 2004.
BULKE, R; BERTÓ, D. J. Gestão de custos. São Paulo: Saraiva, 2006.
CALDIERA, G., et al. Definition and Experimental Evaluation of Function Points for Object-Oriented Systems. In: Proceedings of the 5th international Symposium on Software Metrics. METRICS. IEEE Computer Society. Washington,1998.
CALICO. Softstar Systems: SystemStar does Systems Engneering Estimation. Disponível em: http://www.softstarsystems.com. Acesso em: 10/04/2008.
CARMEL, E. Global software teams: collaborating across borders and time-zones. Washington: Prentice Hall, 1999.
104
CIBOTTO, R. A. G. Um Modelo de Planejamento Estratégico de Sistemas de Informação para Organizações que atuam em Desenvolvimento Distribuído de Software. Dissertação de Mestrado, PCC – Universidade Estadual de Maringá. Maringá, 2009.
CLEMMONS, R K. Project estimation with use case points, In: The Journal of Defense Software Engineering. Fevereiro, 2006.
COCOMO. COCOMO II: Model Definition Manual, v. 2.1, 1995-2000. Disponível em: http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html. Acesso em: 05/03/2009.
CORRÊA, R. C. Custos em empresas prestadoras de serviços de informática: aplicação do ABC. Dissertação de Mestrado, PPGEP - Universidade Federal de Santa Catarina. Florianópolis, 2002.
COST. Maratz Inc, Disponível em: http://www.costxpert.eu/en/home. Acesso em: 03/03/2008.
COSTAR. Softstar Systems: SystemStar does Systems Engneering Estimation. Disponível em: http://www.softstarsystems.com. Acesso em: 06/03/2008.
CREPALDI, S A. Curso Básico de Contabilidade de Custos. São Paulo: Atlas, 2004.
ENAMI, L. N. M. et al. A Project Management Model to a Distributed Software Engineering Environment. In: International Conference on Enterprise Information Systems. Portugal, 2006, p. 382-387.
ENAMI, L. N. M. Um Modelo de Gerenciamento de Projetos Para um Ambiente de Desenvolvimento Distribuído de Software. Dissertação de Mestrado, PCC – Universidade Estadual de Maringá. Maringá, 2006.
FAIRLEY, R.E. The Influence of COCOMO on Software Engineering Education and Training In Software Engineering Education and Training. April 2006 pp. 193-200 Disponível em: http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=1617347&isnumber=33901, Acesso em: 29/05/2008.
FAVELA, J.; PEÑA-MORA, F. An experience in collaborative software engineering education, IEEE Software, v. 18, n. 2. March/April, 2001, p. 47-53.
FOWLER, M. UML Essencial – Um breve guia para linguagem-padrão de modelagem de objetos. 3ª Ed. Porto Alegre: Bookman, 2005.
GOMES, S. Um sistema de contabilidade por atividades para gestão de empresa de serviços em desenvolvimento de software. Tese de Doutorado, PPGEP – Universidade Federal de Santa Catarina. Florianópolis, 2004.
GRAVENA, J. P. Aspectos Importantes de uma Metodologia para Desenvolvimento de Software com Objetos Distribuídos. Trabalho de Conclusão de Curso, DIN - Universidade Estadual de Maringá. Maringá, 2000.
105
HAYWOOD, M. Working in virtual teams: a tale of two projects and many cities, IT Professional. v. 2. n. 2. March/April, 2000, p. 58-60.
HERBSLEB, J. D.; MOITRA, D. Global software development. IEEE Software, v. 18, n. 2. March/April, 2001, p. 16-20.
HUMPHREY, W. S. A discipline for Software Engineering. Addison, Wesley, 1995.
HUZITA, E. H. M. et al. Um ambiente de desenvolvimento distribuído de software – DiSEN, In: I WDDS – I Workshop de Desenvolvimento Distribuído de Software. João Pessoa, 2007, p. 31-38.
HUZITA, E.H.M. et al. DIMANAGER: A Tool for Distributed Software Development Management. In: International Conference on Enterprise Information Systems, Portugal, 2004, p. 659-662.
IEEE. IEEE Standard Glossary of Software Engineering Terminology, 1993. Disponível em: http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.12-1990.pdf. Acesso em: 10/04/2008.
IFPUG. International Function Point User Group. Function Points Counting Practices Manual (version 4.3). Westerville Ohio, Disponível em: http://www.ifpug.org. Acesso em: 04/02/2009.
KOBITZSCH, W. et al. Outsourcing in India, IEEE Software, v. 18, n. 2. March/April, 2001, p. 78-86.
LEDERER, A. L.; PRASAD, J. Causes of inaccurate software development cost estimates, Journal of Systems and Software, v. 31 n. 2. November, 1995, p. 125-134.
LEE, A. et al. Software development cost estimation integrating neural network with cluster analysis, Jounal Information and Management. v. 34. n. 1, August, 1998, p. 1-9.
LEME, L. H. R. Uma estratégia para apoiar gerenciamento de risco em um ambiente distribuído de desenvolvimento de software. Dissertação de Mestrado, PCC - Universidade Estadual de Maringá, 2007.
LIMA, F. Mecanismo de Apoio ao Gerenciamento de RH no Contexto de um Ambiente Distribuído de Software. Dissertação de Mestrado, PCC - Universidade Estadual de Maringá. Maringá, 2004.
LONG. L. D. Fundamentals of Function Point Analysis. Blue Springs: Longstreet Consulting Inc, 2002.
MONTEIRO, T. C. Uma Extensão de Estimativas baseadas em UCP Atendendo às Necessidades do CMMISW Nível 2 e 3. Dissertação de Mestrado, IA - Universidade de Fortaleza. Fortaleza, 2004.
MOURA, L. M. V.; ROCHA, A. R. C. Ambientes de Desenvolvimento de Software. Publicações Técnicas COPPE -ES-271/92 – Universidade Estadual do Rio de Janeiro. Rio de Janeiro, 1992.
106
OLSON, J. S.; OLSON, G. M. Culture surprise in remote software development teams, Journal Queue. v. 1, n. 9. December, 2003, p. 52-59.
PASCUTTI, M.C.D. Uma Proposta de Arquitetura de um Ambiente de Desenvolvimento de Software Distribuído Baseado em Agentes. Dissertação de Mestrado, II - Universidade do Rio Grande do Sul. Porto Alegre, 2002.
PAULK, M.; C. et al. The Capability Maturity Model: Guidelines for Improving the Software Process, Addison-Wesley, 1995.
PEDRAS, M. E. V. Uma Ferramenta de Apoio ao Gerenciamento de Desenvolvimento de Software Distribuído. Dissertação de Mestrado, PCC – Universidade Estadual de Maringá/Universidade Federal do Paraná. Maringá, 2003.
PETERS, J. F.; PEDRYCZ, W. Engenharia de software. 3a Ed. Rio de Janeiro: Elsevier, 2001.
PILATTI, L.; AUDY J. L. N. Características do desenvolvimento global de software em ambientes offshore in sourcing: lições aprendidas de um estudo de caso. In II Workshop Um Olhar Sociotécnico sobre a Engenharia de Software –WOSES. Vila Velha, 2006, p. 85.
PILATTI, L. et al. Avaliando os impactos dos aspectos não-técnicos da engenharia de software em ambientes de desenvolvimento global de software: um caso prático, In III Workshop Um Olhar Sociotécnico sobre a Engenharia de Software-WOSES. Porto de Galinhas, 2007.
PLEEGER, S, L. Engenharia de software: teoria e prática. 2a Ed. São Paulo: Prentice Hall, 2004.
POZZA, R. Proposta de um modelo para cooperação baseado no gerenciamento de workspace no ambiente DiSEN. Dissertação de Mestrado, PCC – Universidade Estadual de Maringá. Maringá, 2006.
PRESSMAN, R. S. Engenharia de software, São Paulo: Pearson Eduacation do Brasil, 2006.
PRIKLADNICKI, R.; AUDY, J. L. N. MuNDDoS: um modelo de referência para desenvolvimento distribuído de software, In: XVIII SBES - Simpósio Brasileiro de Engenharia de Software. Brasília, 2004, p. 289-304.
PRIKLADNICKI, R.; et al. Requirements management in global software development: preliminary findings from a case study in a SW-CMM context, In: II International Workshop on Global Software Development at ICSE. Portland, 2003, p. 53-58.
PRIKLADNICKI, R; AUDY, J. L. N. Uma Análise Comparativa de Práticas de Desenvolvimento Distribuído de Software no Brasil e no exterior. In: XX Simpósio Brasileiro de Engenharia de Software- SBES. Florianópolis, 2006, p. 255-270.
SEI. Capability Maturity Model Integration (CMMISM). Version 1.1 - CMU/SEI-2002-TR-012. March, 2002. Disponível em: http://www.sei.cmu.edu/managing. Acesso em: 03/03/2008.
107
SILVA, C. A. et al. FIB: Um Framework de Apoio à Construção de Interface Visando Aumento de Produtividade no Desenvolvimento de Software. In: Simpósio Brasileiro de Engenharia de Software (SBES - Ferramentas). Campinas, 2008.
SIQUEIRA, F. L.; SILVA, P. S. M. As características do desenvolvimento distribuído de software, In: I Simpósio Brasileiro de Sistemas de Informação –SBSI. Porto Alegre, 2004, p. 171-178.
SOMMERVILLE, I. Engenharia de Software, São Paulo: Addison Wesley, 2004.
SOUZA, R. A gestão dos custos através do custeio baseado em atividade: um estudo de caso em pequena empresa de serviço de suporte em informática. Dissertação de Mestrado, PPGEP – Universidade Federal de Santa Catarina. Florianópolis, 2002.
TRAVASSOS, G. H. O Modelo de Integração de Ferramentas da Estação TABA. Tese de Doutorado, COPPE – Universidade Federal do Rio de Janeiro. Rio de Janeiro, 1994.
TRINDADE, D. F. G. Uma Ferramenta para Gerenciar a Comunicação em um Ambiente Distribuído de Desenvolvimento de Software. Dissertação de Mestrado, PCC – Universidade Estadual de Maringá. Maringá, 2009.
USC. Center for Systems and Software Engineering, Disponível em: http://sunset.usc.edu/csse/research/COCOMOII/cocomo_main.html. Acesso em: 04/03/2008.
VANDERBECK, E. J.; NAGY, C. F. Contabilidade de Custos, 11ª Ed., São Paulo: Pioneira Thomson Learning, 2001.
VIEIRA, E. L.; W., R. S. Improving the Use Case Points Method by Counting only Mandatory Steps. (Technical Report: LSC-UFSC.), 2005.
108
109
Anexo A
Questionário aplicado aos participantes para realização da avaliação da ferramenta CostDDS.
Avaliação da CostDDS
1ª PARTE : Sobre o respondente
Nome: ____________________________________________________________________ Telefone: _________________________________________ Escolaridade (informe somente o maior grau) ( ) 1º Grau ( ) 2º Grau ( ) Superior Incompleto ( ) Superior Completo Curso:______________________________________________________________________ Ano de Conclusão: _________ Pós-Graduação (Especialização, Mestrado, Doutorado e Pós-doutorado): ( ) Especialização ( ) Mestrado ( ) Doutorado ( ) Pós-Doutorado Curso:______________________________________________________________________ Ano de Conclusão: _________ Sobre a atuação profissional 1. Tempo de experiência em desenvolvimento de sistemas: ________________________
2. Tempo de experiência em gerenciamento de projetos: __________________________
3. Você já trabalhou com desenvolvimento distribuído de software (DDS) onde pessoas
fisicamente distribuídas colaboram no desenvolvimento de um software? ( ) Sim ( ) Não
4. Tempo de experiência em gerenciamento de projeto com desenvolvimento
distribuído: ______
110
5. Assinale a(s) função(ões) que exerce atualmente:
( ) Gerente geral da organização ( ) Gerente de uma unidade distribuída ( ) Gerente de projeto ( ) Gerente do setor de desenvolvimento de software ( ) Outro(s):________________________________________________
________________________________ ________________________________
6. Quando surge um determinado problema gerencial, como normalmente você o
resolve?
( ) Busca orientação dos gerentes mais experientes ( ) Consulta histórico de projetos passados ( ) Pesquisa em acervo bibliográfico ( ) Busca orientação de especialistas ( ) Sua experiência ( ) Outro(s): _______________________________________ ________________________________ ________________________________
2ª PARTE : Sobre a empresa 7. Nome da empresa:______________________________________________________
8. Quantidade de funcionários da organização: ___________
9. Quantidade de funcionários no desenvolvimento de software: ___________
10. Tempo na Organização: _____________ anos.
11. Assinale as funções existentes na sua organização para executar o gerenciamento do
projeto?
( ) Gerente geral da organização ( ) Gerente de uma unidade distribuída ( ) Gerente do setor de desenvolvimento de software ( ) Gerente de projeto ( ) Outro(s): __________________________________________ ________________________________ ________________________________
12. A organização já trabalhou com desenvolvimento distribuído de software (DDS)?
( ) Sim ( ) Não
111
3ª PARTE : Sobre a contabilidade 13. Qual tipo de sistema de acumulação de custos a empresa pratica?
( ) Produção por ordem ou encomenda ( ) Produção contínua ou em série ( ) Ambas
14. É utilizado algum software para auxiliar a realização da contabilidade da
organização? Qual? _________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 15. Quando da compra de um equipamento, como é realizado o rateio?
( ) Por tempo de utilização ( ) Por número de projetos ( ) Não é realizado ( ) Outro(s):__________________________
_________________________________ _________________________________
4ª PARTE : Sobre as estimativas de custos 16. Quais funções, em sua organização, são responsáveis por realizar as estimativas de custos
de um projeto de software? ( ) Gerente geral da organização ( ) Gerente de uma unidade distribuída ( ) Gerente de projeto ( ) Desenvolvedor ( ) Analista ( ) Outro(s)___________________________________________________________
________________________________ ________________________________
17. Qual métrica é utilizada para se estimar o tamanho do produto de software a ser
desenvolvido? ( ) Linhas de código ( ) Pontos por função ( ) Pontos por caso-de-uso ( ) Pontos por objeto ( ) Funcionalidades ( ) Atividades ( ) Nenhuma
Outra(s):_______________________________________________________________________________________________ _________________________________
112
18. Qual métrica é utilizada para medir a produtividade da equipe? ( ) Linhas de código ( ) Pontos por função ( ) Pontos por caso-de-uso ( ) Pontos por objeto ( ) Funcionalidades ( ) Atividades ( ) Outras:_______________________________________________________________
__________________________ 19. Qual medida é utilizada para medir a quantidade de mão-de-obra necessária de um
projeto ou de uma atividade? ( ) Horas ( ) Dias ( ) Semanas ( ) Mês ( ) Número de atividades ( ) Outra(s):__________________________________________________________
20. Qual técnica de decomposição do projeto é utilizada para divisão do projeto? ( ) Divisão por problema ( ) Divisão por atividade ( ) Divisão por funcionalidade ( ) Divisão por módulos ( ) Outra(s):________________________________
______________________________________ ( ) Não divide, estima-se o projeto como um todo
21. Existem algumas técnicas utilizadas para auxiliar a realização das estimativas de
custo. Qual delas você ou sua organização utiliza? ( ) Estimativa por analogia ( ) Julgamento de um especialista ( ) Modelagem algorítmica ( ) Lei de Parkinson ( ) Preço definido para ganhar ( ) Outra: _______________________ ( ) Nenhuma
22. A empresa utiliza alguma ferramenta computacional para a realização de estimativa
de custo de seus projetos? ( ) Não ( ) Sim. Qual?____________________________________
113
23. Conhece ou utiliza alguma ferramenta para auxiliar a realização das estimativas de custos de produtos de software? ( ) CostExpert ( ) Costar ( ) USC-COCOMO ( ) Calico ( ) Outras, especifique seu funcionamento:
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
24. Acredita na utilidade de uma ferramenta de apoio para realizar estimativas de
esforço, tempo e custo de projetos de software? ( ) Sim, porque? ( ) Não,
porque?__________________________________________________________________ ____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
5ª PARTE : Sobre a ferramenta CostDDS 25. A apresentação permitiu visualizar a ferramenta e sua utilidade?
( ) Sim ( ) Não, Justifique:
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 26. Em sua opinião, a ferramenta auxilia a tomada de decisão durante as estimativas de
custo? ( ) Sim ( )Não
27. A ferramenta implementa a técnica de decomposição de projetos. Na ferramenta o
desenvolvimento é dividido em “módulos”. Na sua opinião, este tipo de divisão atende as necessidades de distribuição de trabalhos entre as equipes geograficamente distribuídas? Justifique:
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 28. Qual outra técnica de decomposição poderia ser utilizada? ______________________________________________________________________________________________________________________________________________________
114
29. A ferramenta armazena os custos mensais dos locais (equipes), estes conhecimentos discriminados dos custos, auxiliam na tomada de decisão quanto a distribuição de trabalhos entre as equipes?
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 30. A ferramenta implementa as técnicas de cálculo de pontos por função e número de
linhas de código-fonte para estimar o tamanho do software, e consecutivamente o custo. Na sua opinião, estas medidas são práticas para se estimar o trabalho?
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 31. A ferramenta possui um repositório onde dados de projetos passados são
armazenados. Na sua opinião, a interface implementada pela ferramenta permite a fácil consulta dos dados de projetos anteriores? Justifique. ( ) Sim ( ) Não
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ 32. A ferramenta implementa 3 técnicas distintas de estimativa de custo de projetos de
desenvolvimento de software, enumere a importância de cada uma, sendo que 1 é a mais importante e 3 a menos importante:
Estimativa por analogia
Estimativa por modelo empírico
Julgamento por especialista
33. As técnicas de estimativas de custos implementadas na ferramenta, na sua opinião,
atende as necessidades de estimativas de custos no Desenvolvimento Distribuído de Software? Justifique
____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________
115
34. Você considera que o manuseio da ferramenta facilitará a realização de estimativas de projetos?
_________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________ 35. Sugestões/opiniões/críticas. ______________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________ ___________________________________________________________________________
116
117
Anexo B
Neste anexo, são apresentadas as interfaces gráficas da ferramenta CostDDS. As interfaces
são apresentadas segundo suas funcionalidades e atributos nelas tratados.
A interface gráfica “Principal”, Figura B.1, permite o aceso as principais
funcionalidades da ferramenta CostDDS. Esta interface está melhor detalhada no Capítulo 7.
Figura B.1 – Interface gráfica “Principal”.
118
Mensalmente o gerente local, responsável por uma equipe local, deve atualizar
(informar na ferramenta) os custos ocorridos em seu local. Esse procedimento de atualização
é realizado com a interface gráfica “Atualização Mensal dos Custos Locais”, Figura B.2.
Figura B.2 – Interface gráfica “Atualização Mensal dos Custos Locais”.
Os atributos envolvidos na interface gráfica “Atualização Mensal dos Custos Locais”
são:
• Local (nome do local ou equipe, previamente cadastrado);
• Custo (tipo de custo ocorrido no mês referente, previamente cadastrado);
• Valor (valor do custo em unidades monetárias utilizada como padrão entre as
equipes);
• Mês (o mês referente o custo ocorrido);
• Soma custos mensais (neste campo é apresentada, automaticamente, a soma dos
custos ocorridos no mês referente);
Nesta interface, também, encontra-se o botão “Atualização Mensal dos Dados Locais”
para o acesso direto à interface de cadastro mensal dos dados locais.
119
A cada mês, o gerente local tem a responsabilidade de atualizar os dados de sua equipe
(local). Com a utilização desses dados atualizados, as estimativas se tornam mais realistas.
Essa atualização é realizada com a utilização da interface gráfica “Atualização Mensal
dos Dados Locais”, Figura B.3.
Figura B.3 – Interface gráfica “Atualização Mensal dos Dados Locais”.
Os atributos atualizados mensalmente com a interface gráfica “Atualização Mensal
dos Dados Locais” são:
• Quantidade de desenvolvedores (número de integrantes na equipe que trabalhou no
mês referente;
• Carga horária diária (quantidade de horas diárias trabalhadas, dependendo da
legislação do local, diferentes cargas horárias são encontradas entre as equipes
envolvidas).
• Quantidade total de horas diárias trabalhadas (esse atributo representa a quantidade
total de horas diárias trabalhadas, ou seja, a soma da carga horária de cada
integrante da equipe, pois, em alguns casos, pode acontecer que um ou mais
integrantes da equipe pode trabalhar, por exemplo, somente meio período diário.
• Total do custo salarial da equipe (esse atributo representa somente o montante
salarial da equipe, pois, os demais custos são cadastrados na interface gráfica
“Atualização mensal dos custos locais”, Figura B.2. Esse cadastro individual dos
custos salariais, permite a melhor visualização dos custos de determinada equipe
para fins de análise local.
120
Na Figura B.4 é apresentada a interface gráfica “Estimativa Módulo” (interface gráfica
bem detalhada no Capítulo 7).
121
Figura B.4 – Interface gráfica “Estimativa Módulo”.
122
A interface gráfica “Estimativa Módulo” foi desfragmentada em retângulos numerados
com o objetivo de melhor entender a navegação desta e das próximas interfaces a serem
apresentadas neste anexo. As regiões numeradas da Figura B.4 são:
1. No retângulo 1 representam dados a serem selecionados pelo gerente para a
identificação geral do módulo a ser desenvolvido.
2. No retângulo 2 são informados os dados sobre o tamanho do módulo. A interface
gráfica “Cálculo de Pontos por Função”, Figura B.5, pode ser utilizada para
auxiliar a estimativa do tamanho do módulo em quantidade de pontos por função.
3. No retângulo 3 o gerente direciona a estimativa para um determinado local
(equipe).
4. No retângulo 4 é permitido, ao gerente, a realização da estimativa com a
utilização do modelo empírico COCOMO. Ao acionar o botão “Estimar Módulo
por Modelo”, a ferramenta direcionará a navegação para interface gráfica “Cálculo
do expoente”, Figura B.6.
5. No retângulo 5 é permitido, ao gerente, a realização de estimativa diante de
analogias de projetos anteriores. Os dados das estimativas são apresentados
automaticamente segundo dados dos projetos concluídos. A operação realizada
pela ferramenta durante a realização desta estimativa está detalhada no Anexo D
(Diagrama de Sequência “calcularEstimativaLocalporAnalogia()”). O gerente pode
analisar e filtrar os dados utilizados pela ferramenta ao clicar no botão “Consultar
módulos por analogia”, neste momento, a navegação é direcionada para a interface
gráfica “Consulta estimativa por analogia”, Figura B.8, a qual apresenta uma série
de filtros que possibilitam uma melhor análise dos dados dos projetos concluídos.
6. No retângulo 6 o gerente atribui os valores para a estimativa. Caso tenha sido
consultado um ou mais especialistas, seus nomes são cadastrados por meio do
acionamento do botão “Cadastrar Especialista”. As observações sobre as decisões
tomadas diante de estimativa realizada podem ser armazenadas no repositório
junto à estimativa por meio do botão “Observações sobre a Estimativa”. Por fim, a
estimativa de um determinado módulo é concluída com o acionamento do botão
“Concluir estimativa módulo”.
123
O cálculo da quantidade de pontos por função de um módulo é auxiliado com a
utilização da interface gráfica “Cálculo de Pontos por Função”, Figura B.5.
Figura B.5 – Interface gráfica “Cálculo de Pontos por Função”.
Nesta interface “Cálculo de Pontos por Função”, o nome do módulo será apresentado
no campo Módulo.
Na linha do atributo “arquivos lógicos internos:” apresenta três classificações (Baixo,
Médio e Alto), em que cada classificação um peso é associado, conforme explicado no
Capítulo 3. Esse peso é utilizado para multiplicar a quantidade de determinado atributo
obtendo-se um subtotal nesta linha.
Para os demais atributos, outros pesos são utilizados na programação, os quais irão
gerar outros subtotais.
No campo “Total de PF não ajustados:” é mostrado, para o gerente, a soma dos
subtotais dos atributos calculados, este resultado mostra a quantidade total de pontos por
função de um determinado módulo.
No campo “Equivalência em SLOC:” é apresentada a quantidade de linhas de código
equivalente para a quantidade de pontos por função, recém calculados. Essa taxa de conversão
é estipulada no momento do cadastro da linguagem, podendo ser alterada segundo a
necessidade local.
124
Com o botão “Cadastrar valores”, a navegação na ferramenta é retornada para a
interface gráfica “Estimativa Módulo”, Figura B.3.
Quando a estimativa por modelo for realizada, deve-se, em primeiro lugar, calcular o
expoente da equação do modelo, este expoente é composto de cinco variáveis chamadas de
“Fatores de escala”, conforme explicado no Capítulo 4. Esse cálculo é realizado por meio da
utilização da interface gráfica “Cálculo do Expoente (Fatores de Escala)”, Figura B.6.
Figura B.6 – Interface gráfica “Cálculo do Expoente (Fatores de Escala)”.
Os cinco Fatores de escala são ajustados para realização da estimativa do módulo
diante da equipe relacionada. Bem como, o “Valor calibragem B” o qual representa um valor
de ajuste na equação.
Com base em dados históricos e na experiência do gerente em realizar as estimativas,
os ajustes são efetuados.
O valor do expoente é apresentado no campo “Valor do Expoente”.
Após a realização destes cálculos, o gerente prosseguirá por meio do botão “calcular
direcionadores de custos-->” com os cálculos dos “Direcionadores de Custos”, Figura B.7.
125
Figura B.7 – Interface gráfica “Cálculo dos Direcionadores de Custos”.
Com a Interface gráfica “Cálculo dos Direcionadores de Custos” o gerente de projetos
ajusta os direcionadores de custos e valor do multiplicador de esforço é mostrado.
No campo “Módulo” é mostrado o módulo que a estimativa se refere.
Os significados de cada abreviatura dos direcionadores de custos é apresentada na
interface sobre a forma de um texto explicativo, como no texto explicativo “RESTRIÇÃO DO
CRONOGRAMA - restrição no calendário” referindo-se à abreviatura “SCED”. O gerente
ajusta os direcionadores de custos segundo sua experiência e/ou com auxílio de dados de
projetos anteriores. Estes direcionadores de custos estão bem detalhados no Capítulo 4.
Nesta mesma interface, o gerente ajusta os atributos “Fator de Ajuste Equação”, Fator
de Ajuste Tempo 1” e “Fator de Ajuste Tempo 2”. O gerente ajusta estes atributos com a
finalidade de melhorar o resultado das equações utilizadas do modelo COCOMO.
126
Calcula-se os valores dos direcionadores, por meio do botão “Calcula multiplicador”.
Estes direcionadores de custos representam as economias e as “deseconomias” envolvidas no
desenvolvimento, melhor detalhada no Capítulo 4.
As ações executadas para realizar a estimativa utilizando o modelo empírico
COCOMO é melhor detalhada no Anexo D (Diagrama de Sequência
“calcularEstimativaLocalPorModelo()”). Com o botão “ok” encerra o processo de estimativa
utilizando o modelo empírico.
Em seguida, a navegação da ferramenta retornará para a interface gráfica “Estimativa
Módulo”, Figura B.3.
O gerente pode utilizar uma série de filtragens para analisar de diferentes aspectos os
dados de projetos concluídos. A interface gráfica “Consulta estimativa por analogia”, Figura
B.8, permite esta filtragem e análise dos dados de projetos anteriores. Com o auxílio desta
análise, o gerente consegue tomar decisões mais concisas, uma vez embasadas em análises de
dados reais.
127
Figura B.8 – Interface gráfica “Consulta estimativa por analogia”.
3 4
1
2
5
6
128
A interface gráfica “Consulta estimativa por analogia” foi desfragmentada em
retângulos numerados para melhor esclarecer suas partes:
1. O gerente pode combinar algumas seleções de dados opcionais.
2. O “Filtro de datas” pode ser usado quando do resgate de dados de módulos
anteriores entre as datas estipuladas.
3. Os “Filtros COCOMO” é utilizado para realizar analogias por meio de dados das
variáveis das equações do modelo COCOMO.
4. Os “Filtros ANALOGIAS” resgatam, do repositório, os dados dos módulos
segundo os valores estipulados para o “Tamanho do módulo” e/ou “Esforço” e/ou
“Produtividade”.
5. A cada execução de um filtro, os dados são apresentados no campo 5 “ANÁLISE
dos dados selecionados”. Entre as análises, a operação realizada pela ferramenta
para encontrar o valor da variável “custo médio” é melhor detalhado no Diagrama
de sequência “calcularEstimativaLocalPorAnalogia()” (Anexo D, Figura D.3).
6. Os dados apresentados no retângulo 6 são atualizados sempre que um filtro for
executado.
129
Com a interface gráfica “Observações sobre a estimativa realizada”, Figura B.9, o
gerente pode armazenar observações importantes sobre a estimativa realizada.
Figura B.9 – Interface gráfica “Observações sobre a estimativa realizada”.
Ao acionar o botão “cadastrar” a ferramenta retorna a navegação para a Interface
gráfica “Estimativa Módulo”, Figura B.3.
130
Uma vez concluída as estimativas dos módulos diante dos locais, o gerente atribui a
estimativa de um módulo para um local (equipe) com a utilização da interface gráfica
“Estimativa Local”, Figura B.10. Neste caso, a estimativa é computada ao selecionar a
alocação de um módulo para um local. Esta interface é melhor detalhada no Capítulo 7.
Figura B.10 – Interface gráfica “Estimativa Local”.
131
A estimativa de um projeto é realizada por meio da Interface gráfica “Estimativa
Projeto”, Figura B.11. Esta interface é melhor detalhada no Capítulo 7.
Figura B.11 – Interface gráfica “Estimativa Projeto”.
132
Ao terminar o desenvolvimento de um módulo, o gerente atualiza o banco de dados da
ferramenta CostDDS por meio da Interface gráfica “Cadastro dados reais de módulos
concluídos”, Figura B.12, com informações reais sobre o Esforço, Tempo, Custo,
Produtividade e Margem do erro cometida entre a estimativa realizada para o módulo e os
valores reais ocorridos.
Figura B.12 – Interface gráfica “Cadastro dados reais de módulos concluídos”.
133
As interfaces apresentadas deste ponto do Anexo B em diante, são consideradas
secundárias e seu funcionamento permite funções operacionais da ferramenta.
A interface gráfica “Cadastro Classificação”, Figura B.13, permite a inclusão de novas
classificações dos módulos na ferramenta.
Figura B.13 – Interface gráfica “Cadastro Classificação”.
O cadastro da estimativa do tamanho do módulo é realizado com a utilização da
interface gráfica “Tamanho do Módulo em Linhas de Código”, Figura B.14.
Figura B.14 – Interface gráfica “Tamanho do Módulo em Linhas de Código”.
Dois atributos são cadastrados na Interface gráfica “Tamanho do Módulo em Linhas
134
de Código”:
• Módulo (nome do módulo);
• Quantidade SLOC (tamanho do módulo em número de linhas de código-fonte).
O cadastro das funcionalidades de um projeto é realizado com a utilização da interface
gráfica “Cadastro Funcionalidade”, Figura B.15.
Figura B.15 – Interface gráfica “Cadastro Funcionalidade”.
Dois atributos são cadastrados na Interface gráfica “Cadastro Funcionalidade”:
• Projeto (nome do projeto);
• Nome funcionalidade.
135
Os gerentes são cadastrados com a utilização da interface gráfica “Cadastro Gerente”,
Figura B.16.
Figura B.16 – Interface gráfica “Cadastro Gerente”.
Dois atributos são cadastrados na Interface gráfica “Cadastro Gerente”:
• Nome Gerente;
• Função. Para o cadastro são permitidos três tipos de funções aos gerentes.
1. Gerente geral;
2. Gerente local;
3. Gerente de projetos.
136
O cadastro das linguagens de programação é realizado com a utilização da interface
gráfica “Cadastro Linguagem”, Figura B.17.
Figura B.17 – Interface gráfica “Cadastro Linguagem”.
Dois atributos são cadastrados na Interface gráfica “Cadastro Linguagem”:
• Nome Linguagem;
• Equivalência de SLOC por PF.
O atributo Equivalência de SLOC por PF representa a média da quantidade de linhas
de código-fonte que compõem um ponto por função. Esta técnica de conversão é chamada de
Backfiring e a taxa de conversão é determinada segundo a linguagem. Essa taxa pode ser
obtida em (BFPUG, 2009) e ajustada segundo as características locais.
137
O cadastro dos locais (equipes) é realizado com a utilização da interface gráfica
“Cadastro Local”, Figura B.18.
Figura B.18 – Interface gráfica “Cadastro Local”.
Na Interface gráfica “Cadastro Local” é cadastrado o nome do local ou equipe de um
determinado local.
138
O cadastro dos projetos é realizado com a utilização da interface gráfica “Cadastro
Projeto”, Figura B.19.
Figura B.19 – Interface gráfica “Cadastro Projeto”.
Na Interface gráfica “Cadastro Projeto” é cadastrado somente o nome do projeto.
139
Os tipos de custos globais são cadastrados por meio da interface gráfica “Cadastro
Custo Global”, Figura B.20.
Figura B.20 – Interface gráfica “Cadastro Custo Global”.
Na Interface gráfica “Cadastro Custo Global” o atributo trabalhado é o nome do custo.
140
Os nomes dos especialistas são cadastrados por meio da interface gráfica “Cadastro
Especialista(s)”, Figura B.21.
Figura B.21 – Interface gráfica “Cadastro Especialista(s)”.
Na Interface gráfica “Cadastro Especialista(s)”, os atributos cadastrados são: nome,
telefone e e-mail do especialista.
141
Anexo C
Neste anexo é apresentado o diagrama de classes da ferramenta CostDDS. O diagrama de
classe representa a estrutura e as relações entre as classes, e estas classes servem de modelo
para os objetos.
Na figura C.1 é apresentado o diagrama de classes da ferramenta CostDDS o qual
serviu como base para a construção dos demais diagramas.
142
Figura C.1 – Diagrama de Classes da ferramenta CostDDS.
143
Anexo D
Neste anexo são apresentados os diagramas de sequência das principais operações da
ferramenta CostDDS (calcularTotalProjeto(), calcularEstimativaLocalPorModelo() e calcular
estimativaLocalPorAnalogia()).
Estes diagramas permitem a melhor visualização do funcionamento interno da
ferramenta.
No principal diagrama de sequência da ferramenta é apresentada a sequência de passos
para realizar a estimativa total dos custos de um projeto de software, Figura D.1.
144
Figura D.1 – Diagrama de Sequência “calcularTotalProjeto()”.
145
No diagrama de sequência “calcularTotalProjeto()”, Figura D.1, são apresentadas as
entidades e a sequência de ações que acontecem na ferramenta para realizar as estimativa total
dos custos envolvidos em um projeto de software.
As sequências de ações são mostradas a seguir:
1: calcularTotalLocais():double – para cada local escolhido, o valor da estimativa é
resgatado e computado. A ação 1.1: getCustoEstimativa interna ao loop
somatório “loop [todos os locais de produção]” é executada para o resgate
destas estimativas locais. O retorno será um valor flutuante do tipo double.
2: calcularTotalGlobal():double – nesta ação são somados todos os custos globais
do projeto. O resgate dos valores determinados para o projeto em questão é
realizado por meio da ação 2.1: getValor() interna ao loop somatório “loop
[todos os custos globais]”. O retorno será um valor flutuante do tipo double.
Como resultado da execução destas sequências de ações tem-se uma estimativa total
dos custos envolvidos em um projeto que será desenvolvido de forma distribuída.
No entanto, a forma de realizar as estimativas de cada local pode ser realizada por
meio de três técnicas distintas: 1) Estimativa por modelo, Figura D.2; 2), Estimativa por
analogia, Figura D.3; 3) Estimativa por especialista.
146
Figura D.2 – Diagrama de Sequência “calcularEstimativaLocalPorModelo()”.
147
A estimativa do local pode ser realizada por utilização de um modelo empírico, na
ferramenta CostDDS foi optado por trabalhar equações do modelo COMOMO II (Capítulo, 4)
como modelo a ser seguido na ferramenta. No diagrama de sequência
“calcularEstimativaLocalPorModelo()”, Figura D.2, são apresentadas as entidades e a
sequência de ações que acontecem na ferramenta para realizar as estimativas de custos de um
determinado local (equipe) diante de um módulo a ser desenvolvido.
O tempo e o valor são os principais atributos a serem calculados para uma estimativa
de custo local realizada por modelo, para isso, uma seqüência de ações é executada, estas
ações são mostradas a seguir:
1: calcularTempo():int – O calculo do tempo permite os cálculos dos valores dos
custos ocorridos em uma determinada equipe (local). Para calcular o tempo, no
modelo, primeiramente executa-se a ação 1.1: calculoExpoente():double a qual
calculará o expoente da equação do modelo COCOMO. Em seguida, na ação
1.2: calculoDirecionadores():double, os direcionadores de custos são ajustados e
calculados. Na ação 1.3 calcularEsforço():double é calculada a quantidade de
esforço necessário para o desenvolvimento. Por fim, como resultado, obtém-se a
quantidade de tempo necessária para o desenvolvimento do módulo em questão.
2: getQtdHorasMes():int – nesta ação é resgatada do banco de dados uma soma
contendo o total de horas trabalhadas no local em que a estimativa se refere.
3: getValor(): double – esta ação resgata os valores totais dos custos ocorridos em
determinado local por meio do loop somatório “loop [para todos custos locais]”.
Como resultado da execução destas ações, obtém-se o esforço e o tempo necessário
para o desenvolvimento, calculados pelo modelo empírico COCOMO. Estes valores de
esforço e tempo juntos com a quantidade de horas (local) trabalhadas e, juntos com os valores
dos custos (do local) ocorridos neste período, é possível estabelecer um valor para a
estimativa de um módulo neste local.
No local em que a estimativa se refere, uma soma dos custos ocorridos em um período
de doze meses é realizada. Esta soma é dividida pela quantidade de horas trabalhadas (neste
local) neste mesmo período, e tem como resultado o custo da hora (local) de
desenvolvimento. Como o tempo necessário para o desenvolvimento do módulo (neste local)
já foi calculado, multiplica-se o tempo (horas) pelo custo da hora neste local e, com isso,
obtém-se a estimativa do custo do módulo para ser desenvolvido neste local.
148
Figura D.3 – Diagrama de Sequência “calcularEstimativaLocalPorAnalogia()”
149
A estimativa de custos de um local pode, também, ser realizada por utilização de
analogias com projetos anteriormente concluídos. No diagrama de sequência
“calcularEstimativaLocalPorAnalogia()”, Figura D.3, são apresentadas as entidades e a
sequência de ações que acontecem na ferramenta para realizar a estimativa por analogia de
um determinado módulo referindo-se a um determinado local.
O tempo, o valor e a produtividade são os principais atributos a serem calculados para
uma estimativa local realizada por meio de analogias e, para isso, uma seqüência de ações é
executada, conforme mostradas a seguir:
1: buscarModulos(): Modulo [] – esta ação resgata, da base de dados da
ferramenta, os módulos concluídos. O retorno desta função será um conjunto de
módulos que apresentam determinada classificação;
Dentro do loop “[para todos módulos buscados]” são executadas as ações 2, 3 e 4;
2: getSlocReal(): int – esta ação busca o atributo valor real em SLOC (número de
linhas de código-fonte) de cada módulo buscado. Este atributo representa a
quantidade real de linhas de código-fonte que foram desenvolvidas para cada
módulo;
3: getTempoReal(): int – executa a mesma operação da ação 2, com a diferença de
que a ação 3 busca a variável “tempo real” (em horas) de cada módulo
buscado;
4: getProdutividade(): double – esta ação busca, do repositório, a produtividade
real (em SLOC/h) apresentada de cada módulo buscado;
Vale lembrar que estes atributos foram cadastrados, quando da conclusão do
desenvolvimento dos módulos anteriores, por meio da Interface gráfica “Cadastro dados reais
de módulos concluídos” (Anexo B, Figura B.12).
5: getQtdHorasMes(): double – esta ação busca, do repositório, a quantidade de
horas trabalhadas no local em que a estimativa se refere;
6: getValor(): double - esta ação resgata os valores dos custos ocorridos em
determinado local por meio do loop somatório “loop [para todos custos locais]”.
Estas ações resgatam os dados necessários para a realização da estimativa de custo em
um determinado local.
Utilizando o valor do atributo “produtividade real”, pode-se realizar uma estimativa de
tempo ao combiná-lo com o tamanho do módulo a ser desenvolvido.
Da mesma maneira que na estimativa realizada por modelo, Figura D.2, no local em
que a estimativa se refere, uma soma dos custos ocorridos em um período de doze meses é
150
realizada. Esta soma é dividida pela quantidade de horas trabalhadas (neste local) neste
mesmo período, e tem como resultado o custo da hora (local) desenvolvimento. Como o
tempo necessário para o desenvolvimento do módulo (neste local) já foi calculado, multiplica-
se o tempo (horas) pelo custo da hora neste local e, com isso, obtém-se a estimativa do custo
do módulo para ser desenvolvido neste local.