Este documento descreve diferentes modelos de processos de produção de software, incluindo: 1) Os modelos prescritivos/clássicos como Cascata, Codificar e Consertar e Programador-Chefe; 2) Os modelos tentam encontrar um equilíbrio entre ordem e adaptabilidade no desenvolvimento de software; 3) Cada modelo possui vantagens e desvantagens dependendo do projeto. O engenheiro de software deve escolher o modelo mais adequado para sua equipe e projeto.

1. Processo de Produção
de Software
Bacharelado em Engenharia de Software – Aula 15
Prof.ª M.ª Elaine Cecília Gatto

2. MODELOS DE PROCESSOS
DE PRODUÇÃO DE
SOFTWARE

3. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente
CLASSIFICAÇÃO
DOS MODELOS
DE PROCESSOS
DE SOFTWARE

4. Modelos
Especializados
Componentes
Métodos
Formais
Aspectos
Modelos
Modernos
RUP
Modelos de
Processos de
Software
Pessoal e de
Equipe
Pessoal
Equipe
Tecnologias de
Processo
Processo
Produto
MÉTODOS ÁGEIS
CLASSIFICAÇÃO
DOS MODELOS
DE PROCESSOS
DE SOFTWARE

5. Introdução
• “Em um processo de desenvolvimento de
software, o ponto de partido para a arquitetura de
um processo é a escolha de um modelo de vida.”
(PÁDUA, 2015)
• A finalidade dos modelos de processo é tentar
reduzir o caos presente no desenvolvimento de
novos produtos de software.

6. Introdução
• Modelos de processo de produção de
software foram propostos para trazer ordem
ao caos existentes na área.
• Cada modelo tenta encontrar um equilíbrio
entre a necessidade de pôr ordem em um
mundo caótico e a de ser adaptável quando
as coisas mudam constantemente.

7. Introdução
• “Modelos de processos de produção de
software são importantes pois propiciam
estabilidade, controle e organização para uma
atividade que pode, sem controle, tornar-se
caótica, demandando apenas atividades,
controles e produtos de trabalho que sejam
apropriados para a equipe do projeto e para o
produto a ser gerado.” (PRESSMAN, 2016)

8. Qual modelo de ciclo de vida escolher
entre tantos disponíveis?
• O engenheiro de software deve escolher o
que for mais adequado a sua equipe e ao
projeto que ele vai desenvolver.
• Importante: Não há um único modelo de
processo de software que se adeque a todos
os projetos de software (Diversidade).

9. Qual modelo de ciclo de vida escolher
entre tantos disponíveis?
• Se escolher um modelo adequado para a sua
realidade:
• terá um processo eficiente, baseado em
padrões e lições aprendidas e com
possibilidade de capitalizar experiências
• o controle será eficiente, e os riscos, erros e
retrabalho serão minimizados.

10. Qual modelo de ciclo de vida escolher
entre tantos disponíveis?
• Se escolher um modelo inadequado para sua
realidade:
• poderá gerar trabalho repetitivo e
frustrante para a equipe

11. Como escolher um modelo de ciclo de vida
entre tantos disponíveis?
• Para escolher um ciclo de vida, ou pelo menos
as características de processo necessárias
para seu projeto e empresa, o engenheiro de
software pode tentar responder às seguintes
perguntas:

12. Como escolher um modelo de ciclo de vida
entre tantos disponíveis?
1. Quão bem os analistas e o cliente podem conhecer
os requisitos do sistema?
2. Quão bem é compreendida a arquitetura do
sistema?
3. Qual o grau de confiabilidade necessário em relação
ao cronograma?
4. Quanto planejamento é efetivamente necessário?
5. Qual é o grau de risco que esse projeto apresenta?

13. Como escolher um modelo de ciclo de vida
entre tantos disponíveis?
1. Existe alguma restrição de cronograma?
2. Será necessário entregar partes do sistema
funcionando antes de terminar o projeto?
3. Qual é o grau de treinamento e adaptação
necessário para a equipe poder utilizar o ciclo de
vida que parece mais adequado ao projeto?
4. Será desenvolvido um único sistema ou uma família
de sistemas semelhantes?
5. Qual o tamanho do projeto?

