Resumo Engenharia de Software

Capítulo 8 – Modelagem de Análise

Análise de Requisitos: Resulta na especificação das características operacionais

do software, indicando a interface do software com outros elementos do sistema e
estabelece restrições a que o software deve satisfazer. Permite ao engenheiro de
software elaborar requisitos básicos e construir modelos que descrevam cenários,
funções e comportamentos. Propiciam meios de avaliar a qualidade do software.

A modelagem deve atingir a 3 objetivos principais: 1 – Descrever o que o cliente

exige; 2 – Estabelecer a base para a criação de um projeto de software; 3 – Definir um
conjunto de requisitos que possam ser validados quando o software for construído.

Para a criação de um modelo de análise, o modelo deve focalizar os requisitos

que são visíveis e funcionais no problema, na qual cada elemento deve contribuir para
o entendimento global. O modelo deve ter valor a todos os interessados e deve ser o
mais simples possível.

Análise de Domínio: é a identificação, análise e especificação dos requisitos em

comuns de um domínio de aplicação específico, para reuso em vários projetos daquele
domínio de aplicação.

8.2) Abordagens de Modelagem de Análise

Análise estruturada: Considera os dados e os processos que transformam os

dados entidades separadas. Objetos de dados são modelados para que definam seus
atributos e relacionamentos enquanto os Processos são modelados para que mostrem
como eles transformam os dados à medida que os Objetos de dados fluem pelo
sistema.

Análise Orientada a Objetos: Focaliza a definição de classes e o modo pelo qual

elas colaboram umas com as outras para atender aos requisitos. Ex: UML e Processo
Unificado.

8.3) Conceitos de Modelagem de Dados

Objeto de Dados: É uma representação de quase toda a informação composta

que deve ser compreendida pelo software. Por informação composta queremos nos
referir a algo com várias propriedades ou atributos diferente.

Atributo de Dados: Definem as propriedades de um objeto de dados e

assumem uma das três diferentes características: 1 – Nomear um exemplo do objeto
de dados; 2 – Descrever o exemplo; 3 – Fazer referência a outro exemplo. Um ou mais
atributos pode ser definidos como Identificador, tornando-se uma chave.
 Relacionamentos: Objetos de dados são conectadas uns com outros de
diferentes modos através do entendimento do papel dos objetos e do contexto do
software a ser construído.

Cardialidade e Modalidade: Cardialidade é a especificação do número de

ocorrências de um objeto que pode ser relacionado ao número de ocorrências de outro
objeto. A Modalidade de uma relação é 0 se não houver necessidade explícita de o
relacionamento ocorrer ou é opcional, e é 1 quando o relacionamento é obrigatório.

8.4) Análise Orientada a Objetos

Em vez de examinarmos o problema usando um modelo convencional de

entrada-processamento-saída ou um modelo derivado exclusivamente de estruturas de
informação hierárquicas, a Análise Orientada a Objetos cria um modelo orientado a classes
que se apóia no entendimentos dos conceitos de OO.

8.5) Modelagem Baseada em Cenário

Escrita de Casos de Uso: Capta as interações que ocorrem entre produtores e

consumidores de informação e o sistema em si. O conceito de caso de uso descreve um
cenário de uso específico em linguagem direta do ponto de vista de um ator definido, uma vez
que saiba sobre o que escrever, quando escrever, o quão detalhado deve ser a descrição e
como organizá-la.

Diagrama de Atividades: Complementa o caso de uso fornecendo uma

representação gráfica do fluxo de interação em um cenário específico.

Diagrama de Raias: É uma variação do diagrama de atividades que permite ao

modelador, representar o fluxo de atividades descrito pelo caso de uso e ao mesmo tempo,
indicar que ator ou classe de análise é responsável pela ação descrita.

8.6) Modelagem Orientada a Fluxo

