Estimador de Software

Raíssa Giavaroti Machado
DESENVOLVIMENTO DE UM AMBIENTE PARA ESTIMATIVA DE

SOFTWARE UTILIZANDO PONTOS DE CASOS DE USO
Trabalho de conclusão de curso apresentado ao

Instituto Federal de São Paulo, como parte dos
requisitos para a obtenção do grau de Tecnólogo
em Sistemas para Internet.
Área de Concentração: Engenharia de Software
Orientador: Prof. Breno Lisi Romano
São João da Boa Vista

2013
Autorizo a reprodução e divulgação total ou parcial deste trabalho, por qualquer
meio convencional ou eletrônico, para fins de estudo e pesquisa, desde que
citada a fonte.
Ficha catalográfica preparada pela Seção de Tratamento

da Informação do Serviço de Biblioteca – IFSP
Giavaroti Machado, Raíssa.

Desenvolvimento de um ambiente para estimativa de
software utilizando pontos de casos de uso. / Raíssa
Giavaroti Machado ; orientador Breno Lisi Romano. São
João da Boa Vista, 2013.
Trabalho de Conclusão de Curso, IFSP, 2013.
1. Estimativa de Esforços. 2. Técnicas de Estimativa.

3. Casos de Uso. 4. Gerência de Projetos.
I. Desenvolvimento de um ambiente para estimativa

de software utilizando pontos de casos de
uso
AGRADECIMENTOS
Primeiramente agradeço a Deus, por ter me concedido força e inspiração para
realização desta pesquisa, por renovar as minhas vontades quando elas já pareciam ter se
esgotado em meio às dificuldades encontradas e por me mostrar que sempre há um caminho.
Agradeço minha família por todo apoio e incentivos recebidos, em especial aos meus
pais, Regina e Valdir, e ao meu avô, Adilson, cuja lembrança está sempre presente.
Agradeço ao Instituto Federal de São Paulo por ter me proporcionado uma ótima
qualidade de ensino e aprendizado e um ambiente de estudo muito agradável.
Agradeço a todos os professores que passaram por minha vida nestes três anos, e
deixaram um pouco de si de alguma forma.
Agradeço ao meu orientador Breno, pela paciência e boa vontade ao me auxiliar nesta
pesquisa, por ser tão prestativo e estar sempre disponível para me ajudar.
Também agradeço à empresa Netmake, por sua incrível atenção em tudo que precisei
para realização desta pesquisa, em especial à Priscilla Candeia, a qual fica minha enorme
gratidão, por sua boa vontade e solidariedade em me auxiliar nesta pesquisa.
Por fim, agradeço aos meus amigos, os do Instituto Federal e os de fora, que estiveram
sempre presentes, me ajudando e apoiando desde o início deste trabalho, que estiveram do
meu lado quando tudo ia bem, mas principalmente quando parecia que não estava tão bem
assim, o apoio de vocês foi muito importante para mim.

RESUMO
GIAVAROTI MACHADO, RAISSA. (2013). Desenvolvimento de um ambiente para

estimativa de software utilizando pontos de casos de uso. Trabalho de Conclusão de Curso
- Instituto Federal de São Paulo, São João da Boa Vista, 2013.
Esta pesquisa aborda temas das áreas de Engenharia de Software e Gerência de
Projetos, tratando sobre os processos de estimativa de esforços que existem para serem
aplicados no desenvolvimento de um software. Neste trabalho, descreve-se a concepção e
aplicação da técnica de estimativa por Pontos de Caso de Uso, desenvolvida em 1993 por
Gustav Karner, por meio do ambiente proposto por este trabalho. Este ambiente foi
desenvolvido com a intenção de auxiliar os stakeholders quanto ao planejamento de recursos
do projeto, a fim de que este possa desenvolver-se dentro do esperado. Ao término do
desenvolvimento, ele foi aplicado em um estudo de caso com sucesso e com isto validou-se
seu desempenho e apresentou-se seu funcionamento.
Palavras-chave: Ambiente para Estimativa de Esforços. Técnicas de estimativa. Casos de Uso.

Gerência de Projeto. Engenharia de Software.
ABSTRACT
MACHADO, RAISSA GIAVAROTI. (2013). Development of a Effort Estimation

Environment. Course Conclusion Project – Instituto Federal de São Paulo, São João da Boa
Vista, 2013.
This research present topics in the Software Engineering and Project Management
areas, focusing in the processes of efforts estimation to be applied in the software
development. This work describes the design and development of an environment using the
Use Case Points, developed in 1993 by Gustav Karner. The proposed environment was
developed with the intention to assist stakeholders in planning of project resources in order to
enable it to develop as expected. At the end of the development, it was applied on a case study
successfully and it was possible to validate its performance and show its performing.
Keywords: Effort Estimation Environment. Estimation Techniques. Use cases. Project
Management.Software Engineering.
LISTA DE FIGURAS
Figura 1 – Fases do Gerenciamento de Projetos ........................................................ 23
Figura 2 - Ator – Diagrama de Caso de Uso ............................................................... 25
Figura 3 - Caso de Uso – Diagrama de Caso de Uso ................................................. 26
Figura 4 - Etapas do desenvolvimento desta pesquisa ............................................... 41
Figura 5 – Fluxo de atividades para obter as horas estimadas ................................... 45
Figura 6 – MER do ambiente de estimativa ................................................................ 46
Figura 7 – Modelo Relacional do ambiente de estimativa ........................................... 47
Figura 8 – Interface para cadastro de projetos ............................................................ 49
Figura 9 – Interface peso e complexidade de ator ...................................................... 50
Figura 10 – Interface peso e complexidade de caso de uso........................................ 51
Figura 11 – Interface de fator de complexidade técnica – Sistemas distribuídos,
Desempenho e Eficiência ........................................................................................... 52
Figura 12 - Interface de fator de complexidade técnica – Processamento,
Reutilização, Facilidade de instalação e operação, Portabilidade e Mutabilidade ....... 53
Figura 13 - Interface de fator de complexidade técnica – Simultaneidade,
Segurança, Acesso de terceiros e Treinamento especial ............................................ 54
Figura 14 – Interface do fator ambiental...................................................................... 55
Figura 15 – Interface do fator ambiental - Continuação............................................... 56
Figura 16 – Interface de consulta de estimativas ........................................................ 57
Figura 17 – Interface de consulta de estimativas - Continuação ................................. 58
Figura 18 – Interface para relato de feedbacks ........................................................... 62
Figura 19 – Definição de ator – Projeto Medida Certa................................................. 64
Figura 20 – Definição de casos de uso – Projeto Medida Certa .................................. 65
Figura 21 – Estimativa finalizada do projeto Medida Certa ......................................... 68
Figura 22 – Versão número 1 da Estimativa ............................................................... 71
Figura 23 – Versão número 2 da estimativa ................................................................ 71
Figura 24 – Versão número 3 da estimativa ................................................................ 72
Figura 25 – Desenvolvimento dos pontos de casos de uso ........................................ 74
LISTA DE TABELAS
Tabela 1 - Complexidade dos tipos de função ............................................................ 29
Tabela 2 - Características que influenciam na complexidade...................................... 30
Tabela 3 - Peso e complexidade do ator ..................................................................... 34
Tabela 4 - Peso e complexidade do caso de uso ........................................................ 35
Tabela 5 - Fatores que contribuem para a complexidade ........................................... 36
Tabela 6 - Fatores que contribuem para a eficiência .................................................. 38
Tabela 7 – Fatores de Sucesso do Projeto ................................................................. 60
Tabela 8 – Fatores de Projeto Desafiado .................................................................... 60
Tabela 9 – Fatores de Projeto Prejudicado ................................................................. 61
Tabela 10 – Influência dos feedbacks ......................................................................... 61
Tabela 11 – Complexidade atores – Medida Certa ..................................................... 63
Tabela 12 – Complexidade de casos de uso – Medida Certa ..................................... 64
Tabela 13 – Definição do fator técnico – Medida Certa ............................................... 66
Tabela 14 – Definição fator ambiental – Medida Certa................................................ 67
Tabela 15 – Feedback Projeto Medida Certa .............................................................. 75
LISTA DE EQUAÇÕES
Equação 01 - PFNA Pontos por Função Não Ajustados........................................................29
Equação 02 - FAPF Fator de Ajuste de Pontos por Função..................................................30
Equação 03 - PFA Pontos por Função Ajustados..................................................................30
Equação 04 - Esforço.............................................................................................................31
Equação 05 - Prazo................................................................................................................31
Equação 06 - Custo................................................................................................................31
Equação 07 - UAW Peso não ajustado por Ator....................................................................34
Equação 08 - UUCW Peso não ajustado por Casos de Uso..................................................35
Equação 09 - UUCP Pontos não ajustados por Casos de Uso..............................................36
Equação 10 - Tfactor Fator de Complexidade Técnica..........................................................37
Equação 11 - TCF Fator de Complexidade Técnica..............................................................37
Equação 12 - Efactor Fator Ambiental....................................................................................38
Equação 13 - EF Fator Ambiental..........................................................................................38
Equação 14 - UCP Pontos por Casos de Uso........................................................................38
LISTA DE SIGLAS
COCOMO Constructive Cost Model
EF Environmental Factor
ES Engineering Software
FAPF Fator de Ajuste de Pontos por Função
FPA Function Point Analysis
HTML HyperText Markup Language
IHM Interface Humano Máquina
LCD Linguagem de Controle de Dados
LDD Linguagem de Definição de Dados
LMD Linguagem de Manipulação de Dado
LOC Lines of Code
MER Modelo Entidade Relacionamento
OMG Object Management Group
PFA Pontos de Função Ajustados
PFNA Pontos Não Ajustados por Função
PHP PHP HyperText Preprocessor
PMBOK Project Management Body of Knowledge
RUP Rational Unified Process
SGBD Sistema Gerenciador de Banco de Dados
SQL Structured Query Language
TCF Technical Complexity Factor
UAW Unadjusted Actor Weight
UCP Use Case Point

UFC Unadjusted Function Count
UML Unified Modeling Language
USC University of Southern California
UUCP Unadjusted Use Case Points
UUCW Unadjusted Use Case Weight

SUMÁRIO
1 INTRODUÇÃO ........................................................................................................... 17
1.1 Motivação e Contextualização .............................................................................................. 17
1.2 Objetivos ............................................................................................................................... 19
1.2.1 Objetivo Geral .................................................................................................................... 19
1.2.2 Objetivos Específicos ......................................................................................................... 19
1.3 Organização deste trabalho ................................................................................................... 20
2 LEVANTAMENTO BIBLIOGRÁFICO ....................................................................... 21
2.1 Engenharia de Software ........................................................................................................ 21
2.2 Gerência de Projetos ............................................................................................................. 22
2.3 Linguagem UML .................................................................................................................. 24
2.3.1 Diagrama de Caso de Uso .................................................................................................. 25
2.4 Técnicas de Estimativa de Software ..................................................................................... 26
2.4.1 LOC (Lines of Code – Linhas de Código) ......................................................................... 27
2.4.2 FPA (Function Point Analysis – Análise de Pontos por Função) ...................................... 28
2.4.3 COCOMO (I e II) ............................................................................................................... 32
2.4.4 UCP (Use Case Points – Pontos de Caso de Uso).............................................................. 33
2.4.4.1 1ª Fase – Cálculo do UAW (Unadjusted Actor Weight – Peso Não Ajustado por
Ator) 34
2.4.4.2 2ª Fase – Cálculo do UUCW (Unadjusted Use Case Weight – Peso Não Ajustado
por Caso de Uso) ......................................................................................................................... 35
2.4.4.3 3ª Fase – Cálculo dos Pontos Não Ajustados por Caso de Uso (UUCP) ...................... 36
2.4.4.4 4ª Fase – Cálculo do TCF (Technical Complexity Factor - Fator de Complexidade
Técnica) 36
2.4.4.5 5ª Fase – Cálculo do EF (Environmental Factor – Fator Ambiental) ........................... 37
2.4.4.6 6ª Fase – Cálculo dos Pontos de Caso de Uso (UCP) ................................................... 38