14. Como escolher um modelo de ciclo de vida
entre tantos disponíveis?
• Após estudarmos todos os modelos de
processo de produção de software, ou CICLOS
DE VIDA, seremos capazes de responder a
estas perguntas mais claramente

15. DEFINIÇÃO
• “Fornece um guia específico para o trabalho
de engenharia de software, definindo o fluxo
de todas as atividades, ações e tarefas, o grau
de iteração, os artefatos, a organização do
trabalho a ser feito e os passos necessários
para realizar um trabalho de engenharia de
software disciplinado.” (PRESSMAN, 2016)

16. Objetivo de Um Modelo de Processo de
Software
• “Fornecer uma orientação para coordenar e
controlar sistematicamente as tarefas que
precisam ser executadas visando garantir o
produto final e os objetivos do projeto” (TSUI,
KARAM, 2013)

17. Objetivo de Um Modelo de Processo de
Software
• Um modelo de processo de software define:
• Um conjunto de tarefas que precisam ser
executadas;
• A entrada e a saída de cada tarefa;
• As pré-condições e as pós-condições para cada
tarefa;
• A sequência e o fluxo destas tarefas. (TSUI,
KARAM, 2013)

18. VAMOS PENSAR?
• Um processo de desenvolvimento de software
é realmente necessário quando há somente
uma pessoa desenvolvendo-o?

19. VAMOS PENSAR?
• Um processo de desenvolvimento de software
é realmente necessário quando há somente
uma pessoa desenvolvendo-o?
•DEPENDE!

20. VAMOS PENSAR?
• Um processo de desenvolvimento de
software não é realmente necessário quando
há somente uma pessoa desenvolvendo-o,
quando ele for encarado exclusivamente
como um agente de coordenação e controle.

21. VAMOS PENSAR?
• Um processo de desenvolvimento de
software é realmente necessário quando há
somente uma pessoa desenvolvendo-o,
quando ele for encarado como um roteiro
prescritivo para a geração de várias entregas
intermediárias além do código executável, por
exemplo, um documento de design, um guia
de usuário, situações de teste, etc.

22. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

23. Modelo de Processo Prescritivo
• Baseiam-se em uma descrição de como as
atividades são feitas.
• Concentra-se em estruturar e ordenar o
desenvolvimento de software.
• Definem um conjunto prescrito de elementos
de processo e um fluxo de trabalho de
processo previsível.

24. Modelo de Processo Prescritivo
• Prescrevem um conjunto de elementos de
processo:
• Tarefas
• Artefatos
• Garantia da qualidade
• Mecanismos de controle de mudanças
• Fluxo de processo ou fluxo de trabalho

25. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

26. Modelo Codificar e Consertar
• Conhecido como modelo mais simples e caótico,
modelo código-e-correção ou ainda ad-hoc.
• Ciclo Código-Compilação-Teste
• Consiste na absoluta falta de processo
• Enunciado do problema = especificação de
requisitos
• No começo era tudo muito confuso

27. Modelo Codificar e Consertar
• Codifica e “remenda” sem alguma
documentação
• Nenhum processo é definido
• Não exige sofisticação técnica ou gerencial
• Modelo de alto risco, impossível de gerir e
não permite assumir compromissos confiáveis

28. Modelo Codificar e Consertar
• É aquele que acaba sendo usado quando não
se utiliza conscientemente nenhum modelo;
• É considerado o marco zero dos modelos;

29. Modelo Codificar e Consertar
• Com o passar do tempo:
• Softwares mais
complexos
• Mais tarefas
• Mais atividades
• Mais pessoas
• Melhor coordenação
• Mais modelos
surgiram
• As tarefas no
processo, a relação
entre elas e o fluxo
destas tarefas
ficaram mais bem
definidos

30. Modelo Codificar e Consertar
• Contribuição para a área:
• Não traz nenhuma contribuição.

