engenharia de software - aula 2

Página 1

A ideia central é:

Existem diferentes maneiras de organizar o desenvolvimento de um software.

Quando uma empresa vai criar um sistema, ela não simplesmente começa a programar.

Existe um processo:

entender o que o cliente quer → planejar → desenvolver → testar → entregar → manter/evoluir.

A aula apresenta diferentes maneiras de organizar esse processo.

1. 📋 Modelos Prescritivos x Adaptativos

Essa é uma distinção que você precisa saber.

🔵 Prescritivo

É mais rígido e planejado antecipadamente.

Você define as etapas e segue uma ordem.

Exemplo:

Requisitos → Projeto → Programação → Testes → Entrega

O principal exemplo é o Modelo Cascata.

🟢 Adaptativo

É mais flexível.

Você pode desenvolver, receber feedback, mudar alguma coisa e continuar desenvolvendo.

Exemplos:

Scrum

XP

Crystal

FDD

DSDM

A aula caracteriza os adaptativos como modelos focados no produto e nas pessoas, abertos a mudanças e com planejamento incremental e flexível.

Guarda:

Prescritivo = planeja bastante antes e segue uma estrutura.

Adaptativo = desenvolve e se adapta às mudanças.

Página 2

2. 🌊 Modelo Cascata

Esse provavelmente é um dos pontos mais importantes da aula.

Imagine uma escada:

Requisitos ↓ Projeto ↓ Implementação ↓ Testes ↓ Implantação/Manutenção

Você termina uma etapa antes de passar para a próxima.

O problema?

Imagine que o cliente diga:

"Ah, esqueci de falar. Quero que o sistema tenha essa função também."

No Cascata, isso pode ser complicado porque você já avançou bastante no projeto.

Por isso, ele não é bom quando os requisitos mudam muito.

Quando usar Cascata?

Quando:

os requisitos estão bem definidos;

provavelmente haverá poucas mudanças;

o projeto é relativamente previsível.

A aula inclusive diz que o Cascata é apropriado quando os requisitos são bem compreendidos e as mudanças são limitadas.

🎯 Resumo:

Cascata = organizado, previsível, mas pouco flexível.

3. 🧪 Modelo de Prototipação

Agora imagine que o cliente não sabe exatamente o que quer.

Você pode criar uma versão inicial do sistema:

"É mais ou menos isso que você imaginou?"

Cliente:

"Não, quero mudar isso."

Você modifica.

"Agora está melhor?"

E vai refinando.

O processo apresentado na aula é:

Requisitos → Projeto rápido → Protótipo → Avaliação → Refinamento.

🎯 Quando é útil?

Quando o cliente não definiu detalhadamente os requisitos.

Problema?

Como o objetivo é criar algo rapidamente, o protótipo pode acabar sendo feito sem muita preocupação com qualidade e manutenção a longo prazo.

Página 3

4. 🔄 Desenvolvimento Incremental

Esse é fácil de entender.

Em vez de fazer o sistema inteiro e entregar só no final, você divide o sistema em partes e vai entregando aos poucos.

Por exemplo, um sistema de loja:

Incremento 1

Cadastro de usuários.

Incremento 2

Produtos.

Incremento 3

Carrinho.

Incremento 4

Pagamento.

Você vai construindo o sistema incrementalmente.

A aula explica que o sistema é entregue ao cliente em incrementos e que os requisitos são priorizados.

🎯 Guarda:

Incremental = entregar o sistema em partes.

5. 🌀 Modelo Espiral

O Espiral mistura algumas ideias do Cascata e da Prototipação e adiciona uma preocupação importante:

RISCOS.

A aula apresenta o modelo como uma abordagem que incorpora as características do Cascata e da Prototipação, adicionando a análise de riscos.

Pensa assim:

Planeja ↓ Analisa riscos ↓ Desenvolve ↓ Avalia ↓ Repete

🎯 O que guardar?

Espiral = desenvolvimento iterativo + análise de riscos.

