Engenharia de Software¶

Histórico: a crise do software¶

Definição: Crise do software

Em 1968, a NATO Science Committee promoveu uma conferência que oficializou um problema já sentido na prática: o modo como o software vinha sendo criado até ali se mostrava ineficiente. O advento dos computadores pessoais (PCs) tinha aumentado muito a demanda por software, e a necessidade de automatizar atividades se tornara constante — mas faltava um conjunto organizado de práticas e teorias para dar conta dessa demanda com qualidade. Esse movimento é conhecido como a crise do software, e foi o gatilho para a criação formal da Engenharia de Software.

O que é software¶

Definição: Software

Um conjunto de instruções que automatiza determinadas tarefas, sendo estas definidas por meio de documentos que informam como deve ser seu funcionamento e como deve ser codificado por pessoas desenvolvedoras. Um software não é só o programa em si — engloba também toda a sua documentação, as configurações do hardware sobre o qual funciona, e as pessoas envolvidas em sua criação e utilização.

Definição: Software x Sistema — não são sinônimos

Embora usados de forma intercambiável na conversa do dia a dia, sistema é um conceito bem mais amplo, que engloba várias áreas — um sistema de agricultura reúne disciplinas como Agronomia e Administração, e sistemas existem muito antes da computação (a agricultura é uma atividade milenar). Um software, por sua vez, é uma peça relativamente nova que passou a apoiar diferentes áreas dentro de um sistema — um sistema educacional, por exemplo, pode ser suportado por diferentes softwares (financeiro, contábil, acadêmico), cada um automatizando uma parte específica.

O que é Engenharia de Software¶

Definição: Engenharia de Software (ES) — primeira definição formal

Termo cunhado pelo cientista da computação alemão Friedrich Ludwig Bauer, em 1969, numa conferência promovida pela NATO Science Committee: "o estabelecimento e uso de sólidos princípios de engenharia para obter software economicamente confiável e que trabalhe de forma eficiente em máquinas reais." Nessa primeira definição, o termo-chave é princípios de engenharia — a ES se inspirou nas engenharias tradicionais (civil, mecânica, automobilística), ainda bem mais consolidadas e padronizadas na época.

Definição: Engenharia de Software — definição atual

Com o tempo, a computação se modernizou e a engenharia deixou de ser a principal fonte de inspiração da área — dando lugar a uma definição mais ampla: "um processo multidisciplinar, que engloba métodos, computação e pessoas. É a definição de um processo produtivo denominado Processo de Software, o qual aglutina diversas teorias e práticas que visam propiciar a organização, o aumento de produtividade e, principalmente, a qualidade de um software."

Processo de Software¶

Definição: Processo de Software

Conjunto de atividades mínimas que visam produzir um software de qualidade. Quatro atividades formam esse núcleo, independente do modelo de processo escolhido:

Especificação — etapa de entendimento/documentação do que deve ser feito.
Desenvolvimento — etapa de transformação de "o que deve ser feito" em "como deve ser feito" (a codificação em si).
Validação — etapa de avaliação de que "o que foi feito" está de acordo com o "entendido e desejado".
Evolução — etapa de melhorias, constantes durante toda a vida útil do software.

Essas quatro atividades são o mínimo necessário — dependendo do Modelo de Processo utilizado, podem se expandir em outras conforme a necessidade.

Modelos de processo¶

Definição: Modelo de Processo

Meta-informações que orientam como o Processo de Software deve ser aplicado ao longo do ciclo de desenvolvimento. Vários modelos foram criados ao longo do tempo — os mais conhecidos são Cascata, Espiral, RUP e Ágil.

Cascata (Waterfall)¶

Definição: Modelo Cascata (Waterfall)

Criado por Winston Royce em 1970, foi o primeiro modelo de desenvolvimento concebido. Parte do princípio de que cada estágio só pode passar para a próxima etapa quando tudo o que poderia ser feito na etapa anterior estiver concluído — daí o nome "Cascata".

flowchart TD
    A["Definição de<br/>Necessidades"] --> B["Design de<br/>Software"]
    B --> C["Implementação"]
    C --> D["Testes e<br/>Integração"]
    D --> E["Implantação<br/>e Uso"]

Definição de necessidades — todo o entendimento e a documentação devem ser obtidos e criados a partir das necessidades identificadas.
Design de software — a arquitetura do projeto é definida, incluindo entidades, suas relações e o mapeamento entre necessidades e funcionalidades.
Implementação — a codificação do software é realizada.
Testes e integração — testes de unidade e integração validam como os componentes se comportam como um todo.
Implantação e uso — o software é disponibilizado para utilização; necessidades de mudança (evolutivas ou corretivas) identificadas aqui retornam ao início do ciclo.

Definição: Limitações do Cascata

O custo para corrigir um erro detectado numa etapa avançada é alto, já que exige retrabalho em várias etapas anteriores — e uma versão executável do software só fica disponível ao final de toda a execução. Por isso, hoje sua aplicação é restrita a projetos de pequeno porte, nos quais é viável definir tudo o que o software deve fazer antecipadamente e aguardar a entrega de uma vez só.

Espiral¶

Definição: Modelo Espiral

Apresentado por Barry W. Boehm em 1988 (artigo A Spiral Model of Software Development and Enhancement), surgiu como resposta às limitações do Cascata. Mantém o forte foco inicial na identificação e descoberta de necessidades, mas executa essa fase — e todas as demais — de forma cíclica, permitindo que o software seja construído de forma incremental, com avaliação constante de riscos a cada ciclo.

Definição: Gerência de riscos — o diferencial do Espiral

