Processos de software

A equipa tem dez semanas para entregar a aplicação de salas. Se construir todos os ecrãs antes de experimentar a confirmação concorrente, pode descobrir demasiado tarde que a solução não preserva a regra. O processo organiza quando esclarecer requisitos, construir, validar e rever decisões.

Um processo de software define atividades, responsabilidades, resultados e formas de acompanhar o trabalho de desenvolvimento e manutenção. Um modelo de processo simplifica essa organização para discutirmos a sua estrutura.

Atividades e artefactos

Todos os processos precisam de tratar quatro atividades fundamentais:

Atividade	Pergunta	Exemplo de resultado
Especificação	O que deve o sistema fazer e respeitar?	Requisitos e critérios de aceitação
Desenho e implementação	Como vamos organizar e construir a solução?	Modelos, decisões e código
Validação	A solução responde às necessidades?	Resultados de testes e feedback
Evolução	O que muda depois de entrar em uso?	Alterações verificadas e novas versões

Um artefacto é um resultado do trabalho, como um modelo ou um incremento executável. A atividade produz ou altera esse resultado. Um papel identifica responsabilidades; a mesma pessoa pode assumir vários papéis.

As atividades podem repetir-se e mudar de ordem. Ao testar um protótipo, podemos descobrir que um requisito estava errado e regressar à especificação.

Planeamento preditivo e adaptativo

Num processo orientado por um plano, a equipa planeia antecipadamente uma parte significativa das atividades e acompanha os desvios. Isto ajuda a coordenar dependências, aprovações e compromissos conhecidos.

Num processo ágil, a equipa planeia de forma incremental e usa entregas e observações frequentes para adaptar o trabalho. Há objetivos, planos e documentação, com mais detalhe à medida que o conhecimento melhora.

Podemos combinar um orçamento e marcos de aprovação com iterações curtas. A escolha depende da estabilidade dos requisitos, do risco, do acesso a utilizadores e das obrigações de demonstração de conformidade.

Cascata e modelo V

Na cascata, o modelo apresenta fases distintas de requisitos, desenho, implementação, testes e operação. Idealmente, uma fase termina antes de a seguinte avançar. É mais fácil planear quando os requisitos são conhecidos e estáveis; alterações tardias podem obrigar a rever artefactos já aprovados.

O modelo V relaciona decisões com os testes que as verificam. A leitura faz-se em V: descemos nas decisões e subimos na verificação.

Lado esquerdo, decisão	Lado direito, verificação correspondente
Requisitos e cenários de aceitação	Testes de sistema e de aceitação
Arquitetura e interfaces	Testes de integração
Desenho detalhado de unidades	Testes de unidade

Na aplicação, a regra contra sobreposição aparece nos requisitos. O teste de sistema tenta duas reservas concorrentes. O desenho do repositório orienta testes de unidade da condição de sobreposição. A mensagem útil é preparar a verificação enquanto definimos a solução, em vez de pensar nos testes só no fim.

Não confundas uma figura sequencial com a afirmação de que as equipas reais nunca regressam a uma fase anterior.

Iterativo e incremental

Iterar é voltar a trabalhar uma solução para a melhorar. Incrementar é acrescentar capacidade ao produto. São ideias diferentes que podemos combinar.

Na aplicação de salas, cada entrega conserva o que já funciona e acrescenta uma capacidade:

Versão	Capacidade utilizável	Feedback possível
1	Consultar disponibilidade	Os horários apresentados correspondem às salas?
2	Consultar e reservar	O estudante compreende confirmação e conflito?
3	Consultar, reservar e cancelar	Consegue corrigir um engano antes do início?

São incrementos porque a capacidade disponível aumenta, e o feedback de uma versão pode mudar as prioridades da seguinte. Se revemos três vezes o protótipo do mesmo ecrã de reserva, temos iterações sem ainda ter acrescentado funcionalidade utilizável; um incremento também pode passar por várias iterações antes de ser entregue.

O desenvolvimento incremental permite receber feedback cedo e adiar requisitos incertos. Exige atenção à estrutura: acrescentar funcionalidades continuamente sem rever o desenho pode tornar cada alteração mais cara. Também pode não servir uma substituição que precisa de todas as funcionalidades antes de entrar em operação.

Espiral e risco