2.5 Trabalhos Relacionados ........................................................................................................ 39
3 METODOLOGIA ....................................................................................................... 41
3.1 Definição da Técnica de Estimativa ..................................................................................... 41
3.2 Definição das Tecnologias Utilizadas para Desenvolvimento do Ambiente ........................ 42
3.3 Concepção do Ambiente para Estimar o Desenvolvimento de Software .............................. 44
3.3.1 Fluxo de informações no ambiente para estimativa ........................................................... 44
3.3.2 Banco de Dados Relacional para Suportar o Ambiente ..................................................... 45
3.3.3 Ambiente de Estimativa por Pontos de Caso de Uso ......................................................... 48
3.3.3.1 Estimativa por Pontos de Caso de Uso – Cadastro de Projetos .................................... 48
3.3.3.2 Estimativa por Pontos de Caso de Uso – Fase 1 ........................................................... 49
3.3.3.8 Estimativa por Pontos de Caso de Uso – Consulta de estimativas................................ 56
3.3.3.9 Estimativa por Pontos de Caso de Uso – Relatar Feedback.......................................... 58
3.4 Aplicação do Ambiente em um Experimento ....................................................................... 63
4 RESULTADOS .......................................................................................................... 70
5 CONCLUSÕES .......................................................................................................... 77
5.1 Sugestões e recomendações para trabalhos futuros .............................................................. 78
REFERÊNCIAS ............................................................................................................... 79
Capítulo
17
1 Introdução
De acordo com Karner (1993) quando se inicia um projeto de desenvolvimento de
software é de grande valia que se saiba o quanto de recursos será investido para que ele seja
concluído, sejam esses recursos materiais, estruturais, humanos ou temporal e orçamentário.
Dessa forma, torna-se interessante estimar o custo e o tempo necessários no seu
desenvolvimento.
Portanto, esta pesquisa pretende apresentar a aplicação de uma métrica de estimativa
de esforços para o desenvolvimento, que auxilia quanto ao planejamento de tais recursos para
que o projeto seja desenvolvido dentro do esperado, utilizando os recursos planejados.
1.1 Motivação e Contextualização
Hoje em dia, é importante para as empresas investir em medidas que possam avaliar
seu desempenho e eficiência, a fim de observar como está o processo de desenvolvimento de
sistemas, e assim poder planejar com mais certeza os passos do projeto.
Um projeto cujo caminho seja bem definido tem mais chances de ser desenvolvido
dentro do esperado, porém, muita atenção está voltada ao processo de gerenciamento de
projetos, com realização de cronogramas e metas a serem cumpridas. Por outro lado, não
existe muita preocupação quanto às estimativas de esforço de software, o que é errado, pois
estimar é uma tarefa importante. A estimativa deve ser realizada no ínicio do projeto e ser
refinada de acordo com o ciclo de desenvolvimento (PRESSMAN, 2011).
Segundo definição em dicionário, a palavra “estimar” significa determinar o valor de
algo, avaliar, calcular o preço e a quantidade. Estimar um software significa que serão feitos
18
cálculos fundamentados em técnicas que poderão avaliar e calcular o preço aproximado de
um projeto de desenvolvimento (MINIDICIONÁRIO EDIOURO DA LÍNGUA
PORTUGUESA, 1999).
Levando esses pontos em consideração, foi identificada certa deficiência para estimar,
de modo apropriado, o desenvolvimento e planejamento de um software, que se não for feito
corretamente pode ocasionar atrasos na entrega das fases do projeto, prejudicando-o como
todo (STANDISH GROUP REPORTER, 1995).
Segundo pesquisa do grupo THE STANDISH GROUP REPORTER (1995), uma das
causas do descumprimento do prazo de entrega de um projeto é que muitos são cancelados
antes mesmo de serem concluídos. Uma possível solução para este problema é fazer a
estimativa de software para obter uma base de como organizar custos e desenvolvimento na
intenção de conciliá-los para alcançar o resultado final esperado.
Existem diversas técnicas usadas para estimar tempo e custo no desenvolvimento de
software, dentre as principais podem-se citar: Pontos de Caso de Uso (KARNER, 1993),
Pontos por Função (ALBRECHT, 1981), COCOMO - Constructive Cost Model (BOEHM,
1981). Diante deste contexto, surge a necessidade de ambientes automatizados que possam
auxiliar na aplicação de uma destas técnicas de estimativa, sendo este o escopo desta
pesquisa.
Embasados em ambientes, como o deste trabalho, os profissionais irão estimar a
complexidade de forma mais rápida, podendo dar um retorno do preço aproximado,
oferecendo uma estimativa cujos riscos sejam toleráveis e perto do valor real (ARNOLD,
PEDROSS, 1998).
19
1.2 Objetivos
Diante do contexto relatado anteriormente, esta seção apresenta o objetivo geral desta
pesquisa, como alguns objetivos específicos.
1.2.1 Objetivo Geral
O objetivo deste trabalho é aplicar a estimativa de desenvolvimento de software
utilizando a técnica de Pontos de Caso de Uso (UCP – Use Case Points) através do
desenvolvimento de um ambiente, visando auxiliar nas dificuldades existentes no processo de
identificar custos de um desenvolvimento, servindo também como base para os profissionais e
empresas ao levantar os orçamentos no desenvolvimento, embasados em uma técnica da
Engenharia de Software (ES).
1.2.2 Objetivos Específicos
A fim de alcançar o objetivo geral descrito acima, este trabalho tem como objetivos
específicos:
• Levantamento bibliográfico a fim de pesquisar e apresentar trabalhos que estejam
diretamente relacionados com o desta pesquisa;
• Estudo dos conceitos de estimativa de esforço;
• Desenvolver um ambiente para estimar desenvolvimento de software, aplicando os
conceitos de estimativa por UCP;
• Aplicar o ambiente desenvolvido em um experimento, visando verificar e validar seu
funcionamento; e
• Analisar os resultados obtidos e sugerir melhorias para trabalhos futuros.

20
1.3 Organização deste trabalho
O presente trabalho divide-se em 4 capítulos além desta introdução.
No capítulo 1, faz-se uma introdução ao tema de estimativa de esforços e
apresentam-se os objetivos desta pesquisa. Também se discorre sobre a motivação e a
contextualização deste trabalho.
O capítulo 2 apresenta o levantamento bibliográfico e alguns trabalhos
relacionados com o seu desenvolvimento. Este capítulo abrangerá os principais
conceitos envolvidos com o tema desta pesquisa, envolvendo gerência de projetos,
Engenharia de Software, linguagem UML (Unified Modeling Language – Linguagem
de Modelagem Unificada) e técnicas de estimativa, fornecendo base para o
desenvolvimento do objetivo proposto.
Já o capítulo 3, discorre sobre a metodologia aplicada neste projeto,
descrevendo qual técnica de estimativa será utilizada, as tecnologias adotadas para o
desenvolvimento da proposta, o desenvolvimento do ambiente e a sua aplicação em
um estudo de caso.
O capítulo 4 apresenta uma análise dos resultados obtidos com este trabalho.
Por fim, o capítulo 5 descreve as conclusões e sugestões para trabalhos futuros.

Capítulo
21
2 Levantamento Bibliográfico
Nas próximas seções serão apresentados temas relacionados ao desta pesquisa,
fornecendo um embasamento teórico para o entendimento do trabalho.
Serão abordados tópicos sobre linguagem de modelagem de projetos (UML),
Engenharia de Software, Gerenciamento de Projetos e técnicas de estimativa, de modo a
demonstrar o quanto estimar projetos envolve várias áreas da disciplina de Engenharia e como
é difícil fornecer o custo aproximado do valor real, sem uso de análise e estudo do sistema
que será desenvolvido.
2.1 Engenharia de Software
Segundo Falbo (2005) a Engenharia de Software surgiu em meados da década de
1970, visando proporcionar um tratamento mais sistemático e controlado ao processo de
desenvolvimento de software.
Este processo a que referimos é algo que possui início, meio e fim e que necessita
certo esforço empreendido para que seja concluído, sejam esses esforços orçamentais, de
cumprimento de prazos ou de recursos humanos (PROJECT MANAGEMENT INSTITUTE,
2004).
A Engenharia de Software engloba todos os passos do projeto, desde seu planejamento
até sua conclusão, aplicando práticas de gerenciamento de projetos que visam a organização,
qualidade e produtividade do projeto (FALBO, 2005).

22
Segundo Falbo (2005, p. 02), “a Engenharia de Software trata de aspectos
relacionados ao estabelecimento de processos, métodos, técnicas, ferramentas e ambientes de
suporte ao desenvolvimento de software”.
2.2 Gerência de Projetos
Segundo o Guide to the Project Body of Knowledge de 2000, Gerenciamento de
Projetos é a aplicação de conhecimentos, habilidades, ferramentas e técnicas nas atividades do
projeto a fim de atender todos os seus requisitos definidos. Trata-se de uma estratégia para
organizações, permitindo que elas unam os resultados dos projetos com os objetivos do
negócio e possam competir em seus mercados.
Conforme o guia PMBOK (Project Management Body of Knowledge) de
gerenciamento de projetos, a gerência se divide em cinco grupos de processos: Iniciação,
Planejamento, Execução, Controle e Encerramento.
No primeiro grupo, chamado Iniciação, é desenvolvido o termo de abertura do projeto,
documento elaborado com o objetivo de reconhecer a existência de um projeto. Nele, há
informações sobre o produto, cronograma básico, nome do gerente, restrições, necessidades
iniciais e justificativa do projeto.
Já no segundo grupo, chamado Planejamento, é feito o documento que descreve o
plano global do projeto e os procedimentos a serem conduzidos durante a sua execução. É a
base para o próximo processo de execução do projeto. No documento de plano global do
projeto, existem informações sobre os objetivos, metas e escopos, cronograma, análise de
custos e orçamento e planos auxiliares.
O processo de Execução lida com a própria realização do projeto, gerenciando e
orientando seu desenvolvimento.

23
A fase de Controle ocorre desde o início até o fim do projeto e tem como objetivo
controlar e monitorar o andamento do projeto. Esta fase também é responsável por fazer o
controle integrado de mudanças que existirem.
O Encerramento significa o término do projeto e sua conclusão.
Na figura 1, pode-se observar a organização das fases de Gerenciamento de Projetos.
Figura 1 – Fases do Gerenciamento de Projetos
Fonte: Elaboração do autor
A estimativa de software, no caso descrito acima, pertence ao processo de
Planejamento do sistema, interferindo nas áreas de cronograma, custos e recursos humanos.
Sendo assim, o foco desta pesquisa que é estimativa de software está incluso, de forma direta,
na análise de custos e orçamentos do projeto.
É importante lembrar que existem outros modelos de gerenciamento de projeto, além
do guia PMBOK, e que esses guias não são obrigatórios de serem seguidos. A finalidade de
ambos é servir como base para organizar o desenvolvimento de um projeto, garantindo assim
chances maiores de sucesso ao mesmo. Dessa forma, percebe-se o quão importante é a
disciplina de Gerenciamento de Projetos e como utilizar uma ferramenta adequada como
auxílio é essencial aos profissionais da área.

24
2.3 Linguagem UML
Conforme Gudwin (2010) uma das fases do processo de desenvolvimento de software
é a modelagem do projeto. Nessa fase, inclui-se a utilização da notação chamada UML, que
suporta a diagramação de todo o sistema.
A UML surgiu da união de três metodologias de modelagem: o método do americano
Grady Booch, o método do sueco Ivar Jacobson e o método do americano James Rumbaugh.
(BOOCH; RUMBAUGH; JACOBSON, 2005).
Essas três metodologias tinham similaridade de conceitos, mas eram empregadas em
notações diferentes. Assim, em certa metodologia havia características que faltavam em outra,
e características nesta que faltavam àquela (GUDWIN, 2010).
Quando foi lançada a primeira versão da UML, foi estabelecido um consórcio com
várias empresas que atuavam na área de desenvolvimento de software, entre essas empresas
encontrava-se a IBM, a Microsoft, a Oracle e a Rational. Todas elas contribuíram com
informações para melhorar a linguagem. Dessa forma, em 1997, a UML 1.0 se tornou
uma linguagem padrão de modelagem de projetos, mantida pela OMG (Object Management
Group – Grupo de Gestão de Objetos) (BOOCH; RUMBAUGH; JACOBSON, 2005).
A UML é a linguagem de modelagem mais utilizada atualmente pela equipe de
desenvolvimento. Ela pode ser empregada para especificar, visualizar, construir e documentar
o projeto, proporcionando vários níveis de abstração aos envolvidos (SILVA, 2009).
Esta notação abrange vários diagramas para especificar os requisitos do sistema, entre
eles estão o diagrama de classes, que demonstra todas as classes do projeto, com seus
respectivos métodos e atributos; o diagrama de sequência, que é parte complementar do
diagrama de caso de uso e define os passos para realização do caso de uso a qual pertence; e o
diagrama de estado, que mostra os estados de um objeto durante seu ciclo de vida no projeto
(OMG UNIFIED MODELING LANGUAGE, 2011).

25
Na próxima seção desta pesquisa trata-se sobre o diagrama de caso de uso da
linguagem UML, pois está diretamente relacionado com este trabalho.
2.3.1 Diagrama de Caso de Uso
Um diagrama de grande importância da UML é o Diagrama de Caso de Uso, em que é
feita a especificação de todas as funcionalidades do sistema, através da utilização das formas
gráficas de ator e caso de uso (OMG UNIFIED MODELING LANGUAGE, 2011).
O diagrama de caso de uso é o que mais se aproxima da visão do cliente. Com base
nele, é possível visualizar, especificar e documentar o comportamento de um elemento,
fazendo com que sistemas, subsistemas e classes fiquem compreensíveis (BOOCH;
RUMBAUGH; JACOBSON, 2005).
O ator, conforme ilustrado na Figura 1, representa um papel que interage diretamente
com o sistema. Este papel pode ser uma pessoa ou outros sistemas que irão interagir com os
casos de uso.
Figura 2 - Ator – Diagrama de Caso de Uso
Fonte: OMG (Object Management Group)
O caso de uso, ilustrado na Figura 2, por sua vez, expressa uma função do sistema, e
contém sua própria documentação.

26
Figura 3 - Caso de Uso – Diagrama de Caso de Uso
Fonte: OMG (Object Management Group)
Cada caso de uso representa um requisito funcional, e na sua documentação inclui-se o
nome, as pré-condições para que ele ocorra, um breve descritivo sobre sua função no sistema,
e fluxos principal e alternativo (BOOCH; RUMBAUGH; JACOBSON, 2005).
Os fluxos, também chamados de cenários, visam demonstrar os passos que o caso de
uso deverá seguir. No fluxo principal são descritos os passos da forma que se espera que eles
ocorram e no fluxo alternativo são descritos as exceções daquele caso de uso (BOOCH;
RUMBAUGH; JACOBSON, 2005).
2.4 Técnicas de Estimativa de Software
Segundo Karner (1993), estimar os esforços que serão empreendidos no
desenvolvimento de um software é tarefa importante para as empresas que atuam nessa área.
Quando um método de estimativa é aplicado, torna-se possível ter conhecimento de quanto
aproximadamente deverá ser investido pela organização, visando o objetivo de cumprir os
prazos e entregar o produto solicitado pelo cliente.
De acordo com Pressman (2011) para que a estimativa seja realizada, é necessário que
os stakeholders 1conheçam e tenham de forma bem definida e refinada os requisitos do
sistema.
1
Conjunto de pessoas ou organizações que têm interesse na realização de um determinado projeto
(TECNOLOGIA DE PROJETOS, 2008).
27
Estimar um software então, quer dizer que, embasados no documento de elicitação de
requisitos, no conhecimento que as pessoas envolvidas têm do projeto e do ambiente em que
este será desenvolvido é possível obter informações sobre tempo, custos e recursos que serão
utilizados no desenvolvimento do sistema, alcançando assim a finalidade deste processo.
Dentro do contexto apresentado anteriormente, percebe-se que estimar é um processo
contido no processo de Engenharia de Software, principalmente na disciplina de
Gerenciamento de Projetos, tornando-se um passo importante durante o desenvolvimento de
sistemas, que se feito com a máxima proximidade possível, permite que o projeto evolua
conforme o planejado.
Atualmente, existem várias técnicas disponíveis para estimar um software, sendo que
em seguida serão detalhadas as principais.
2.4.1 LOC (Lines of Code – Linhas de Código)
Esta técnica de estimativa consiste na contagem de linhas de código do programa. É a
mais antiga medida de tamanho do desenvolvimento de software, porém não é aceita
como a melhor maneira de medir os processos de um software.
Os proponentes dessa ténica argumentam que LOC está presente em todos os projetos
e pode ser facilmente contado, que muitos modelos de estimativas utilizam LOC e que
existem muitos trabalhos escritos sobre essa técnica. Por outro lado, os oponentes
argumentam que LOC é totalmente dependente da linguagem de programação que será
utilizada no projeto, que quando é considerada a produtividade essa técnica penaliza
projetos bem elaborados, mas menores, e também que essa técnica não pode acomodar
linguagens não procedurais, ou seja, linguagens que não se baseiam em procedimentos
(PRESSMAN, 2011).
28
2.4.2 FPA (Function Point Analysis – Análise de Pontos por Função)
Proposta em 1979 por Allan J. Albrecht, na técnica de FPA é possível estimar
independente das tecnologias que serão utilizadas no projeto. Ela mede desde custos até
outros recursos, como por exemplo, o ambiente de desenvolvimento, proporcionando uma
estimativa mais aproximada do custo real do projeto (SILVA, 2009).
Segundo Albrecht (1979), a FPA utiliza uma métrica que se divide em três etapas:
1. PFNA - Pontos de Função Não Ajustados;
2. FAPF - Fator de Ajuste de Pontos de Função; e
3. PFA - Pontos de Função Ajustados.
Karner (1993) cita que este modelo leva em consideração o número de complexidade de:
1. Entradas Externas: número de comandos que o software irá aceitar;
2. Saídas Externas: quantos tipos de informações de saída o sistema poderá gerar;
3. Consultas Externas: quantos tipos de pergunta um usuário pode fazer ao sistema;
4. Arquivos Lógicos Internos: quantos arquivos o software pode lidar de forma
simultânea; e
5. Arquivos Lógicos Externos: número de ligações que este sistema pode ter com
outro sistema.
Para cada um desses itens são aplicados os níveis simples, médio ou complexo, com
seus respectivos pesos, a fim de encontrar a quantidade de UFC (Unadjusted Function
Count– Quantidade Não Ajustada de Funções) (KARNER, 1993).
Após o cálculo de UFC, é feito a segunda etapa dessa métrica, em que se mede o
FAPF. O cálculo do fator de ajuste descreve o tamanho da complexidade técnica
envolvida no desenvolvimento e implementação do sistema (KARNER, 1993).
Por fim, os PFA são o resultado da multiplicação dos casos anteriores.

