Ciclo de Vida

Clássico ou Convencional
CICLOS DE VIDA DE
O Modelo Cascata
DESENVOLVIMENTO DE Elicitação
SISTEMAS
Análise

Projeto

Ana Paula Terra Bacelo Blois Implementação

Testes
Material Adaptado do Prof. Marcelo Yamaguti
Manutenção

Ciclo de Vida Clássico

ou Convencional Enfoque Incremental
Apropriado para sistemas transacionais onde as
Representa uma variação do ciclo de vida clássico,


rotinas e procedimentos a serem automatizados são

altamente estruturados. onde a partir da fase de especificação funcional

Problemas do ciclo de vida clássico: (projeto lógico) são feitos incrementos sucessivos.

Os projetos raramente seguem o fluxo seqüencial
que o modelo propõe;
Pressupõe que a partir da especificação funcional

Dificuldades do cliente em declarar explicitamente

todas as suas necessidades; toda a decomposição do sistema - em termos de

Uma versão do software somente estará pronta
subsistemas e módulos - passa a ser conhecida.
ao final do cronograma do projeto;

Incremento dos custos de correção na medida em
que se avancem as fases.

Prototipação Prototipação

Processo que propicia ao desenvolvedor criar um
O modelo pode assumir uma das três formas:
modelo do software que será implementado.
Um protótipo em papel ou visual que retrata a

Os protótipos permitem: interação homem-máquina;

Um protótipo de trabalho que implementa algum

que o projetista avalie previamente algumas
características particulares do projeto; subconjunto da função exigida do software
desejado;

que o modelo seja testado sem o risco de

Um programa que executa parte ou toda a função
comprometer todo um projeto;
desejada, porém que necessita ser aprimorado

que o usuário tenha condições de melhor para tornar-se operacional.
entender o produto que esta sendo desenvolvido.

1
 Prototipação Prototipação
Início

Coleta e
Problemas da prototipação:

Fim Refinamento
dos Requisitos
Engenharia
Não entendimento pelo cliente de que o protótipo
do Produto Projeto não é um produto acabado;
Rápido

Refinamento
Concordância do desenvolvedor com este

do Protótipo Construção entendimento.
Avaliação do do Protótipo
Protótipo
pelo Cliente

Definição da Abordagem
Técnicas de Quarta Geração a ser Utilizada

Coleta de
Alta
Requisitos
Estratégia . Convencional . Prototipação
. Incremental . Incremental
de Projeto Complexidade
Implementação da
usando 4GL Aplicação
. Pacote . Prototipação
Teste
. Convencional
Baixa

ESPECIFICAÇÃO DE REQUISITOS
Definição de B. Meyer

“Especificar o documento de requisitos de um software é

ESPECIFICAÇÃO DE REQUISITOS definir de uma forma completa e não ambígua:

as características externas do software oferecidas aos
usuários;

a forma pela qual o software é integrado no sistema.”

Definição de A. Davis

“Durante a fase de requisitos, é necessário analisar, e portanto
entender o problema a ser resolvido.

Análise do problema é a atividade que inclui o
entendimento das necessidades do usuário bem como as
limitações impostas na solução.”

2
ENGENHARIA DE REQUISITOS O PROCESSO DE ELICITAÇÃO
Objetivos do Sistema
Engenharia de
Requisitos
Entrevista não obtém toda a informação necessária.

O engenheiro de requisitos deve se envolver
Documentos de Requisito

com o ambiente de trabalho do cliente,

se misturar com os funcionários,

Especificação de Software

observar, aprender, e questionar, de forma a

superar a ignorância do domínio do problema.

Projeto

É preciso entender a razão porque as coisas são
Engenharia de feitas da forma que são.
Software Pedaços de Código

GERANDO A ESPECIFICAÇÃO FASE DE ANÁLISE: GERANDO A

DE REQUISITOS

Durante a fase de análise o objetivo é a obtenção de
uma especificação que seja consistente e completa.

O analista deve:

Avaliar o fluxo e o conteúdo da informação;

Definir e elaborar todas as definições do software;

Entender o comportamento do software no
contexto dos eventos que o afetem;

Estabelecer as características de interface do
software com o usuário;

Identificar restrições para o projeto.
ESPECIFICAÇÃO DE REQUISITOS

Princípios fundamentais dos métodos de análise:
[Pressman 95]