Embora o Diagrama de Fluxo de Dados(DFD) não sejam parte formal da UML, eles
podem ser usados para complementar os diagramas de UML e fornecer visão adicional dos
requisitos e fluxo do sistema. No DFD, os objetos de dados entram no software, são
transformados por elementos de processamento e os objetos de dados resultantes saem do
software.

À medida que o DFD é refinado em maior nível de detalhe, o analista realiza uma
decomposição funcional implícita do sistema.

Modelagem de Fluxo de Controle: Utilizada para tratar uma grande classe de

aplicações é orientada por eventos em vez de dados, produzem informações de controle em
vem de relatórios ou imagens, e processam informação com grande preocupação em tempo e
desempenho.
 Especificação de Controle: Representa o comportamento do sistema como uma
especificação de comportamento seqüencial ou como uma especificação de comportamento
combinatória.

Especificação de Processo: Usada para descrever todos os processos do modelo de

fluxo que aparecem no nível de refinamento final.

8.7) Modelagem Baseada em Classe

Classes de Análise: Classes podem ser identificadas como sendo uma Entidade
Externa (que produzem ou consomem informações), Coisas (que são parte do domínio de
informação do problema), Ocorrências (eventos que ocorrem durante o contexto), Papéis
(funções desempenhadas por pessoas), Unidades Organizacionais (Unidades divididas por
funções), Lugares (que estabelecem o contexto do problema) e Estruturas (que definem uma
classe do problema).

Atributos: Os atributos definem a classe – que esclarecem o que a classe

representa no contexto de espaço do problema.

Operações: Definem o comportamento de um objeto, sendo assim, uma

operação deve ter ‘conhecimento’ da natureza e dos atributos e associações da classe.

Modelagem CRC (Classe-Responsabilidade-Colaboração): Fornece um meio

simples para identificar e organizar as classes relevantes aos requisitos do sistema.
Responsabilidades são os atributos e operações relevantes. Colaboradores são as classes
necessárias para dar à classe informação necessárias para completar uma responsabilidade.

Associações: Quando duas classes de análise estão relacionadas entre si de

algum modo, podendo criar um vínculo de dependência entre elas.

Pacote de Análise: Quando vários elementos do modelo de análise são

empacotados como um agrupamento.

8.8) Modelo Comportamental

O modelo comportamental indica como o software responderá a eventos ou

estímulos externos.

Eventos no Caso de Uso: Um caso de uso é examinado para encontrar pontos

de troca de informações, para então, definir o evento gerado por essa troca.

Representação de Eventos: No contexto de modelagem comportamental,

devem ser consideradas duas caracterizações de estados diferentes: 1 – o estado de cada
classe à medida que o sistema realiza sua função; 2 – o estado do sistema, observado de fora,
à medida que o sistema realiza sua função.

Diagrama de Estado para Classes de Análise: Representa os estados ativos de

cada classe e os eventos que causam mudanças entre esses estados ativos.

Diagrama de Sequência: Indica como os eventos provocam transições de

objeto para objeto.
Capítulo 15 – Métricas de Produto para Software
Usamos medidas para entender melhor os atributos dos modelos que criamos para
avaliar a qualidade dos produtos ou sistemas submetidos à engenharia que construímos.
Apesar de as métricas de produto para software de computador serem frequentemente não
absolutas, elas nos dão um modo sistemático de avaliar qualidade com base em um conjunto
de regras claramente definidas. Essas medidas de atributos internos dos produtos dão ao
engenheiro de software uma indicação em tempo real da eficácia dos modelos de análise,
projeto e código, da efetividade dos casos de teste e da qualidade global do software em
construção.

15.1) Qualidade de Software

Qualidade de software: Satisfação de requisitos funcionais e de desempenho

explicitamente declarados, normas de desenvolvimento documentadas e características
implícitas que são esperadas em todo o software desenvolvido. Os requisitos de software é a
base a partir da qual a qualidade é medida. Normas especificadas definem um conjunto de
critérios que guiam o modo pelo qual o software é construído. O software deve atender
também a requisitos implícitos (ex: facilidade de uso).