29
Macoratti (2004) cita em seu artigo “Quanto vale o software que você produz?” um
exemplo da aplicação dessa técnica para um sistema de cadastro de clientes. Nesse
sistema é possível realizar as operações de listagem dos clientes em ordem alfabética e
exportação do cadastro para outro sistema via arquivo texto.
No caso citado acima e utilizando o manual de contagem da complexidade da PFA,
existem os seguintes casos que devem ser considerados:
- Arquivo Lógico Interno: 01 (arquivo de cliente que será exportado);
- Arquivo Lógico Externo: não há.
- Entrada Externa: 01 (inclusão de cliente);
- Saída Externa: 01 (listagem em ordem alfabética);
- Consulta Externa: 01 (exportar o arquivo texto);
Para o cálculo do PFA neste exemplo o autor considerou estes tipos de função como
sendo de complexidade baixa, somente para exemplificar.
Após o levantamento feito anteriormente deve-se calcular os PFNA, para isso é
necessário multiplicá-la pelo seu respectivo peso, que pode ser visto na Tabela 1 abaixo.
Tabela 1 - Complexidade dos tipos de função
Fonte: José Carlos Macoratti (2004)
Tipo de Complexidade Complexidade Complexidade

Função baixa média alta
Entrada Externa 3 4 6
Saída Externa 4 5 7
Arquivo Lógico
Interno 7 10 15
Arquivo Lógico
Externo 5 7 10
Consulta
Externa 3 4 6
Aplica-se a seguinte equação e obtém-se o resultado 17.
Equação 01:
30
Onde:
TP = Tipo de Função
C = Complexidade
O próximo passo é fazer o cálculo do FAPF. Este fator consiste em atribuições de 0 a
5 na influência das características observadas na Tabela 2, e no somatório dessas
atribuições.
Tabela 2 - Características que influenciam na complexidade
Fonte: José Carlos Macoratti (2004)
Característica Descrição
1 Comunicação de dados
2 Processamento distribuído
3 Performance
4 Utilização do equipamento
5 Volume de transações
6 Entrada de dados on-line
7 Eficiência do usuário final
8 Atualização on-line
9 Processamento complexo
10 Reutilização de código
11 Facilidades de implantação
12 Facilidade Operacional
13 Múltiplos Locais
14 Facilidades a mudanças
O valor do FAPF para este exemplo será de 1,1, pode-se observar o cálculo na
equação abaixo.
Equação 2:
Onde:
I = Influência
Por fim, para obter os PFA deve-se multiplicar os dois valores obtidos anteriormente.
O resultado será de 18,7 Pontos por Função.
Equação 3:
31
Onde:
PFNA = Pontos por Função Não Ajustados
FAPF = Fator de Ajuste de Pontos por Função
Com este valor em mãos, é possível estimar o esforço, prazo e custo desse sistema de
cadastro. Macoratti (2004) considerou as seguintes infomações:
1- Produtividade média de 10 horas / PFA.
2- Média de jornada de trabalho é de 6 horas.
3- Valor de uma hora de trabalho é de R$ 25,00.
Aplicando as equações que seguem:
Equação 4:
Equação 5:
Equação 6:
O resultado é de 187 horas necessárias de esforço para conclusão desse sistema; com
prazo de 7,8 dias para término e um custo de R$ 4.675,00 reais.
Com este exemplo é possível observar a aplicação dessa métrica e como utilizá-la para
obter as estimativas desejadas.
Segundo instituição Brazilian Function Point Users Group (1999) a técnica de
estimativa de Pontos por Função apresenta como vantagens o fato de ser feita baseada no
ponto de vista do usuário, ser uma métrica de fácil aprendizagem e aplicação. Ela também
acompanha e avalia a produtividade e qualidade dos projetos de software, possibilita a
coleta de dados para obter diversos indicadores de acompanhamento do desenvolvimento
e pode ser aplicada em diversas fases, inclusive na manutenção do sistema.

32
Algumas desvantagens dessa técnica é que ela precisa de um acompanhamento
constante para gerar os indicadores, a sua aplicação nas diversas fases do
desenvolvimento demanda esforço na contagem dos pontos por função de cada fase e
requer um meio eficiente de armazenamento dos dados obtidos (BRAZILIAN FUNCTION
POINT USERS GROUP, 1999).
2.4.3 COCOMO (I e II)
Proposto por Barry Boehm em 1981, o COCOMO é um modelo desenvolvido para
estimar o esforço de desenvolvimento, custos, prazo e tamanho de equipe.
Devido à incapacidade de lidar com ciclos de vida iterativos, uma nova versão
chamada COCOMO II foi lançada no ano de 2000. Este modelo aplicado ao RUP
(Rational Unified Process – Processo Unificado da Rational) estima o esforço, prazo e
custos para as fases de Elaboração e Construção (AGUIAR, 2010).
Para utilizar esse modelo é preciso calibrá-lo de acordo com o ambiente alvo a qual
ele se destina. Esta calibração pode ser feita de acordo com dados históricos disponíveis
sobre o ambiente e, na ausência de tais dados, devem ser escolhidos projetos equivalentes
para fazer a calibração. Os dados históricos selecionados devem ser validados antes do
uso, alimentando-os no software escolhido, calculando os coeficientes equilibrados.
De acordo com Aguiar (2010) o modelo COCOMO II é calibrado com dados de 161
projetos diferentes e encontra-se em constante desenvolvimento pela USC (Universityof
Southern California – Universidade do Sul da Califórnia).
A estimativa deste modelo é feita com base nas linhas de código do projeto, caso a
organização que esteja estimando não utilize o método de LOC também é possível estimar
de acordo com a técnica de FPA (AGUIAR, 2010).

33
Dessa forma, percebe-se que COCOMO é utilizado sempre em conjunto com alguma
outra técnica de estimativa, a fim de chegar à quantidade de linhas de código do
desenvolvimento.
Uma das vantagens de utilizar COCOMO é que este método é fundamentado em
fórmula matemática e, além disso, também pode ser aplicado nas diversas fases do
desenvolvimento de um software (BRAZILIAN FUNCTION POINT USERS GROUP, 1999).
Como desvantagens, essa técnica apresenta o fato de ser dependente da tecnologia que
será utilizada, não fornece indicadores e também depende de experiências anteriores para
ser aplicada (BRAZILIAN FUNCTION POINT USERS GROUP, 1999).
2.4.4 UCP (Use Case Points – Pontos de Caso de Uso)
Esta técnica de estimativa foi proposta por Gustav Karner em 1993, e será utilizada no
desenvolvimento desta pesquisa, pois a finalidade deste projeto é o desenvolvimento de
um ambiente de estimativa de software baseado em pontos de caso de uso.
Conforme Ribu (2001) a técnica de UCP trata da estimativa por Pontos de Caso de
Uso, ou seja, mede o custo do projeto baseado no diagrama de caso de uso da UML.
Como este diagrama é um dos primeiros que pode ser feito, baseado nos requisitos do
sistema, torna-se possível estimar o valor com a máxima antecedência, possibilitando
assim um retorno de custos o quanto antes ao cliente.
Segundo Karner (1993) esta técnica tem como base o modelo de FPA, porém foram
feitos alguns aperfeiçoamentos, como o Fator Ambiental, considerado de extrema
importância durante o desenvolvimento de um projeto.
O Fator Ambiental é aquele que influencia diretamente na equipe de desenvolvimento,
determinando o quanto esta equipe conhece a linguagem que será utilizada, sua
experiência e motivação para o desenvolvimento do projeto. Ele é responsável por
especificar como será o ambiente e condições de trabalho para desenvolver o sistema.

34
Para utilizar essa métrica, é necessário seguir seis fases que levam aos UCP, estas
fases serão descritas a seguir.
2.4.4.1 1ª Fase – Cálculo do UAW (Unadjusted Actor Weight – Peso Não Ajustado
por Ator)
Para realização deste cálculo, é necessário saber a quantidade de cada tipo de ator
existentes no projeto e qual a sua complexidade. Deve-se considerar os dados da Tabela 3
para definir a complexidade. Após obter essas informações, é preciso multiplicar a
quantidade de atores de cada tipo pelo seu respectivo peso. Dessa forma, obtém-se o peso
não ajustado por ator. O UAW é o somatório de todas as multiplicações encontradas
anteriormente.
Tabela 3 - Peso e complexidade do ator
Fonte: Gustav Karner (1993)
Complexidade Definição Peso
Simples Um ator é simples se representar 1

outro sistema como uma API.
Médio Um ator é médio se: 2
1. Faz uma interação com outro sistema
através de um protocolo
2. Há interação humana com uma linha de
terminal.
Complexo Um ator é complexo se ele interage 3

através de uma interface gráfica.
Na equação que segue pode-se observar o cálculo do UAW.
Equação 7:
Onde:
A = Quantidade de ator dos tipos simples, médio ou complexo
P = Peso da respectiva complexidade a qual aquele ator pertence

35
2.4.4.2 2ª Fase – Cálculo do UUCW (Unadjusted Use Case Weight – Peso Não
Ajustado por Caso de Uso)
Para o cálculo desta fase, é preciso saber a quantidade de cada tipo de caso de uso
existente no projeto e a sua complexidade, que pode ser definida consultando as
informações da Tabela 4.
Tabela 4 - Peso e complexidade do caso de uso
Complexidade Definição Peso
Simples Um caso de uso é considerado simples quando tem até 3 transações2, 5

incluindo os cursos alternativos.
Deve-se ser capaz de realizar o caso de uso com menos de cinco
objetos de análise
Médio Um caso de uso é médio, se tiver de 3 a 7 transações, incluindo 10
cursos alternativos.
Deve-se ser capaz de realizar o caso de uso com 5 a 10 objetos de
análise.
Complexo Um caso de uso é complexo se tiver mais do que sete transações, 15
incluindo cursos alternativos. O caso de uso deve, no mínimo, precisar
de 10 objetos de análise.
Assim como na primeira fase, após ter obtido esses dados deve-se fazer a
multiplicação de cada tipo de caso de uso pelo seu respectivo peso, e por fim somar os
resultados encontrados anteriormente. Dessa forma, obtém-se o total de Peso Não
Ajustados por Caso de Uso (UUCW) (KARNER, 1993).
O cálculo citado pode ser observado na equação abaixo.
Equação 8:
Onde:
UC = Quantidade de casos de uso dos tipos simples, médio ou complexo
2
Transação neste caso refere-se aos cursos principal e alternativo documentados no caso de uso em questão
(KARNER, 1993).
36
P = Peso da respectiva complexidade a qual aquele caso de uso pertence
2.4.4.3 3ª Fase – Cálculo dos Pontos Não Ajustados por Caso de Uso (UUCP)
Após ter feito os cálculos descritos anteriormente é possível obter o valor do UUCP,
somando os dois valores encontrados anteriormente:
Equação 9:
Assim, obtém-se o valor de Pontos de Caso de Uso Não Ajustados (KARNER, 1993).
Logo em seguida deve-se calcular os fatores técnicos e de ambiente.
2.4.4.4 4ª Fase – Cálculo do TCF (Technical Complexity Factor - Fator de
Complexidade Técnica)
Segundo Karner (1993) o TCF mede o quão difícil de desenvolver será o sistema em
questão. É quase o mesmo da análise de FPA, mas foram adicionados e removidos alguns
fatores.
Na tabela 5 é possível observar quais são esses fatores e seus respectivos pesos.
Tabela 5 - Fatores que contribuem para a complexidade
Fator Fator que contribui para a complexidade Peso

F1 Sistemas distribuídos 2
F2 Objetivos de desempenho da aplicação, em 1
qualquer resposta ou transferência.
F3 Eficiência do usuário final (online) 1
F4 Processamento interno complexo 1
F5 Reutilização, o código deve ser capaz de 1
reuso em outras aplicações.
F6 Facilidade de instalação 0,5
F7 Facilidade de operação, usabilidade. 0,5
F8 Portabilidade 2
F9 Mutabilidade 1
F10 Simultaneidade 1
F11 Características especiais de segurança 1
F12 Oferece acesso direto para terceiros 1
F13 Treinamento especial a usuários 1
37
Para cada fator listado na Tabela 5, deve ser atribuído de 0 a 5 a influência que ele tem
no sistema que será desenvolvido. Após essa atribuição, multiplica-se o valor atribuído pelo
peso do fator e assim obtém-se o valor respectivo do fator em questão.
Logo em seguida, deve-se somar todos os valores obtidos nas multiplicações feitas
anteriormente, atribuindo a este somatório o nome de TFactor.
Equação 10:
Onde:
I = Influência definida para aquele fator
P = Peso do respectivo fator
O cálculo do TCF utilizará o valor obtido nos cálculos anteriores:
Equação 11:
Portanto, agora obtém-se o valor do fator de complexidade técnica do sistema
(KARNER, 1993).
2.4.4.5 5ª Fase – Cálculo do EF (Environmental Factor – Fator Ambiental)
O próximo passo é fazer o cálculo do fator ambiental. Este fator mede o quão eficiente
é o projeto que será desenvolvido (KARNER, 1993).
Para medí-lo, deve-se proceder da mesma maneira que o cálculo do fator anterior.
Na tabela a seguir é possível verificar quais são os fatores ambientais e seus
respectivos pesos.
38
Tabela 6 - Fatores que contribuem para a eficiência
Fator Fator que contribui para a eficiência Peso