Na espiral, cada ciclo identifica objetivos e alternativas, avalia riscos, desenvolve e valida uma solução e prepara o ciclo seguinte. O trabalho é orientado pelo risco, não apenas por uma lista de funcionalidades.

Suponhamos que a aplicação depende de uma API de horários cuja qualidade desconhecemos. Antes de desenhar todos os ecrãs, fazemos uma experiência curta para verificar disponibilidade, formato dos dados e tempos de resposta. O resultado ajuda a decidir se usamos a API, uma cópia local ou outra solução.

Definimos a pergunta e o limite de tempo antes da experiência. Assim sabemos que incerteza o protótipo tem de resolver e quando já temos informação para decidir.

Integração e configuração

Também podemos construir um sistema a partir de componentes existentes. Procuramos soluções, avaliamos a sua adequação, ajustamos requisitos quando isso faz sentido, configuramos e integramos os componentes, e validamos o resultado.

Reutilizar autenticação pode reduzir código próprio. Continuamos a ter de verificar compatibilidade, licenças, atualizações, proteção de dados e comportamento quando o serviço falha. A integração passa a ser uma parte central do trabalho.

RUP

O Rational Unified Process, RUP, é iterativo e incremental, orientado por casos de uso e centrado na arquitetura. Foi desenvolvido em conjunto com a UML. Os casos de uso conduzem o trabalho desde a análise de requisitos até aos testes do sistema: cada caso descreve uma interação com resultado observável, e os testes do sistema verificam essas interações. Organiza o tempo em quatro fases:

Fase	Objetivo principal	Evidência para avançar
Inception, conceção	Delimitar visão, âmbito, viabilidade e riscos	Problema e casos críticos entendidos
Elaboration, elaboração	Estabilizar a arquitetura e reduzir riscos principais	Arquitetura avaliada nos cenários críticos
Construction, construção	Desenvolver e testar os incrementos	Produto cumpre os critérios definidos
Transition, transição	Colocar o produto em uso	Entrega, apoio e feedback dos utilizadores

Uma fase pode conter várias iterações. As disciplinas atravessam as fases com intensidades diferentes.

Disciplina	Conceção	Elaboração	Construção	Transição
Requisitos	forte	média	baixa	baixa
Desenho	baixa	forte	média	baixa
Implementação	quase ausente	média, protótipos de risco	forte	baixa
Teste	baixo	médio, avalia arquitetura	forte	forte, feedback de uso

Lê a tabela por linhas e colunas: a fase responde a «em que momento e com que objetivo dominante?», e a disciplina responde a «que tipo de trabalho estamos a realizar?». Priorizar casos de uso pertence à disciplina de requisitos, mesmo quando ocorre durante a elaboração. Identificar atores começa na conceção e pode continuar ao refinar os casos na elaboração; não é uma atividade exclusiva de uma fase.

Elaboração não significa só desenhar, tal como construção não significa só programar; a fase indica o objetivo dominante, não a única atividade permitida. Para as reservas concorrentes, a elaboração pode incluir código e testes de um protótipo do mecanismo de confirmação, pois queremos provar que a arquitetura resolve o risco antes de construir funcionalidades que dependem dela.

Valores ágeis e escolher um processo

Uma equipa tem dois objetivos: substituir um sistema obrigatório com regras conhecidas e explorar uma nova forma de procurar salas. Pode planear migração e conformidade com marcos claros, enquanto testa a pesquisa em ciclos curtos com estudantes.

Os quatro valores do Manifesto Ágil orientam esta escolha:

• Indivíduos e interações acima de processos e ferramentas.
• Software em funcionamento acima de documentação extensa.
• Colaboração com o cliente acima de negociação de contratos.
• Responder à mudança acima de seguir um plano.

Os itens da direita têm valor; os da esquerda valem mais. Na escolha do processo, pesamos características do projeto: falar semanalmente com o responsável pelas salas vale mais do que aprovar um documento de 40 páginas sem contacto, e mostrar a consulta real de disponibilidade vale mais do que descrever todos os ecrãs futuros. Mas “ágil é sempre melhor” não explica como cumprir uma auditoria, tal como “o contrato exige datas” não obriga a esperar pelo fim para receber feedback. O Scrum organiza esses ciclos com requisitos escritos como histórias com aceitação, e o XP acrescenta as práticas técnicas que os sustentam.