PROCESSOS

DE
SOFTWARE
Prof: Flávio Dusse
AULA 03: 10/03/2023
Tema: Modelos 1
 AGENDA DA AULA DE HOJE (03)
• Resumo da aula passada
• Assunto do dia

2
 AGENDA DA AULA DE HOJE (03)
• Resumo da aula passada
• Assunto do dia

3
O QUE É PROCESSO?

4
O QUE É SOFTWARE?

5
 O QUE SÃO PROCESSOS DE
SOFTWARE?
•Conjunto de atividades, parcialmente
ordenadas, com a finalidade de obter um
produto de software
• Estudado dentro da área de Engenharia de
Software, sendo considerado um dos
principais mecanismos para se obter software
de qualidade e cumprir correta-mente os
contratos de desenvolvimento 6
TRIÂNGULO DAS RESTRIÇÕES

7
 3 ONDAS DA CIÊNCIAS DA
COMPUTAÇÃO
Onda Relação Máquina Rede Softwares Mídia Dados
1ª 1 computador Mainframe Rede local Caros Texto Somente
N usuários desenvolvimento Privados
e aquisição

2ª 1 computador PC Internet Caros Texto Privados

1 usuário Servidores aquisição (pouco Públicos
web áudio,
imagem)
3ª N computadores Smartphones Wi-fi Maioria Texto, Bigdata
1 usuário IoT Nuvem Gratuitos áudio,
Névoa imagem
e vídeo
8
 TERMINOLOGIAS
•Atividades
• O que deve ser feito
• estrutura e organização (Ex: ordenação, priorização, composição,
decomposição)
•Fases
• Conjunto de atividades do processo
•Procedimentos
• métodos, técnicas, roteiros, padrões adotados nas atividades
• Recursos
• agentes, ferramentas (hardware, software) para realizar as atividades
•Artefatos
• requeridos e/ou produzidos pelas atividades 9
 ATIVIDADES
Artefatos Artefatos

10
 FASES
• Análise Econômica (Planejamento)
• Análise de Requisitos de Software
• Especificação
• Arquitetura de Software
• Implementação (Codificação)
• Teste
• Documentação
• Suporte e Treinamento do Software
• Manutenção 11
 AGENDA DA AULA DE HOJE (03)
• Resumo da aula passada
• Assunto do dia

12
 NOMENCLATURAS
•Atividades
• O que deve ser feito
• estrutura e organização (Ex: ordenação, priorização, composição,
decomposição)
•Fases
• Conjunto de atividades do processo
•Procedimentos
• métodos, técnicas, roteiros, padrões adotados nas atividades
• Recursos
• pessoas, ferramentas (hardware, software) para realizar as atividades
•Artefatos
• requeridos e/ou produzidos pelas atividades 13
 PROCEDIMENTOS
• Métodos, técnicas, roteiros, padrões
adotados nas atividades
• Depende da empresa
• Depende do projeto
• Depende do cliente
• E depende dos agentes
14
 NOMENCLATURAS
•Atividades
• O que deve ser feito
• estrutura e organização (Ex: ordenação, priorização, composição,
decomposição)
•Fases
• Conjunto de atividades do processo
•Procedimentos
• métodos, técnicas, roteiros, padrões adotados nas atividades
• Recursos
• pessoas, ferramentas (hardware, software) para realizar as atividades
•Artefatos
• requeridos e/ou produzidos pelas atividades 15
 RECURSOS: AGENTES
• São responsáveis pela execução das
atividades
• Trabalham em times alocados em
projetos
• Diferentes cargos e funções
• Competências
16
 RECURSOS: FERRAMENTAS
• Dão suporte as atividades
• Ferramentas específicas para cada fase
• Podem ser integradas
• CASE (Computer Aided Software Engineering)
• Ex: IBM Rational TUP, Eclipse, Visual Studio

17
 NOMENCLATURAS
•Atividades
• O que deve ser feito
• estrutura e organização (Ex: ordenação, priorização, composição,
decomposição)
•Fases
• Conjunto de atividades do processo
•Procedimentos
• métodos, técnicas, roteiros, padrões adotados nas atividades
• Recursos
• pessoas, ferramentas (hardware, software) para realizar as atividades
•Artefatos
• requeridos e/ou produzidos pelas atividades 18
 ARTEFATOS
• Se o software é o produto final,
artefatos são subprodutos do processo
• Resultado de uma atividade é um
artefato de saída
• Que por ser utilizado como artefato de
entrada de outra(s) atividade(s)
19
 “PROCESSO” DE PROCESSOS DE
SOFTWARE
• CMM - Modelo de Maturidade em Capacitação
• CMMI - Modelo de Maturidade em
Capacitação Integrado
• ISO 9000, ISO/IEC 12207, ISO/IEC 15504
(anteriormente SPICE)
• MR-MPS
• IBM Rational Unified Process
20
 MODELOS DE