F1 Familiaridade com algum processo formal 1,5
F2 Trabalhadores meio período -1
F3 Capacidade de analista 0,5
F4 Experiência em desenvolvimento de aplicações 0,5
F5 Experiência em programação Orientada a Objeto 1
F6 Motivação 1
F7 Dificuldade da linguagem de programação -1
F8 Requisitos estáveis 2
Do mesmo modo que o fator técnico deve ser feita uma atribuição de 0 a 5
representando a influência do fator no sistema que será desenvolvido. Após a atribuição dos
valores, deve ser feita a multiplicação do peso do fator por sua influência, e por fim os
resultados das multiplicações devem ser somados. A este somatório atribui-se o nome de
EFactor.
Equação 12:
Onde:
I = Influência definida para aquele fator
P = Peso do respectivo fator
O cálculo do EF é feito com base no valor encontrado anteriormente dessa forma:
Equação 13:
Assim, obtém-se o valor do fator ambiental do desenvolvimento (KARNER, 1993).
2.4.4.6 6ª Fase – Cálculo dos Pontos de Caso de Uso (UCP)
Finalmente, o cálculo do UCP é feito multiplicando todos os valores encontrados
anteriormente:
Equação 14:
39
É importante ressaltar que este método de estimativa não retorna o custo de um
desenvolvimento e sim quanto tempo, em horas, levará para que o projeto seja concluído.
Com base nos pontos por caso de uso, é possível calcular o custo se você tiver em mãos o
preço da hora de serviço, pois por recomendação, deve-se utilizar a média de 20 horas por
ponto de caso de uso.
Dessa forma, ao multiplicar os pontos de caso de uso por 20 obtém-se o valor total de
horas que serão trabalhadas. Após isso, basta multiplicar o preço da hora pela quantidade de
horas que se obtém o preço estimado do desenvolvimento do projeto (KARNER, 1993).
2.5 Trabalhos Relacionados
A seguir serão apresentados trabalhos cujo tema está relacionado ao desta pesquisa.
Wenderlich (2008) desenvolveu uma ferramenta para apoio no processo de estimativa
de software, e além disso, com esta ferramenta também é possível controlar os projetos
através de consultas e emissão de relatórios. Na ferramenta desenvolvida por esse autor, são
abordadas as técnicas de estimativa de pontos por caso de uso, pontos por função e
COCOMO, ela permite recalibragem dos parâmetros das métricas se for necessário ou uma
revisão técnica das mesmas.
Em 2009, Caio Silva fez uma pesquisa propondo um novo modelo de estimativa de
software para sistemas computadorizados. Como consequência deste trabalho, foi
desenvolvida uma ferramenta que estima por pontos de caso de uso que permite ajuste dos
fatores técnicos e ambientais de acordo com o meio em que o projeto está envolvido.
Em 2001, Ribu desenvolveu uma pesquisa em que se aplicava o método de estimativa
por pontos de caso de uso, mesmo que os casos de uso não estejam escritos por extenso. O
trabalho dele também mostra como os casos de uso podem ser dimensionados em outras
formas alternativas e a melhor forma de escrevê-los para fins de cálculo.

Capítulo
41
3 Metodologia
Esta pesquisa tem como objetivo a concepção de um ambiente para auxiliar na estimativa
de esforços empreendidos no desenvolvimento de um software.
Ter um ambiente que faça essa estimativa é importante devido ao fato de tornar possível
utilizar os dados históricos para futuras consultas de estimativas e armazenar versões
anteriores de um projeto para comparar e acompanhar como está o desenvolvimento da
organização. Adicionalmente, possibilita-se o reuso das estimativas que já foram feitas
quando há necessidade de fazer alterações nas mesmas, devido a mudanças que surgiram no
sistema que será desenvolvido.
Para alcançar este objetivo, tornou-se necessário definir um plano estratégico
representado na Figura 4.
As próximas seções irão detalhar as etapas demonstradas nesta figura.
Figura 4 - Etapas do desenvolvimento desta pesquisa
Fonte: Elaboração do autor.
3.1 Definição da Técnica de Estimativa
Para o desenvolvimento deste ambiente, será utilizada a técnica de estimativa por UCP
por se tratar de uma técnica de fácil aplicação, que não requer muito tempo de treinamento ou
42
experiência prática. Além disto, justifica-se sua escolha, pois o diagrama e a documentação de
casos de uso de um sistema pode ser feito logo após a conclusão da fase de análise de
requisitos do projeto.
Sendo assim, utilizando essa técnica, é possível estimar os esforços de um projeto e
retornar informações ao cliente sobre os custos e número total de horas, de forma mais rápida.
3.2 Definição das Tecnologias Utilizadas para Desenvolvimento do
Ambiente
Para atingir ao objetivo desta pesquisa e, consequentemente, desenvolver um ambiente
que calcule a estimativa do esforço empreendido, em horas, no desenvolvimento de um
software, faz-se necessário utilizar tecnologias de linguagem de programação e banco de
dados. A partir dessas tecnologias, é possível desenvolver e manipular os dados de um
sistema.
A linguagem de programação a ser utilizada para o desenvolvimento do ambiente
proposto é o PHP (PHP HyperText Preprocessor – PHP Pré-processador de Hipertexto). Esta
linguagem é do tipo scripting, ou seja, que pode ser executada do interior de outras
linguagens de programação, como HTML, JavaScript, ou de programas, pois não se restringe
a esses ambientes. Esta linguagem é amplamente utilizada e, especialmente, interessante para
desenvolvimento web, já que pode ser incorporada ao código de uma página HTML (Hyper
Text Markup Language – Linguagem de Marcação de Hipertexto).
Uma de suas principais vantagens se deve ao fato de possibilitar um desenvolvimento
ágil e dinâmico, devido à facilidade em utilizar o código entre as marcações HTML. É uma
linguagem simples para iniciantes, mas que oferece vários recursos para um programador
profissional (MANUAL PHP, 2013). Essa linguagem pode ser executada em vários sistemas
operacionais, como Linux.

43
Conforme Jonathan Hackenhaar, Renata Zanella e Tatiana Cardoso (2010) “o PHP
possui licença gratuita, está sempre atualizado com correções de falhas, adição de novos
recursos, exige e consome menos recursos de hardware do servidor, documentação, controle
e reportamento de erros”.
Além disto, optou-se também pelo PHP para desenvolver o ambiente proposto, pois a
autora desta pesquisa possui experiência de trabalho com essa linguagem, de modo que esse
conhecimento auxiliou na construção do ambiente para estimativa.
Para armazenar os parâmetros dos cálculos de estimativa e os seus respectivos
resultados, faz-se necessário o uso de um banco de dados. Como Sistema de Gerenciamento
de Banco de Dados (SGBD) será utilizado o MySql, por se tratar de um SGBD open source e
relacional. Os bancos relacionais organizam seus dados em relações, também chamadas de
tabelas, o que facilita sua estruturação e manipulação (DATE,2003).
A fim de trabalhar com os bancos relacionais, será utilizada a linguagem padrão para
manipulação, a linguagem SQL (Structured Query Language – Linguagem de Consulta
Estruturada).
Segundo Date (2003), essa linguagem subdivide-se em três componentes:
1. LDD (Linguagem de Definição de Dados) – Utilizada para
estruturação do banco de dados;
2. LCD (Linguagem de Controle de Dados) – Utilizada para controlar
os mecanismos de segurança do banco e manter a integridade dos
dados; e
3. LMD (Linguagem de Manipulação de Dados) – Utilizada para
manipular os dados do banco. Realiza operações de leitura e escrita.
Neste trabalho de pesquisa, serão utilizados os três componentes do SQL, citados
anteriormente.
44
Como ferramenta para o desenvolvimento desse ambiente será utilizada o Scriptcase,
que é um gerador de aplicações em linguagem PHP e que se conecta com vários bancos de
dados como Oracle, Firebird e inclusive o Mysql que é o banco utilizado nessa pesquisa. Ele
funciona na rede local ou na internet e gera aplicações que rodam em qualquer servidor PHP.
Escolheu-se utilizar essa ferramenta devido à familiaridade que a autora desse trabalho possui
com ela, de modo que esse conhecimento auxiliou na concepção do ambiente de estimativa.
Apoiados pelo uso das tecnologias citadas, busca-se atingir ao objetivo final deste
trabalho com a concepção do ambiente para estimar o desenvolvimento de software.
3.3 Concepção do Ambiente para Estimar o Desenvolvimento de Software
Esta seção apresenta a concepção do ambiente para estimar software, abordando como
será o fluxo de informações nesse ambiente, o desenvolvimento do banco de dados a ser
utilizado por ele e também apresenta o desenvolvimento propriamente dito deste ambiente.
3.3.1 Fluxo de informações no ambiente para estimativa
Esta seção aborda o tratamento das informações no ambiente para estimativa.
Na Figura 5, pode-se observar o fluxo de atividades a fim de obter as horas estimadas
do desenvolvimento.
45
Figura 5 – Fluxo de atividades para obter as horas estimadas
O usuário representado informa os dados descritos nas setas. Essas informações
fornecidas representam a complexidade dos atores e dos casos de uso e os pesos dos fatores
técnicos e ambientais.
Esses dados serão processados no ambiente de estimativa, onde serão também
realizados os cálculos a fim de obter o total de pontos por casos de uso do sistema, de acordo
com a seção 2.4.4 do Capítulo 2.
Após isso, o ambiente fará a conversão dos pontos encontrados para horas necessárias
de desenvolvimento, tempo em meses e o custo aproximado deste desenvolvimento.
Também é possível consultar feedbacks de projetos feitos anteriormente, a fim de
aperfeiçoar os dados inseridos no ambiente para que ele possa fornecer um dado mais preciso
a cada vez que for utilizado.
Dessa forma, obtém-se o total de horas estimadas no desenvolvimento do software.
3.3.2 Banco de Dados Relacional para Suportar o Ambiente
A fim de se desenvolver o ambiente para estimativa desta pesquisa e garantir um bom
desempenho a ele, foi desenvolvido o Modelo Entidade Relacionamento (MER), onde foram
detalhadas as entidades desse projeto e os relacionamentos existentes entre elas. Desenvolveu-
se também o Modelo Relacional a partir do MER.
O banco de dados foi elaborado de acordo com as seguintes considerações:
1. O projeto pode ter mais de uma versão de estimativa e a versão, por sua vez,
armazena todos os dados referentes a essa estimativa como: quantidade de
casos de uso e atores existentes no projeto para cada complexidade e o nível de
influência dos fatores técnico e ambiental;

46
2. Também pode-se armazenar informações sobre o andamento do projeto,
tratando sobre mudanças de requisito, mudança na influência dos fatores, entre
outros casos que podem implicar no sucesso ou não desse projeto. Com estas
informações, é possível obter feedbacks, que podem ser usados na elaboração
de novas estimativas de projetos, auxiliando na definição dos dados que serão
inseridos no ambiente para uso no cálculo, proporcionando que a experiência
obtida em projetos anteriores seja aproveitada. Desta forma, a estimativa será
feita de forma mais precisa pela empresa, possibilitando que haja sempre uma
melhora gradativa, além de servir como base de consulta para acompanhar
essas melhoras.
Na Figura 6, pode-se observar o MER do banco de dados desenvolvido para uso nesse
ambiente.
Figura 6 – MER do ambiente de estimativa

47
A Figura 7 mostra o modelo relacional deste banco, produzido a partir do MER da
Figura 6.
Figura 7 – Modelo Relacional do ambiente de estimativa

48
Com a elaboração destes dois passos, é possível proporcionar ao ambiente de
estimativa todo o suporte necessário para seu bom funcionamento. Além disto, com a
utilização de um banco de dados para armazenar todos os passos para o cálculo da estimativa
de esforços por pontos de caso de uso, pode-se utilizar estas informações como referência
para futuros projetos, inclusive auxiliando nas decisões quanto aos fatores ambientais e
técnicos.
O modelo físico do banco de dados desenvolvido e utilizado pelo ambiente foi criado
a partir do Modelo Relacional apresentado anteriormente e seu código encontra-se no
APÊNDICE A desta pesquisa.
3.3.3 Ambiente de Estimativa por Pontos de Caso de Uso
Nessa seção, será apresentada a concepção do ambiente para realizar a estimativa por
pontos de caso de uso, de acordo com o apresentado na Figura 4.
As próximas subseções apresentam cada fase do processo de estimativa por pontos de
caso de uso, descritas no Capítulo 2 deste trabalho e apresentam as funcionalidades do
ambiente que correspondem à respectiva fase reportada na seção.
3.3.3.1 Estimativa por Pontos de Caso de Uso – Cadastro de Projetos
Para iniciar uma estimativa sobre um projeto de desenvolvimento, é necessário fazer o
cadastro desse projeto.
Foi desenvolvida uma interface independente do cálculo de estimativa para que esse
cadastro seja feito.
Na Figura 8 apresentada a seguir, pode-se observar essa interface.

49
Figura 8 – Interface para cadastro de projetos

3.3.3.2 Estimativa por Pontos de Caso de Uso – Fase 1
Após o projeto ter sido cadastrado, é possível iniciar o cálculo da estimativa. Para isso,
deve-se selecionar a opção “Nova Estimativa” no menu do ambiente.
A fase 1 dessa técnica de estimativa trata do cálculo do peso não ajustado por ator
(UAW).
Este cálculo define quantos atores dos tipos simples, médio e complexo existem no
sistema e seus respectivos pesos.
Com isto, o usuário deverá informar quantos atores de cada tipo há em seu projeto.
Após isso, o ambiente fará o cálculo, multiplicando a quantidade de atores de cada tipo pelo
seu peso e, finalmente, irá somar os valores encontrados, conforme descrito no Capítulo 2
deste trabalho.
Ao fazer a multiplicação obtem-se o valor do UAW.
Para auxiliar o usuário na classificação dos atores, é apresentado um texto com a
descrição de cada tipo, servindo como base para a identificação de cada ator. Isto considera as
questões de usabilidade no ambiente proposto.
A Figura 9 mostra a IHM (Interface Humano Máquina) do ambiente proposto que
corresponde à fase 1 desse processo de estimativa.

50
Figura 9 – Interface peso e complexidade de ator
Na fase 2, faz-se o cálculo do peso não ajustado por casos de uso (UUCW).
O cálculo desta fase baseia-se em quantos casos de uso de complexidade simples,
média ou complexa existem no sistema e seus respectivos pesos.
Assim como na fase anterior, o usuário deverá informar a quantidade de cada tipo de
complexidade de caso de uso existente em seu projeto.
Após inserir essas informações, o ambiente fará a multiplicação da quantidade de cada
tipo de caso de uso pelo seu respectivo peso e somará os resultados obtidos, conforme
descrito no Capítulo 2. Dessa forma, obtem-se o UUCW.
Na Figura 10 é apresentado um protótipo da IHM do ambiente proposto que
corresponde à fase 2.
51
Figura 10 – Interface peso e complexidade de caso de uso
O ambiente não armazena detalhadamente cada ator e caso de uso, pois este não é o
foco dessa pesquisa. Além disso, tais informações não influenciam no cálculo da estimativa.
Ele trata somente da quantidade de cada tipo existente no projeto, porém essas informações
podem ser adicionadas em trabalhos futuros.
Nesta fase, faz-se o cálculo dos pontos não ajustados por caso de uso (UUCP).
Para obter esse valor, devem-se somar os dois resultados obtidos nas fases anteriores:
UAW + UUCW.
Essa fase não apresenta uma IHM referente, pois este cálculo será feito pelo próprio
ambiente. Dessa forma, torna-se desnecessária qualquer interferência do usuário para que ela
seja realizada com sucesso.

