INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

Licenciatura em Eng.ª Informática e de Telecomunicações – LEIT

Ficha de apoio Engenharia de Software

Projectos Académicos – Engenharia de Software 1 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

Gestão de projectos de desenvolvimento de software

Estimativas

As estimativas servem para dar uma imagem do trabalho a ser realizado, os recursos necessários,
a duração do projecto e por fim os custos do mesmo.

A pesar de as estimativas serem um pouco de arte e ciência, elas não devem ser conduzidas de
forma desordenada, porque elas é que ditarão o funcionamento das restantes actividades do
projecto.

Para alcançar boas estimativas de prazo, esforço e custos existem algumas técnicas.

Técnicas de estabelecimento de estimativas

1. Postergar as estimativas para o mais tarde no projecto:

Esta opção é atraente, mas não é prática, pois, as estimativas devem ser estabelecidas
logo no início do projecto. No entanto deve-se reconhecer que quanto mais tarde for feita
a estimativa, maior é o conhecimento do projecto e menores são as chances de se cometer
erros.

2. Utilização de procedimentos não algorítmicos:

Estimativas na base da opinião de um especialista

Estimativas na base do melhor preço

Estimativas na base de projectos similares

3. Uso de procedimentos algorítmicos:

Consiste na utilização de fórmulas matemáticas derivadas de experiências para prever o

esforço como uma função do tamanho (linhas de código ou pontos de função)

É de salientar que as experiências que deram origem a esses métodos derivam de um

conjunto limitado de projectos. E que nestes modelos, os factores culturais da
organização não são tomados em consideração pois os projectos que constituem a base de
dados dos modelos são externos à organização.

Projectos Académicos – Engenharia de Software 2 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

O ideal seria utilizar dados históricos da organização, mas na ausência destes, os modelos
empíricos têm se mostrado mais eficientes a pesar das suas limitações.

Estimativas de tamanho:

Entre as formas de se medir o tamanho de um software, a mais simples, directa e altamente

utilizada é a contagem das linhas de código dos programas fontes.

Existem vários estudos que demonstram a alta correlação entre esta métrica e o tempo para
desenvolver um sistema. Entretanto, o uso dessa métrica apresenta algumas desvantagens:

a) Verifica-se que ela é fortemente ligada a linguagem de programação utilizada no

desenvolvimento;

b) Pode ser difícil estimar essa grandeza no início do desenvolvimento, sobretudo quando
não há dados históricos relacionados com a linguagem de programação utilizada no
projecto.

Visando a possibilitar a realização de estimativas de tamanho mais cedo no processo de software,

foram propostas outras métricas. O exemplo mais conhecido é a contagem dos pontos de função
(PF), que busca a medir as funcionalidades de um sistema requisitadas e recebidas pelo usuário,
de forma independente da linguagem de programação utilizada no desenvolvimento. Depois
podem ser convertidos em LOC por ponto de função para cada linguagem de programação.

A título de exemplo segue a tabela representando o número de linhas de código para cada ponto
de função de acordo com a linguagem de programação utilizada para o desenvolvimento:

Linguagem de Programação C C++ Java Sql

LOC’s/PF 162 66 63 40

Estimativas de esforço:

Para a realização de estimativas de tempo e custos é fundamental estimar antes o esforço

necessário para completar o projecto ou cada uma das suas actividades.

Projectos Académicos – Engenharia de Software 3 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

Estimativas de esforço podem ser obtidas directamente pelo julgamento de um especialista,

tipicamente usando técnicas de decomposição ou a partir de dados de tamanho ou ainda a partir
de dados históricos.

Quando estimativas de tamanho são usadas como base, deve-se considerar um factor de
produtividade, indicando quanto em unidade de esforço é necessário para completar um projecto
ou módulo descrito em unidades de tamanho.

Quando uma organização não tem ainda dados suficientes para definir seus próprios factores de
produtividade, é aconselhável que se utilize modelos algorítmicos ou empíricos.

