# Processos de software

Atividades do processo e modelos RUP, XP e Scrum, com um sprint de exemplo.

Página: https://resumos.rgo.pt/cadeiras/es/processos-software/

Um **processo de software** é um conjunto organizado de atividades, papéis e artefactos que leva uma equipa da ideia ao produto e à sua evolução. Sem processo, cada membro trabalha à sua maneira e ninguém sabe o que está pronto. Com processo, todos sabem o que fazer a seguir e como se decide que algo está feito.

## As atividades de todos os processos

Qualquer processo, por mais ágil ou pesado, contém estas atividades, misturadas de formas diferentes:

*   **Especificação.** Descobrir e registar o que o software deve fazer (requisitos).
*   **Desenho e implementação.** Decidir a estrutura e escrever o código.
*   **Validação.** Confirmar que o software faz o que deve e que é o produto certo.
*   **Evolução.** Adaptar o software a requisitos e ambientes novos.

A diferença entre modelos não está nas atividades, que são sempre estas, mas na ordem, na frequência e no peso da documentação. Quando comparares modelos, compara por aí.

O modelo em cascata

O modelo em cascata executa as atividades em sequência estrita: requisitos completos, depois desenho completo, depois código, depois testes, sem voltar atrás. Cada fase só começa quando a anterior está fechada e assinada. Aplica-se quando os requisitos são estáveis e o contrato é fechado, por exemplo software embarcado com especificação fixa. Quando os requisitos mudam a meio, e mudam quase sempre, a cascata obriga a renegociar tudo ou a fingir que nada mudou.

Nem todos os processos iterativos são ágeis. Três modelos intermédios que deves conseguir distinguir:

| Modelo | Ideia | Ponto forte | Quando usar |
| --- | --- | --- | --- |
| Incremental | Entregar o sistema em incrementos funcionais, cada um com requisitos, desenho, código e testes | O cliente usa algo cedo e o risco reparte-se | Requisitos conhecidos mas entrega faseada pedida |
| Prototipagem | Construir uma versão descartável para validar requisitos com o cliente | Resolve dúvidas de interface e âmbito antes de comprometer | Requisitos incertos, sobretudo de interação |
| Espiral | Cada volta passa por objetivos, riscos, desenvolvimento e planeamento, com protótipos nas zonas de risco | Ataca explicitamente os maiores riscos primeiro | Projetos grandes com riscos técnicos sérios |

## RUP: iterativo e guiado pela arquitetura

O RUP (Rational Unified Process) organiza o projeto em quatro fases, cada uma com iterações: **conceção** (perceber o problema e o âmbito), **elaboração** (fixar a arquitetura e atacar os maiores riscos), **construção** (desenvolver o produto) e **transição** (entregar e formar utilizadores). É iterativo, cada fase produz executáveis cada vez mais completos, mas continua a ser um processo com muitos papéis e artefactos formais.

No exemplo do início de sessão, cada fase deixaria um artefacto reconhecível: a conceção produz a visão do produto e os casos de uso principais; a elaboração produz a arquitetura executável com o fluxo de início de sessão a funcionar contra a base de dados; a construção produz os incrementos com todas as histórias implementadas e testadas; a transição produz o guia de entrega e a formação de quem gere as contas.

Usa o RUP como referência de processo planificado e iterativo: bom para projetos grandes com requisitos relativamente estáveis e riscos técnicos sérios, pesado para equipas pequenas com requisitos a mudar depressa.

## XP: disciplina técnica em equipa pequena

O XP (Extreme Programming) leva boas práticas ao extremo em equipas pequenas e coesas. As práticas centrais são: **programação em par** (dois programadores, um teclado), **desenvolvimento guiado por testes** (escrever o teste antes do código), **refatoração** contínua (melhorar o desenho sem mudar o comportamento), **integração contínua** (juntar o trabalho de todos várias vezes por dia) e **pequenas entregas** frequentes.

Repara na lógica: cada prática reduz o custo da mudança. Testes escritos primeiro apanham regressões, a integração diária evita divergências grandes e as entregas curtas dão feedback real do cliente. O XP é exigente com disciplina, e é por isso que várias das suas práticas aparecem noutros processos.

## Scrum: gerir o trabalho por sprints

