Fundamentos de Engenharia de Software

Dois estudantes pedem a sala A das 14h às 15h, cada um no seu telemóvel. O protótipo confirma ambos, embora uma sala não possa ter duas reservas sobrepostas. O erro obriga a decidir quem confirma, que regra aplica e como a equipa demonstra que a respeita.

Num exercício individual, podes controlar entradas e execução. Numa aplicação partilhada, os pedidos chegam em ordens diferentes e os utilizadores têm interesses distintos. A regra precisa de valer nessas condições, mesmo que cada ecrã, observado isoladamente, pareça funcionar.

O que a disciplina estuda

Engenharia de Software é a aplicação sistemática de princípios de engenharia ao desenvolvimento, operação e manutenção de software. Sistemática significa que a equipa consegue explicar o processo seguido, as decisões tomadas e a evidência que as sustenta.

O produto inclui programas, configuração, dados necessários à operação e documentação. Um repositório pode conter código correto e ser difícil de manter se não explicar como instalar, testar ou recuperar o sistema.

Guardar reservas num ficheiro local pode servir um protótipo com um utilizador. Para vários utilizadores e dispositivos, precisamos de uma autoridade comum e de controlar alterações concorrentes. A escolha técnica depende destas condições de uso.

Qualidade e custo

Um sistema de qualidade satisfaz as necessidades nas condições de uso previstas. Consideramos o comportamento funcional e características como desempenho, fiabilidade, segurança, usabilidade e capacidade de manutenção.

Na aplicação de salas:

• O estudante consegue consultar disponibilidade e criar uma reserva válida.
• Duas tentativas concorrentes não criam uma sobreposição.
• Um estudante não altera a reserva de outro sem autorização.
• A equipa consegue mudar a duração máxima sem editar regras espalhadas por vários ecrãs.

As características podem entrar em conflito. Uma confirmação instantânea sem verificar o servidor parece rápida, mas pode comunicar um sucesso falso, por isso temos de definir o que significa confirmar e medir o desempenho desse comportamento correto.

O custo do ciclo de vida inclui desenvolvimento, operação, correção e evolução. Uma solução barata de implementar pode exigir muitas horas de suporte. Uma abstração criada para necessidades imaginadas também custa tempo de compreensão e manutenção.

Complexidade e trabalho em equipa

A complexidade técnica vem de estados, dependências, concorrência, distribuição e restrições. A complexidade de gestão vem de pessoas, interesses, coordenação, contratos e incerteza. Uma aplicação pequena com vários serviços externos pode ser tecnicamente arriscada. Um sistema tecnicamente conhecido pode ser difícil de gerir se os intervenientes discordarem do objetivo.

Um stakeholder, ou parte interessada, influencia o sistema ou sofre os seus efeitos. O estudante, o responsável pelas salas, a equipa de suporte e a direção têm necessidades distintas, e o comprador e o utilizador não são necessariamente a mesma pessoa.

Por isso a equipa deve partilhar termos e decisões. Se uma pessoa entende “reservada” como pedido enviado e outra como confirmação do servidor, vão construir comportamentos incompatíveis.

Esforço não é duração

O esforço mede trabalho, por exemplo em pessoa-dias. A duração mede o tempo de calendário até terminar. Três pessoas a trabalhar dois dias produzem até seis pessoa-dias de esforço, mas isso não prova que uma tarefa de seis pessoa-dias possa terminar em dois dias.

Há trabalho que não podemos dividir livremente. Novas pessoas precisam de aprender e alguém tem de as orientar. Também aumenta a coordenação. Com $n$ pessoas, o número de pares possíveis é

$$P = \frac{n(n-1)}{2}.$$

Cada pessoa pode comunicar com $n-1$ colegas. O produto $n(n-1)$ conta Ana–Bruno e Bruno–Ana separadamente, por isso dividimos por dois. Para quatro pessoas temos $4 \times 3 / 2 = 6$ pares; para sete temos $7 \times 6 / 2 = 21$ pares. Isto conta pares possíveis, não reuniões obrigatórias nem horas de comunicação.

A contagem ajuda a perceber a lei de Brooks: acrescentar pessoas a um projeto atrasado pode atrasá-lo ainda mais, porque cada pessoa nova precisa de aprender e aumenta a coordenação. Não é uma proibição de contratar. Depende de a tarefa se dividir e do custo de integrar o trabalho.

Como a disciplina surgiu

À medida que os computadores passaram a executar sistemas maiores, tornou-se difícil prever custos, concluir projetos e garantir fiabilidade. A expressão “crise do software” descreveu estes problemas. A conferência NATO de 1968 ajudou a consolidar a Engenharia de Software como disciplina.

No webinar, observa como a evolução do hardware altera os problemas de organização, abstração e custo do software:

Abrir no YouTube

Algumas ideias mudaram a forma de trabalhar:

Ideia	Problema que ajuda a resolver
Programação estruturada	Fluxos de controlo difíceis de seguir
Modularidade e ocultação de informação	Uma alteração espalha-se por muitas partes
Abstrações e orientação a objetos	Representar conceitos e responsabilidades
Modelação e UML	Comunicar estrutura e comportamento
Desenvolvimento ágil	Aprender com requisitos e necessidades que mudam
Integração contínua	Descobrir incompatibilidades antes de uma integração final

Não há uma técnica que elimine toda a dificuldade. A complexidade do problema, a necessidade de mudança e a comunicação continuam a exigir julgamento. Esta é a tese de Fred Brooks em «No Silver Bullet» (1986): o esforço divide-se entre a dificuldade essencial do problema e a dificuldade acidental das ferramentas e representações. Brooks argumentava que nenhuma técnica isolada produziria, por si só, na década seguinte uma melhoria de uma ordem de magnitude em produtividade, fiabilidade ou simplicidade, sem excluir ganhos acumulados de várias técnicas combinadas.

Do problema à evidência

No caso da reserva duplicada, reconstruímos o raciocínio:

1. Definimos a regra: duas reservas confirmadas da mesma sala não se sobrepõem.
2. Decidimos que o servidor verifica e cria a reserva numa operação atómica: outra tentativa não pode intercalar-se entre a verificação e a criação.
3. Implementamos a regra no local que controla os dados, não só no ecrã.
4. Testamos duas tentativas concorrentes e esperamos uma confirmação e uma recusa.
5. Registamos a decisão para a próxima equipa perceber por que a verificação local não chega.

Um teste passado dá evidência para este cenário, mas não prova que todos os comportamentos possíveis estejam corretos. Esta ligação entre necessidade, decisão e evidência acompanha o ciclo de vida.