52
A fase 4 determina o valor do Fator de Complexidade Técnica (TCF). Este fator mede
a dificuldade encontrada para desenvolver o sistema em questão.
Para cada fator técnico, deve-se atribuir a influência que varia de 0 a 5, lembrando que
os fatores técnicos são aqueles que medem as dificuldades que serão encontradas para
desenvolver o sistema em questão.
Cada fator possui seu respectivo peso e ao atribuir o valor da sua influência no sistema
que será desenvolvido, faz-se a multiplicação desses valores e, por fim, somam-se todos os
resultados de multiplicações encontrados. Desse modo, obtem-se o TFactor. Após isso, se
aplica a fórmula descrita no Capítulo 2 deste trabalho e chega-se ao fator de complexidade do
sistema. As Figuras 11, 12 e 13 ilustram a IHM do ambiente que corresponde à fase 4 deste
processo.
Figura 11 – Interface de fator de complexidade técnica – Sistemas distribuídos,
Desempenho e Eficiência

53
Figura 12 - Interface de fator de complexidade técnica – Processamento, Reutilização,
Facilidade de instalação e operação, Portabilidade e Mutabilidade

54
Figura 13 - Interface de fator de complexidade técnica – Simultaneidade, Segurança, Acesso
de terceiros e Treinamento especial
Todas as descrições de relevâncias dos fatores técnicos utilizadas neste trabalho foram
feitas com base nos trabalhos de Karner (1993) e Silva (2009).
Na fase 5 é calculado o valor do fator ambiental (EF). Este fator mede a eficiência do
sistema que será desenvolvido.
Para realizar este cálculo deve-se atribuir a influência de 0 a 5, para cada fator listado.
Do mesmo modo que no caso anterior, após fazer a atribuição das influências, o
sistema fará a multiplicação pelo respectivo peso do fator e somará os resultados obtidos.
55
Após isso, aplica-se a fórmula descrita no Capítulo 2 deste trabalho e obtém-se o valor do
fator ambiental do desenvolvimento.
Nas Figuras 14 e 15 apresenta-se a IHM do ambiente que se refere a esta fase.
Figura 14 – Interface do fator ambiental

56
Figura 15 – Interface do fator ambiental - Continuação
Assim como no fator técnico, todas as descrições de relevâncias dos fatores ambientais
utilizadas neste trabalho foram feitas com base nos trabalhos de Karner (1993) e Silva (2009).
Por fim, na fase 6 faz-se o cálculo dos pontos por caso de uso (UCP). Este cálculo é
feito multiplicando os resultados obtidos nas fases de número 3, 4 e 5, e é feito
automaticamente pelo ambiente, por isso esta fase não apresenta uma IHM referente.
3.3.3.8 Estimativa por Pontos de Caso de Uso – Consulta de estimativas
O ambiente que foi desenvolvido permite que o usuário consulte as estimativas que
foram feitas para o projeto.
Na IHM de consulta, apresentam-se todas as informações que foram passadas para que
se obtivesse o resultado da estimativa.
É possível observar dados do projeto, da versão, a definição das complexidades de
atores e casos de uso, como também a definição dos fatores técnicos e ambientais.
A partir dessa IHM, se desejar, o usuário pode iniciar uma nova estimativa.
57
Nas Figuras 16 e 17 abaixo, pode-se observar a interface de consulta de estimativas.
Figura 16 – Interface de consulta de estimativas

58
Figura 17 – Interface de consulta de estimativas - Continuação

3.3.3.9 Estimativa por Pontos de Caso de Uso – Relatar Feedback
Pensando em reportar casos de sucesso ou insucesso em um projeto, foi desenvolvida
uma interface de feedback onde é possível ao usuário relatar casos que possam ter
influenciado no andamento do projeto.
Este relato deve ser feito ao término do projeto, pois assim é possível definir com mais
detalhes o que pode ter influenciado de uma forma positiva ou negativa, como por exemplo,
se houve mudança nos requisitos. Após a definição dos feebacks ter sido feita, o projeto terá
seu status atualizado para “finalizado”.
Esses dados de feedback poderão ser consultados a qualquer instante, de modo que
sirvam como justificativa para explicar os motivos de um projeto ter sofrido alterações em seu
custo e/ou prazo de entrega. Porém, não será possível redefinir a influência dos feedbacks,
após eles já terem sido estabelecidos.
Os casos de feedbacks utilizados neste ambiente foram feitos com base na pesquisa
CHAOS do THE STANDISH GROUP REPORTER de 1995.
O Standish Group classificou os projetos da seguinte maneira:

59
· Tipo 1, ou o sucesso do projeto: O projeto é concluído dentro do prazo e do
orçamento, com todos os recursos e funções.
· Tipo 2, ou projeto arriscado: O projeto está concluído e operacional, mas acima do
orçamento, da estimativa de tempo, e oferece menos recursos e funções que originalmente
especificado.
· Tipo 3, ou projeto prejudicado: O projeto é cancelado em algum momento durante
o ciclo de desenvolvimento.
Segundo a pesquisa CHAOS feita pelo Standish Group, as causas de insucesso em um
projeto são:
Reinício do projeto;
Deslizes de custos;
Deslizes de tempo; e
Insuficiência das aplicações ao fornecer as características esperadas.
O aspecto mais importante da pesquisa é descobrir por que os projetos falham. Para
fazer isso, o Standish Group pesquisou gerentes executivos de TI e suas opiniões sobre os
porquês de projetos bem sucedidos.
As três principais razões para que um projeto seja bem-sucedido são: o envolvimento
do usuário, apoio executivo à gestão e uma declaração clara dos requisitos (THE STADISH
GROUP REPORTER, 1995).
Existem outros critérios de sucesso, mas com estes três elementos no local, as chances
de sucesso são muito maiores. Sem eles, a chance de falha aumenta.
Na tabela abaixo, estão as respostas obtidas dos gerentes para os casos em que houve
sucesso do projeto.
60
Tabela 7 – Fatores de Sucesso do Projeto
Fonte: Standish Group
Fatores de Sucesso do Projeto % das respostas

Envolvimento do usuário 15,90%
Apoio à Gestão Executiva 13,90%
Declaração clara de Requisitos 13,00%
Planejamento adequado 9,60%
Expectativas realistas 8,20%
Marcos do projeto menores 7,70%
Equipe competente 7,20%
Conhecer bem o que será feito. Entender. 5,30%
Visão clara e objetiva 2,90%
Funcionários focados 2,40%
Outros 13,90%
Os participantes da pesquisa também foram questionados sobre os fatores que tornam
projetos arriscados. O resultado da pesquisa encontra-se apresentado na Tabela 8.
Tabela 8 – Fatores de Projeto Desafiado
Fatores de Projeto Desafiado % das respostas

Falta de envolvimento do usuário 12,80%
Requisitos e especificações incompletos 12,30%
Alteração Requisitos e Especificações 11,80%
Falta de apoio executivo 7,50%
Necessidades do usuário não foram
supridas 7,00%
Falta de Recursos 6,40%
Expectativas irrealistas 5,90%
Objetivos pouco claros 5,30%
Prazos irrealistas 4,30%
Nova Tecnologia 3,70%
Outros 23,00%
Finalmente, apresentam-se na Tabela 9 as opiniões sobre o porquê de projetos
prejudicados e, finalmente, cancelados.

61
Tabela 9 – Fatores de Projeto Prejudicado
Fatores de Projeto prejudicado % das respostas

Requisitos incompletos 13,10%
Falta de envolvimento do usuário 12,40%
Falta de Recursos 10,60%
Expectativas irrealistas 9,90%
Falta de apoio executivo 9,30%
Alteração de Requisitos e Especificações 8,70%
Falta de Planejamento 8,10%
Falta de Gerenciamento 6,20%
Falta de conhecimento sobre a tecnologia
que será utilizada 4,30%
Outros 9,90%
Desta forma, utilizou-se nesta etapa os fatores apresentados nas Tabelas 7, 8 e 9.
Com isto, o usuário deverá inicialmente escolher para qual projeto ele fará a definição
e, após isso, indicar a influência de 0 a 5, de acordo com a tabela abaixo, para cada fator.
Tabela 10 – Influência dos feedbacks
Grau de Influência Descrição

0 Não influenciou
1 Pouco influenciou
2 Influenciou moderadamente
3 Influenciou
Influenciou de forma
4 significativa
5 Influenciou completamente
A Figura 19 mostra a interface correspondente ao relato de feedbacks do projeto
baseado na pesquisa do Standish Group (1995).
Nessa IHM, também é possível informar o tempo que foi realmente necessário para
terminar o projeto. Dessa forma, fica disponível para consulta o tempo aproximado gerado
pelo processo de estimativa e o tempo real utilizado no desenvolvimento.

62
Figura 18 – Interface para relato de feedbacks

63
3.4 Aplicação do Ambiente em um Experimento
Após o término do desenvolvimento, o ambiente foi aplicado em um estudo de caso,
visando validar seu funcionamento quanto à estimativa de esforços.
Para essa validação, foi escolhido o projeto “Medida Certa” trabalhado em sala de aula
durante o segundo semestre de 2013, em que foi desenvolvido um aplicativo, na plataforma
Android, para acompanhamento de pesos, medidas e controle alimentar.
Este projeto foi desenvolvido pela turma do curso Tecnólogo em Sistemas para
Internet do 6º semestre de 2013 e envolveu as disciplinas de Desenvolvimento em
Dispositivos Móveis, Sistemas Distribuídos para WEB, Qualidade e Testes de Software e
Desenvolvimento de Projetos WEB.
Na finalidade de utilizar este projeto multidisciplinar como experimento, foram
definidas as complexidades de atores, complexidades de casos de uso, fatores técnicos e
ambientais, com base no documento de casos de uso desse projeto, que pode ser consultado
no TestLink acessando o endereço 200.133.203.29/tsi pelo navegador de internet e
informando na autenticação o login “medida” e a senha “certa”.
Na Tabela 11, observam-se as complexidades de atores.
Tabela 11 – Complexidade atores – Medida Certa
Quantidade de atores Complexidade

0 Simples
1 Médio
1 Complexo
Ao aplicar a fórmula para cálculo da complexidade de atores, conforme observado no
Capítulo 2, obtém-se o UAW igual a 5, conforme pode ser visto na Figura 19, já utilizando o
ambiente proposto.
64
Figura 19 – Definição de ator – Projeto Medida Certa
Na tabela 12, podem-se observar as complexidades dos casos de uso.
Do mesmo modo, ao aplicar a fórmula descrita no Capítulo 2, obtém-se como UUCW
o valor de 200, conforme mostrado na Figura 20.
Tabela 12 – Complexidade de casos de uso – Medida Certa
Quantidade de casos de uso Complexidade

18 Simples
11 Médio
0 Complexo
65
Figura 20 – Definição de casos de uso – Projeto Medida Certa
Ao fazer a soma desses dois valores, resulta no UUCP igual a 205.
Nas próximas tabelas, é possível observar os valores de influência atribuídos para os
fatores técnicos e ambientais para esse projeto multidisciplinar.

66
Tabela 13 – Definição do fator técnico – Medida Certa
Fator Técnico Influência

4 - Processamento distribuído e transferência de dados
Fator 1 – Sistemas Distribuídos online em ambas as direções
Fator 2 - Objetivos de desempenho
da aplicação, em qualquer resposta 0 - Nenhuma exigência especial de performance foi
ou transferência fixada pelo usuário
Fator 3 - Eficiência do usuário 1 - Aplicação não apresenta nenhum tipo de interface
final complexa
Fator 4 - Processamento interno
complexo 1 - Não apresenta nenhum dos itens
Fator 5 – Reutilização 1 - Não apresenta código reutilizável
0 - Nenhuma consideração especial foi feita pelo usuário
e nenhum procedimento especial foi requerido para a
Fator 6 - Facilidade de instalação instalação
0 - Nenhuma consideração especial sobre facilidade
Fator 7 - Facilidade de operação, operacional, além dos procedimentos normais de
usabilidade backups, foi feita pelo usuário
0 - Nenhuma solicitação do usuário para considerar a
necessidade de instalar a aplicação em mais de uma
Fator 8 – Portabilidade plataforma
0 - Nenhum requisito especial do usuário para projetar a
Fator 9 – Mutabilidade aplicação, visando minimizar ou facilitar mudanças
Fator 10 – Simultaneidade 1 - Não é esperado acesso simultâneo
2 - Necessidade de controle de segurança foi levada em
consideração no projeto do sistema e a aplicação foi
Fator 11 - Características especiais projetada para ser acessada somente por usuários
de segurança autorizados
1 - Existem restrições operacionais, mas são menos
Fator 12 - Oferece acesso direto restritivas do que aplicações típicas. Nenhum esforço
para terceiros extra é necessário para suplantar as restrições
Fator 13 - Treinamento especial a 0 - Nenhuma solicitação do usuário para considerar a
usuários necessidade de treinamento especial
Aplicando as fórmulas descritas no Capítulo 2, o valor do Tfactor encontrado para este
projeto é de 15 e o valor final do TCF é 0,75.

67
Tabela 14 – Definição fator ambiental – Medida Certa
Fator Técnico Influência

Fator 1 - Familiaridade com algum processo formal 2 - Um ou mais membros utilizou
o processo uma ou poucas vezes
Fator 2 - Trabalhadores meio período 4 - Todos os membros da equipe
trabalham em período parcial
Fator 3 - Capacidade de análise 2 - Possui experiência de poucos
projetos
Fator 4 - Experiência em desenvolvimento de aplicações 2 - Todos os membros tem mais
de 1,5 anos de experiência
Fator 5 - Experiência em programação Orientada a Objeto 3 - A maioria da equipe tem mais
de 2 anos de experiência
Fator 6 – Motivação 2 - Equipe motivada
Fator 7 - Dificuldade de linguagem de programação 4 - Poucos membros da equipe
tem alguma experiência (1 ano).
Os outros são novatos
Fator 8 - Requisitos estáveis 3 - Estabilidade global. Poucas
mudanças são necessárias
Novamente, aplicando as fórmulas descritas no Capítulo 2, obtém-se o valor de
Efactor igual a 8 e o valor do EF igual a 1,16.
Como último passo dessa técnica, deve-se multiplicar todos os valores obtidos
anteriormente (UUCP * TCF * EF). Assim, como valor de UCP obtém-se 178.
É importante lembrar que o total de horas de trabalho por mês foi elaborado da
seguinte forma: cada pessoa da turma trabalhou no projeto em média 8 horas por semana e ao
multiplicar esse valor por 4,5 semanas obtém-se o valor de 36 horas por mês para cada
integrante. Como o projeto contou com a participação de 15 pessoas aproximadamente, o
valor total de horas mensais de serviço foi de 540 horas. Já quanto ao valor da hora de
trabalho, foi utilizado um número fictício, portanto o custo exibido abaixo não implica no
custo real do projeto.
Na Figura 21 a seguir, observam-se os resultados obtidos, lembrando que os valores
são aproximados e não exatos.