15.1.1) Fatores de Qualidade McCall

Os fatores que afetam a qualidade do software podem ser dividido em

dois grandes grupos: 1 – Fatores que podem ser medidos diretamente (ex: defeito por ponto
de função); 2 – Fatores que podem ser medidos apenas indiretamente (ex: usabilidade).
McCall propõe uma categorização de fatores baseados em três aspectos importantes de um
software: características operacionais, sua habilidade de passar por modificações e sua
adaptabilidade a novos ambientes. Em alguns casos é impossível desenvolver medidas diretas
desses fatores.

15.1.2) Fatores de Qualidade ISO 9126

A norma ISSO 9126 foi desenvolvida numa tentativa de identificar os

atributos de qualidade para software de computador, identificando seis atributos-chave:
Funcionalidade, Confiabilidade, Usabilidade, Eficiência, Manutenibilidade, Portabilidade. Os
fatores ISSO não necessariamente se prestam a medidas diretas, mas fornece uma base valiosa
para medidas indiretas e uma excelente lista de verificação para avaliação.

15.1.3) Transição para Visão Quantitativa

Em todos os casos, as métricas representam medidas indiretas, isto é,

nunca realmente medimos a qualidade, mas uma manifestação da qualidade. O problema é
definir a relação precisa entre a variável que é medida e a qualidade do software.

15.2) Um Arcabouço para Métricas de Produto

15.2.1) Métricas, Medidas e Indicadores

Medida: Fornece uma indicação quantitativa de extensão, quantidade,

dimensão ou capacidade de algum atributo de um produto ou processo. Métrica: É o ato de
determinar grau em que um sistema, componente ou processo possui um determinado
atributo. Indicador: É uma métrica que fornece profundidade na visão do processo, projeto ou
o produto em si.
 15.2.2) O Desafio das Métricas Técnicas

O grande problema das medidas de complexidade propostos é que

cada um adota um ponto de vista diferente sobre o que é complexidade e que atributos de um
sistema levam à complexidade.

15.2.3) Princípios de Medição

O processo de medição por ser definido por cinco atividades:

Formulação, Coleta, Análise, Interpretação e Realimentação. As métricas serão úteis quando
este possui propriedades matemáticas desejáveis; quando a métrica diminui ou aumenta de
acordo com a característica; quando a métrica mede o fator de interesse independente de
outros fatores.

15.2.4) Medições de Software Orientadas a Objeto

Enfatiza a necessidade de estabelecer um objetivo explícito na

medição; definir um conjunto de questões que precisam ser respondidas a fim de alcançar o
objetivo e identificar métricas para responder a essas questões.

15.2.5) Os Atributos de Métricas de Software Efetivas

As métricas e as medidas que levam a elas devem ser: Simples e

computáveis (fácil de aprender e sem gasto excessivo de tempo); Empíricas e Intuitivamente
persuasivas (deve satisfazer às noções intuitivas do engenheiro); Consistentes e Objetivas
(deve produzir resultados não ambíguos); Consistentes no uso de unidades e dimensões
(cálculo matemático que não levem a unidades bizarras); Independente da linguagem de
programação; Mecanismo efetivo para realimentação de alta qualidade (a métrica deve levar a
um produto de maior qualidade).

15.2.6) A Paisagem da Métrica de Produto

Métricas para o modelo de análise: Enfatiza a entrega da

funcionalidade, o tamanho do sistema e a qualidade da especificação.

Métricas para o modelo de projeto: Quantificam atributos do projeto

de um modo que permita ao engenheiro de software avaliar a qualidade do projeto.

Métricas para Código-Fonte: Usadas para avaliar sua complexidade,

manutenibilidade e testabilidade.

Métricas de teste: Ajuda o projeto de casos de teste efetivos e avaliam