31. Modelo Codificar e Consertar
• Vantagens (?):
• Não se gasta tempo com documentação,
planejamento ou projeto, isto é, vai-se direto à
codificação
• O progresso é facilmente visível à medida que o
programa vai ficando pronto
• Não há necessidade de conhecimentos ou
treinamento especiais
• Qualquer pessoa que programe pode desenvolver
software com esse modelo de ciclo de vida

32. Modelo Codificar e Consertar
• Desvantagens (?):
• É muito difícil avaliar a qualidade e os riscos
do projeto
• Se no meio do projeto a equipe descobrir
que as decisões arquiteturais estavam
erradas, não há solução, a não ser começar
tudo de novo.

33. Modelo Codificar e Consertar
Enunciado
do
Problema
Código Compilação
Depuração
Teste de
Unidade
Liberação
Problema
Problema
O Modelo Codificar e Consertar por Tsui. (2013)

34. O Modelo Codificar e Consertar por Raul. (2013)

35. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador-
Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

36. Metodologia da Equipe do Programador-
Chefe
• Ideia organizacional popular nos meados da
década de 1970.
• Metodologia de coordenação e
gerenciamento (em vez de processo).
• Baseado na ideia de cirurgião-chefe.
• Precursora da divisão de um grande problema
em múltiplos componentes

37. Metodologia da Equipe do Programador-
Chefe
• Pequenas equipes com um chefe desenvolvem os
componentes.
• Existe um programador-chefe que planeja, divide
e designa as tarefas para diferentes especialistas.
• O programador-chefe age exatamente como um
cirurgião-chefe em uma equipe cirúrgica e dirige
todas as atividades do trabalho.

38. Metodologia da Equipe do Programador-
Chefe
• Entre 7 e 10 pessoas na equipe.
• Especialistas:
• Designer
• Programadores
• Testadores
• Editores de documentação
• Programador-chefe

39. Modelos de Processos de Software
Prescritivos/Clássicos/Tradicionais
Codificar e
Consertar
Programador
-Chefe
Cascata
Entrelaçado
Subprojetos
Redução de
Riscos
Modelo V
Modelo W
Incremental
Evolucionário
Prototipação
Espiral
Prototipação
Evolucionária
Entrega
Evolucionária
Entrega em
Estágios
Orientado a
Cronograma
Orientado a
Ferramenta
Concorrente

40. Modelo Cascata (Waterfall)
• Introduz a noção de fases bem definidas e a
necessidade de documentação ao longo do
processo
• Característica:
• Existência de fases bem definidas e
sequenciais não apenas para o código final.

41. Modelo Cascata (Waterfall)
• Década de 70
• Considerado o Avô de todos os ciclos de vida
existentes.
• Abordagem sequencial e sistemática
• Tarefas ocorrem sequencialmente uma pós a
outra, com a saída de uma tarefa caindo na
próxima.

42. Modelo Cascata (Waterfall)
• Conhecido também como ABORDAGEM
ORIENTDA A DOCUMENTO, ou DIRIGIDO POR
DOCUMENTAÇÃO, pois gera uma grande
quantidade de documentos (requisitos, design
e testes) e é ela quem determina se a fase foi
o não concluída

43. Modelo Cascata (Waterfall)
• Nível extremamente baixo de superposição de
tarefas: iteração única, nada de paralelismo.
• Iteração baixa com pessoas: apenas na
especificação e na entrega.

44. Modelo Cascata (Waterfall)
O Modelo Cascata por Pressman. (2016)

45. O Modelo Cascata
por Boehm (1981)

46. O Modelo Cascata por Tsui (2013)
Requisitos
Design
Código
Teste
Integrar e
Empacotar

47. O Modelo Cascata por Royce
(1970) apresentado como algo a
NÃO SER SEGUIDO. O modelo
como filosofia de projeto
organizado é válido. Entretanto,
a implementação do modelo é
arriscada pois, apenas na fase
de teste vários aspectos do
sistema seriam experimentados
na prática pela primeira vez.
Assim, muito RETRABALHO seria
necessário.