PROCESSOS DE SOFTWARE
• Quem realizam as atividades, de que forma os
engenheiros agem e comunicam os seus
resultados e quando as atividades são
realizadas são fatores determinados no
planejamento
• Deve ser definido, para o desenvolvimnento de
software, um modelo de processo de software
21
O QUE É MODELO?

22
 O QUE É MODELO?
• Etimologia da palavra ‘modelo’
• Do Latim: modellum, forma diminutiva
de modus, que significa “medida que
não pode ser ultrapassada”

23
 O QUE É MODELO?
• Dicionário

24
 O QUE SÃO MODELOS
DE PROCESSOS DE SOFTWARE?
• São representações ou interpretações
simplificada da realidade física
estruturadas para a definição,
implementação, gerenciamento e
melhoria de processos relacionados ao
desenvolvimento de software
25
 MODELO DE
PROCESSOS DE SOFTWARE
• Na literatura, existem diversos modelos de processos de
software
• Características genéricas
• fases (ordem)
• atividades
• papéis
• artefatos
• comunicação
• priorização
26
 MODELO DE
PROCESSOS DE SOFTWARE
• Programar e Arrumar
• Modelo Cascata
• Prototipação
• Desenvolvimento Rápido de Aplicação
• Modelo Incremental
• Modelo Espiral
• ‘Modelo’ RUP
• Modelos Ágeis 27
 PROGRAMAR E ARRUMAR
• Code and fix (Codificar e corrigir)
• Software desvinculou do Hardware em
meados da década de 60
• Alguns consideravam software como
arte
• Crise do software
28
CRISE DO SOFTWARE

29
CURVA DE FALHAS DO HARDWARE

“mortalidade “desgaste”
índice de
falhas infantil”

tempo

30
 CURVA DE FALHAS DO SOFTWARE

curva real
índice de
mudança
falhas

curva idealizada
curva idealizada

tempo

31
 CAUSAS DA CRISE DE SOFTWARE
• Projetos que estouram o cronograma
• Projetos que estouram o orçamento
• Baixa qualidade
• Clientes insatisfeitos
• Produtos difíceis de manter....
•e
• Mitos... 32
 PRINCIPAIS MITOS
• Atraso_no_projeto X alocação_de_pessoas
• Mudanças se acomodam facilmente
depois do software pronto
• Detalhes do problema podem ser passados
durante o projeto
• Software = arte ?
33
 SOLUÇÃO NA ÉPOCA
• Usar técnicas da Engenharia
• Processo de Software
• Modelos
• Modelos Cascata

34
 OBJETIVO DE SE TRABALHAR COM
MODELOS
• Principal função é colocar em ordem o
caos do desenvolvimento de software
• Acabar com “faço do meu jeito”
• Modelos devem ser adaptados ao
pessoal, ao problema e ao projeto

35
 MODELO CASCATA
• Também chamado de modelo clássico
• ou modelo “top-down”
• ou modelo “waterfall”
• Proposto por W.W. Royce em 1970
• Até 1980 teve aceitação geral
• Mais rígido
• Menos administrativo
• Referência dos outros modelos 36
MODELO CASCATA

37
MODELO CASCATA

38
 CASCATA
VANTAGENS
• Torna o processo de desenvolvimento de
software estruturado
• Padrão para outros modelos
• Simplicidade
• Fácil Gerenciamento
• Não há tantos problemas de Comunicação
39
 CASCATA
DESVANTAGENS
• Projetos raramente seguem fluxo sequencial
• Não suporta modificações nos requisitos
• Não permite feedbacks entre as fases
• Versão funcional disponível apenas no final do
desenvolvimento
• Erros ou mal-entendidos podem ser detectados apenas
no final (mais caro e desastroso)
• Se ocorrer um atraso, todo processo é afetado 40
 VARIAÇÕES DO MODELO CASCATA
• Buscam minimizar as desvantagens do
Cascata
• Modelo Cascata Entrelaçado
• Modelo Cascata com Subprojetos
• Modelo Cascata com Redução de Riscos
• Modelo Cascata em V
• Modelo Cascata em W
41
 MODELO CASCATA ENTRELAÇADO
• Também chamado de Sashimi
• ou “Overlapped Waterfall”
• Propõe que cada fase continue tratando
as atividades da fase anterior e procure
iniciar o tratamento das questões da
fase seguinte
42
MODELO CASCATA

43
MODELO CASCATA ENTRELAÇADO

44
 ENTRELAÇADO
VANTAGENS
• Uma fase só estará completa depois
que as atividades referentes à fase
anterior tiverem sido consideradas
•As equipes das diferentes fases
trabalham juntas boa parte do tempo
•Reduz a quantidade de documentação
45
 ENTRELAÇADO
DESVANTAGENS
• Adiciona complexidade
• Obscuro quando uma fase termina e a outra
começa
• Falhas de comunicação podem acontecer
devido a realização de atividades paralelas
• Mesmo que exista o entrelaçamento entre as
fases subsequentes, pode ser necessário
retornar a fases mais anteriores ainda 46
 MODELO CASCATA COM
