Módulo 01 — Introdução à Engenharia de Software

Onde estamos. Este é o ponto de partida da nossa jornada. Antes de você projetar, testar ou avaliar a qualidade de qualquer sistema, precisamos combinar o que significa, de fato, fazer engenharia quando o produto é software. Quero que você chegue à aula tendo entendido por que essa disciplina existe e por que ela é diferente de simplesmente “saber programar”.

Deixe-me começar com uma provocação honesta. Você já sabe programar. Ao longo do curso, escreveu funções, resolveu problemas, fez código funcionar. Então por que ainda precisamos de uma disciplina inteira chamada Engenharia de Software? A resposta é que escrever um programa que funciona na sua máquina, hoje, para você mesmo, é uma coisa. Construir um sistema que funcione daqui a três anos, mantido por uma equipe que muda, usado por pessoas que você nunca conhecerá, sob prazo e orçamento, é outra coisa completamente diferente. É essa segunda atividade que chamamos de engenharia de software, e é sobre ela que vamos conversar durante todo o semestre.

Por que a engenharia de software surgiu

A história aqui não é decorativa: ela explica a razão de ser de tudo o que estudaremos. No fim da década de 1960, a indústria vivia o que ficou conhecido como a crise do software. O hardware barateava e ganhava poder rapidamente, e passou a ser possível imaginar sistemas muito maiores e mais ambiciosos do que se conseguia efetivamente construir. Projetos estouravam prazos, custavam muito mais do que o previsto, entregavam menos do que prometiam e, quando entregavam, o resultado era difícil de manter e cheio de defeitos. O termo engenharia de software foi cunhado e popularizado em conferências promovidas pela OTAN em 1968 e 1969, justamente para provocar uma mudança de mentalidade: tratar a construção de software com a mesma disciplina, método e responsabilidade que as engenharias tradicionais aplicam a pontes e edifícios.

A ideia central que você deve carregar

Programar é produzir código. Fazer engenharia de software é aplicar um processo sistemático, disciplinado e mensurável à construção, operação e manutenção de software, de modo que o resultado seja confiável, sustentável e economicamente viável. A diferença não está na dificuldade de uma linha de código, e sim na escala, na duração e nas consequências.

Repare que a crise nunca foi tecnológica no sentido de “falta uma linguagem melhor”. Ela era, e ainda é, uma crise de organização, comunicação e método. Sistemas grandes falham menos por causa de um algoritmo mal escolhido e mais por causa de requisitos mal compreendidos, decisões de projeto não documentadas, ausência de testes e equipes que não conversam. Guarde isso, porque cada módulo desta disciplina ataca uma dessas causas.

O que é software, de verdade

Vale a pena refinar o que entendemos por software, porque o senso comum reduz software a “o programa”, e essa redução esconde metade do trabalho. Quando falamos de um produto de software profissional, não estamos falando apenas do código executável. Estamos falando de um conjunto que inclui os programas, mas também as estruturas de dados que eles manipulam, a documentação que descreve como o sistema funciona e como usá-lo, os arquivos de configuração e, hoje, uma quantidade enorme de conhecimento sobre como o sistema deve se comportar. Ian Sommerville, um dos autores de referência que acompanhará você o semestre inteiro, distingue dois tipos de produto: o software de produto genérico, vendido a muitos clientes no mercado, e o software sob encomenda, desenvolvido para um cliente específico. Essa distinção parece sutil, mas muda decisões inteiras de processo, de requisitos e de avaliação de qualidade.

Um segundo ponto que costuma passar despercebido é que o software não se desgasta como um objeto físico, mas se deteriora de outra maneira. Uma engrenagem falha por uso; o software falha por mudança. Cada alteração que fazemos para corrigir um defeito ou adicionar uma funcionalidade introduz o risco de novos defeitos e, com o tempo, corrói a estrutura interna do sistema, tornando-o cada vez mais caro de modificar. Esse fenômeno é a razão pela qual dedicamos tanta atenção, mais adiante, a qualidade, testes e manutenção.

As atividades fundamentais de todo processo

Independentemente da metodologia que uma equipe adote — e veremos várias ao longo do semestre —, existe um conjunto de atividades que sempre aparece, de alguma forma, em qualquer construção séria de software. Quero que você as reconheça desde já como um mapa mental, porque elas organizam praticamente todo o conteúdo dos próximos módulos.

As quatro atividades que sustentam qualquer processo