O domínio de informação de um problema deve
ser representado e compreendido;
Modelos que descrevem a informação, função e


comportamento do sistema devem ser resolvidos;

Os modelos (e o problema) devem ser divididos
em partições, de maneira que revele os detalhes
em forma de camadas (ou hierarquicamente);

O processo de análise deve mover-se da
informação essencial para os detalhes de
implementação.

FASE DE PROJETO: GERANDO A FASE DE PROJETO: GERANDO A

ESPECIFICAÇÃO DE PROJETO ESPECIFICAÇÃO DE PROJETO

Projeto pode ser definido como o processo realizado
O Processo de Projeto

quando tomamos um modelo lógico de um sistema
juntamente com um conjunto de objetivos fortemente
Projeto de Dados;
formulados para aquele sistema, e produzimos a

especificação de um sistema físico que atenderá a
Projeto Arquitetural;

esses objetivos.
Projeto Procedimental;

Projeto da Interface.

3
 ENFOQUES METODOLÓGICOS ENFOQUES METODOLÓGICOS

ABORDAGEM INFORMACIONAL
ABORDAGEM FUNCIONAL

(1,1) (0,n)
Cliente Contratação Projeto
(0,n)
Utilização ARQUIVO

FLUXO DE PROCESSO
(0,n) (FONTE) DADOS (DESTINO)

Alocação Recursos X TRANS- Y TRANS- Z

FORMAR FORMAR
Materiais E
X EM Y Y EM Z
S

(1,n)
Recursos
Humano

ENFOQUES METODOLÓGICOS

ABORDAGEM ORIENTADA A OBJETOS TÉCNICAS PARA MODELAGEM
DE SOFTWARE
MO
DFD

E-R

INTRODUÇÃO:
INTRODUÇÃO: Modelos Modelagem de Software

Objetivos dos modelos

Testar uma entidade física antes de lhe dar forma.

ex.: modelos de aviões testados em túneis de vento.

Modelos de componentes de um sistema:

Comunicação com clientes.
Modelo de dados/informações:

ex.: plantas baixas.
Armazenamento de informações;

Visualização.

Manipulação de dados armazenados;

ex.: maquetes.

Redução da complexidade.
Modelo funcional:

Não há um único modelo "correto" de um situação, apenas
Processos (funções).

modelos adequados e inadequados.

Modelo dinâmico:

A mente humana só consegue tratar um limitado volume de
informações a cada momento.
Tempo;

Os modelos reduzem a complexidade de um problema

Controle.
dividindo-o em vários problemas menores.

4
INTRODUÇÃO : INTRODUÇÃO :
Modelagem de Dados/Informações Modelagem Funcional

Objetivos:
Objetivos:

Obter uma descrição abstrata, independente de
Modelar os aspectos relacionados à

implementação em computador, dos dados que transformação de valores como funções,

serão armazenados na base de dados. restrições e dependências funcionais do sistema.

Identificar a estrutura e significado dos dados na
Deve permitir descrever o sistema como uma

organização. composição de subsistemas interativos que

processam dados e informações.

Deve descrever o sistema em termos de

processos e suas interfaces.

INTRODUÇÃO : INTRODUÇÃO :
Modelagem Dinâmica Porque modelar o sistema?

Também chamada de Modelagem Comportamental.
Aceitação pelo usuário:

Ausência de modelo visível ao usuário faz com que

Objetivos: ele dê conformidade a soluções incompletas ou

Modelar os aspectos relacionados ao
mesmo erradas!
comportamento do sistema, isto é, mostra o que é
Falta de interação com o usuário.

feito quando.

Deve permitir descrever como o sistema reage a
Ciclo de vida muito comprido:
eventos de tempo e de controle.
O usuário modifica suas necessidades: o problema

Deve descrever o sistema em termos de estados muda!

e as transições entre estes estados.
As pessoas envolvidas não permanecem até o fim.

INTRODUÇÃO :
Porque modelar o sistema?

Documentação:

Documentos textuais e narrativos cansam e

desestimulam.

Realizados após o desenvolvimento do sistema:

desatualização.

Os modelos facilitam a comunicação entre os

envolvidos no desenvolvimento do sistema.

Indispensável para a manutenção do sistema.

Confiabilidade:

Testes e depuração de sistemas mal-modelados.