Modelo de processo de software tradicionais

1. Aula 04 - Modelos de Processo
em Desenvolvimento de
Software
Prof. Alinne Souza

2. Agenda
Conceitos Fundamentais
Modelos de Ciclo de Vida
Tipos de Modelos
Tailoring

3. O que é um Modelo?
Simplificação da
Realidade
Planos de detalhes, estruturais
ou comportamentais.
Melhor Entendimento
Construídos para compreender o
sistema em desenvolvimento.
Guia para Construção
Especifica estrutura,
comportamento e documenta
decisões.

4. Importância dos Modelos
Sistemas Complexos
Não temos capacidade de compreendê-
los inteiramente.
Relação com Realidade
Os melhores modelos simplificam a
realidade de forma eficaz.
Múltiplos Modelos
Nenhum modelo único é suficiente.
Independência
Conjunto de modelos independentes se
complementam.

5. O que são Modelos de Processo?
Definição
Um modelo de processo é uma representação abstrata que descreve a
abordagem para o desenvolvimento de software, incluindo atividades,
artefatos, papéis e iterações envolvidas.
Importância
Os modelos fornecem um framework comum para equipes, melhoram a
previsibilidade, facilitam o gerenciamento de recursos e ajudam a garantir a
qualidade do software.

6. Enquanto o processo é a execução real das atividades de
desenvolvimento, o modelo é a estrutura conceitual que
orienta e organiza estas atividades.
Modelo vs. Processo de Software

7. Modelo vs. Processo de Software
Modelo
Um modelo de processo de software é uma
representação abstrata, um template ou framework que
define a estrutura geral a ser seguida.
Características:
• Genérico e conceitual
• Descreve fases e atividades em alto nível
• Pode ser aplicado a diferentes tipos de projetos
• Serve como ponto de partida para personalização
Exemplos: Cascata, Espiral, Scrum, XP
Processo
Um processo de software é a implementação específica de
um modelo, adaptada às necessidades e contexto de uma
organização ou projeto.
Características:
• Concreto e detalhado
• Define papéis, responsabilidades e fluxos de trabalho
específicos
• Inclui ferramentas, técnicas e práticas específicas
• Adaptado à cultura e ao contexto organizacional
Exemplos: O processo da empresa X baseado no Scrum
com adaptações específicas

8. Atributos de um Modelo de
Processo
Atividades
Especifica as tarefas a
serem realizadas, sua
sequência, dependências e
critérios de entrada/saída.
Papéis
Define as responsabilidades
de cada pessoa ou equipe
envolvida no processo de
desenvolvimento.
Documentação
Define quais documentos
serão produzidos durante o
desenvolvimento e como
serão estruturados e
compartilhados.
Ciclo de Vida
Estabelece como o tempo é
organizado e como as
atividades são distribuídas
durante o projeto.

9. Modelos de Ciclo de Vida
Linear
Progride sequencialmente de uma
fase para outra, sem retorno. Cada
fase deve ser concluída antes do
início da próxima.
Iterativo
Repete as fases múltiplas vezes,
refinando o produto a cada ciclo.
Permite maior flexibilidade e
adaptação.
Incremental
Constrói o sistema em pequenas
partes, adicionando
funcionalidades a cada
incremento. Fornece valor mais
rapidamente.
Evolutivo
Permite que o software evolua ao
longo do tempo com base em
feedbacks e mudanças nos
requisitos, adaptando-se
constantemente.

10. Visão Geral dos Principais Modelos
Modelos Tradicionais
• Cascata (Waterfall)
• Iterativo
• Incremental
• Espiral
• Prototipagem
• Modelo V
• RUP (Rational Unified Process)
Caracterizados por fases bem definidas, documentação
extensa e planejamento detalhado antecipado.
Modelos Ágeis
• Scrum
• Kanban
• XP (Extreme Programming)
• Crystal
• FDD (Feature-Driven Development)
• DSDM (Dynamic Systems Development Method)
• Lean Software Development
Focados em adaptabilidade, colaboração, entrega
contínua e resposta rápida a mudanças.

11. Principais Diferenças entre Modelos
Aspecto Tradicionais Ágeis
Planejamento Detalhado e antecipado Adaptativo e contínuo
Documentação Extensa e abrangente Mínima e prática
Entregas No final ou em grandes
marcos
Frequentes e incrementais
Mudanças Resistentes e formais Bem-vindas e incorporadas
Cliente Envolvimento no início e fim Colaboração constante

12. Modelo Cascata (Waterfall)