48. O Modelo Cascata DUPLA por
Royce (1970) apresentado como
forma de minimizar a fragilidade
do modelo original. Os
problemas encontrados em uma
fase podem ser resolvidos
retornando-se à fase anterior
para efetuar as correções.
Problemas encontrados em uma
fase algumas vezes não foram
originados na fase
imediatamente anterior, mas
talvez várias fases antes.

49. Esta Figura mostra como as
interações entre as fases do
MODELO CASCATA acabam
acontecendo na prática.

50. Modelo Cascata (Waterfall)
• Para a época era confiável e utilizável em
projetos de qualquer escala por conta do alto
nível de controle que facilita a gestão do
projeto.
• Atualmente é adequado a projetos de
pequena duração.

51. Modelo Cascata (Waterfall)
• Baseado na filosofia BDUF (big design up front):
• Propõe que, antes de produzir linhas de código,
deve-se fazer um trabalho detalhado de análise
e projeto, de forma que, quando o código for
efetivamente produzido, esteja o mais próximo
possível dos requisitos do cliente.

52. Modelo Cascata (Waterfall)
• Vantagens:
• Os requisitos devem ser especificados na
primeira etapa
• Requisitos, design, código e teste dessem ser
concluídas antes que o software seja
empacotado
• O processo é monitorado à medida que passa
pelos estágios

53. Modelo Cascata (Waterfall)
• Vantagens:
• Torna-se mais barato corrigir erros quando eles são
detectados com antecedência e, a existência de
fases bem definidas permite isso.
• O projeto só pode seguir em frente quando os
requisitos são aceitos e estáveis.
• Abordagem sistemática e organizada.
• Fácil verificar se o código funciona corretamente.

54. Modelo Cascata (Waterfall)
• Vantagens:
• Se os requisitos são bem conhecidos e estáveis,
então, este modelo é adequado.
• Se a empresa estiver preocupada com o custo
ou tempo de desenvolvimento, então, este
modelo não é o adequado.
• Serve de guia para equipes técnicas fracas e
inexperientes.

55. Modelo Cascata (Waterfall)
• Desvantagens:
• Projetos reais raramente seguem o fluxo
sequencial.
• Exige que o cliente explicite todas as suas
necessidades na fase de comunicação, o que é
muito difícil.
• Uma versão operacional só será liberada ao final
do projeto. Um erro não detectado pode ser um
problema grave.

56. Modelo Cascata (Waterfall)
• Desvantagens:
• Difícil verificar a escrita dos modelos e projetos.
• Não produz resultados tangíveis até a fase de
codificação.
• Difícil estabelecer requisitos completos antes
de começar a codificar.
• Não há flexibilidade com requisitos.

57. Modelo Cascata (Waterfall)
• Desvantagens:
• Inadequado para o ritmo acelerado atual
de produção de software que possui
inúmeras mudanças.
• Rígido e burocrático.
• Não prevê a correção posterior de
problemas nas fases anteriores.

58. Modelo Cascata (Waterfall)
• Contribuição para a área:
• Introduziu a noção de que o desenvolvimento
de software ocorre em fases bem definidas e de
que é necessário produzir não apenas um
código executável, mas também documentos
que ajudem a visualizar o sistema de forma
mais abstrata que o código.

59. REFERÊNCIAS
1. TSUI, Frank; KARAM, Orlando. Fundamentos
da Engenharia de Software. Tradução e
Revisão Técnica de Edson Tanaka. 2.ª Edição.
Rio de Janeiro: LTC, 2013.
2. WAZLAWICK, Raul Sidnei. Engenharia de
Software: Conceitos e Práticas. 1.ª edição.
Rio de Janeiro: Elsevier, 2013.

60. REFERÊNCIAS
3. PRESSMAN, R. S.; MAXIM, B. R. Engenharia de
Software: Uma Abordagem Profissional. Tradução:
João Eduardo Nóbrega Tortello. Revisão Técnica:
Reginaldo Arakaki, Julio Arakaki, Renato Manzan de
Andrade. 8.ª Edição. Porto Alegre: AMGH, 2016.
4.FILHO, W. P. P. Engenharia de Software:
Fundamentos, Métodos e Padrões. 3.ª Edição.Rio
de Janeiro: LTC, 2015