A principal diferença do Espiral em relação ao Cascata é a gerência de riscos constante: como o software é construído gradualmente, cada nova parte desenvolvida passa por uma análise de riscos quanto à sua execução e aos impactos sobre o que já foi implementado. Isso permite aplicar o modelo a projetos de qualquer porte, mitigando problemas antecipadamente — ao custo de um processo mais complexo de gerenciar, devido à constante reavaliação de riscos em cada etapa.

RUP (Rational Unified Process)¶

Definição: RUP (Rational Unified Process)

Modelo criado na década de 1990 pela Rational Software Corporation (posteriormente incorporada à IBM). Assim como o Espiral, é um modelo iterativo-incremental, fortemente atrelado à Orientação a Objetos e ao uso extensivo de UML. Suas metas: gestão de documentos, arquitetura baseada em componentes, uso de documentos visuais, verificação constante da qualidade e gestão/controle de mudanças do software.

Definição: Fases e disciplinas do RUP

O RUP organiza o trabalho em quatro fases sequenciais — Iniciação (definições iniciais, prazos e riscos), Elaboração (arquitetura e design, refinamento dos entendimentos), Construção (codificação a partir da arquitetura definida) e Transição (entrega, implantação e treinamentos) — cruzadas com um conjunto de disciplinas executadas com ênfase variável em cada fase: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Gerenciamento de Configuração e Mudança, Gerenciamento de Projeto e Ambiente.

Definição: RUP é um modelo pesado

O RUP é conhecido por ser muito robusto — possui mais de 100 documentos e mais de 40 papéis de atuação definidos, embora não seja obrigatório usar todos os recursos (sendo comuns customizações). Por sua verbosidade, sua adoção mais comum ocorre em empresas de grande porte e para softwares de grande criticidade, nos quais o ciclo de vida completo é vital para a qualidade.

Ágil¶

Definição: Manifesto Ágil

Em 2001, um grupo de especialistas (Kent Beck, Ward Cunningham, Martin Fowler, Robert C. Martin, Andrew Hunt, Jeff Sutherland, entre outros) percebeu que, apesar da evolução dos modelos existentes, ainda havia um foco excessivo no processo em si e não no produto final — o que frequentemente onerava o software em custo e prazo. A resposta foi o Manifesto Ágil, com quatro premissas fundamentais:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Definição: Por que o Ágil não elimina a documentação

Uma leitura apressada do manifesto ("software em primeiro lugar e documentação depois") poderia sugerir que documentar deixa de importar — não é o caso. Times pequenos e auto-organizados, foco em valor, ciclos curtos iterativo-incrementais e uma linguagem ubíqua comum a todos os stakeholders ainda dependem de algum nível de entendimento compartilhado do que deve ser feito — seja de forma direta (via documentação) ou indireta (via aprendizado empírico do time). Em projetos ágeis, funcionalidades simples (CRUDs) costumam ser documentadas de forma sucinta; funcionalidades mais complexas ainda se beneficiam de documentação, frequentemente só formalizada por completo após a homologação pelo solicitante, para evitar retrabalho.

Exemplos de metodologias ágeis: Scrum, Extreme Programming (XP), Agile RUP, Kanban, Lean e Crystal Methods — Scrum e Kanban são detalhados em Gestão de Projetos.

Complementos de processo: linguagens, riscos, prototipagem e levantamento¶

Gerações de linguagens de programação¶

Geração	Característica	Exemplos
1GL	Linguagem de máquina (binário), específica de cada processador	Instruções 0 e 1
2GL	Assembly: mnemônicos legíveis, ainda ligados à arquitetura	Assembly x86/ARM
3GL	Alto nível, mais próxima da linguagem humana, independente de máquina; exige compilador ou interpretador	COBOL (negócios, 1959), Fortran (científica, anos 1950), C, Java, Python
4GL	Foco no resultado, declarativas, perto do domínio (consultas e relatórios)	SQL, geradores de relatórios, low-code
5GL	Resolução de problemas por restrições e lógica (IA clássica)	Prolog

Conhecer a evolução ajuda a entender por que cada linguagem existe e por que sistemas legados em COBOL ainda vivem em bancos e governo.

Gerenciamento de riscos¶

Definição: risco de projeto

Risco é um evento ou condição incerta que, se ocorrer, afeta de forma positiva ou negativa pelo menos um objetivo do projeto (tempo, custo, escopo, qualidade). O modelo espiral foi o primeiro modelo de processo a incluir gestão de riscos.

Quatro atividades (PMBOK): identificar (de projeto, de produto e de negócio), analisar (probabilidade: muito baixa a muito alta; consequência: insignificante a catastrófica), planejar a resposta (evitar, mitigar, transferir ou aceitar) e monitorar continuamente, reavaliando em cada reunião de acompanhamento. Um registro de riscos (matriz probabilidade x impacto) ajuda a priorizar (Gestão de projetos).

Prototipagem e levantamento de requisitos¶

Protótipo: versão simplificada e rápida do software (ou de telas) para examinar e esclarecer requisitos antes de construir; pode ser descartável ou evolutivo. Reduz o risco de entregar algo que não é o que o usuário precisava (Requisitos).
Requisito é uma condição ou capacidade que o sistema deve ter; escreva-os de forma clara, verificável e sem ambiguidade, registre dependências entre requisitos e documente-os.
Entrevista: exige preparo: justificar a necessidade, definir objetivo, escolher o entrevistado, roteiro (template), conversa informal inicial, registro, transcrição e aceitação pelo entrevistado. Falhas clássicas: linguagem técnica (de ambos os lados) e analista sem conhecimento do negócio.
JAD (Joint Application Design): substitui entrevistas individuais por oficinas em grupo com usuários e desenvolvedores, com um facilitador, para levantar e validar requisitos de forma colaborativa e rápida. Complementa as técnicas de elicitação.