13. Características do Modelo
Cascata
Ciclo de Vida Linear
Segue uma sequência rígida e unidirecional de fases, onde cada fase deve ser
concluída antes do início da próxima.
Documentação Extensa
Exige documentação detalhada em cada fase, servindo como entradas para as
fases subsequentes e referência futura.
Requisitos Estáveis
Assume que os requisitos são bem compreendidos desde o início e
permanecerão estáveis durante todo o projeto.
Marcos Definidos
Estabelece pontos de verificação claros entre as fases, facilitando o
gerenciamento e monitoramento do progresso.

14. Modelo Cascata (Waterfall)

15. Quando Usar o Modelo Cascata
Requisitos Claros e Estáveis
Ideal para projetos onde os requisitos são bem definidos desde o início e têm baixa
probabilidade de mudanças significativas durante o desenvolvimento.
Domínio Bem Conhecido
Aplicável quando a equipe possui ampla experiência com o domínio do problema e as
tecnologias envolvidas, reduzindo incertezas.
Conformidade Regulatória
Adequado para projetos que exigem extensa documentação para atender a padrões
regulatórios ou de certificação, como sistemas críticos de segurança.
Projetos de Curta Duração
Eficiente para projetos pequenos com escopo limitado e prazo curto, onde a
sobrecarga de abordagens mais flexíveis pode não ser justificada.

16. Problemas do Modelo Cascata
Inflexibilidade
• Dificuldade em acomodar mudanças
após o início do projeto.
• Alterações nos requisitos tornam-se
extremamente custosas em fases
avançadas, podendo exigir retorno a
fases iniciais.
Feedback Tardio
O cliente só vê o produto funcionando
nas fases finais, o que pode resultar em
um sistema que atende às
especificações documentadas, mas não
às necessidades reais do usuário.
Detecção Tardia de Problemas
Problemas fundamentais de design ou
arquitetura são descobertos apenas
durante a implementação ou testes,
quando as correções são mais caras e
demoradas.

17. Modelo Incremental

18. Características do Modelo
Incremental
Entregas Parciais
O sistema é construído e entregue em partes, com cada incremento adicionando
novas funcionalidades ao produto existente.
Priorização de Funcionalidades
As funções mais essenciais são desenvolvidas primeiro, seguidas por recursos de
menor prioridade em incrementos subsequentes.
Ciclos Completos
Cada incremento passa por todas as fases do desenvolvimento (requisitos, design,
implementação, teste), resultando em um produto parcial utilizável.
Valor Antecipado
Os usuários podem começar a utilizar as funcionalidades básicas enquanto
recursos adicionais estão sendo desenvolvidos nos incrementos seguintes.

19. Modelo Incremental

20. Quando Usar o Modelo Incremental
Entrega Rápida de Valor
Quando é necessário disponibilizar funcionalidades básicas rapidamente, permitindo que
os usuários comecem a obter benefícios do sistema antes da sua conclusão total.
Financiamento Gradual
Em projetos onde o investimento é liberado em fases, sendo cada incremento financiado
após a demonstração de resultados tangíveis do incremento anterior.
Recursos Limitados
Quando há restrições de pessoal ou infraestrutura que impossibilitam o desenvolvimento
simultâneo de todas as funcionalidades do sistema.
Time-to-Market
Em mercados competitivos onde lançar um produto básico rapidamente pode garantir
vantagem comercial, enquanto funcionalidades adicionais são desenvolvidas em paralelo.

21. Problemas do Modelo Incremental
Arquitetura Inicial Crítica
Exige uma arquitetura bem
planejada desde o início para
acomodar todos os incrementos
futuros sem redesigns significativos.
Decisões arquiteturais pobres podem
limitar severamente a evolução do
sistema.
Desafios de Integração
A adição de novos incrementos a um
sistema existente pode introduzir
complexidades de integração,
especialmente se os incrementos
anteriores não foram projetados com
extensibilidade suficiente.
Experiência Fragmentada
Os usuários podem ficar insatisfeitos
com versões iniciais limitadas se as
expectativas não forem gerenciadas
adequadamente ou se funcionalidades
críticas forem adiadas para
incrementos posteriores.

22. Modelo Espiral

23. Características do Modelo Espiral
Foco em Riscos
O gerenciamento de riscos é central, com identificação e mitigação explícitas de
problemas potenciais a cada ciclo do desenvolvimento.
Expansão Progressiva
O escopo e a complexidade aumentam gradualmente a cada volta da espiral,
permitindo que o produto evolua de forma controlada.
Pontos de Decisão
Incorpora pontos de verificação explícitos onde stakeholders podem avaliar o
progresso e decidir se o projeto deve continuar, ser ajustado ou encerrado.
Flexibilidade Metodológica
Permite incorporar elementos de outros modelos (prototipagem, cascata,
incremental) dependendo dos riscos e necessidades específicas de cada ciclo.

24. Modelo Espiral