O Scrum organiza o trabalho em **sprints**, iterações de duração fixa (tipicamente duas semanas) que terminam sempre com um incremento utilizável do produto. Os papéis são três: o **dono do produto** (decide o que tem valor e ordena a lista de trabalho), a **equipa de desenvolvimento** (decide quanto consegue fazer) e o **facilitador** (remove obstáculos e protege o processo).[1](https://resumos.rgo.pt/cadeiras/es/processos-software/#user-content-fn-agil)

A lista de trabalho (**product backlog**) contém histórias de utilizador ordenadas por valor. No **planeamento do sprint** a equipa escolhe o que cabe no sprint (**sprint backlog**). Há uma **reunião diária** curta para sincronizar (o que fiz, o que vou fazer, o que me bloqueia). No fim, a **revisão** mostra o incremento ao dono do produto e a **retrospetiva** melhora o processo da equipa.

[Vídeo: Scrum contra metodologia ágil: qual a diferença?, Darcy DeClute](https://www.youtube.com/watch?v=fu-k4O21Q1Q)

A miniatura vem do YouTube. O vídeo só carrega quando clicas. [Abrir no YouTube](https://www.youtube.com/watch?v=fu-k4O21Q1Q)

Confusões frequentes

Scrum não é ausência de planeamento: planeia-se em cada sprint e revê-se no fim. E as reuniões diárias não são para reportar ao chefe: são para a equipa se sincronizar. Se numa pergunta trocares os papéis (o dono do produto a decidir quanto cabe no sprint, por exemplo), a resposta está errada.

## RUP, XP e Scrum lado a lado

Ordem das atividades: fases sequenciais (conceção, elaboração, construção, transição), cada uma com iterações internas. Documentação: pesada e formal, com artefactos por fase. Feedback do cliente: sobretudo na conceção e na transição.

Ordem das atividades: ciclos curtíssimos guiados por testes, sem fases separadas. Documentação: mínima, o código testado é a documentação. Feedback do cliente: contínuo, com entregas frequentes e cliente presente.

Ordem das atividades: sprints de duração fixa com planeamento, execução, revisão e retrospetiva. Documentação: leve, backlog ordenado e incremento demonstrável. Feedback do cliente: no fim de cada sprint, na revisão.

A linha temporal de um sprint de duas semanas mostra onde cai cada atividade: especificação e desenho nos dias 1 e 2, implementação nos dias 3 a 7, validação nos dias 8 e 9, revisão e retrospetiva no dia 10.

![Linha temporal de um sprint de dez dias: especificação e desenho nos dias 1 e 2, implementação nos dias 3 a 7, validação nos dias 8 e 9, revisão no dia 10.](https://resumos.rgo.pt/cadeiras/es/processos-software/figura-1.svg)

## Exercício: distribuir um sprint de duas semanas

A equipa vai implementar o início de sessão da app num sprint de duas semanas (dez dias úteis). Distribui as atividades:

1.  **Dias 1 a 2, especificação e desenho.** Escrever as histórias (iniciar sessão com email e palavra passe, recuperar palavra passe, bloquear após tentativas falhadas), desenhar os casos de uso e decidir as classes. Critério de saída: o dono do produto aceita as histórias e os critérios de aceitação.
2.  **Dias 3 a 7, implementação.** Programar em pares as histórias por ordem de valor, com testes escritos antes do código e integração diária. Critério de saída: código revisto e integrado.
3.  **Dias 8 a 9, validação.** Testes de integração e de sistema sobre o incremento, mais revisão com o dono do produto. Critério de saída: incremento utilizável demonstrado.
4.  **Dia 10, revisão e retrospetiva.** Mostrar o início de sessão a funcionar, recolher feedback (por exemplo, pedir início com conta externa) e registar uma melhoria de processo para o próximo sprint.

Repara que a evolução já está prevista: o feedback da revisão entra no backlog do sprint seguinte. É isto que distingue um processo iterativo de um plano em cascata: no fim de cada sprint há produto a funcionar e uma decisão informada sobre o que fazer a seguir.

## Para saber mais

*   [Guia do Scrum da Atlassian](https://www.atlassian.com/agile/scrum): papéis, eventos e artefactos com esquemas.

Na próxima página, [Gestão de projetos](https://resumos.rgo.pt/cadeiras/es/processos-software/gestao-projetos/), vais ver como estimar quanto cabe num sprint e como perceber a meio se o plano está a cumprir-se.

## Notas de rodapé

1.  Beck, K. et al., Manifesto for Agile Software Development, 2001. O Scrum aplica diretamente dois dos seus valores: software a funcionar acima de documentação abrangente, e colaboração com o cliente acima de negociação de contratos. [Voltar](https://resumos.rgo.pt/cadeiras/es/processos-software/#user-content-fnref-agil)