a eficácia do teste.

15.3) Métricas para o Modelo de Análise

15.3.1) Métricas Baseadas em Função (FP)

Pode ser usada como um meio para estimar o custo ou esforço

necessário para projetar, codificar e testar o software; prever o número de erros e o número
de componentes/linhas de código projetado no sistema.

15.3.2) Métricas de Qualidade de Especificação

 Propõe uma lista de características que podem ser usadas para avaliar
a qualidade do modelo de análise e da correspondente especificação de requisitos como
especificidade, consistência, rastreabilidade, precisão, reusabilidade e etc.

15.4) Métricas para o Modelo de Projeto

15.4.1) Métricas de Projeto Arquitetural

Focalizam as características da arquitetura do programa com ênfase na

efetividade dos módulos ou componentes da arquitetura.

15.4.2) Métricas para o Modelo de Projeto OO

Focalizam medições que podem ser aplicadas à classe e às

características do projeto – localização, encapsulamento, herança - que tornam a classe
singular.

15.4.3) Métricas Orientadas a Classe – O conjunto de Métricas CK

Como a classe é fundamental de um sistema OO, medidas e métricas

para uma classe individual, para a hierarquia de classes e para as colaborações entre classes
serão de grande valor para um engenheiro de software que precisa avaliar a qualidade do
projeto.

15.4.4) Métricas Orientadas à Classe – O conjunto de Métricas MOOD

Propõe um conjunto de métricas para o projeto orientado a objetos

que fornece indicadores quantitativos para as características do projeto OO.

15.4.5) Métricas Propostas por Lorenz e Kidd

Métricas baseadas em quatro categorias: tamanho (focaliza a

contagem de atributos), herança (focalizam o modo pelo qual as operações são reusadas),
aspectos internos (focalizam a coesão e código) e externos (examinam acoplamento e reuso).

15.4.6) Métricas de Projeto em Nível de Componente

Focalizam as características internas e incluem a medida dos “três C” –

Coesão, Acoplamento e Complexidade.

15.4.7) Métricas Orientadas a Operação

Focalizam as operações baseado no tamanho médio de operação

(número de linhas de código) e a complexidade da operação.

15.5) Métricas de Código-Fonte

A teoria de Halstead associou leis quantitativas ao desenvolvimento de

software de computador, usando um conjunto de medidas primitivas que podem ser
originadas após o código ser gerado, criando a métrica baseada no número de operadores e
operandos do código.
 15.6) Métricas para Teste

A maioria das métricas propostas focaliza o processo de teste, não as

características do teste propriamente dito. As métricas de Halstead podem ser aplicadas para
determinar o esforço do teste baseado no volume e nível do programa. As métricas de OO
também podem ser aplicadas considerando encapsulamento e herança.

Capítulo 22 – Métricas de Processo e Projeto

Medição pode ser aplicada ao processo de software com o objetivo de

melhorá-lo de forma contínua. Pode ser usada ao longo de um projeto de software
para auxiliar na estimativa, no controle de qualidade, na avaliação de produtividade e
no controle do projeto. Finalmente, medição pode ser usada pelos engenheiros de
software para ajudar a avaliar a qualidade dos produtos do trabalho e auxiliar na
tomada de decisões táticas à medida que o projeto evolui.

22.1) Métricas nos Domínios do Processo e do Projeto

Seu objetivo é fornecer um conjunto de indicadores de processo que

leva a aperfeiçoamento do processo de software no longo prazo. Permite que o
gerente de projeto avalie o estado de um processo em andamento; acompanhe riscos
em potencial; descubra áreas-problema antes de se tornarem críticos; ajuste fluxo de
trabalho ou tarefas e avalie a capacidade da equipe de projeto de controlar a
qualidade.

22.1.1) Métricas de Processo e Aperfeiçoamento do Processo de

Software

O processo situa-se no centro de um triângulo que liga três

