A Crise do Software: do caos à engenharia

Engenharia de Software Modelos de Ciclo de Vida Design Patterns História da Computação Metodologias ...

Engenharia de Software Modelos de Ciclo de Vida Design Patterns História da Computação Metodologias

📚 Neste artigo você vai aprender

1. 1 A Crise do Software
2. 2 Modelo cascata
3. 3 Modelo espiral
4. 4 Modelo iterativo e incremental
5. 5 Comparativo dos modelos
6. 6 Padrões de projeto (design patterns)
7. 7 Legado e lições
8. 📖 Glossário de termos técnicos

1. A Crise do Software

No final da década de 1960, a indústria da computação vivia um paradoxo: o hardware evoluía em ritmo exponencial, mas a capacidade de produzir software confiável ficava cada vez mais para trás. Projetos atrasavam, orçamentos explodiam e sistemas entregues frequentemente não atendiam às necessidades dos usuários. Esse conjunto de problemas crônicos recebeu o nome de Crise do Software — termo cunhado durante a Conferência de Engenharia de Software da OTAN 📖, realizada em Garmisch, Alemanha, em 1968 [1].

💡 Definição

Crise do Software é o nome dado ao conjunto de problemas sistêmicos enfrentados pela indústria de desenvolvimento de software entre as décadas de 1960 e 1990: projetos cronicamente atrasados, custos imprevisíveis, defeitos abundantes e incapacidade de atender aos requisitos dos usuários.

📊 Os números da crise Dados históricos

Relatórios da época e estudos posteriores revelaram números alarmantes [2]:

~60%

Projetos atrasados

2–3×

Estouro de custo

~30%

Projetos cancelados

~20%

Atendiam requisitos

O projeto do OS/360 📖 da IBM é frequentemente citado como caso emblemático: envolveu milhares de programadores, atrasou anos e acumulou inúmeros defeitos, sendo descrito por Frederick Brooks como um "pântano de alcatrão" [3].

⚠️ Sintomas recorrentes

A crise se manifestava por cinco sintomas interligados [4]:

1

Atrasos crônicos

A falta de metodologia tornava impossível estimar cronogramas realistas.

2

Custos imprevisíveis

Sem métricas de estimativa, orçamentos eram suposições otimistas.

3

Defeitos abundantes

Ausência de testes formais resultava em produtos instáveis.

4

Desalinhamento com o usuário

Sem análise rigorosa de requisitos, o software não resolvia o problema real.

5

Manutenção impossível

"Código espaguete" 📖 sem documentação tornava qualquer evolução um risco.

🕰️ Linha do tempo

1960s

Complexidade cresce com mainframes 📖. Projetos como SAGE 📖 e OS/360 falham sistematicamente [3].

1968

Conferência da OTAN em Garmisch cunha o termo "crise do software" [1].

1970

Royce descreve o modelo cascata [5].

1970–80s

Linguagens estruturadas (C, Pascal), programação modular 📖 e primeiras ferramentas CASE 📖.

1986

Boehm propõe o modelo espiral [6]. Brooks publica "No Silver Bullet" [7].

1990s

CMM 📖, orientação a objetos 📖 e padrões de projeto (GoF) [8].

2001

Manifesto Ágil [9].

---

2. Modelo Cascata

O modelo cascata (waterfall) foi o primeiro modelo de ciclo de vida de software formalizado. Descrito por Winston Royce em 1970 [5], propõe que o desenvolvimento avance em fases sequenciais — como água descendo uma cascata — onde cada fase deve ser concluída antes que a próxima se inicie.

🔢 As seis fases Sequencial

1

Requisitos

Levantamento e documentação completa. O cliente aprova antes de prosseguir.

2

Projeto (design)

Arquitetura, módulos, banco de dados e interfaces — tudo antes de codificar.

3

Implementação

Codificação do sistema com base no projeto aprovado.

4

Testes

Verificação e validação contra os requisitos documentados.

5

Implantação

Entrega e instalação no ambiente do cliente.

6

Manutenção

Correções, adaptações e melhorias ao longo da vida útil.

⚠ Curiosidade

Royce nunca defendeu o cascata puro. No artigo original, ele já sugeria ciclos de feedback entre fases — mas a indústria adotou apenas a versão sequencial simplificada [5].