68
Figura 21 – Estimativa finalizada do projeto Medida Certa
Na Figura 21, é possível ver a quantidade de pontos de casos de uso obtidos com essa
estimativa. O valor das horas por pontos de caso de uso é constante e igual a 20, pois por
definição da literatura de Karner (1993), gasta-se em média vinte horas para desenvolver cada
ponto de caso de uso calculado.
O total de horas para conclusão do projeto é feito através da multiplicação dos valores
de total de pontos de casos de uso e horas gastas para cada um. Dessa forma, obtém-se o valor
total de horas de desenvolvimento necessárias para realização e término desse projeto, ou
seja, 3738 horas já com uma margem de erro de 5%.
O dado de margem de erro tem grande importância no processo de estimativa, pois ele
garante que além do tempo estimado seja acrescido mais alguns dias de desenvolvimento,
fornecendo assim uma margem de segurança para os desenvolvedores, caso ocorra algum
problema durante o processo de desenvolvimento, ou também para complementar o sistema
que já foi finalizado, verificando erros, aumentando sua confiabilidade, facilidade de uso,
69
entre outros casos que podem ser abordados e tratados quando se há mais tempo para
trabalhar em um projeto. O valor fornecido nesse campo será aplicado no valor total de horas
necessárias para desenvolvimento.
Também nessa IHM deve-se informar o total de horas mensais que serão dedicadas à
realização desse projeto. Com esse valor é possível chegar à quantidade aproximada de meses
que levará para concluir esse projeto, quando faz-se a divisão do total de horas pela
quantidade de horas mensais.
Há ainda mais um campo em que atribui-se o valor da hora de trabalho dos
participantes do projeto. Assim ao realizar a multiplicação do total de horas por esse valor, é
possível obter o custo aproximado desse projeto.

Capítulo
70
4 Resultados
Após o desenvolvimento do ambiente e visando analisar os resultados obtidos com sua
aplicação em um estudo de caso, foram feitas três estimativas para o projeto Medida Certa,
porém com a margem de erro variando, conforme será explicado a seguir.
A margem de erro influencia de forma direta no total de horas necessárias no
desenvolvimento. Seu valor é aplicado a esse total atribuindo de forma percentual mais horas
para realização do software em questão. Dessa forma, quanto maior a margem de erro mais
horas terá o desenvolvimento dos pontos de casos de uso e, consequentemente, mais tempo
haverá para concluir o projeto. Indicar esse dado é importante, pois ele garante mais tempo ao
desenvolvimento, e esse tempo pode ser usado para aperfeiçoar o sistema e garantir que ele se
torne mais confiável, com melhor usabilidade e até mesmo trabalhar em funções para
melhorá-las e que não puderam ser tão aprofundadas no tempo normal de desenvolvimento.
Em um primeiro momento a estimativa foi feita com margem de erro igual a 0%, isso
proporcionou que o desenvolvimento desse projeto fosse avaliado de modo que ocorresse
completamente dentro do esperado, mesmo que este dado seja aproximado e sem um espaço
de tempo que poderia servir como folga para desenvolver o sistema com mais segurança e
confiabilidade. Os outros dados observados como horas de trabalho mensal e valor da hora de
trabalho foram mantidos os mesmos citados no Capítulo 3 dessa pesquisa. Ao aplicar o
percentual zero na margem de erro, obteve-se o resultado apresentado na Figura 22.
Como é possível observar, caso essa margem de erro fosse o caso real encontrado no
desenvolvimento desse projeto, ele duraria aproximadamente sete meses e teria um total de
horas necessárias no valor de 3560 horas.

71
Figura 22 – Versão número 1 da Estimativa
Após essa estimativa, foi atribuído à margem de erro o valor de 5% e o resultado pode
ser visto na Figura 23.
Figura 23 – Versão número 2 da estimativa

72
Aplicando essa margem de erro, o valor total de horas necessárias aumentou para 3738
obtendo como diferença para a estimativa anterior o valor de 178 horas. Apesar de haver tal
aumento, não houve alterações no tempo aproximado de desenvolvimento desse projeto. O
valor atribuído à margem de erro a essa versão da estimativa foi baseado no caso real do
desenvolvimento.
Por fim, a última aplicação apresentada por esta pesquisa tem como margem de erro o
valor de 15%. Esse valor foi adotado por Silva (2009) em sua tese de mestrado, e foi
considerado como a margem de erro mais segura para ser utilizada durante o processo de
estimativa, por conter o prazo estimado com 0%, possibilitar tempo a mais de
desenvolvimento e permitir contornar situações que não foram previstas, por isso este valor
também foi adotado nessa pesquisa.
Na Figura 24 pode-se observar o resultado obtido quando aplicada a margem de erro
de 15% para desenvolvimento do projeto Medida Certa.
Figura 24 – Versão número 3 da estimativa

73
É possível ver que o tempo estimado para desenvolvimento aumentou em um mês se
comparado aos casos anteriores, subindo para oito meses necessários e o total de horas
aumentou em 534 horas.
Esse valor proporcionaria que o desenvolvimento tivesse certo tempo para tratar
possíveis problemas que poderiam aparecer ou elaborar um software mais seguro e confiável,
devido à folga obtida no total de horas. Dentre os possíveis problemas que poderiam ser
resolvidos com esse tempo estão os casos de mudança de requisitos - que inclusive aconteceu
no projeto Medida Certa. Com esse tempo extra, seria possível fazer o levantamento de
requisitos de forma mais segura e melhor estudada para que não acontecessem tais mudanças,
que impactaram principalmente o início da fase de desenvolvimento do sistema, acarretando
problemas com o cumprimento de prazos do projeto.
É importante ressaltar que até o término dessa pesquisa, o projeto multidisciplinar não
havia sido finalizado, portanto não é possível indicar ao certo quanto tempo realmente foi
necessário para o seu desenvolvimento. Entretanto, ao levar em consideração o ritmo de
desenvolvimento em que ele se encontra e se a equipe mantiver os padrões de horas
trabalhadas mensalmente, o desenvolvimento deverá ser finalizado em aproximadamente 2
meses e meio. Esse valor foi levantado com cada grupo, ao ser analisado a quantidade restante
de casos de uso a ser desenvolvidos. Na Figura 25 pode-se ver o andamento do
desenvolvimento do projeto Medida Certa e as tendências futuras de seu desenvolvimento e
conclusão, a partir do mês de Novembro.

74
Figura 25 – Desenvolvimento dos pontos de casos de uso
Observando esse gráfico, pode-se concluir que a estimativa feita pelo ambiente,
utilizando a margem de erro de 5% como caso real, em que se obteve como tempo necessário
para conclusão do projeto o período de 7 meses chegou bem próximo ao tempo de
desenvolvimento mostrado na Figura 25, que é, de 6 meses e meio.
Para finalizar, foi levantada a influência dos feedbacks pela equipe do projeto
multidisciplinar, liderada pela gerente do mesmo, e os dados atribuídos podem ser vistos na
tabela a seguir.
75
Tabela 15 – Feedback Projeto Medida Certa
Fonte: Elaboração por Gerente de Projeto
Feedback Influência
Declaração clara de requisitos 5 - Influenciou completamente
Marcos do projeto menores 4 - Influenciou de forma significativa

Equipe competente 4 - Influenciou de forma significativa
Conhecer bem o que será feito. Entender 5 - Influenciou completamente
Visão clara e objetiva 5 - Influenciou completamente
Funcionários focados 4 - Influenciou de forma significativa
Prazos irrealistas 3 - Influenciou
Nova tecnologia 3 - Influenciou
Falta de planejamento 4 - Influenciou de forma significativa
Falta de gerenciamento 3 - Influenciou
Falta de conhecimento, sobre a tecnologia que será utilizada 3 - Influenciou
Como é possível observar não foram preenchidos todos os feedbacks disponíveis,
apenas os que influenciaram esse projeto e para cada um deles foi atribuído seu respectivo
grau de influência.
Observando essa tabela, pode-se identificar que a declaração clara de requisitos foi o
que mais influenciou no andamento desse projeto, mas também que os prazos irrealistas, a
falta de planejamento e por se tratar de uma tecnologia nova tiveram um grau de influência
considerável, contribuindo para problemas como o cumprimento de prazos estipulados no
início do projeto, causando atrasos na entrega. Por outro lado, a equipe competente e focada
serviu para equilibrar o desfalque causado pelos outros casos de feedbacks.
É importante ressaltar que por se tratar de um projeto acadêmico, os alunos
trabalharam mais no final para cumprir as metas estabelecidas de cada disciplina, e como a
estimativa foi feita com menos horas e não foi possível estimar essas horas no final, isso
significa que o projeto atrasou.

76
Além disso, o tempo de desenvolvimento engloba as fases de teste, correção e
validação, o que apresenta um atraso ainda maior no projeto Medida Certa. Dessa forma,
pode-se observar o quão importante é utilizar uma margem de erro de 15% como segurança,
pois se adotado esse valor o projeto não teria sofrido tanto atraso assim.
77
5 Conclusões
Este trabalho teve como objetivo geral o desenvolvimento de um ambiente para
estimar os esforços empreendidos no desenvolvimento de software.
Para alcançar esse objetivo, fez-se o levantamento bibliográfico, abordando temas
relacionados ao desta pesquisa, como Engenharia de Software, Gerência de Projetos e
Linguagem UML.
Os conceitos de estimativa de software foram apresentados, bem como as técnicas
deste processo mais conhecidas e utilizadas. Também foram apresentados alguns trabalhos
que estão diretamente relacionados a este, ressaltando a importância deste tema tanto na
comunidade acadêmica quanto empresarial.
Para desenvolver o ambiente proposto por este trabalho, foram definidas algumas
etapas como a escolha da linguagem de programação, definição da técnica de estimativa a ser
utilizada, concepção do banco de dados que dará suporte a esse ambiente e, por fim, o
desenvolvimento do ambiente.
Para validar e apresentar seu desempenho, o ambiente foi aplicado em um estudo de
caso do projeto Medida Certa, desenvolvido por alunos do Instituto Federal de Educação,
Ciência e Tecnologia do campus de São João da Boa Vista, e pôde-se comprovar que a
estimativa feita por ele se aproximou muito do caso real observado no projeto estudado.
Dessa forma, o ambiente se demonstrou eficaz não só para auxiliar gerentes em suas tomadas
de decisões, como também para mostrar aos clientes os recursos que serão empreendidos no
desenvolvimento do software proposto, assim como o tempo e o custo necessários para
desenvolvê-lo.
78
Utilizando esse ambiente para fazer a estimativa de esforços pode-se garantir que a
organização faça investimentos cabíveis e dentro do estimado, além de proporcionar prazos
mais realistas para a entrega de um projeto.
Sendo assim, atingiu o seu objetivo com sucesso, pois todas as etapas propostas foram
alcançadas de forma satisfatória, e como resultado esse trabalho apresenta uma ferramenta
para estimar esforços no desenvolvimento de sistemas utilizando a técnica de pontos de casos
de uso.
Para conceber este ambiente foram encontradas algumas dificuldades logo no início da
fase de desenvolvimento. A ferramenta Scriptcase utilizada não possui licença gratuita, e sim
uma versão disponível para download no site que funciona durante 20 dias, porém não
publica o projeto que foi desenvolvido. Dessa forma, a autora dessa pesquisa entrou em
contato com a empresa responsável pelo Scriptcase, a Netmake, e conversou sobre uma
possível licença para concluir essa pesquisa. A Netmake por sua vez, atendeu prontamente ao
pedido e liberou duas licenças válidas por 30 dias, totalizando 60 dias para desenvolvimento,
correção de erros e publicação do ambiente de estimativa. Assim, foi possível concluir o
desenvolvimento desse projeto.
5.1 Sugestões e recomendações para trabalhos futuros
A autora dessa pesquisa deixa como sugestão para trabalhos futuros uma adaptação do
ambiente para serem gravados os nomes dos atores e dos casos de uso, para ter uma
documentação do projeto no ambiente. Atualmente, o ambiente armazena apenas a quantidade
de cada tipo de ator e casos de uso existentes. Também como sugestão pode-se fazer o
controle de acessos de acordo com o perfil dos usuários, realizando cadastros e login no
sistema.
79
Como recomendação, pode-se fazer com que o ambiente permita que uma estimativa
já feita possa ser alterada, desde que seja uma alteração pequena, pois refazer o processo
inteiro implica em uma nova versão de estimativa.

80
Referências
AGUIAR, M. Estimando os projetos com COCOMO II. Rio de Janeiro, Project
Management Institute, 2010.
ALBRECHT, A. J., Measuring Application Development Productivity, Joint Share Guide

IBM Conference on Application Development Regards, vol., no., p. 83, 92, Outubro 1979.
ARNOLD M., PEDROSS P., Software size measurement and productivity rating in a
large-scale software development department, Software Engineering,
1998.Proceedingsofthe 1998 International Conference, vol., no., pp.490, 493, 19-25 Abril
1998.
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I.UML: Guia do Usuário. 2 ed. Rio de
Janeiro: Elsevier, 2005. Disponível em:
<http://books.google.com.br/books?id=ddWqxcDKGF8C&printsec=frontcover&hl=pt-
PT#v=onepage&q&f=false>. Acesso em: 05 de junho de 2013.
BRAZILIAN FUNCTION POINT USERS GROUP. Sistemática de Métricas, Qualidade e

Produtividade. 1999. Disponível em:
<http://www.bfpug.com.br/Artigos/sistematica_metricas_simoes.htm>.Acesso em: 22 de
maio de 2013.
DATE, C. J. Introdução a sistemas de banco de dados. 8 ed. Rio de Janeiro: Elsevier, 2003.
Disponível em:
<http://books.google.com.br/books?id=xBeO9LSlK7UC&printsec=frontcover&hl=pt-
PT#v=onepage&q&f=false>. Acesso em: 06 de junho de 2013.
FALBO A. R., Engenharia de Software: Notas de Aula, Espírito Santo, Universidade

Federal do Espírito Santo, 2005.
GUDWIN, R. Introdução à linguagem UML. Universidade Estadual de Campinas, 2010.
HACKENHAAR, J.; ZANELLA, R.; CARDOSO, T. Um comparativo entre PHP e JSP:

definindo a melhor aplicação para o desenvolvimento de projetos web. Rio Grande do
Sul, Faculdade Cenecista de Osório, 2010.
KARNER, G. Resource estimation for objector projects. Stockholm: Objective Systems SF