fatores com profunda influência na qualidade do software e no desempenho da
organização. A capacidade e a motivação pessoal, a complexidade do produto e a
tecnologia são esses três fatores. Além disso, esse triângulo se encontra dentro de um
círculo de condições ambientais, que incluem o ambiente de desenvolvimento,
condições de negócio e características do cliente.

22.1.2) Métricas de Projeto

Enquanto as métricas de processo de software são usadas com

finalidade estratégica, métricas de projeto são táticas, com o objetivo de adaptar o
fluxo de trabalho e as atividades técnicas do projeto. São usadas para minimizar o
cronograma de desenvolvimento, fazendo ajustes necessários para evitar atrasos,
problemas e riscos, além de avaliar a qualidade do produto durante a evolução.

22.2) Medição de Software

A medição de um software pode ser categorizada em: Medidas Diretas

são todos os processos ligados diretamente no desenvolvimento do produto (linhas de
código, tempo de execução); Medidas Indiretas: Inclui funcionalidades, qualidade,
complexidade e etc.
 22.2.1) Métricas Orientadas a Tamanho
Métricas orientadas a tamanho são originadas pela normalização das
medidas de qualidade e/ou produtividade, considerando o tamanho do software que foi
produzido. Mas não são muito bem aceitas sendo que a principal controvérsia ocorre devido
ao número de linhas, pois isso depende da linguagem de programação utilizada.

22.2.2) Métricas Orientadas à Função

A métrica orientada a função mais amplamente utilizada é a Pontos

por Função, cujo cálculo é baseado em características do domínio de informação e
complexidade do software. Existem controvérsias na sua utilização, uma vez que apesar de ser
independente da linguagem de programação, o cálculo é baseado em dados subjetivos e as
contagens no domínio da informação podem ser difíceis de coletar posteriormente.

22.2.4) Métricas Orientadas a Objeto

Métricas de projeto de software convencional (LOC ou FP) podem ser

usadas para estimar projetos de software. No entanto, essas métricas não fornecem
granularidade suficiente para os ajustes de cronograma e esforço que são necessários quando
iteramos ao longo de um processo evolutivo ou incremental.

22.2.5) Métricas Orientadas a Casos de Uso

O caso de uso é definido logo no início do processo de software,

permitindo que seja usado para estimativa antes que as atividades significativas de
modelagem e construção sejam iniciadas. Casos de uso descrevem as funções e características
visíveis ao usuário que são requisitos básicos de um sistema. É independente da linguagem de
programação.

2.3) Métricas de Qualidade de Software

Métricas de qualidade de software focalizam o processo, projeto e produto.

Desenvolvendo e analisando referências para métricas de qualidade, uma organização pode
corrigir áreas do processo de software, que são as causas dos defeitos.

2.3.1) Medição de Qualidade

Apesar de existirem várias medidas de qualidade de software, a

correção, manutebilidade, integridade e usabilidade fornecem indicadores úteis à equipe de
software.

2.3.2) Eficiência na Remoção de Defeitos

Uma métrica de qualidade que fornece benefício tanto no nível de

projeto quanto de processo é a eficiência na remoção de defeitos (DRE). É uma medida da
capacidade de filtragem das atividades de controle e garantia de qualidade de software.
 22.4) Integração de Métricas no Processo de Software

22.4.1) Argumentos Favoráveis a Métrica de Software

Para o estabelecimento de metas para aperfeiçoamento do processo, o

estado atual do desenvolvimento do software deve ser conhecido. A medição é usada para
estabelecer um referencial do processo a partir do qual as melhorias podem ser avaliadas.
Usando a medição, os aspectos de desenvolver estimativas, produzir sistemas de alta
qualidade e entregar os produtos dentro do prazo torna-se mais gerenciáveis. Coletar métricas
de qualidade permite à organização ‘sintonizar’ seu processo de software para remover as
causas de defeitos.

