Modelos de Processo de

Software
 3

Processo de Software

► Sequência estruturada de atividades, papéis, artefatos e

ferramentas.

► Define como o software será construído, entregue e mantido.

► Garante qualidade, previsibilidade e controle.

 3

Processo de Software

► Um processo é estruturado em atividades.

► Cada atividade é atribuída a um papel específico dentro da
equipe.
► Essas atividades resultam em artefatos — como modelos,
documentos ou códigos — que representam produtos de
trabalho.
► Cada atividade deve produzir ao menos um artefato de saída
verificável e, em alguns casos, pode necessitar de artefatos de
entrada para ser executada adequadamente.
 3

Processo de Software

► Na definição de um processo, deve-se definir quais são os

papéis.

► Exemplos:
• Analista
• Arquiteto
• Desenvolvedor
• Testador
• Gerente
 3

Processo de Software

► Os processos de software na Engenharia de Software reúnem

diferentes atividades:
• Desenvolvimento: voltadas à construção do produto, como
análise de requisitos, projeto e implementação.
• Gerência de Projeto: relacionadas ao planejamento e
controle, incluindo estimativas, cronogramas e análise de
riscos.
• Apoio: focadas na qualidade do produto e do processo, por
meio de revisões e inspeções.

Os Modelos de Ciclo de Vida ou Modelos de Processo de Software

oferecem a estrutura que orienta a definição do processo de software.
 3

Modelos de Processo de Software

► Um modelo de processo é uma representação

abstrata que descreve atividades principais, sua
sequência e, às vezes, os artefatos envolvidos.

► Base para orientar a condução do projeto, mas

não garante, por si só, o controle efetivo do
desenvolvimento de software.
 3

Modelos de Processo de Software

► Existem vários modelos de processo de software

(ou paradigmas de engenharia de software)

► Cada um representa uma tentativa de colocar

ordem em uma atividade inerentemente
caótica
 3

Modelos de Processo de Software

► Geralmente envolve as fases: Análise e

Especificação de Requisitos, Projeto, Implementação,
Testes, Entrega e Implantação, e Manutenção.

► Os principais modelos de ciclo de vida são agrupados

nas categorias: modelos sequenciais, modelos
incrementais e modelos evolutivos.
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata (Waterfall)

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 6

O Modelo Cascata

► modelo mais antigo e o mais amplamente usado

da engenharia de software
► modelado em função do ciclo da
engenharia convencional
► requer uma abordagem sistemática,
sequencial ao desenvolvimento de software
► o resultado de uma fase se constitui na entrada
da outra
 7

O Modelo Cascata
 8

O Modelo Cascata

Engenharia
Engenharia de de Sistemas / Informação e
Sistemas
Análise de Modelagem
Requisitos
► envolve a coleta deProjeto
requisitos em nível do
sistema, com uma pequena quantidade de
Codificação
projeto e análise de alto nívelTestes
► esta visão é essencial quando o software deve fazer
Manutenção
interface com outros elementos (hardware, pessoas
e banco de dados)
 9

O Modelo Cascata

Análise de Requisitos de Software

Engenharia de
Sistemas
► o processo de Análise
coletade dos requisitos é intensificado e
concentrado especificamente
Requisitos no software
Projeto

Codificação
► deve-se compreender o domínioTestes
da informação, a
função, desempenho e interfaces exigidas
Manutenção

► osrequisitos (para o sistema e para o software) são

documentados e revistos com o cliente
 10

O Modelo Cascata

Projeto

► tradução dos requisitos do software para um

conjunto de representações que podem ser
avaliadas quanto à qualidade, antes que a
codificação se inicie
 11

O Modelo Cascata

Codificação

► tradução das representações do projeto para uma

linguagem de programação, resultando em
instruções executáveis pelo computador
 12

O Modelo Cascata

Testes
Engenharia de
► Concentra-se:
Sistemas
Análise de
■ nos aspectos lógicos internos
Requisitos do software,
Projeto
garantindo que todas as instruções tenham sido
testadas Codificação

■ nos aspectos funcionais externos,