Especificação: descobrir e registrar o que o sistema deve fazer e sob quais restrições. Projeto e implementação: organizar a estrutura interna e traduzir a especificação em software que funciona. Validação: verificar que o que foi construído corresponde ao que era necessário. Evolução: modificar o software para acompanhar as mudanças de necessidade ao longo do tempo.

O diagrama a seguir mostra como essas atividades se encadeiam e, principalmente, como a evolução realimenta o ciclo. Observe que não se trata de uma linha reta que começa e termina; trata-se de um fluxo que se repete enquanto o software estiver vivo.

flowchart LR
    A[Especificação] --> B[Projeto e Implementação]
    B --> C[Validação]
    C --> D[Evolução]
    D -. novas necessidades .-> A
    C -. defeitos encontrados .-> B
    style A fill:#cfe2ff,stroke:#084298
    style B fill:#d1e7dd,stroke:#0f5132
    style C fill:#fff3cd,stroke:#664d03
    style D fill:#f8d7da,stroke:#842029

Não se preocupe em dominar cada atividade agora. A intenção é que, quando estudarmos requisitos, você saiba que está aprofundando a especificação; quando estudarmos UML e projeto, saiba que está no projeto; quando chegarmos a testes e TDD, reconheça a validação; e quando falarmos de qualidade e manutenção, entenda que estamos cuidando da evolução.

Engenharia de software como camadas

Roger Pressman, o outro grande autor que vamos consultar, propõe uma imagem que ajuda muito: a engenharia de software como um conjunto de camadas que se apoiam umas nas outras. Na base está um compromisso com a qualidade, sem o qual nada acima se sustenta. Sobre esse compromisso repousa o processo, que define a sequência e a organização do trabalho. Sobre o processo estão os métodos, que são as técnicas concretas de fazer cada atividade — como levantar requisitos, como modelar, como testar. E, no topo, estão as ferramentas, que automatizam e apoiam os métodos.

flowchart TB
    F[Ferramentas] --> M[Métodos]
    M --> P[Processo]
    P --> Q[Foco na Qualidade]
    style Q fill:#d1e7dd,stroke:#0f5132,stroke-width:2px
    style P fill:#cfe2ff,stroke:#084298
    style M fill:#e2d9f3,stroke:#59359a
    style F fill:#fff3cd,stroke:#664d03

A lição desse modelo é a ordem de prioridade. Estudantes tendem a se empolgar primeiro com as ferramentas — a IDE nova, o framework da moda. Mas uma ferramenta poderosa aplicada sobre um processo caótico apenas produz caos mais rápido. Por isso, nesta disciplina, investimos primeiro em entender processo e métodos, e tratamos as ferramentas como apoio, nunca como fim.

Atributos de um bom software

Se o objetivo é qualidade, precisamos combinar o que “qualidade” significa, e aqui não basta o software “funcionar”. Um sistema pode fazer exatamente o que foi pedido e, ainda assim, ser um mau software se for impossível de manter, inseguro ou insuportavelmente lento. A tabela abaixo reúne atributos que, juntos, caracterizam um software profissional. Vamos aprofundá-los no módulo de qualidade, mas quero que você já os conheça.

Atributo	O que significa na prática
Manutenibilidade	O software pode ser modificado com esforço proporcional à mudança pedida.
Confiabilidade	O software se comporta como esperado e falha raramente, de forma previsível.
Segurança	Informações e operações estão protegidas contra uso indevido.
Eficiência	O software usa os recursos de máquina de forma econômica.
Usabilidade	As pessoas certas conseguem usar o sistema para o fim pretendido.

Note uma tensão importante que reaparecerá o semestre todo: esses atributos competem entre si. Tornar um sistema mais seguro pode reduzir a usabilidade; otimizar a eficiência pode prejudicar a manutenibilidade. Boa engenharia é, em grande medida, a arte de fazer essas escolhas de forma consciente e justificada, e não por acaso.

Um primeiro contato com código sob a ótica da engenharia

Ao longo do semestre, usarei a linguagem Dart nos exemplos, porque sua sintaxe é clara e não nos distrai do que importa: os conceitos de engenharia. Quero que você já perceba, desde este primeiro exemplo, que a mesma funcionalidade pode ser escrita de formas com qualidades muito diferentes. Considere um trecho que decide se um cliente recebe desconto.

// Versão que "apenas funciona"
double preco(double v, int t) {
  if (t == 1) return v * 0.9;
  if (t == 2) return v * 0.8;
  return v;
}

