Engenharia de Software

Planejamento e Gerência de Projetos de Software

Professor: Gabriel Soares Baptista

Por que planejar?

Planejar não é adivinhar o futuro. É reduzir a incerteza o suficiente para tomar decisões responsáveis.

Esta aula reúne dois blocos do Capítulo 23 de Sommerville:

1. Conceitos, preço, custos e estimativas

O que um bom plano organiza?

Exemplo: dependências escondidas

Sistema acadêmico com matrícula, boletos, histórico e autenticação institucional.

Sem planejamento, a equipe começa pelas telas mais fáceis. Parece produtivo nas primeiras semanas.

Os três momentos do planejamento

Custo não é a mesma coisa que preço

Componentes de custo: esforço (salários), hardware/software (licenças, servidores), viagens/treinamentos.

Preço para ganhar

Estratégia em que a empresa estima o valor que o cliente espera pagar e adapta a proposta.

Desenvolvimento dirigido a planos

Trabalho planejado em detalhes. Comum em projetos grandes, contratos formais, sistemas críticos e ambientes regulados.

Seções do plano: introdução, organização, análise de riscos, recursos, divisão de trabalho, cronograma, monitoramento.

Plano monitorável e o ciclo iterativo

Resultados observáveis: "relatório de vendas com exportação CSV até semana 4" em vez de "trabalhar no módulo de relatórios".

Programação de projeto

Decide como o trabalho é dividido, quando executado e por quem.

Envolve: duração, esforço, dependências, alocação de pessoas, datas, marcos e entregáveis.

Tarefa: duração × esforço

Duração e esforço não são a mesma coisa. Tarefa de 10 dias com esforço de 5 → meio período. Com esforço de 20 → duas pessoas em paralelo.

Dependências entre tarefas

Se T3 atrasar, T5 atrasa. Se T5 é contratual, o atraso se propaga.

Marcos e entregáveis

Representando cronogramas

Tabela, gráfico de barras (Gantt) ou rede de atividades.

T3 e T4 em paralelo. T5 no final porque depende das duas.

Gráfico de Gantt do livro

Atividades, paralelismo e milestones marcados no calendário.

Alocação de pessoas

O cronograma precisa considerar quem executa. Uma pessoa pode estar em vários projetos, de férias ou ser especialista em parte crítica.

Contingência e prazos realistas

Cronogramas tendem ao otimismo. A equipe imagina o caminho perfeito.

Sommerville recomenda contingência de 30% a 50% conforme incerteza e experiência.

Planejamento ágil

Métodos ágeis também planejam, mas evitam detalhar tudo cedo demais.

Fluxo do planejamento ágil

Histórias, pontos e velocidade

O ponto não é uma hora. É relativo. Uma história de 8 pontos é maior/mais incerta que uma de 2.

Limitações do planejamento ágil

Depende de envolvimento real do cliente, equipe estável e coordenação informal.

Técnicas de estimativa

Estimar é difícil: software é invisível, flexível e dependente de conhecimento humano.

Incerteza das estimativas iniciais

Se a estimativa inicial é $x$, o esforço real pode estar entre $0{,}25x$ e $4x$.

Quanto mais cedo, maior a faixa de erro. Estimativa inicial não é verdade final.

Estimativa baseada em experiência

Usa conhecimento de projetos anteriores. Melhora quando várias pessoas participam.

Passos: listar entregáveis → decompor → estimar cada parte → discutir divergências → somar + contingência → revisar com o projeto.

Modelagem algorítmica: COCOMO II

$$ \text{Esforço} = A \times \text{Tamanho}^{B} \times M $$

• $A$: práticas locais e tipo de software
• $\text{Tamanho}$: código, pontos de função ou aplicação
• $B$: expoente (crescimento não linear)
• $M$: multiplicador (produto, processo, plataforma, equipe)

Projetos maiores não crescem apenas em código. Aumentam comunicação, coordenação, integração e risco.

Submodelos do COCOMO II

O submodelo depende da informação disponível no momento.

Pontos de aplicação (modelo de composição)

Fórmula para estimar esforço em pessoas-mês ($PM$):

$$ PM = \frac{NAP \; \times \; \bigl(1 - \frac{\%reúso}{100}\bigr)}{PROD} $$

A produtividade depende de experiência, capacidade e ferramentas (ICASE).

Exemplo passo a passo

Protótipo com 80 pontos de aplicação. A equipe estima 25% de reúso. Produtividade: 10 pontos/mês.

Passo 1 — substituir os valores na fórmula:

$$ PM = \frac{80 \; \times \; \bigl(1 - \frac{25}{100}\bigr)}{10} $$

Passo 2 — resolver a porcentagem:

$$ PM = \frac{80 \times 0{,}75}{10} $$

Passo 3 — multiplicar e dividir:

$$ PM = \frac{60}{10} = 6 $$

Resultado: esforço aproximado de 6 pessoas-mês.

Drivers de custo (multiplicadores)

Os drivers de custo ajustam a estimativa para cima ou para baixo conforme características do projeto:

Duração nominal do projeto (TDEV)

Não basta dividir esforço por prazo. 60 pessoas-mês ≠ 60 pessoas em 1 mês.

A fórmula COCOMO para duração nominal em meses de calendário:

$$ TDEV = 3 \times PM^{\,0{,}33 \;+\; 0{,}2 \times (B - 1{,}01)} $$

O expoente $B$ reflete o overhead de projetos maiores: comunicação, coordenação, integração.

Exemplo: cálculo do TDEV

Projeto com esforço $PM = 60$ e expoente $B = 1{,}17$.

Passo 1 — calcular o expoente da potência:

$$ 0{,}33 + 0{,}2 \times (1{,}17 - 1{,}01) = 0{,}33 + 0{,}2 \times 0{,}16 $$

Passo 2:

$$ 0{,}33 + 0{,}032 = 0{,}362 $$

Passo 3 — aplicar a fórmula:

$$ TDEV = 3 \times 60^{\,0{,}362} $$

$$ TDEV \approx 3 \times 4{,}37 \approx 13 \text{ meses} $$

Com 60 pessoas-mês de esforço, a duração nominal é de aproximadamente 13 meses com uma equipe média de 4 a 5 pessoas.

Compressão de prazo aumenta esforço

Se o cliente exige 11 meses em vez dos 13 nominais (≈25% de compressão).

Por que o esforço sobe com prazo menor?

• mais pessoas → mais comunicação
• mais coordenação entre tarefas paralelas
• mais integração e controle

Próximos passos

Gerenciamento de Qualidade (Capítulo 24).

Padrões, revisões, medições e práticas para aumentar a qualidade do produto e do processo.