22.4.2) Estabelecimento de uma Referência

Para uma melhoria efetiva no processo os dados referenciais devem

ser razoavelmente precisos; os dados devem ser coletados de tantos projetos quanto possível;
as medições devem ser consistentes; as aplicações devem ser análogas ao trabalho que precisa
ser estimado.

22.4.3) Coleta, Cálculo e Avaliação de Métricas

A coleta de dados exige uma investigação histórica de projetos

anteriores para reconstruir os dados necessários. Uma vez coletadas essas medidas o cálculo e
análise das métricas são possíveis. A avaliação as métricas focaliza as razões subjacentes dos
resultados obtidos e produz um conjunto de indicadores que dão diretrizes ao projeto ou
processo.

22.5) Métricas para Pequenas Organizações

Uma abordagem para as pequenas organizações é ‘torne simples’, ajuste às

necessidades locais e certifique-se de que tem valor.
Capítulo 23 – Estimativa de Projetos de Software

23.1) Observações sobre Estimativa

As métricas de processo e projeto podem fornecer perspectiva histórica

e insumo poderoso para a geração de estimativas quantitativas. A estimativa de
recursos, de custo e de cronograma para o esforço de engenharia de software exige
experiência, acesso a boas informações históricas e coragem para se empenhar em
previsões quantitativas, quando a informação qualitativa é tudo que existe. O risco da
estimativa é medido pelo grau de incerteza das estimativas quantitativas estabelecidas
para recurso, custo e cronograma.

23.2) O Processo de Planejamento de Projeto

O objetivo do planejamento de projeto é fornecer um arcabouço que

permita o gerente fazer estimativas razoáveis de recursos, custo e cronograma, além
de tentar definir cenários correspondentes tanto do melhor quanto do pior caso, de
modo que o comportamento do projeto possa ser delimitado.

23.3) Escopo e Viabilidade do Software

O escopo do software descreve as funções e características a serem

entregues aos usuários finais, os dados que entram e saem, o “conteúdo” final é o
resultado do uso do software e o desempenho, as restrições, as interfaces e a
confiabilidade que limitam o sistema. As funções descritas no escopo são avaliadas e
refinadas para fornecer mais detalhes antes do início da estimativa. Determinado o
escopo, a equipe de software deve determinar se aquilo pode ser feito dentro das
dimensões mencionadas.

23.4) Recursos

23.4.1) Recursos Humanos

A quantidade de pessoas necessárias para um projeto só pode

ser determinada depois de ser feita uma estimativa do esforço de desenvolvimento.
Após a avaliação do escopo e a seleção das aptidões necessárias, é feito a alocação e
divisão dos recursos humanos.

23.4.2) Recursos de Software Reusáveis

Engenharia de software baseada em componentes enfatiza a
reusabilidade, que são frequentemente negligenciados durante o planejamento, tornando-se
foco de preocupação somente durante a fase de desenvolvimento de software.

23.4.3) Recursos de Ambiente

O ambiente que apóia o projeto de software incorpora elementos de

hardware e software. O hardware fornece a plataforma que apóia as ferramentas (software)
necessárias para produzir os produtos de trabalho, que são resultados de boas práticas de
engenharia de software.
 23.5) Estimativa do Projeto de Software

A estimativa de custo e de esforço nunca será uma ciência exata, pois depende
de um demasiado número de variáveis – humanas, técnicas, ambientais, políticas – pode
afetar o custo final do software e o esforço aplicado pra desenvolvê-lo. Existem algumas
opções para conseguir estimativas:

1) Adiar a estimativa até o projeto estar o mais adiantado possível (não é muito
viável, pois estimativas devem ser fornecidas logo)
2) Basear as estimativas em projetos semelhantes (pode funcionar bem se o projeto
for bastante semelhante a esforços anteriores e as outras influências do projeto
forem equivalentes)
3) Usar técnicas de decomposição relativamente simples
4) Usar um ou mais modelos empíricos para estimativas