25. Quando Usar o Modelo Espiral
Projetos de Alto Risco
Ideal para sistemas complexos e inovadores onde existem muitas incertezas técnicas ou
de requisitos que precisam ser investigadas e mitigadas gradualmente.
Grandes Investimentos
Adequado para projetos com orçamentos significativos, onde a abordagem incremental
focada em riscos ajuda a justificar continuamente o investimento aos stakeholders.
Sistemas Críticos
Aplicável a sistemas onde falhas podem ter consequências graves, beneficiando-se da
ênfase em identificação e mitigação precoce de riscos potenciais.
Requisitos Evolutivos
Útil quando os requisitos são inicialmente vagos ou propensos a mudanças significativas,
permitindo refinamento progressivo com base em protótipos e feedback.

26. Problemas do Modelo Espiral
Complexidade de
Gerenciamento
A natureza flexível e dirigida por riscos
requer gerentes de projeto altamente
experientes e habilidosos para avaliar
adequadamente os riscos e determinar
quando avançar para o próximo ciclo.
Overhead Administrativo
A ênfase na análise de riscos e pontos
de decisão pode introduzir
complexidade administrativa
significativa, com muitas reuniões,
documentação e avaliações formais.
Difícil Previsibilidade
O número de ciclos necessários pode
ser difícil de prever antecipadamente,
complicando estimativas de tempo e
custo e potencialmente frustrando
stakeholders que preferem
cronogramas definidos.

27. Modelo Protatipagem

28. Características do Modelo de Prototipagem
Desenvolvimento Rápido
Prioriza a criação veloz de versões funcionais simplificadas
para demonstração e feedback, em vez de documentação
extensa.
Visualização Concreta
Fornece representações tangíveis do sistema para facilitar o
entendimento dos requisitos e validar conceitos antes do
desenvolvimento completo.
Interação com Usuários
Envolve os usuários finais desde o início para capturar
feedback real e identificar melhorias necessárias enquanto
as mudanças ainda são relativamente baratas.
Iteração de Design
Permite múltiplas iterações de design baseadas em feedback
concreto, resultando em uma solução mais alinhada com as
necessidades reais dos usuários.

29. Modelo de Prototipagem

30. Quando Usar o Modelo de
Prototipagem
Requisitos Incertos
Quando os requisitos são ambíguos ou difíceis de definir previamente, permitindo que os
usuários "vejam e sintam" possibilidades antes de finalizar as especificações.
Interfaces Complexas
Para sistemas com interfaces de usuário elaboradas ou fluxos de interação complicados,
onde a experiência prática é essencial para avaliar a usabilidade.
Inovações Tecnológicas
Ao explorar novas tecnologias ou abordagens onde existem incertezas técnicas
significativas que precisam ser validadas antes do compromisso total.
Envolvimento do Usuário
Quando há forte necessidade de engajamento contínuo dos usuários finais, permitindo
feedback frequente e participação ativa no processo de design.

31. Problemas do Modelo de Prototipagem
Confusão de Expectativas
Usuários podem confundir o protótipo
com o produto final, criando
expectativas irrealistas sobre prazos de
entrega ou funcionalidades. A natureza
preliminar do protótipo nem sempre é
compreendida.
Compromissos Técnicos
A pressão para desenvolver protótipos
rapidamente pode levar a atalhos
técnicos, baixa qualidade de código ou
arquiteturas inadequadas,
especialmente se protótipos
descartáveis acabarem se tornando a
base do produto final.
Ciclo Infinito de Revisões
Sem limites claros, o processo pode
cair em um ciclo interminável de
modificações do protótipo, atrasando o
desenvolvimento real e aumentando
custos sem avançar em direção à
conclusão.

32. Problemas dos Modelos Tradicionais
Resposta Lenta a Mudanças
A natureza estruturada e sequencial dificulta a adaptação a
novos requisitos ou condições de mercado que surgem
durante o desenvolvimento.
Ênfase Excessiva em Documentação
O foco em documentação extensa pode desviar recursos do
desenvolvimento real e criar artefatos que rapidamente se
tornam obsoletos.
Entrega Tardia de Valor
Longos ciclos de desenvolvimento significam que os usuários
só obtêm valor no final do projeto, quando o produto
completo é entregue.
Envolvimento Limitado do Cliente
A participação do cliente tende a se concentrar no início
(requisitos) e no fim (aceitação), com pouca colaboração
durante as fases intermediárias.

33. Metodologias Ágeis
1
Indivíduos e interações
Mais que processos e ferramentas
2
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