❌ Limitações e críticas

A principal fragilidade é a premissa de que os requisitos podem ser completamente definidos no início [10]. Se um erro só é descoberto na fase de testes, o custo de correção é exponencialmente maior [4].

O cliente só vê o sistema funcionando na etapa final, quando mudanças significativas são quase inviáveis. Essa rigidez motivou a busca por modelos alternativos.

---

3. Modelo Espiral

Proposto por Barry Boehm em 1986 [6], o modelo espiral combina o cascata com prototipagem 📖 e adiciona a análise de riscos como atividade central de cada ciclo.

🌀 Os quatro quadrantes Boehm, 1986

1

Planejamento

Definir objetivos, alternativas e restrições para esta iteração.

2

Análise de riscos

Identificar riscos técnicos, de custo e de prazo. Se o risco for inaceitável, o projeto pode ser cancelado.

3

Desenvolvimento e testes

Projetar, codificar e testar o incremento planejado.

4

Avaliação do cliente

O cliente revisa o resultado e fornece feedback para a próxima volta.

💡 Quando usar

Especialmente adequado para projetos grandes e de alto risco — sistemas militares e aeroespaciais — onde o custo de fracasso é extremamente elevado [10].

---

4. Modelo Iterativo e Incremental

Em vez de entregar tudo no final, o sistema é construído em partes. Cada incremento passa por um mini-ciclo completo de análise, projeto, codificação e testes [4].

🔄 Iterativo vs. incremental Conceitos

↻

Iterativo = refinar

Cada ciclo melhora o que já existe. Como um pintor que faz um esboço, depois adiciona detalhes e cor.

+

Incremental = adicionar

Cada ciclo entrega uma parte nova e funcional. Como construir uma casa cômodo por cômodo.

Na prática, quase sempre se combinam. As metodologias ágeis — Scrum 📖, XP 📖, Kanban 📖 — são a evolução direta desse modelo [9].

---

5. Comparativo dos Modelos

Nenhum modelo é universalmente superior — cada um se adequa a contextos diferentes [10]:

📋 Cascata vs. espiral vs. iterativo

Critério	Cascata	Espiral	Iterativo
Fluxo	Linear, uma passada	Ciclos com análise de risco	Mini-ciclos de entrega
Requisitos	Fixos no início	Refinados a cada volta	Evoluem continuamente
Entrega	Somente no final	Protótipos + produto final	Incrementos funcionais
Feedback	Só na entrega	A cada volta	A cada incremento
Custo de mudança	Muito alto	Médio	Baixo
Risco	Alto	Controlado	Moderado
Ideal para	Requisitos estáveis	Projetos grandes, alto risco	Maioria dos projetos modernos

---

6. Padrões de Projeto (Design Patterns)

Padrões de projeto são soluções reutilizáveis para problemas recorrentes no design de software. O conceito foi popularizado pelo livro de Gamma, Helm, Johnson e Vlissides — o Gang of Four — que catalogou 23 padrões em três categorias [8].

💡 O que são

Não são código pronto, mas receitas documentadas que descrevem como estruturar classes e objetos para resolver um tipo específico de problema de forma elegante. Funcionam como um vocabulário compartilhado entre engenheiros.

🏭 Criacionais — como criar objetos 5 padrões

Singleton

Uma única instância global

Factory Method

Subclasses decidem o que criar

Abstract Factory

Famílias de objetos relacionados

Builder

Construção passo a passo

Prototype

Clonagem de instâncias

🧩 Estruturais — como compor objetos 7 padrões

Adapter

Traduz interfaces incompatíveis

Facade

Interface simplificada

Decorator

Adiciona responsabilidades

Composite

Árvore parte-todo

Bridge

Separa abstração e implementação

Flyweight

Compartilha estado comum

Proxy

Substituto controlado

💬 Comportamentais — como objetos interagem 11 padrões

Observer

Notificação um-para-muitos

Strategy

Algoritmos intercambiáveis

Command

Encapsula requisições

Iterator

Percorre coleções

State

Comportamento por estado

Template Method

Esqueleto de algoritmo

Mediator

Centraliza comunicação

Chain of Resp.

Cadeia de tratadores