23.6) Técnicas de Decomposição

A estimativa de projetos de software é uma forma de solução de problemas, e

muitas vezes o problema é muito complexo para ser considerado como um só. Para
isso, o problema é decomposto, recaracterizando-o como um conjunto de problemas
menores.

23.6.1) Dimensionamento do Software

A precisão da estimativa de um projeto de software depende de alguns

fatores: 1 – O grau em que o planejador estimou adequadamente o tamanho do
produto; 2 – A aptidão para traduzir a estimativa de tamanho em esforço humano; 3 –
O grau com que o plano de projeto reflete a capacidade da equipe de software; 4 – A
estabilidade dos requisitos do produto e do ambiente. O dimensionamento diz
respeito ao tamanho do software, precisa ser quantificável e pode ser uma medida
direta (LOC) ou indireta (FP).

23.6.2) Estimativa Baseada no Problema

Baseada em LOC: A declaração de escopo é preliminar, em que cada

sentença teria que ser expandida para fornecer detalhes concretos e limites
quantitativos.

Baseada em FP: Focaliza os valores do domínio da informação e vez

das funções do software. É estimado as entradas, saídas, consultas, arquivos e
interfaces externas para o software.

23.6.5) Estimativa Baseada em Processo

A técnica mais comum para estimar um projeto é basear a estimativa

em um processo que será usado, ou seja, o processo é decomposto em um conjunto
relativamente pequeno de tarefas e o esforço necessário para realizar cada tarefa é
estimado.
 23.6.7) Estimativas com Casos de Uso

Desenvolver estimativas com casos de uso é problemático, pois os

casos de uso são descritos usando muitos formatos e estilos diferentes; representam
uma visão externa (visão do usuário) e escrita em diferentes níveis de abstração; não
tratam da complexidade e características das funções e não descrevem
comportamentos complexos.

23.7) Modelos de Estimativas Empíricos

Os dados empíricos que apóiam a maioria dos modelos de estimativa são

derivados de uma amostra limitada de projetos, por isso nenhum modelo de estimativa é
adequado a todas as classes de software e a todos os ambientes de desenvolvimento. Utiliza
fórmulas derivadas empiricamente para prever o esforço como função de LOC ou FP.
23.7.1) Estrutura dos Modelos de Estimativa
Um modelo de estimativa típico é derivado usando análise de
regressão de dados coletados em projetos de software anteriores.
23.7.2) O Modelo COCOMO II
O modelo COCOMO, que significa modelo construtivo de custo,
tornou-se um dos modelos de estimativa de custo mais amplamente usados. Evoluiu para o
modelo COCOMO II que requer informações de tamanho e usa pontos por objeto, usando a
contagem da quantidade (1) de telas, de (2) relatórios e (3) componentes.
23.7.3) A Equação de Software
A equação de software é um modelo multiderivado, que considera
uma distribuição de esforço específica ao longo da vida de um projeto de desenvolvimento de
software.
23.9) Técnicas Especializadas de Estimativa
23.9.1) Estimativa para Desenvolvimento Ágil
Como os requisitos para um projeto ágil são definidos como um
conjunto de cenários de usuário é possível desenvolver uma abordagem de estimativa que seja
informal, mas ainda razoavelmente disciplinada e significativa no contexto de planejamento de
projeto para cada incremento de software.
23.9.2) Estimativa para Projetos de Engenharia Web
Projetos de engenharia web frequentemente adotam o modelo ágil de
processo. O volume de uma estimativa de WebApp é mais bem determinado pela coleta de
medidas associadas com a aplicação, suas características de página web e características
funcionais.
23.10) A Decisão e Fazer/Comprar
Os passos envolvidos na aquisição do software são definidos pela criticalidade
do software e a ser adquirido pelo custo final. Na análise final, a decisão de fazer/comprar é
tomada com base nas seguintes condições: (1) O produto de software vai ficar disponível antes
do software desenvolvido inteiramente? (2) O custo de aquisição + personalização será menor
que o custo de desenvolvimento do software? (3) O custo de apoio externo será menor que o
custo de apoio interno? Para ajudar a chegar numa decisão existe técnicas estatísticas tais
como a análise por arvore de decisão.
Capítulo 24 – Cronogramação