Testes para
descobrir erros e garantir que a entrada definida
Manutenção

produza resultados que concordem com os

esperados.
 13

O Modelo Cascata

Manutenção
Engenharia de
► provavelmente
Sistemas o software deverá sofrer
mudanças depois
Análise de que for entregue ao cliente
Requisitos
Projeto

► causas das mudanças: Codificação

• erros, adaptação do software Testes

para acomodar
mudanças em seu ambiente externo e exigência
Manutenção do
cliente para acréscimos funcionais e de desempenho
 16

O Modelo Cascata

► Projetos reais raramente seguem o fluxo sequencial

que o modelo propõe

► Logo no início é difícil estabelecer explicitamente

todos os requisitos. No começo dos projetos sempre
existe uma incerteza natural

► O cliente deve ter paciência. Uma versão executável

do software só fica disponível numa etapa avançada
do desenvolvimento
 15
Problemas com o Modelo Cascata

Embora o Modelo Cascata tenha

fragilidades, ele é significativamente
melhor do que uma abordagem casual
ao desenvolvimento de software.
 16

O Modelo Cascata

►O modelo Cascata trouxe contribuições

importantes para o processo de
desenvolvimento de software:
■ Imposição de disciplina, planejamento e
gerenciamento
■ A implementação do produto deve ser postergada
até que os objetivos tenham sido completamente
entendidos
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 18

O Modelo de Prototipação

►o objetivo é entender os requisitos do

usuário e, assim, obter uma melhor definição
dos requisitos do sistema.

► possibilitaque o desenvolvedor crie um modelo

(protótipo) do software que deve ser construído

► apropriado para quando o cliente não tem

definido detalhadamente os requisitos.
 19
O Paradigma de Prototipação para obtenção
dos requisitos

Obter Requisitos

Elaborar Projeto Rápido

Refinamento do Protótipo

Construir Protótipo
Avaliar Protótipo
 20
O Paradigma de Prototipação para obtenção
dos requisitos
 21
O Paradigma de Prototipação para obtenção
dos requisitos
 22
O Paradigma de Prototipação para obtenção
dos requisitos
 23
O Paradigma de Prototipação para obtenção
dos requisitos
 24
O Paradigma de Prototipação para obtenção
dos requisitos
 25
O Paradigma de Prototipação para obtenção
dos requisitos
 26
O Paradigma de Prototipação para obtenção
dos requisitos
 27

Problemas com a Prototipação

► cliente não sabe que o software que ele vê não

considerou, durante o desenvolvimento, a
qualidade global e a manutenibilidade a longo
prazo

► desenvolvedor frequentemente faz uma

implementação comprometida (utilizando o que
está disponível) com o objetivo de produzir
rapidamente um protótipo
 28
Comentários sobre o Paradigma de
Prototipação

► ainda que possam ocorrer problemas, a

prototipação é um ciclo de vida eficiente.
►a chave é definir-se as regras do jogo logo
no começo.
► o cliente e o desenvolvedor devem ambos
concordar que o protótipo seja construído
para servir como um mecanismo a fim de
definir os requisitos
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 30

O Modelo RAD

► RAD ( Rapid Application Development) é um

modelo sequencial linear que enfatiza um ciclo
de desenvolvimento extremamente curto

►O desenvolvimento rápido é obtido usando

uma abordagem de construção baseada em
componentes.
 31

O Modelo RAD

► Osrequisitos devem ser bem entendidos e o

alcance do projeto restrito

►O modelo RAD é usado principalmente para

aplicações de sistema de informação

► Cada função principal pode ser direcionada

para uma equipe RAD separada e então
integrada para formar o todo.
 32

O Modelo RAD

Equipe #3
Equipe #1 Equipe #2 Modelagem
do Negócio
Modelagem Modelagem Modelagem
do Negócio dos Dados
do Negócio Modelagem Modelagem
Modelagem dos Dados do Processo
dos Dados Modelagem Geração da
do Processo Aplicação
Modelagem Teste e
Geração da
do Processo Aplicação Modificação

Geração da Teste e
Modificação
Aplicação
Teste e
60 a 90 dias Modificação
 33