Visitor

Operação sobre estrutura

Memento

Captura estado para undo

Interpreter

Avalia gramáticas

---

7. Legado e Lições

A Crise do Software nunca teve uma resolução definitiva — como argumentou Brooks, a complexidade essencial do software é irredutível [7].

O que houve foi uma resposta acumulativa: o cascata [5] mostrou que era preciso ter processo; o espiral [6] mostrou que era preciso gerenciar riscos; o modelo iterativo mostrou que era preciso obter feedback rápido; e o Manifesto Ágil [9] combinou tudo com foco em pessoas e adaptação contínua.

Os padrões de projeto [8] contribuíram com um vocabulário compartilhado que permitiu comunicar soluções complexas de forma precisa e eficiente.

🚀 Conclusão

A grande lição da Crise do Software é que não basta escrever código — é preciso engenharia: processo, gestão de riscos, feedback, colaboração e reutilização de conhecimento. A crise não acabou; aprendemos a conviver com a complexidade.

📖 Glossário de Termos Técnicos

OTAN (em inglês: NATO — North Atlantic Treaty Organization)

Organização do Tratado do Atlântico Norte, aliança político-militar intergovernamental fundada em 1949. Em 1968, o comitê científico da OTAN patrocinou a conferência em Garmisch (Alemanha) que cunhou o termo "engenharia de software" e diagnosticou formalmente a crise do software [1].

Mainframe

Computador de grande porte, com alta capacidade de processamento e armazenamento, utilizado por grandes organizações para tarefas críticas como processamento de transações em lote, censos e cálculos científicos. Nas décadas de 1960–70, o crescimento da complexidade dos mainframes evidenciou a incapacidade da indústria de produzir software na mesma escala [4].

SAGE (Semi-Automatic Ground Environment)

Sistema de defesa aérea automatizado dos Estados Unidos, desenvolvido entre os anos 1950 e 1960. Foi um dos maiores projetos de software da época, envolvendo milhares de programadores e milhões de linhas de código. Seus desafios ilustraram os primeiros sinais da crise do software [4].

OS/360

Sistema operacional desenvolvido pela IBM para a família de computadores System/360 na década de 1960. Considerado um dos projetos de software mais problemáticos da história: atrasou anos, ultrapassou amplamente o orçamento e foi entregue com milhares de defeitos. Frederick Brooks liderou o projeto e narrou suas lições no livro The Mythical Man-Month [3].

Código espaguete (spaghetti code)

Termo pejorativo para código-fonte com fluxo de controle complexo, emaranhado e sem estrutura clara, difícil de ler, manter e depurar. O nome faz analogia com um prato de espaguete, em que os fios se entrelaçam de forma caótica. Era um problema comum antes da adoção da programação estruturada [4].

Programação modular

Paradigma de desenvolvimento que consiste em dividir um programa em módulos independentes e coesos, cada um responsável por uma funcionalidade específica. Os módulos podem ser desenvolvidos, testados e mantidos separadamente, promovendo reuso e reduzindo a complexidade global do sistema [10].

Ferramentas CASE (Computer-Aided Software Engineering)

Classificação que abrange todas as ferramentas baseadas em computadores que auxiliam atividades de engenharia de software, desde análise de requisitos e modelagem até programação e testes. Surgiram nos anos 1980 como tentativa de automatizar e padronizar o processo de desenvolvimento [10].

CMM (Capability Maturity Model)

Modelo de maturidade de capacidade desenvolvido pelo SEI (Software Engineering Institute) da Carnegie Mellon University em 1991. Define cinco níveis de maturidade organizacional para o processo de desenvolvimento de software — de "inicial" (caótico) a "otimizado" (melhoria contínua). Foi posteriormente expandido para o CMMI [11].

Orientação a objetos (Object-Oriented Programming — OOP)

Paradigma de programação baseado no conceito de "objetos", que encapsulam dados (atributos) e comportamentos (métodos) em unidades coesas. Seus pilares são: encapsulamento, herança, polimorfismo e abstração. Linguagens como Smalltalk, C++ e Java popularizaram o paradigma, que se tornou dominante a partir dos anos 1990 [4].

Prototipagem (prototyping)