24.1) Conceitos Básicos

O atraso na entrega de um software ocorre por data de entrega

irrealista, mudanças nos requisitos, subestimativa honesta da quantidade de
esforço e recursos, riscos imprevisíveis ou previsíveis que não foram
considerados, dificuldades técnicas e humanas, falha de comunicação e falha da
gerência em reconhecer o atraso e tomar atitude para corrigi-lo.

24.2) Cronogramação de Projeto

Cronogramação de projeto é uma atividade que distribui o esforço estimado
pela duração estimada do projeto, partilhando esses esforços por tarefas especificas de
engenharia de software.
24.2.1) Princípios Básicos
- Divisão do projeto em atividades e tarefas
- Determinação das interdependências de cada atividade
- Atribuição de tempo para cada tarefa
- Definição da quantidade de membros pro projeto
- Definição de um membro especifico para uma determinada tarefa
- Definição de um resultado para cada tarefa
- Cada tarefa deve ser associada a um marco de referência
24.2.2) O Relacionamento entre Pessoal e Esforço
Quando ocorre um atraso na entrega do software, tende-se a
aumentar a quantidade de pessoas nas ultimas fases do projeto, porém isso pode ter um
efeito danoso, causando atrasos ainda maiores, uma vez que o novo pessoal precisa aprender
sobre o sistema e os que vão treiná-los acabam perdendo mais tempo ainda.
24.3) Definição de um Conjunto de Tarefas para o Projeto de Software
Para desenvolver um cronograma de projeto, um conjunto de tarefas precisa
ser distribuído pelo prazo do projeto. O conjunto de tarefas vai variar dependendo do tipo de
projeto e do grau de rigor com o qual a equipe decide fazer o seu trabalho. Principais tarefas:
1) Determinação de escopo inicial
2) Planejamento conceitual preliminar
3) Avaliação do risco da tecnologia
4) Prova de Conceito
5) Implementação Conceitual
6) Reação do cliente
24.4) Definição de uma Rede de Tarefas
Rede de Tarefas é uma representação gráfica do fluxo de tarefas de um
projeto. Como pode existir tarefas paralelas, deve-se determinar as dependências entre
tarefas para garantir o progresso contínuo em direção ao término.
24.5) Cronogramação
Ferramentas de cronogramação: PERM e CPM.
Ambas as ferramentas permitem ao planejador determinar o caminho critico,
estabelecer estimativas de tempo mais prováveis e calcular limites de tempo.
24.5.1) Gráficos de Tempo
Gráfico de Tempo: É gerada após determinar e subdividir o conjunto
de tarefas, duração e data de inicio para cada tarefa.
Tabelas de Projeto: Uma listagem tabular de todas as tarefas, de suas
datas finais e iniciais, planejadas e reais e várias outras informações relacionadas.
24.5.1) Acompanhamento do Cronograma
 O acompanhamento pode ser feito de várias formas:
- Reuniões periódicas sobre o estado do projeto
- Avaliação de resultados de todas as revisões
- Determinação se os marcos de referência foram atingidos
- Comparação da data de inicio real com a planejada
- Reunião dos profissionais para obter sua avaliação do progresso
alcançado
- Avaliação do progresso quantitativamente

24.6) Análise do Valor Agregado

O valor agregado é uma medida de progresso, que nos permite avaliar a
“porcentagem de execução” de um projeto usando análise quantitativa. Para isso, é feito o
cálculo do custo orçado do trabalho realizado.