Existem vários modelos que derivam estimativas de esforço a partir de dados de LOC’s (Lines
Of Code) ou PF’s (Pontos de Função). De maneira geral, todos têm a seguinte estrutura:

E: Esforço em pessoas por mês;

A, B e C: São constantes derivadas empiricamente;

T: Estimativa de Tamanho em LOC’s

Alocação de recursos

Estimar os recursos necessários para realizar o esforço de desenvolvimento é outra tarefa

importante.

Quando falamos de recursos, estamos englobando pessoas, hardware e software. Em todos casos
é necessário observar a disponibilidade do recurso.

Assim, é importante definir a partir de que data o recurso será necessário, por quanto tempo ele
será necessário e qual é a quantidade de horas necessárias por esse período.

A partir da informação acima, observa-se que já está sendo tratada a estimativa de tempo. Assim,
a alocação de recursos e estimativa de tempo são actividades realizadas normalmente em
paralelo.

Estimativa de tempo

Projectos Académicos – Engenharia de Software 4 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

De posse da estimativa de esforço e da alocação de recursos, é possível estimar o tempo de cada

actividade e, por conseguinte, do projecto.

Se a estimativa de esforço tiver sido feita para o projecto como um todo, então ela deve ser
distribuída pelas actividades do projecto.

É importante recordar que dados históricos de projectos já concluídos são uma boa base para se
fazer essa distribuição. No entanto, muitas vezes, uma organização que ainda não tenha esses
dados disponíveis. Embora as características do projecto sejam determinantes para a distribuição
de esforço, uma diretriz inicial útil consiste em considerar a proposta de PRESSMAN para a
distribuição de esforço apresentada na tabela seguinte:

Fase Planeamento Especificação Projecto Implementação Testes e Entrega

Esforço Até 3% 10% à 25% 20% à 15% à 20% 30% à 40%

Fase/Total 25%

Estimativas de custos

De posse nas demais estimativas, é possível estimar os custos do projecto, tomando em

consideração os seguintes itens:

 Custos relativos ao esforço empregado pelos membros das equipas para o

desenvolvimento.

 Custos de hardware (incluindo custos de manutenção);

 Outros custos relacionados ao projecto, tais como custos de viagens e treinamentos

realizados no âmbito do projecto;

 Despesas gerais, incluindo gastos com água, luz, telefone, pessoal de apoio
administrativo, pessoal de suporte e outros.

Para a maioria dos projectos, o custo dominante é o que se refere ao esforço empregado
juntamente com as despesas gerais.

Sommerville sugere que, de modo geral, os custos relacionados às despesas gerais correspondam
a um valor equivalente aos custos relativos ao esforço empregado pelos membros das equipas no
projecto.

Projectos Académicos – Engenharia de Software 5 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

Os custos de material são menos influentes, mas não devem ser desconsiderados sob pena de
provocarem prejuízo no projecto.

Se o custo do projecto estiver sendo calculado como parte de uma proposta para o cliente, então
será preciso definir o preço cotado.

Uma abordagem para definir o preço cotado pode ser considera-lo como o custo do projecto mais
o lucro.

Modelo COCOMO (Constructive Cost Model)

É um modelo desenvolvido para estimar o esforço, prazo, custo e tamanho da equipa para um
projecto de software.

COCOMO é apresentado na forma de um conjunto de modelos hierarquicamente em três níveis:

básico, intermediário e avançado.

COCOMO básico:

Calcula o esforço de desenvolvimento de um software em função do tamanho estimado em

linhas de código.

COCOCMO intermediário

Calcula o esforço de desenvolvimento de software em função do tamanho e de um conjunto

atributos ou factores de software que incluem avaliações sobrejectivas do produto, hardware,
pessoal e atributos do projecto conforme mostra a tabela seguinte:

Categoria Atributos

Produto RELY - Required Software Reliability(Confiabilidade exigida do Sistema)

DATA – Data Base Size (Tamanho da Base de Dados)