Não precisa decorar todos os detalhes do modelo.

Página 4

6. 🔁 Processo Iterativo / RUP

Iterativo significa que você não faz tudo uma única vez.

Você faz uma versão → avalia → melhora → faz outra → melhora novamente.

A aula apresenta o RUP (Rational Unified Process) como um processo iterativo voltado ao desenvolvimento de sistemas orientados a objetos.

A ideia principal é:

Os requisitos podem evoluir durante o projeto, então algumas etapas precisam ser revisitadas.

7. 🧩 Desenvolvimento baseado em componentes

Aqui a ideia é muito simples:

Por que criar tudo do zero se já existe algo que podemos reutilizar?

Um componente é algo que pode ser utilizado novamente em outro contexto.

Por exemplo, imagine que você precise de um sistema de login.

Se já existe um componente pronto de autenticação que funciona bem, você pode reutilizá-lo em vez de programar tudo novamente.

A aula descreve justamente o desenvolvimento baseado em componentes como a composição de sistemas utilizando componentes existentes e reutilizáveis.

🎯 Guarda:

Componentes = reutilização.

8. 🧱 Desenvolvimento orientado a serviços

A ideia é parecida, mas agora pensamos em serviços.

Um serviço é uma funcionalidade que pode ser oferecida por um sistema e reutilizada.

A aula divide exemplos em:

serviços de utilidades;

serviços de negócios;

serviços de coordenação.

Não precisa aprofundar muito nisso agora.

O principal:

Orientado a serviços = construir software utilizando serviços que podem ser reutilizados.

Página 5

9. 🔨 Processo de desenvolvimento de software

Agora chegamos a uma parte importante.

A aula apresenta quatro grandes atividades:

1️⃣ Especificação

Descobrir:

O que o sistema precisa fazer?

Aqui entram os requisitos.

Exemplo:

"O usuário deve conseguir fazer login."

A especificação envolve estudar viabilidade, levantar/analisar requisitos, especificá-los e validá-los com o cliente.

2️⃣ Projeto e implementação

Depois de saber o que precisa ser feito:

Como vamos construir isso?

O projeto define a estrutura do software.

Depois vem a implementação:

Programar aquilo.

A aula destaca que projeto e implementação são atividades muito relacionadas e podem ocorrer de maneira intercalada.

3️⃣ Validação

Agora precisamos descobrir:

O sistema realmente funciona e atende ao que o cliente pediu?

São apresentados:

teste de componentes;

teste do sistema;

teste de aceitação.

4️⃣ Evolução

Depois que o software está pronto, ele não necessariamente acaba ali.

O cliente pode pedir:

"Quero uma nova função."

Então:

avaliar → propor mudanças → implementar mudanças.

Isso é a evolução do software.

Página 6

🐛 10. Debugging

Esse você provavelmente vai encontrar bastante em programação.

Debugging = procurar e corrigir erros no programa.

A aula apresenta quatro etapas:

Localizar o erro;

Criar uma solução para corrigir;

Corrigir;

Testar novamente.

Então:

Bug = erro/problema no programa.

Debugging = processo de encontrar e corrigir esse erro.

🎯 O QUE VOCÊ PRECISA DECORAR/ENTENDER

Se a prova vier baseada nessa aula, eu focaria nisso:

ConceitoLembre disso

PrescritivoRígido, planejamento antecipado

AdaptativoFlexível, aceita mudanças

CascataEtapas sequenciais; bom quando requisitos são estáveis

PrototipaçãoCriar protótipo e refinar com feedback

IncrementalEntregar o sistema em partes

EspiralIteração + análise de riscos

RUPProcesso iterativo

ComponentesReutilização de componentes

ServiçosReutilização de funcionalidades/serviços

EspecificaçãoDefinir o que o sistema precisa fazer

ImplementaçãoTransformar o projeto em programa

ValidaçãoVerificar se atende aos requisitos

EvoluçãoAlterar/melhorar depois de pronto

DebuggingEncontrar e corrigir erros