O Modelo RAD

Desvantagens:
■ Exige recursos humanos suficientes para
todas as equipes

■ Exige que desenvolvedores e clientes

estejam comprometidos com as atividades
de “fogo-rápido” a fim de terminar o
projeto num prazo curto
 34

O Modelo RAD

► Nem todos os tipos de aplicação são

apropriadas para o RAD:
■ Deve ser possível a modularização efetiva da
aplicação
■ se alto desempenho é uma característica e o
desempenho é obtido sintonizando as interfaces
dos componentes do sistema, a abordagem
RAD pode não funcionar
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 36

Modelos Evolutivos de Processo

► Existem situações em que a engenharia

de software necessita de um modelo de
processo que possa acomodar um
produto que evolui com o tempo.
 37

Modelos Evolutivos de Processo

► quando os requisitos de produto e de negócio

mudam conforme o desenvolvimento procede
► quando uma data de entrega apertada
(mercado), torna impossível a conclusão de um
produto completo.
► quando um conjunto de requisitos importantes é
bem conhecido, porém os detalhes ainda devem
ser definidos
 38

Modelos Evolutivos de Processo

► modelos evolutivos são iterativos

► possibilitam
o desenvolvimento de
versões cada vez mais completas do
software.
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 40

O Modelo Incremental

►o modelo incremental combina elementos do

modelo cascata (aplicado repetidamente) com
a filosofia iterativa da prototipação

►o objetivo é trabalhar junto do usuário para

descobrir seus requisitos, de maneira
incremental, até que o produto final seja
obtido.
 41

O Modelo Incremental
 42

O Modelo Incremental

►a versão inicial é frequentemente o

núcleo do produto (a parte mais
importante)
■ a evolução acontece quando novas
características são adicionadas à medida que
são sugeridas pelo usuário

► Estemodelo é importante quando é difícil

estabelecer inicialmente uma especificação
detalhada dos requisitos
 43

O Modelo Incremental

►o modelo incremental é mais apropriado para

sistemas pequenos

► Asnovas versões podem ser planejadas de

modo que os riscos técnicos possam ser
administrados (Ex. disponibilidade de
determinado hardware)
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 45

O Modelo Espiral

►O modelo espiral acopla a natureza iterativa da

prototipação com os aspectos controlados e
sistemáticos do modelo cascata.

►O modelo espiral é dividido em uma série de

atividades de trabalho ou regiões de tarefa.

► Existem tipicamente de 3 a 6 regiões

 46

O Modelo Espiral (com 4 regiões)

 47

O Modelo Espiral (com 4 regiões)

 48
O Modelo Espiral

o “loop” mais interno

está concentrado
nas possibilidades
do sistema
Risk
Proto-
REVIEW analysis
type 1
Requirements plan
Life-cycle plan Concept of
Operation
 49
O Modelo Espiral

o próximo “loop”
está concentrado na Risk
analysis
definição dos Prototype

requisitos do
Simulations, models, benchmarks
sistema
SW
requirements

Development Requirement
plan validation
 50
O Modelo Espiral

Risk
analysis

prototype 3
o “loop” um pouco
mais externo está
concentrado no simulations, models, benchmarks

projeto do sistema Product

design

Integration Design V&V

and test plan
 51
O Modelo Espiral

Risk
analysis

Opera-
tional
prototype
um “loop” ainda
mais externo está Simulations, models, benchmarks

concentrado na
construção do Detailed design
Code
sistema Unit test
Integration
test
Acceptance
Service test
 52

O Modelo Espiral (com 4 regiões)

 53

O Modelo Espiral (com 4 regiões)

 54
O Modelo Espiral

• são definidos objetivos específicos

para a fase do projeto
COLOCAÇÃO DE • são identificadas restrições sobre o
OBJETIVOS processo e o produto
• é projetado um plano de
gerenciamento detalhado
• são identificados riscos do projeto
• dependendo dos riscos, estratégias
alternativas podem ser planejadas
 55
O Modelo Espiral

• para cada um dos