SUBPROJETOS
• Também conhecido como Waterfall with Subprojects
• Introduz o conceito de “Dividir para conquistar”
• mais fácil conduzir um processo de desenvolvimento de vários
subsistemas parcialmente dependentes do que o de um grande
sistema completo
• Subprojetos podem ser desenvolvidos em paralelo ou
em momentos diferentes
• Precursor do Processo Unificado e Modelos Ágeis
47
MODELO CASCATA

48
MODELO CASCATA COM
SUBPROJETOS

49
 COM SUBRPOJETOS
VANTAGENS
• Permite que algumas fases do Modelo Cascata sejam
executadas em paralelo
• Permite dividir o software em módulos que podem ser
desenvolvidos por equipes diferentes (ou pela mesma
equipe em momentos diferentes)
• Pode produzir várias entregas de partes funcionais a
medida que ficam prontas
• Dividir o software em módulos menores permite que
subprojetos mais rápidos e fáceis de gerenciar sejam
utilizados 50
 COM SUBPROJETOS
DESVANTAGENS
• Adiciona complexidade
• Falhas de comunicação podem acontecer devido a
realização de atividades paralelas
• Interdependência entre os módulos podem surgir
• Necessário um design arquitetônico bem elaborado
• Apesar de facilitar na gerência de um módulo pode gerar
inconsistências entre os módulos
• Mesmo que exista o paralelismo ainda assim não há
feedback para fases iniciais do processo 51
 MODELO CASCATA COM REDUÇÃO DE
RISCOS
• Também conhecido como Waterfall with Risk
Reduction
• Enfatiza a necessidade de tratar inicialmente
os maiores riscos e incertezas do projeto antes
de se iniciar um processo de desenvolvimento
com fases bem definidas
• Adequado a projetos com grande número de
riscos significativos 52
 MODELO CASCATA COM
REDUÇÃO DE RISCOS
• Foco na boa definição dos requisitos do
projeto nas fases iniciais
• Acrescenta uma fase de redução de risco
antes do início do processo em cascata
• Reduzir o risco com os requisitos
• Utilizar técnicas que garantam que os
requisitos serão os mais estáveis possíveis
53
 PRINCIPAIS TÉCNICAS PARA
REDUÇÃO DE RISCOS
• Desenvolvimento de protótipos de interface com
usuário
• Desenvolvimento de história de usuário
(storyboards)
• Condução de vários ciclos de entrevistas com
usuário
• Filmagem do usuário utilizando softwares antigos
• Etc.. 54
MODELO CASCATA

55
MODELO CASCATA COM
REDUÇÃO DE RISCOS
Análise de
Risco

56
 COM REDUÇÃO DE RISCOS
VANTAGENS
• Foca nos requisitos
• Mitiga erros nas fases iniciais no processo
• Evita que erros sejam propagados pelas
fases
• Garante estabilidade ao processo antes
de comprometer um grande número de
recursos de execução 57
 COM REDUÇÃO DE RISCOS
DESVANTAGENS
• Adiciona complexidade
• Necessário profissionais experientes com
atividades de redução de risco
• Dificuldade na definição de um
cronograma preciso
• Dificuldade na definição de um
orçamento preciso 58
 MODELO CASCATA EM V
• Prevê uma fase de Verificação para
cada fase do desenvolvimento

59
MODELO CASCATA

60
MODELO CASCATA EM V

61
 CASCATA EM V
VANTAGENS
• Foca nos testes e diferentes tipos de
testes
• Testa cada fase do desenvolvimento
• Precursor do TDD (Desenvolvimento
Dirigido por Testes, Test Driven
Development)
62
 CASCATA EM V
DESVANTAGENS
• Adiciona complexidade
• Necessário profissionais experientes
com atividades de testes de cada fase
• Divisão estrita entre as atividades
construtivas do lado esquerdo e
atividades de testes (‘destrutivas’) do
lado direito 63
 MODELO CASCATA EM W
• Assim como Modelo Cascata em V,
enfatiza a importância dos testes em
seus vários níveis
• Surgiu por conta da divisão muito
estrita entre as atividades construtivas
do lado esquerdo do Modelo V e
atividades de testes do lado direito 64
MODELO CASCATA

65
MODELO CASCATA EM W

66
 CASCATA EM W
VANTAGENS
• Foca nos testes e diferentes tipos de testes
• Incorpora o teste nas atividades de
desenvolvimento desde o seu início
• Reduz a divisão estrita entre as atividades
construtivas e atividades de testes
(‘destrutivas’)
• Testes são feitos antes da implementação 67
 CASCATA EM W
DESVANTAGENS
• Adiciona complexidade (MUITA)
• Necessário profissionais experientes com
atividades de testes de cada fase

68
 PRÓXIMA AULA
• Prototipação
• RAD
• Modelo Incremental
• Modelo espiral
• Processo Unificado
69