CPLX – Product Complexity (Complexidade do Sistema)

TIME – Execution Time Constraint (Restrições do tempo de execução)

STOR – Main Storage Constraint (Restrições de memória)

Harware

VIRT – Virtual Machine Volatility (Volatilidade da máquina virtual)

Projectos Académicos – Engenharia de Software 6 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

TURN – Computer Turnaround Time (Tempo de rotatividade do computador)

Pessoal ACAP – Analist Capability

AEXP – Application Experience

VEXP - Virtual Machine Experience

PCAP – Programmer Capability

LEXP – Programming Language Experience

Projecto MODP – Modern Programming Practices

TOOL – Use of Software Tools

SCED – Required Development Schedule (Cronograma)

A tabela abaixo apresenta a classificação dos quinze atributos direccionadores de custo, para o
cálculo do factor de ajuste.

Atributo Valor

Muito baixo Baixo Nominal Elevado Muito elevado Extra elevado

Produto
RELY 0,75 0,88 1 1,15 1,4 -

DATA - 0,94 1 1,08 1,16 -

CPLX 0,7 0,85 1 1,15 1,3 1,65

Hardware
TIME - - 1 1,11 1,3 1,66

STOR - - 1 1,06 1,21 1,56

VIRT - 0,87 1 1,15 1,3 -

TURN - 0,87 1 1,07 1,15 -

Pessoal
Projectos Académicos – Engenharia de Software 7 de 9 Ag-17
 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

ACAP 1,46 1,19 1 0,86 0,71 -

AEXP 1,29 1,13 1 0,91 0,82 -

PCAP 1,42 1,17 1 0,86 0,7 -

VEXP 1,21 1,1 1 0,9 - -

LEXP 1,14 1,07 1 0,95 - -

Projecto
MODP 1,24 1,1 1 0,91 0,82 -

TOOL 1,24 1,1 1 0,91 0,83 -

SCED 1,23 1,08 1 1,04 1,1 -

COCOMO avançado

Incorpora todas as características da versão intermediária, incluindo a avaliação do impacto dos

atributos do software e da equipa desenvolvedora em cada passo do processo da Engenharia de
Software.

Depois da análise de requisitos funcionais do software, o tamanho da aplicação deve ser

estimado em milhares de linhas de código (KLOC) e o projecto deve ser classificado em um dos
três modos de desenvolvimento: orgânico, semi-destacado e embutido.

Modo orgânico

Equipas relativamente pequenas desenvolvem sistemas num ambiente familiar, a maior parte das
pessoas engajadas têm experiência prévia com sistemas similares e entendimento completo do
sistema, uso de algoritmos simples, pouca necessidade de inovação, requisitos não variam,
tamanho relativamente pequeno de até 50KLOC’s.

Modo semi-destacado

Projectos com características entre o orgânico e o embutido. As equipas podem ser constituídas
por pessoas com pouca assim como grande experiência, o tamanho do software pode ir até
300KLOC’s.

Modo embutido:

Projectos Académicos – Engenharia de Software 8 de 9 Ag-17

 INSTITUTO SUPERIOR DE TRANSPORTES E COMUNICAÇÕES

O produto a ser desenvolvido deverá operar dentro de um contexto complexo. São caracterizados
por serem relativamente grandes ultrapassando os 300KLOC’s, com muita necessidade de
inovação, altos custos de verificação e validação.

De uma forma geral, utilizando o modelo COCOMO, o esforço, o tempo de desenvolvimento e o

tamanho da equipa não calculados de acordo com as fórmulas e tabelas seguintes:

Básico Básico Intermediário

T C D E A B A B

Orgânico 2,5 0,38 Orgânico 2,4 1,05 3,2 1,05

SemiDestacado 2,5 0,35 SemiDestacado 3,0 1,12 3,0 1,12

Embutido 2,5 0,32 Embutido 3,6 1,2 2,8 1,2

Projectos Académicos – Engenharia de Software 9 de 9 Ag-17