34. Características das Metodologias Ágeis
Iterações Curtas
Ciclos de
desenvolvimento
geralmente de 1 a 4
semanas, permitindo
feedback rápido e
adaptação constante às
mudanças.
Equipes Auto-
organizadas
Times multifuncionais
com autonomia para
determinar como
realizar o trabalho,
promovendo
responsabilidade
coletiva e inovação.
Comunicação
Frequente
Reuniões diárias,
revisões de iteração e
retrospectivas mantêm
todos alinhados e
facilitam a identificação
precoce de problemas.
Entregas
Incrementais
Software funcionando
entregue regularmente,
priorizando
funcionalidades de
maior valor para o
cliente desde as
primeiras iterações.

35. Principais Metodologias Ágeis
Cada metodologia tem seu próprio conjunto de práticas e princípios, mas todas compartilham os valores
fundamentais do Manifesto Ágil.

36. Tailoring: Personalização do Processo
Adaptação Estratégica
Alinhamento com objetivos de negócio
Seleção de Componentes
Escolha das práticas e ferramentas adequadas
Configuração Específica
Definição de parâmetros e regras de trabalho
Implementação Contextual
Aplicação considerando equipe e ambiente

37. Fatores que Influenciam o Tailoring
Tamanho e Complexidade do
Projeto
Projetos maiores podem exigir mais
documentação e controles formais.
1
Experiência da Equipe
Equipes experientes podem precisar de
menos supervisão e estrutura.
Criticidade e Riscos
Sistemas críticos requerem
processos mais rigorosos de
verificação e validação.
Restrições de Tempo e
Orçamento
Podem determinar quais práticas são
viáveis dentro dos limites do projeto.
Cultura Organizacional
Influencia a aceitação e o sucesso da
implementação do processo.
Regulamentações do Setor
Setores regulamentados podem
exigir conformidade com padrões
específicos.

38. Exemplo de Tailoring: Adaptação do Scrum
Scrum Padrão
• Sprints de 2 semanas
• Daily Scrums de 15 minutos
• Sprint Planning no início
• Sprint Review e Retrospective no final
• Papéis: Scrum Master, Product Owner,
Desenvolvedores
Adaptação para Equipe Distribuída
• Daily Scrums assíncronas via ferramenta de
chat
• Sprint Planning estendido para 4 horas com
documentação detalhada
• Reuniões de alinhamento técnico semanais
adicionais
• Ferramentas de colaboração remota para
todas as cerimônias
• Tempo adicional alocado para comunicação
Adaptação para Projeto Regulatório
• Adição de checklist de conformidade antes do Sprint Review
• Documentação adicional para auditoria
• Participação de especialista em regulamentação nas cerimônias
• Sprint maior (3-4 semanas) para acomodar verificações
• Fase de validação formal após cada incremento

39. Passos para Realizar o Tailoring Eficaz
Avaliação do Contexto
Análise detalhada do ambiente organizacional, características do projeto, experiência da equipe, restrições e requisitos específicos para entender
quais adaptações são necessárias.
Seleção do Modelo Base
Escolha do modelo de processo que melhor se alinha com as necessidades identificadas, servindo como ponto de partida para as adaptações
específicas.
Personalização das Práticas
Modificação de atividades, artefatos e técnicas do modelo base, adicionando, removendo ou ajustando elementos para melhor atender
ao contexto específico.
Documentação do Processo Adaptado
Registro claro das adaptações feitas, incluindo justificativas, para garantir compreensão e consistência na aplicação do processo
personalizado.
Piloto e Refinamento
Implementação inicial em escala limitada, coletando feedback e realizando ajustes antes da adoção completa, garantindo que o processo
adaptado funcione na prática.

40. Existe um modelo ideal?

41. Existe um Modelo Ideal?
0
Modelos "Perfeitos"
Não existe um único modelo ideal que
funcione perfeitamente para todos os
projetos, equipes e contextos
organizacionais.
85%
Abordagens Híbridas
Percentual aproximado de organizações
que adotam elementos de múltiplos
modelos para criar sua própria
abordagem personalizada.
3x
Adaptabilidade
Organizações que adaptam seus
processos ao contexto específico têm
até três vezes mais chances de entregar
projetos bem-sucedidos.

42. Reflexão Final
"O design não é apenas como parece e como se sente. O design é como funciona." -
Steve Jobs
• A escolha do modelo de processo deve ser guiada pelo contexto específico do projeto, considerando fatores como
complexidade, estabilidade dos requisitos, disponibilidade do cliente, restrições organizacionais e expertise da
equipe.
• Como Steve Jobs sugeriu, o valor real está em como o processo funciona para entregar resultados, não apenas em
como ele é percebido ou documentado.
• A evolução contínua dos modelos de desenvolvimento de software reflete nossa busca por equilibrar estrutura e
flexibilidade, previsibilidade e adaptabilidade, disciplina e criatividade.