Esse código funciona, mas repare como ele comunica mal a intenção. O que é t? O que significam 1 e 2? Um colega que o leia daqui a um ano não saberá, e essa incompreensão é exatamente a semente da deterioração que discutimos. Compare com a versão a seguir, funcionalmente idêntica, mas pensada como engenharia.

enum TipoCliente { comum, premium, vip }

double precoComDesconto(double valorBase, TipoCliente tipo) {
  const descontos = {
    TipoCliente.comum: 0.0,
    TipoCliente.premium: 0.10,
    TipoCliente.vip: 0.20,
  };
  final desconto = descontos[tipo] ?? 0.0;
  return valorBase * (1 - desconto);
}

A segunda versão custou mais linhas, e um iniciante poderia julgá-la “exagero”. No entanto, ela é legível sem comentários, resiste melhor a mudanças e comunica a regra de negócio com clareza. Essa diferença — invisível para quem só pensa em “fazer funcionar” e evidente para quem pensa em engenharia — é a mentalidade que esta disciplina quer instalar em você.

Ética e responsabilidade profissional

Não posso encerrar esta introdução sem tocar em algo que os manuais às vezes deixam para o fim, mas que considero parte da fundação. Software hoje decide crédito, medeia eleições, controla veículos e guarda dados íntimos de milhões de pessoas. Quem o constrói carrega responsabilidade proporcional. Sommerville dedica espaço à responsabilidade profissional justamente porque competência técnica sem senso ético produz sistemas tecnicamente impecáveis e socialmente danosos. Ao longo do semestre, sempre que discutirmos uma decisão de projeto, quero que você pergunte não apenas “isto funciona?”, mas também “isto é confiável, honesto e respeitoso com quem vai usar?”.

Software é uma atividade coletiva

Há um último mal-entendido que preciso desfazer antes de seguirmos, porque ele molda a forma como você deve estudar este semestre. O imaginário popular retrata quem faz software como uma pessoa solitária diante da tela, resolvendo problemas por conta própria. A realidade profissional é quase o oposto. Sistemas de qualquer porte relevante são construídos por equipes, e a maior parte das falhas de projeto não nasce de um erro técnico individual, mas de uma falha de comunicação entre pessoas: um requisito entendido de dois jeitos diferentes, uma decisão de projeto que ninguém registrou, uma suposição que cada um fez de um jeito. Sommerville insiste nesse ponto porque ele reorganiza prioridades. Se a comunicação é o principal ponto de falha, então documentar com clareza, nomear bem as coisas no código, escrever requisitos sem ambiguidade e manter registros de decisão deixam de ser burocracia e passam a ser engenharia no sentido mais estrito.

Isso tem uma consequência direta para você. Grande parte do valor de um profissional de software não está na velocidade com que ele produz código sozinho, mas na sua capacidade de tornar o próprio trabalho compreensível e continuável por outras pessoas. É por isso que, ao longo dos módulos, eu voltarei repetidamente à ideia de que o código e os documentos que você produz têm dois leitores: a máquina, que precisa executá-los, e o ser humano, que precisará entendê-los e modificá-los. Sempre que esses dois interesses entrarem em conflito, a boa engenharia tende a favorecer o leitor humano, porque é ele quem sustenta o sistema no tempo.

Como este módulo se conecta ao restante do curso

Este módulo é o alicerce. Aqui você entendeu por que a engenharia de software existe, o que a distingue da programação, quais atividades sustentam qualquer processo e o que significa qualidade. No próximo módulo, aprofundaremos os fundamentos e a noção de processo de software. Em seguida, percorreremos os modelos de ciclo de vida, a engenharia de requisitos, o projeto e a modelagem, os testes e, por fim, a qualidade. Cada tema que virá é uma resposta detalhada a um dos problemas que a crise do software revelou.

Síntese

Quero que você retenha três ideias desta primeira conversa. A primeira é que a engenharia de software nasceu de uma crise que era de método, não de tecnologia, e que essa origem explica nossa ênfase em processo e disciplina. A segunda é que todo processo, por mais diferente que pareça, se organiza em torno de especificar, projetar e implementar, validar e evoluir, e que estudaremos cada uma dessas frentes a fundo. A terceira é que qualidade não é o mesmo que “funcionar”: é um conjunto de atributos que competem entre si e que exigem escolhas conscientes. Chegue à aula com essas três ideias assentadas, porque a partir delas construiremos tudo o mais.

Para consolidar antes da aula: tente explicar, em voz alta e com suas palavras, a diferença entre “escrever um programa” e “fazer engenharia de software”. Se você conseguir defender essa diferença com um exemplo próprio, entendeu o essencial deste módulo.