AB., 1993.
LÓPEZ, P. A. P., COCOMO II – Um modelo para estimativa de custos de Gerência de

Projetos. Rio Grande do Sul, Universidade do Vale do Rio dos Sinos, 2005.
MACORATTI. Quanto vale o software que você produz?. 2004. Disponível em:
<http://www.macoratti.net/eng_qvs.htm>. Acesso em: 13 de maio de 2013.
MANUAL PHP. What is PHP?. 2013. Disponível em: <http://br2.php.net/manual/en/intro-

whatis.php>.Acesso em: 20 de maio de 2013.
81
OBJECT MANAGEMENT GROUP. OMG Unified Modeling Language. Object

Management Group, Ago. 2011.
PRESSMAN, Roger S. Engenharia de Software.7.ed. São Paulo: McGraw Hill, 2011.
PROJECT MANAGEMENT BODY OF KNOWLEDGE. A guide to the Project

management body of knowledge. Pennsylvania: Newtown Square, 2000.
PROJECT MANAGEMENT INSTITUTE. Gerenciamento de Projetos. 2010. Disponível

em: <http://www.pmisp.org.br/institucional/pmi/gerenciamento-de-projetos>.Acesso em: 12
de maio de 2013.
PROJECT MANAGEMENT INSTITUTE. O que é gerenciamento de projetos?. 2013.

Disponível em: <http://brasil.pmi.org/brazil/AboutUS/WhatIsProjectManagement.aspx>.
Acesso em: 12 de maio de 2013.
RIBU, K. Estimatingobject-oriented software projectswith use cases. 2001. 147 f.

Dissertação (Mestrado em Informática) – Universityof Oslo, Oslo.
SILVA, C. Um modelo de estimativa de esforços para o desenvolvimento de sistemas

computadorizados. 2009. 139 f. Dissertação (Mestrado em Informática) – Instituto
Tecnológico de Aeronáutica, São José dos Campos.
THE STANDISH GROUP REPORT. Chaos.The Standish Group, 1995.
WENDERLICH, A. Ferramenta de cálculo de estimativas de software. Universidade

Regional de Blumenau: Centro de Ciências Exatas e Naturais, 2008.
XIMENES, S. Minidicionário Ediouro da Língua Portuguesa. 8.ed. Rio de Janeiro:

Ediouro. 1999.
82
APÊNDICE A – Modelo físico do banco de dados
create database if not exists estimativa;

use estimativa;
CREATE TABLE tipo_fator (
descricao varchar(100),
codTipoFator char(1) not null,
PRIMARY KEY (codTipoFator)

);
CREATE TABLE fator (
codFator varchar(4) not null,

peso float(5,2),
codTipoFator char(1),
primary key (codFator),

FOREIGN KEY(codTipoFator) REFERENCES tipo_fator (codTipoFator)
);
CREATE TABLE relevancia (
codFatorRelevancia int not null auto_increment,

codRelevancia int,
codFator varchar(4),
primary key (codFatorRelevancia),

FOREIGN KEY(codFator) REFERENCES fator (codFator)
);
CREATE TABLE caso_uso (

83
codCasoUso int not null auto_increment,

qtdSimples int,
qtdMedio int,
qtdComplexo int,
status char(1),
primary key (codCasoUso)

);
CREATE TABLE ator (
codAtor int not null auto_increment,

qtdMedio int,
qtdComplexo int,
qtdSimples int,
status char(1),
primary key (codAtor)

);
CREATE TABLE projeto (
codProjeto int not null auto_increment,

nome varchar(50),
gerente varchar(30),
status char(1),
dataInicio date,
dataFim date,
tempoEstimado varchar(5),
tempoReal varchar(5),
primary key (codProjeto)

);
CREATE TABLE versao (

84
codVersao int not null auto_increment,

numVersao int,
data date,
tempoEstimado varchar(5),
custo float(11,2),
horaTrabalho varchar(5),
margemErro varchar(3),
codCasoUso int,
codAtor int,
codProjeto int,
status char(1),
primary key (codVersao),

FOREIGN KEY(codCasoUso) REFERENCES caso_uso (codCasoUso),
FOREIGN KEY(codAtor) REFERENCES ator (codAtor),
FOREIGN KEY(codProjeto) REFERENCES projeto (codProjeto)
);
CREATE TABLE versao_relevancia(
codFatorRelevancia int,
codVersao int,
status char(1),
FOREIGN KEY(codFatorRelevancia) REFERENCES relevancia

(codFatorRelevancia),
FOREIGN KEY(codVersao) REFERENCES versao (codVersao)
);
CREATE TABLE projeto_feedback (

id_proj_feed int not null auto_increment,
influencia char(1),
codFeedback int,
codProjeto int,
85
primary key(id_proj_feed),
FOREIGN KEY(codProjeto) REFERENCES projeto (codProjeto)
);
insert into tipo_fator (codTipoFator, descricao)

values ('A', 'Ambiental');
insert into tipo_fator (codTipoFator, descricao)

values ('T', 'Técnico');
insert into fator (codFator, descricao, peso, codTipoFator)

values ('FA01', 'Familiaridade com algum processo formal', 1.5,
'A');

values ('FA02', 'Trabalhadores meio período', -1, 'A');

values ('FA03', 'Capacidade de análise', 0.5, 'A');

values ('FA04', 'Experiência em desenvolvimento de aplicações', 0.5,
'A');

values ('FA05', 'Experiência em programação Orientada a Objeto', 1,
'A');

values ('FA06', 'Motivação', 1, 'A');

values ('FA07', 'Dificuldade da linguagem de programação', -1, 'A');

values ('FA08', 'Requisitos estáveis', 2, 'A');
86

values ('FT01', 'Sistemas distribuídos', 2, 'T');

