Engenharia de Software

Recursos necessários

Para o caso dos recursos, os mais difíceis de gerir são os humanos. Em um processo de software,
haverá muitas pessoas envolvidas, executando diferentes papéis tais como: Gestor de projecto,
gestor de qualidade, clientes, usuários e outros.

O número de papéis e suas denominações pode variar dependendo da organização e até do projecto.

As pessoas trabalhando em um projecto são organizadas em equipas, assim, o conceito de equipa

pode ser visto como um conjunto de pessoas exercendo diferentes tarefas, mas objectivando uma
meta comum.

Esta não é só uma característica do desenvolvimento de software apenas, mas da organização de

pessoas em qualquer actividade.

Então, a definição de equipa dada é válida para uma ampla variedade de situações, tal como uma
equipa de futebol.

Para uma boa formação de equipas devem ser considerados aspectos fundamentais para a definição
de papéis, tais como:

 Liderança;

 Organização;

 Coordenação; entre outros

Além disso, há outros factores que afectam a formação de equipas como:

 Relacionamento interpessoais;

 Tipo de projecto; e

 Criatividade
Tipos de equipas

No que diz respeito a formação de equipas, podemos identificar três tipos de equipas como sendo
os mais comuns:

1. Democrática descentralizada:

Neste tipo de equipas, n indivíduos são alocados a m tarefas diferentes tarefas, formando
equipas informais de desenvolvimento com um responsável de cada equipa, sendo que a
coordenação entre as equipas fica a cargo do gestor do projecto.

2. Controlada descentralizada:

Neste caso, n indivíduos são organizados em k equipas, cada equipa sendo alocada a uma
ou mais tarefas; a organização de cada equipa é específica a ela mesma, a coordenação
ficando a cargo do gestor do projecto; e

3. Controlada centralizada:

Neste tipo de equipa, n indivíduos são alocados a m diferentes tarefas com pequeno grau
de interação, sendo que a coordenação da equipa fica a cargo do gestor do projecto.

Por fim, na formação de equipas deve-se levar em consideração o tamanho da equipa pois, quanto
maior for o número de membros da equipa, maior é a quantidade de caminhos de comunicação, o
que pode ser um problema uma vez que o número de pessoas que devem se comunicar pode afectar
a qualidade do produto resultante.

A partir dos fundamentos apresentados já é possível estabelecer estimativas.

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.

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.

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 usados 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 de 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

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 ainda não tem 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.

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)

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
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:

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

C D 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