Abordagem de desenvolvimento em que uma versão preliminar e simplificada do sistema (protótipo) é construída rapidamente para validar requisitos, testar conceitos e obter feedback do usuário antes de investir no desenvolvimento completo. Pode ser descartável (usada apenas para aprendizado) ou evolutiva (refinada até se tornar o produto final) [10].

Scrum

Framework ágil para gestão e desenvolvimento de produtos complexos. Organiza o trabalho em ciclos curtos chamados sprints (tipicamente 2 a 4 semanas), com papéis definidos (Product Owner, Scrum Master, equipe de desenvolvimento) e cerimônias regulares (planejamento, revisão, retrospectiva e reuniões diárias) [12].

XP (Extreme Programming)

Metodologia ágil criada por Kent Beck no final dos anos 1990, focada em práticas de engenharia de software como programação em par, desenvolvimento orientado a testes (TDD), integração contínua, refatoração constante e entregas frequentes. Enfatiza feedback rápido e simplicidade [13].

Kanban

Método de gestão visual do fluxo de trabalho, originado no sistema de produção da Toyota e adaptado para desenvolvimento de software por David Anderson. Utiliza um quadro com colunas representando etapas do processo e cartões representando itens de trabalho. Seus princípios incluem limitar o trabalho em progresso (WIP) e otimizar o fluxo contínuo [14].

Referências

1. [1] NAUR, Peter; RANDELL, Brian (ed.). Software Engineering: report on a conference sponsored by the NATO Science Committee. Garmisch, Germany: NATO, 7–11 Oct. 1968. Brussels: Scientific Affairs Division, NATO, 1969. Disponível em: http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF. Acesso em: 14 mar. 2026.
2. [2] THE STANDISH GROUP. CHAOS Report. Boston: The Standish Group International, 1995.
3. [3] BROOKS, Frederick P. The Mythical Man-Month: essays on software engineering. Reading, MA: Addison-Wesley, 1975. ISBN 0-201-00650-2.
4. [4] PRESSMAN, Roger S.; MAXIM, Bruce R. Engenharia de software: uma abordagem profissional. 9. ed. Porto Alegre: AMGH, 2020. ISBN 978-85-8055-534-1.
5. [5] ROYCE, Winston W. Managing the development of large software systems. In: PROCEEDINGS OF IEEE WESCON, Los Angeles, 1970. Proceedings [...]. New York: IEEE, 1970. p. 1–9.
6. [6] BOEHM, Barry W. A spiral model of software development and enhancement. ACM SIGSOFT Software Engineering Notes, New York, v. 11, n. 4, p. 14–24, Aug. 1986. DOI: 10.1145/12944.12948.
7. [7] BROOKS, Frederick P. No silver bullet: essence and accidents of software engineering. Computer, Washington, v. 20, n. 4, p. 10–19, Apr. 1987. DOI: 10.1109/MC.1987.1663532.
8. [8] GAMMA, Erich; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns: elements of reusable object-oriented software. Reading, MA: Addison-Wesley, 1994. ISBN 0-201-63361-2.
9. [9] BECK, Kent et al. Manifesto for Agile Software Development. 2001. Disponível em: https://agilemanifesto.org/. Acesso em: 14 mar. 2026.
10. [10] SOMMERVILLE, Ian. Engenharia de software. 10. ed. São Paulo: Pearson Education do Brasil, 2016. ISBN 978-85-430-1968-2.
11. [11] PAULK, Mark C. et al. Capability Maturity Model for Software, Version 1.1. Pittsburgh: Software Engineering Institute, Carnegie Mellon University, 1993. (Technical Report CMU/SEI-93-TR-024). Disponível em: https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=11955. Acesso em: 15 mar. 2026.
12. [12] SCHWABER, Ken; SUTHERLAND, Jeff. The Scrum Guide: the definitive guide to Scrum: the rules of the game. 2020. Disponível em: https://scrumguides.org/. Acesso em: 15 mar. 2026.
13. [13] BECK, Kent; ANDRES, Cynthia. Extreme Programming Explained: embrace change. 2. ed. Boston: Addison-Wesley, 2004. ISBN 0-321-27865-8.
14. [14] ANDERSON, David J. Kanban: successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press, 2010. ISBN 978-0-9845214-0-1.