values ('FT02', 'Objetivos de desempenho da aplicação, em qualquer
resposta ou transferência', 1, 'T');

values ('FT03', 'Eficiência do usuário final', 1, 'T');

values ('FT04', 'Processamento interno complexo', 1, 'T');

values ('FT05', 'Reutilização. O código deve ser capaz de reuso em
outras aplicações', 1, 'T');

values ('FT06', 'Facilidade de instalação', 0.5, 'T');

values ('FT07', 'Facilidade de operação, usabilidade', 0.5, 'T');

values ('FT08', 'Portabilidade', 2, 'T');

values ('FT09', 'Mutabilidade', 1, 'T');

values ('FT10', 'Simultaneidade', 1, 'T');

values ('FT11', 'Características especiais de segurança', 1, 'T');

values ('FT12', 'Oferece acesso direto para terceiros', 1, 'T');
87

values ('FT13', 'Treinamento especial a usuários', 2, 'T');
insert into relevancia (codRelevancia, codFator)

values (0, 'FT01');
values (1, 'FT01');
values (2, 'FT01');
values (3, 'FT01');
values (4, 'FT01');
values (5, 'FT01');

values (0, 'FT02');
values (1, 'FT02');
values (2, 'FT02');
values (3, 'FT02');
values (4, 'FT02');
values (5, 'FT02');

values (0, 'FT03');
values (1, 'FT03');
values (2, 'FT03');
88
values (3, 'FT03');

values (4, 'FT03');
values (5, 'FT03');

values (0, 'FT04');
values (1, 'FT04');
values (2, 'FT04');
values (3, 'FT04');
values (4, 'FT04');
values (5, 'FT04');

values (0, 'FT05');
values (1, 'FT05');
values (2, 'FT05');
values (3, 'FT05');
values (4, 'FT05');
values (5, 'FT05');

values (0, 'FT06');
values (1, 'FT06');
89
values (2, 'FT06');

values (3, 'FT06');
values (4, 'FT06');
values (5, 'FT06');

values (0, 'FT07');
values (1, 'FT07');
values (2, 'FT07');
values (3, 'FT07');
values (4, 'FT07');
values (5, 'FT07');

values (0, 'FT08');
values (1, 'FT08');
values (2, 'FT08');
values (3, 'FT08');
values (4, 'FT08');
values (5, 'FT08');

values (0, 'FT09');
90
values (1, 'FT09');

values (2, 'FT09');
values (3, 'FT09');
values (4, 'FT09');
values (5, 'FT09');

values (0, 'FT10');
values (1, 'FT10');
values (2, 'FT10');
values (3, 'FT10');
values (4, 'FT10');
values (5, 'FT10');

values (0, 'FT11');
values (1, 'FT11');
values (2, 'FT11');
values (3, 'FT11');
values (4, 'FT11');

values (0, 'FT12');
91
values (1, 'FT12');

values (2, 'FT12');
values (3, 'FT12');
values (4, 'FT12');
values (5, 'FT12');

values (0, 'FT13');
values (1, 'FT13');
values (2, 'FT13');
values (3, 'FT13');
values (4, 'FT13');

values (0, 'FA01');
values (1, 'FA01');
values (2, 'FA01');
values (3, 'FA01');
values (4, 'FA01');

values (0, 'FA02');
values (1, 'FA02');
92
values (2, 'FA02');

values (3, 'FA02');
values (4, 'FA02');

values (0, 'FA03');
values (1, 'FA03');
values (2, 'FA03');
values (3, 'FA03');
values (4, 'FA03');

values (0, 'FA04');
values (1, 'FA04');
values (2, 'FA04');
values (3, 'FA04');
values (4, 'FA04');

values (0, 'FA05');
values (1, 'FA05');
values (2, 'FA05');
values (3, 'FA05');
93
values (4, 'FA05');

values (0, 'FA06');
values (1, 'FA06');
values (2, 'FA06');
values (3, 'FA06');
values (4, 'FA06');

values (0, 'FA07');
values (1, 'FA07');
values (2, 'FA07');
values (3, 'FA07');
values (4, 'FA07');

values (0, 'FA08');
values (1, 'FA08');
values (2, 'FA08');
values (3, 'FA08');
values (4, 'FA08');
94
update relevancia set descricao = 'A aplicação não auxilia na

transferência de dados ou processamento entre as CPUs da instalação'
where codFator = 'FT01' and codRelevancia = 0;
update relevancia set descricao = 'A aplicação prepara dados para o
usuário final processar em outra CPU da instalação. Por exemplo,
planilhas eletrônicas ou gerenciadores de banco de dados de PC'
update relevancia set descricao = 'Os dados são transferidos e
processados em uma outra CPU da instalação (mas NÃO para
processamento pelo usuário final como visto no item 1)' where
codFator = 'FT01' and codRelevancia = 2;
update relevancia set descricao = 'Processamento distribuído e
transferência de dados on-line apenas em uma direção' where codFator
= 'FT01' and codRelevancia = 3;
update relevancia set descricao = 'Processamento distribuído e
transferência de dados on-line em ambas direções' where codFator =
'FT01' and codRelevancia = 4;
update relevancia set descricao = 'As funções de processamento são
executadas dinamicamente na CPU mais apropriada' where codFator =
update relevancia set descricao = 'Nenhuma exigência especial de
performance foi fixada pelo usuário' where codFator = 'FT02' and
codRelevancia = 0;
update relevancia set descricao = 'Requisitos de performance foram
estabelecidos e revisados, mas nenhuma ação especial foi necessária'
update relevancia set descricao = 'O tempo de resposta é crítico
durante as horas de pico. Nenhuma consideração especial para
utilização de CPU foi requerida' where codFator = 'FT02' and
codRelevancia = 2;
update relevancia set descricao = 'O tempo de resposta é crítico
durante todo o horário de utilização. Não foi necessário nenhum
procedimento especial para utilização de CPU' where codFator =
update relevancia set descricao = 'Os requisitos de performance
estabelecidos pelo usuário são rigorosos e requer tarefas de análise
95
de performance na fase de análise e projeto da aplicação' where

update relevancia set descricao = 'Além do descrito no item 4,
ferramentas de análise de performance foram usadas nas fases de
projeto, desenvolvimento e/ou implementação' where codFator = 'FT02'
and codRelevancia = 5;
update relevancia set descricao = 'Aplicação não apresenta nenhum
tipo de interface complexa' where codFator = 'FT03' and
codRelevancia = 0;
update relevancia set descricao = 'Aplicação apresenta um baixo grau
de complexidade' where codFator = 'FT03' and codRelevancia = 1;
update relevancia set descricao = 'Aplicação necessita de um
treinamento avançado' where codFator = 'FT03' and codRelevancia = 2;
update relevancia set descricao = 'Aplicação é considerada complexa,
mas não há nenhum requisito do usuário relacionado à eficiência'
update relevancia set descricao = 'Aplicação é considerada complexa,
e possui requisitos estabelecidos para eficiência do usuário' where
update relevancia set descricao = 'Aplicação extremamente complexa,
e o requisitos estabelecidos são rigorosos o suficiente para que
seja necessário o uso de ferramentas e processos especiais' where
update relevancia set descricao = 'Não apresenta nenhum dos itens'
update relevancia set descricao = 'Apresenta um dos itens' where
update relevancia set descricao = 'Apresenta dois dos itens' where
update relevancia set descricao = 'Apresenta três dos itens' where
update relevancia set descricao = 'Apresenta quatro dos itens' where
update relevancia set descricao = 'Apresenta todos os itens' where
update relevancia set descricao = 'Não apresenta código
reutilizável' where codFator = 'FT05' and codRelevancia = 0;
96
update relevancia set descricao = 'O código reutilizável é usado

somente dentro da própria aplicação' where codFator = 'FT05' and
codRelevancia = 1;
update relevancia set descricao = 'Menos de 10% da aplicação foi
feita, levando-se em conta a sua utilização por outras aplicações'
update relevancia set descricao = '10% ou mais da aplicação foi
feita, levando-se em conta a sua utilização por outras aplicações'
update relevancia set descricao = 'A aplicação foi projetada e
documentada para facilitar a reutilização de código e a aplicação é
customizada pelo usuário a nível do código fonte' where codFator =
update relevancia set descricao = 'A aplicação foi projetada para
facilitar a reutilização de código e a aplicação é customizada para
uso através de parâmetros que podem ser atualizados pelo usuário'
update relevancia set descricao = 'Nenhuma consideração especial foi
feita pelo usuário e nenhum procedimento especial foi requerido para
a instalação' where codFator = 'FT06' and codRelevancia = 0;
update relevancia set descricao = 'Nenhuma consideração especial foi
feita pelo usuário, mas um procedimento especial foi requerido para
a instalação' where codFator = 'FT06' and codRelevancia = 1;
update relevancia set descricao = 'Requisitos de instalação foram
fixados pelo usuário' where codFator = 'FT06' and codRelevancia = 2;
update relevancia set descricao = 'Requisitos de instalação foram
fixados pelo usuário e roteiros de instalação foram preparados e
testados' where codFator = 'FT06' and codRelevancia = 3;
ferramentas automatizadas de instalação foram preparadas e testadas'
ferramentas automatizadas de instalação foram preparadas e testadas'
update relevancia set descricao = 'Nenhuma consideração especial
sobre facilidade operacional, além dos procedimentos normais de
97
backups, foi feita pelo usuário' where codFator = 'FT07' and

codRelevancia = 0;
update relevancia set descricao = 'Procedimentos eficientes de
inicialização, backups e recuperação foram preparados, mas a
intervenção do operador é necessária' where codFator = 'FT07' and
codRelevancia = 1;
update relevancia set descricao = 'Procedimentos eficientes de
inicialização, backups e recuperação foram preparados, mas nenhuma
intervenção do operador é necessária' where codFator = 'FT07' and
codRelevancia = 2;
update relevancia set descricao = 'A aplicação minimiza a operação
de montagem de fitas magnéticas' where codFator = 'FT07' and
codRelevancia = 3;
update relevancia set descricao = 'A aplicação minimiza a
necessidade de manuseio de formulários ' where codFator = 'FT07' and
codRelevancia = 4;
update relevancia set descricao = 'A aplicação foi projetada para
não precisar de intervenção do operador no seu funcionamento normal.
Apenas a inicialização e parada do sistema ficam a cargo do
operador' where codFator = 'FT07' and codRelevancia = 5;
update relevancia set descricao = 'Nenhuma solicitação do usuário
para considerar a necessidade de instalar a aplicação em mais de uma
plataforma' where codFator = 'FT08' and codRelevancia = 0;
update relevancia set descricao = 'Necessidade de instalação em
múltiplas plataformas foi levada em consideração, projeto foi
desenvolvido para operar somente em ambientes idênticos de hardware
e software' where codFator = 'FT08' and codRelevancia = 1;
desenvolvido para operar somente em ambientes similares de hardware
e software' where codFator = 'FT08' and codRelevancia = 2;
desenvolvido para operar inclusive em plataformas diferentes' where
update relevancia set descricao = 'Um plano de documentação e
manutenção foi elaborado e testado para suportar a aplicação em
98
múltiplas plataformas e a aplicação atende aos itens 1 e 2' where

update relevancia set descricao = 'Um plano de documentação e
manutenção foi elaborado e testado para suportar a aplicação em
múltiplas plataformas e a aplicação atende ao item 3' where codFator
= 'FT08' and codRelevancia = 5;
update relevancia set descricao = 'Nenhum requisito especial do
usuário para projetar a aplicação, visando minimizar ou facilitar
mudanças' where codFator = 'FT09' and codRelevancia = 0;
update relevancia set descricao = 'É fornecido recurso da
consulta/relatórios flexíveis capaz de manipular solicitações
simples de consulta' where codFator = 'FT09' and codRelevancia = 1;
consulta/relatórios flexíveis capaz de manipular solicitações de
consulta de média complexidade' where codFator = 'FT09' and
codRelevancia = 2;
consulta/relatórios flexíveis capaz de manipular solicitações
complexas de consulta' where codFator = 'FT09' and codRelevancia =
3;
update relevancia set descricao = 'Dados de controle são atualizadas
pelo usuário através de processos on-line e interativos, mas as
alterações só são efetivadas no próximo dia útil' where codFator =
update relevancia set descricao = 'Dados de controle são mantidos em
tabelas que podem ser atualizadas pelo usuário' where codFator =
update relevancia set descricao = 'Não é esperado acesso simultâneo'
update relevancia set descricao = 'São esperados acessos simultâneos
esporadicamente' where codFator = 'FT10' and codRelevancia = 1;
update relevancia set descricao = 'Acessos simultâneos são
esperados' where codFator = 'FT10' and codRelevancia = 2;
update relevancia set descricao = 'Acessos simultâneos são esperados
diariamente' where codFator = 'FT10' and codRelevancia = 3;
update relevancia set descricao = 'Muitos acessos simultâneos foram
fixados pelo usuário para a aplicação, o que força a execução de
99
tarefas de análise de performance na fase de projeto da aplicação'

update relevancia set descricao = 'Requer o uso de ferramentas
controle de acesso nas fases do projeto desenvolvimento e/ou
implantação, além das considerações acima' where codFator = 'FT10'
para considerar a necessidade de controle de segurança da aplicação'
update relevancia set descricao = 'Necessidade de controle de
segurança foi levada em consideração no projeto do sistema' where
update relevancia set descricao = 'Necessidade de controle de
segurança foi levada em consideração no projeto do sistema e a
aplicação foi projetada para ser acessada somente por usuários
autorizados' where codFator = 'FT11' and codRelevancia = 2;
update relevancia set descricao = 'Um plano de segurança foi
elaborado e testado para suportar o controle de acesso a aplicação'
update relevancia set descricao = 'Um plano de segurança foi
elaborado e testado para suportar o controle de acesso a aplicação e
a auditoria' where codFator = 'FT11' and codRelevancia = 4;
update relevancia set descricao = 'Não há restrições operacionais
implícitas ou explícitas' where codFator = 'FT12' and codRelevancia
= 0;
update relevancia set descricao = 'Existem restrições operacionais,
mas são menos restritivas do que aplicações típicas. Nenhum esforço
extra é necessário para suplantar as restrições' where codFator =
update relevancia set descricao = 'Algumas considerações sobre tempo
e segurança são necessárias' where codFator = 'FT12' and
codRelevancia = 2;
update relevancia set descricao = 'Necessidades especiais de
processador para uma parte específica da aplicação' where codFator =
update relevancia set descricao = 'Restrições operacionais
estabelecidas requerem atenção especial a nível de processador
100
central ou processador dedicado para executar a aplicação' where

update relevancia set descricao = 'Além do descrito acima, existem
sobrecargas a nível das unidades de processamento (CPUs)
distribuídas da instalação' where codFator = 'FT12' and
codRelevancia = 5;
para considerar a necessidade de treinamento especial' where
update relevancia set descricao = 'Necessidade de treinamento
especial foi levada em consideração no projeto do sistema' where
update relevancia set descricao = 'Necessidade de treinamento foi
levada em consideração no projeto do sistema e a aplicação foi
projetada para ser acessada com facilidade pelos usuários' where
update relevancia set descricao = 'Necessidade de treinamento
especial foi levado em consideração no projeto do sistema e a
aplicação foi projetada para ser utilizada por usuários de diversos
níveis' where codFator = 'FT13' and codRelevancia = 3;
update relevancia set descricao = 'Um plano de treinamento foi
elaborado e testado para facilitar o uso da aplicação' where
update relevancia set descricao = 'A equipe não é familiarizada com
processo de desenvolvimento de software' where codFator = 'FA01' and
codRelevancia = 0;
update relevancia set descricao = 'A equipe tem conhecimento teórico
do processo de desenvolvimento do software' where codFator = 'FA01'
update relevancia set descricao = 'Um ou mais membros utilizou o
processo uma ou poucas vezes' where codFator = 'FA01' and
codRelevancia = 2;
update relevancia set descricao = 'Pelo menos a metade dos membros
da equipe tem experiência no uso do processo em diferentes projetos'
where codFator = 'FA01' and codRelevancia = 3;
101
update relevancia set descricao = 'Toda a equipe tem experiência no

uso do processo em vários projetos diferentes' where codFator =
'FA01' and codRelevancia = 4;
update relevancia set descricao = 'Não tem membro com dedicação
parcial' where codFator = 'FA02' and codRelevancia = 0;
update relevancia set descricao = 'Poucos membros (20%) trabalham em
período parcial' where codFator = 'FA02' and codRelevancia = 1;
update relevancia set descricao = '35% dos membros trabalham em
período parcial' where codFator = 'FA02' and codRelevancia = 2;
update relevancia set descricao = 'A metade dos membros da equipe
trabalham em período parcial' where codFator = 'FA02' and
codRelevancia = 3;
update relevancia set descricao = 'Todos os membros da equipe
trabalham em período parcial' where codFator = 'FA02' and
codRelevancia = 4;
update relevancia set descricao = 'O líder do projeto é novato'
update relevancia set descricao = 'Possui experiência de apenas um
projeto' where codFator = 'FA03' and codRelevancia = 1;
update relevancia set descricao = 'Possui experiência de poucos
projetos' where codFator = 'FA03' and codRelevancia = 2;
update relevancia set descricao = 'Pelo menos 2 anos de experiência
com vários projetos' where codFator = 'FA03' and codRelevancia = 3;
update relevancia set descricao = 'Pelo menos 2,5 anos de
experiência com vários projetos' where codFator = 'FA03' and
codRelevancia = 4;
update relevancia set descricao = 'Pelo menos 3 anos de experiência
com projetos variados' where codFator = 'FA03' and codRelevancia =
5;
update relevancia set descricao = 'Todos os membros da equipe são
novatos' where codFator = 'FA04' and codRelevancia = 0;
update relevancia set descricao = 'Poucos membros da equipe possuem
alguma experiência (de 1 a 1,5 ano). Os outros são novatos' where
codFator = 'FA04' and codRelevancia = 1;
update relevancia set descricao = 'Todos os membros tem mais de 1,5
ano de experiência' where codFator = 'FA04' and codRelevancia = 2;
102
update relevancia set descricao = 'A maioria da equipe tem 2 anos de

experiência' where codFator = 'FA04' and codRelevancia = 3;
update relevancia set descricao = 'Todos os membros são experientes'
update relevancia set descricao = 'A equipe não é familiarizada com
análise e projeto OO' where codFator = 'FA05' and codRelevancia = 0;
update relevancia set descricao = 'Todos os membros tem menos de 1
update relevancia set descricao = 'Todos os membros tem de 1 a 1,5
update relevancia set descricao = 'A maioria da equipe tem mais de 2
anos de experiência' where codFator = 'FA05' and codRelevancia = 3;
experientes (mais de 2 anos)' where codFator = 'FA05' and
codRelevancia = 4;
update relevancia set descricao = 'Equipe desmotivada' where
update relevancia set descricao = 'Equipe pouco motivada' where
update relevancia set descricao = 'Equipe motivada' where codFator =
update relevancia set descricao = 'Equipe muito motivada' where
update relevancia set descricao = 'Equipe motivada e inspirada'
programadores experientes' where codFator = 'FA07' and codRelevancia
= 0;
update relevancia set descricao = 'A maioria dos membros da equipe
possuem mais de 2 anos de experiência' where codFator = 'FA07' and
codRelevancia = 1;
update relevancia set descricao = 'Todos os membros tem mais de 1
ano e meio de experiência' where codFator = 'FA07' and codRelevancia
= 2;
update relevancia set descricao = 'A maioria da equipe tem mais de 1
103
update relevancia set descricao = 'Poucos membros da equipe tem

alguma experiência (1 ano). Os outros são novatos' where codFator =
novatos' where codFator = 'FA07' and codRelevancia = 5;
update relevancia set descricao = 'Requisitos muito instáveis com
mudanças frequentes' where codFator = 'FA08' and codRelevancia = 0;
update relevancia set descricao = 'Requisitos instáveis. Clientes
demandam várias mudanças realizadas em diversos intervalos' where
update relevancia set descricao = 'Requisitos instáveis. Clientes
demandam algumas mudanças realizadas em diversos intervalos' where
update relevancia set descricao = 'Estabilidade global. Pequenas
mudanças são necessárias' where codFator = 'FA08' and codRelevancia
= 3;
update relevancia set descricao = 'Requisitos estáveis ao longo do
desenvolvimento' where codFator = 'FA08' and codRelevancia = 4;

Estimador de Software

Enviado por

Dados do documento

Descrição original:

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Estimador de Software

Enviado por

Direitos autorais:

Formatos disponíveis

Raíssa Giavaroti Machado

DESENVOLVIMENTO DE UM AMBIENTE PARA ESTIMATIVA DE

Trabalho de conclusão de curso apresentado ao

Área de Concentração: Engenharia de Software

Orientador: Prof. Breno Lisi Romano

São João da Boa Vista

Ficha catalográfica preparada pela Seção de Tratamento

Giavaroti Machado, Raíssa.

Trabalho de Conclusão de Curso, IFSP, 2013.

1. Estimativa de Esforços. 2. Técnicas de Estimativa.

I. Desenvolvimento de um ambiente para estimativa

Primeiramente agradeço a Deus, por ter me concedido força e inspiração para

esgotado em meio às dificuldades encontradas e por me mostrar que sempre há um caminho.

qualidade de ensino e aprendizado e um ambiente de estudo muito agradável.

deixaram um pouco de si de alguma forma.

gratidão, por sua boa vontade e solidariedade em me auxiliar nesta pesquisa.

assim, o apoio de vocês foi muito importante para mim.

GIAVAROTI MACHADO, RAISSA. (2013). Desenvolvimento de um ambiente para

Esta pesquisa aborda temas das áreas de Engenharia de Software e Gerência de

aplicados no desenvolvimento de um software. Neste trabalho, descreve-se a concepção e

desenvolvido com a intenção de auxiliar os stakeholders quanto ao planejamento de recursos

do projeto, a fim de que este possa desenvolver-se dentro do esperado. Ao término do

seu desempenho e apresentou-se seu funcionamento.

Palavras-chave: Ambiente para Estimativa de Esforços. Técnicas de estimativa. Casos de Uso.

MACHADO, RAISSA GIAVAROTI. (2013). Development of a Effort Estimation

areas, focusing in the processes of efforts estimation to be applied in the software

Keywords: Effort Estimation Environment. Estimation Techniques. Use cases. Project

COCOMO Constructive Cost Model

FAPF Fator de Ajuste de Pontos por Função

FPA Function Point Analysis

HTML HyperText Markup Language

IHM Interface Humano Máquina

LCD Linguagem de Controle de Dados

LDD Linguagem de Definição de Dados

LMD Linguagem de Manipulação de Dado

LOC Lines of Code

MER Modelo Entidade Relacionamento

OMG Object Management Group

PFA Pontos de Função Ajustados

PFNA Pontos Não Ajustados por Função

PHP PHP HyperText Preprocessor

PMBOK Project Management Body of Knowledge

RUP Rational Unified Process

SGBD Sistema Gerenciador de Banco de Dados

SQL Structured Query Language

TCF Technical Complexity Factor

UAW Unadjusted Actor Weight

UCP Use Case Point

UML Unified Modeling Language

USC University of Southern California

UUCP Unadjusted Use Case Points

UUCW Unadjusted Use Case Weight

1.1 Motivação e Contextualização .............................................................................................. 17

1.2 Objetivos ............................................................................................................................... 19

1.2.1 Objetivo Geral .................................................................................................................... 19

1.2.2 Objetivos Específicos ......................................................................................................... 19

1.3 Organização deste trabalho ................................................................................................... 20

2 LEVANTAMENTO BIBLIOGRÁFICO ....................................................................... 21

2.1 Engenharia de Software ........................................................................................................ 21

2.2 Gerência de Projetos ............................................................................................................. 22

2.3 Linguagem UML .................................................................................................................. 24

2.3.1 Diagrama de Caso de Uso .................................................................................................. 25