riscos identificados, AVALIAÇÃO E
umaCOLOCAÇÃO
análise detalhada REDUÇÃO DE
DE
é executada. RISCOS
OBJETIVOS
• passos são tomados para
reduzir o risco
 56
O Modelo Espiral

AVALIAÇÃO E
COLOCAÇÃO DE REDUÇÃO DE
OBJETIVOS RISCOS

depois da avaliação do risco, um

modelo de desenvolvimento é DESENVOLVIMENTO
escolhido para o sistema
E VALIDAÇÃO
 57
O Modelo Espiral

AVALIAÇÃO E
COLOCAÇÃO DE REDUÇÃO DE
OBJETIVOS RISCOS
o projeto é revisto e é tomada
uma decisão de continuidade
se é decidido continuar, são
projetados planos para a próxima
PLANEJAMENTO DESENVOLVIM
fase do projeto (próximo“loop”) O
E
E VALIDAÇÃ
 58

O Modelo Espiral
► engloba as melhores características do ciclo de
vida Clássico e da Prototipação, adicionando
um novo elemento: a Análise de Risco

► segue a abordagem de passos sistemáticos do

Ciclo de Vida Clássico incorporando-os numa
estrutura iterativa que reflete mais realisticamente
o mundo real

► usa a Prototipação, em qualquer etapa da

evolução do produto, como mecanismo de
redução de riscos
 59
Comentários sobre o Ciclo de Vida em
Espiral

► É uma abordagem mais realística para o

desenvolvimento de software em grande
escala.
► usa uma abordagem que capacita o desenvolvedor
e o cliente a entender e reagir aos riscos em cada
etapa evolutiva
► pode ser difícil convencer os clientes que uma
abordagem "evolutiva" é controlável
 61

O Modelo Espiral (com 6 regiões)

Planejamento
Análise de Riscos

Comunicação
com Cliente

Engenharia

Avaliação do Cliente
Construção e Liberação
 62

O Modelo Espiral
► adiciona um novo elemento: a Análise de Risco

► usa a Prototipação, em qualquer etapa da

evolução do produto, como mecanismo de
redução de riscos

► exige considerável experiência na

determinação de riscos e depende dessa
experiência para ter sucesso
 4

Modelos de Processo de Software

► O Modelo Sequencial Linear

■ também chamado Modelo Cascata

► O Modelo de Prototipação

► O Modelo RAD (Rapid Application Development)

► Modelos Evolutivos de Processo de Software

■ O Modelo Incremental
■ O Modelo Espiral
■ O Modelo de Montagem de Componentes
 64
O Modelo de Montagem de Componentes

► Utilizatecnologias orientadas a objeto

► Quando projetadas e implementadas
apropriadamente as classes orientadas a
objeto são reutilizáveis em diferentes
aplicações e arquiteturas de sistema
► O modelo de montagem de components
incorpora muitas das características do modelo
espiral.
 64
O Modelo de Montagem de Componentes
 66

identificar
omponentes
componentes
candidatos

procurar Construir a na
componentes Planejamento
iteração do
na biblioteca sistema Análise de Riscos

extrair colocar os
municação
componentes novos
se
mdisponíveis
Cliente componentes
na biblioteca

construir os
componentes
não
disponíveis
aliação do Cliente
Engenharia
Construção e Liberação
 67
O Modelo de Montagem de Componentes

►O modelo de montagem de componentes

conduz ao reuso do software
►a reusabilidade fornece uma série de
benefícios:
■ redução de 70% no tempo de desenvolvimento
■ redução de 84% no custo do projeto
■ índice de produtividade de 26 (normal da
indústria é de 17)
► esses resultados dependem da robustez da
biblioteca de componentes
 67
Comparando Modelos

Modelo Vantagens Desvantagens Melhor Contexto

Estrutura clara,
Cascata Rígido, difícil mudar Projetos estáveis
documentação
Entregas rápidas, Integração
Incremental Sistemas evolutivos
feedback complexa
Gestão de riscos Custo alto,
Espiral Projetos críticos
eficaz complexidade
Protótipo
Bom para elicitar
Prototipação confundido com Requisitos incertos
requisitos
produto