UA3 — Analisar e Desenvolver Plano de Projeto
O plano de projeto documenta tudo que envolve o desenvolvimento de um software: escopo, equipe, infraestrutura, cronograma, riscos e acompanhamento. Sem ele, o projeto está sujeito a instabilidade, retrabalho e custos imprevistos.
O que é o Plano de Projeto?
O projeto de software começa quando termina a primeira iteração da engenharia de requisitos. Seu objetivo é aplicar princípios, conceitos e práticas que levem ao desenvolvimento de um sistema de alta qualidade. O plano de projeto é o documento que norteia toda a equipe durante o ciclo de desenvolvimento — definindo métricas, atividades por membro, estimativas e as mudanças que inevitavelmente ocorrem.
Manifesto do Projeto de Software — Mitch Kapor
“Projeto é onde você fica com um pé em dois mundos — o da tecnologia e o das pessoas. Um software bem projetado apresenta três qualidades: solidez (sem bugs que impeçam seu funcionamento), comodidade (adequado ao propósito para o qual foi planejado) e deleite (a experiência de uso deve ser prazerosa).”
Três características de um bom projeto
- Deve implementar todos os requisitos explícitos do modelo de requisitos e acomodar os implícitos desejados pelos envolvidos.
- Deve ser um guia legível e compreensível para quem gera código, testa e dá suporte ao software.
- Deve dar uma visão completa do software, tratando os domínios de dados, funcional e comportamental do ponto de vista da implementação.
As 7 seções do Plano de Projeto
| Seção | O que contém |
|---|---|
| Introdução | Objetivos do projeto e restrições que afetam o gerenciamento |
| Organização do projeto | Como a equipe é organizada; papéis e responsabilidades de cada membro |
| Análise de riscos | Riscos identificados, probabilidade de ocorrência e estratégias de mitigação |
| Requisitos de hardware e software | Infraestrutura necessária para o desenvolvimento |
| Divisão de trabalho (WBS) | Partição do projeto em atividades, milestones e entregáveis associados |
| Cronograma do projeto | Dependências entre atividades, estimativa de tempo e alocação de pessoas |
| Monitoração e relatórios | Relatórios gerenciais: o que, quando e como monitorar o progresso |
Planos complementares
Além do plano principal, planos específicos podem ser criados para dar suporte a atividades críticas:
| Plano | Descrição |
|---|---|
| Qualidade | Procedimentos de qualidade e normas que serão aplicados |
| Validação | Abordagem, recursos e cronograma para validação do sistema |
| Gerenciamento de configuração | Procedimentos e estruturas para controle de versão e mudanças |
| Manutenção | Previsão de requisitos, custos e esforço de manutenção pós-entrega |
| Desenvolvimento da equipe | Como as habilidades e experiências dos membros serão desenvolvidas |
Custos de um projeto de software
Os custos de um projeto de software se dividem em três parâmetros principais:
- Custo de esforço — o maior componente; engloba o tempo da equipe
- Custos de hardware e software — licenças, servidores, ferramentas e manutenção
- Custos de viagens e treinamentos — deslocamentos e capacitação
EAP — Estrutura Analítica do Projeto (WBS)
A EAP decompõe hierarquicamente o trabalho em pacotes gerenciáveis. O resultado é o documento central do plano: WBS (Work Breakdown Structure) com alocação pessoa-tarefa, análise de riscos, cronograma e orçamento. A regra: divida até que cada tarefa dure entre 1 semana e 8–10 semanas — mais que isso deve ser subdividida.
Projeto
/
Módulo A Módulo B
/ \
Tarefa 1 Tarefa 2 Tarefa 3
(2 dias) (3 dias) (1 dia)
Quatro etapas da programação do projeto
- 1. Identificar atividades — a partir dos requisitos de software e informações de projeto
- 2. Identificar dependências — quais atividades precisam terminar antes de outras começar
- 3. Estimar recursos — tempo, pessoas e infraestrutura por atividade
- 4. Alocar pessoas e criar gráficos — Gráfico de Gantt: barras baseadas em calendário, mostrando responsáveis, duração prevista e datas de início/fim
Modelos de ciclo de vida
| Modelo | Características | Melhor para |
|---|---|---|
| Cascata (Waterfall) | Fases sequenciais; saída de uma fase é a entrada da próxima | Escopo fixo e bem definido |
| Incremental | Entregas parciais funcionais em ciclos; cada ciclo agrega funcionalidade | Entregas contínuas ao cliente |
| Scrum / Ágil | Sprints curtos (1–4 sem.), backlog priorizado, feedback constante | Produtos digitais com requisitos mutáveis |
| Espiral | Cada ciclo inclui análise de risco; mais iterações = menos risco acumulado | Sistemas críticos e de alta complexidade |
Técnicas de estimativa
Pontos de Função
Mede o tamanho funcional do software independente de tecnologia ou linguagem.
Story Points
Esforço relativo entre tarefas em Scrum — não horas, mas complexidade comparativa.
COCOMO
Modelo matemático que estima custo a partir do tamanho do sistema (linhas de código).
Planning Poker
Técnica colaborativa: cada membro estima independentemente; divergências são discutidas.
Estimativas são sempre imprecisas — e ainda assim essenciais
Nenhuma estimativa é exata. O valor está no processo: ele força a equipe a pensar sobre o problema antes de codificar. A melhor abordagem combina planejamento formal e métodos ágeis, ajustando o equilíbrio conforme o tipo de projeto.
Práticas Modernas — Plano de Projeto
- Scrum substituiu o Gantt na maioria dos times ágeis. Em vez de WBS detalhado, usa-se Product Backlog + Sprint Planning. Ferramentas: Jira, Linear, GitHub Projects.
- Story Mapping (Jeff Patton) é a alternativa ágil à WBS: organiza funcionalidades em uma narrativa de jornada do usuário, priorizando por valor de negócio.
- OKRs (Objectives and Key Results) substituíram os tradicionais cronogramas de milestones em empresas de tecnologia — o objetivo define o “por quê”, e os key results medem o sucesso objetivamente.
- Estimativas em pontos de função estão em desuso em times Scrum; story points (Fibonacci) ou T-shirt sizes são mais comuns. Planning Poker permanece válido.
Dicas para a Prova
- Quando o enunciado descrever como o usuário vai interagir ou como o software se comunicará via APIs, o elemento em foco é o Projeto de Interface.
- Se falar de equipe e papéis, é Organização do Projeto. Se falar de o que pode dar errado, é Análise de Riscos.
- As 7 seções do plano de projeto: Introdução, Organização, Análise de Riscos, Requisitos de HW/SW, WBS, Cronograma, Monitoração.
- Custo de esforço = maior componente do custo de software (engloba o tempo da equipe).
- WBS: divida tarefas até durarem entre 1 semana e 8–10 semanas.
Referências bibliográficas desta UA
- PRESSMAN, R. S.; MAXIM, B. R. Engenharia de software: uma abordagem profissional. 8. ed. Porto Alegre: AMGH, 2016.
- SOMMERVILLE, I. Engenharia de software. 9. ed. São Paulo: Pearson, 2011.
- McLAUGHLIN, R. Some notes on program design. ACM SIGSOFT Software Engineering Notes, v. 16, n. 4, 1991.