Fabrício Costa Santana
professorfabricio.net
[email protected]

Ementa:
◦ Visão geral de um sistema. Conceito de sistemas.
Sistemas de informação. Análise de sistemas.
Estudo do ciclo de vida de um sistema.
Metodologias de desenvolvimento de sistemas.
Técnicas de Entrevistas e de Coleta de Dados.
Análise estruturada de sistemas. Ferramentas da
Análise Estruturada.

OBJETIVO GERAL
◦ Capacitar o aluno a utilizar adequadamente as
ferramentas da análise estruturada e projeto
estruturado nas fases de desenvolvimento de
modelos corretos de sistemas. Apresentar ao aluno
as etapas seguidas pelo analista de sistemas na
construção de um modelo do sistema até a sua
implementação, usando essas técnicas. Deverá
também saber como e quando utilizar as
ferramentas de análise e projeto estruturados.

OBJETIVOS ESPECÍFICOS
◦ Compreender, de forma integrada, a natureza dos
sistemas de informação, sua importância para as
organizações para uma melhor compreensão do papel
dos profissionais que atuam nessa área;
◦ Utilizar o pensamento sistêmico na solução de
problemas, dando condições para que este apresente
propostas de pesquisa e desenvolvimento na área de
sistemas de informação;
◦ Ter uma visão clara de um sistema, com suas etapas de
desenvolvimento e a complexidade implícita em cada
uma delas;
◦ Entender e saber aplicar as ferramentas de análise
estruturada de sistemas;
◦ Dominar as técnicas da análise essencial.





YOURDON, Edward. Análise estruturada
moderna. Rio de Janeiro: Campus, 1990. 836p.
GANE, Chris; SARSON, Trish. Análise estruturada
de sistemas. Rio de Janeiro: LTC, 1995. 257p.
MARTIN, James; McCLURE, Carma. Técnicas
estruturadas e CASE. São Paulo: Makron Books,
1991. 854p.
DeMARCO, Tom. Análise estruturada e
especificação de sistemas. Rio de Janeiro:
Campus, 1989.
HEUSER, Carlos. Projeto de Banco de Dados. 1998
Conjunto de elementos interdependentes
(entidades
relacionadas),
ou
um
todo
organizado, ou partes que interagem formando
um todo unitário e complexo desenvolvendo
atividades ou funções para atingir um ou mais
objetivos.

O objetivo é a própria razão de existência do
sistema

É tudo aquilo que o sistema necessita como
material de operação e é obtido no meio
ambiente com o qual interage. É a energia
que entra no sistema.

Transformação de um insumo (entrada) em
um produto, serviço, ou resultado (saída).
Este processo é a maneira pela qual os
elementos componentes de um sistema
interagem no sentido de produzir as saídas
desejadas.



São os resultados do processo de
transformação das entradas;
É o produto final do processamento que será
colocado no meio ambiente em que o sistema
se insere;
É a forma de o sistema influenciar o meio.


A retroalimentação pode ser considerada
como a reintrodução de uma saída sob a
forma de informação.
Essa realimentação é um instrumento de
regulação retroativa, ou de controle, em que
as informações realimentadas são resultados
das divergências verificadas entre as
respostas de um sistema e os parâmetros
previamente estabelecidos.



Padaria
Construção
Consultório Médico


Sistemas Naturais
Sistemas Feitos Pelos Homens

Conceito:
◦ “Sistemas feitos pelo homem, que interagem com
ou são controlados por um ou mais computadores”
(YOURDON, Edward)





Sistemas
Sistemas
Sistemas
Sistemas
Sistemas
Batch
On-line
de Tempo Real
de Apoio à Decisão
Baseados no Conhecimento
1.
2.
3.
4.
Quanto mais especializado é um sistema,
menos capaz ele é de se adaptar a
circunstâncias diferentes.
Quanto maior for um sistema, maior o
número de recursos que serão necessários à
manutenção diária.
Os sistemas sempre fazem parte de
sistemas maiores e sempre podem ser
divididos em sistemas menores.
Os sistemas crescem

Um sistema de informação é um conjunto
organizado de elementos, podendo ser
pessoas, dados, atividades ou recursos
materiais em geral. Estes elementos
interagem entre si para processar informação
e divulga-la de forma adequada em função
dos objetivos de uma organização.





Hardware
Software
Dados
Procedimentos
Peopleware
Estratégico
Tático
Operacional

Sistema de Processamento de Transações
◦
◦
◦
◦
Dados reais e precisos.
Saída: relatórios analíticos
Frequência: periódica
Ex: faturamento, estoque, contabilidade
Operacional

Sistema de Controle Operacional
◦ Supervisão
◦ Compara o realizado com o previsto
Tático
◦ Relatórios consolidados
◦ Frequência: periódica
◦ Ex: custos, planejamento e controle de produção

Sistema de Apoio à Decisão
◦ Média Gerência
◦ Análise matemática e estatística dos dados
Tático
◦ Saída: gráficos e tabelas
◦ Frequência: a pedido
◦ Ex: simulação de cenários, análise de investimentos
Estratégico

Sistema de Planejamento Estratégico
◦ Alta administração
◦ Analisa os fatores críticos de sucesso
◦ Trabalha com projeções a longo prazo e tendências do
mercado
◦ Saídas: gráficos e tabelas sofisticados
◦ Frequência: a pedido
◦ Ex: sistemas de informações executivas, BI







Usuários
Gerente de Projeto
Auditores, Controle de Qualidade e
Padronizadores
Analista
Projetista
Programador
Operador




Para quem o sistema é construído;
O analista deve manter contato constante
com eles;
A frase “o cliente tem sempre razão” deve ser
respeitada;
Devem ser chamados de Clientes ou
Proprietários.

Operadores
◦ Têm visão local, isto e, não conhecem o processo
de forma global
◦ Responsáveis por executar as funções do sistema
◦ Têm uma visão física do sistema, ou seja, imaginam
o funcionamento do sistema considerando a
tecnologia de implementação

Supervisores
◦ Podem ou não ter uma visão local
◦ Geralmente conhecem as operações pois muitos já
foram Utilizadores operadores. Além disso, têm que
supervisionar os Utilizadores operadores
◦ Orientado por considerações orçamentais (reduzir o
quadro de funcionários ou aproveitá-los melhor)
◦ Normalmente agem como intermediários em
relação aos níveis mais elevados

Executivos
◦
◦
◦
◦
◦
Não têm experiência operativa
Têm a iniciativa do projeto
Possuem uma visão global
Têm preocupações estratégicas
Capazes de lidar com modelos abstratos

Amador
◦ Nunca trabalhou com um computador
◦ Tem dificuldade para entender os modelos
produzidos pelos analistas
◦ Receia ser substituído pelo sistema ou ter sua
importância minimizada

Novato arrogante
◦ Participou de alguns projetos
◦ Possui ou trabalha com computadores
◦ Por conhecer algumas ferramentas, gosta de opinar
sobre as tecnologias a serem usadas para
implementar o sistema

Experiente
◦ Conhecem a análise de sistemas
◦ Têm experiência de outros projetos
◦ Discutem sobre as técnicas de modelação sendo
utilizadas

Principais funções:
◦ Gerenciar e alocar recursos de toda a equipe técnica
◦ Prestar contas junto à administração superior
◦ Encaminhar problemas identificados no decorrer do
projeto

Responsáveis por garantir que o sistema será
desenvolvido de acordo com os vários
padrões internos e externos da organização,
especialmente aqueles voltados à segurança e
ao controle de qualidade do produto final.

O analista de sistemas precisa ter aptidões
interpessoais (além do conhecimento da
tecnologia), ou seja, deve falar com outras
pessoas usando a “linguagem” que elas usam,
para não ser considerado amedrontador ou
alienígena.

Desempenha vários papéis:
◦
◦
◦
◦
Arqueólogo e escriba
Mediador
Inovador
Líder de projeto

Características de um bom analista:
◦ Possui habilidade com pessoas.
◦ Possui conhecimento de aplicações (ajuda a
compreender a empresa do usuário).
◦ Possui habilidade em tecnologia.
◦ Mente lógica e organizada (visualizar o sistema sob
diferentes perspectivas).


Tem a função de transformar os requisitos
dos usuários, modelados pelo analista de
sistemas, em um projeto implementável em
um computador.
Normalmente o analista e o projetista são a
mesma pessoa, ou membros do mesmo
grupo de pessoas.


O analista de sistemas deve fornecer
informações suficientemente detalhadas para
que o projetista elabore um projeto
tecnologicamente bom.
O projetista deve fornecer informações
suficientes para que o analista possa dizer se
os requisitos dos usuários podem ser
completamente atendidos ou devem ser
modificados.


Responsável por codificar e testar (usando
uma linguagem de programação) os módulos
do sistema modelados pelos projetistas.
Em um cenário ideal, o programador não
deveria ter contato com o analista já que se
baseia apenas no trabalho feito pelo
projetista.

Pessoa encarregada de operar os
computadores, da rede, da segurança do
hardware e das bases de dados, da execução
dos programas e da saída das impressoras.






Conceito:
Estudo de um problema, que antecede à tomada de
uma decisão/ação (antes de passar à sua resolução).
Em Sistemas de Informação:
Estudo de alguma área de trabalho ou de uma
aplicação, descrição das suas características e
funcionalidades, levando geralmente à especificação
de um novo sistema.
Análise Estruturada:
É a utilização de ferramentas que permitem a
especificação formal dos requisitos do sistema a ser
desenvolvido.




Etapa onde ocorre uma análise detalhada dos
requisitos levantados;
São construídos modelos para representar o
sistema a ser desenvolvido;
Uma especificação formal dos requisitos é
produzida, representando todos os requisitos
analisados;
Uma revisão da especificação é realizada, de
forma a garantir que a mesma esteja
completa, consistente e precisa quanto às
informações nela apresentadas.




O Domínio da Informação de um problema
precisa ser representado e entendido;
As funções a serem desenvolvidas pelo
sistema devem ser definidas (modelos devem
ser desenvolvidos descrevendo a informação,
a função e o comportamento do sistema);
Os modelos devem ser particionados de
modo que revelem detalhes em forma de
camadas;
O processo de análise deve ir da informação
essencial até os detalhes de implementação.

É uma representação em pequena escala de
um objeto que se pretende executar ou
reproduzir em tamanho natural.





Mapas: modelos bidimensionais do mundo
em que vivemos;
Globos: modelos tridimensionais do mundo
em que vivemos;
Pautas musicais: representações gráficas /
textuais das notas musicais;
Desenhos arquitetônicos: planta de uma casa,
ou edifício, ou ponte...;
Fluxograma: representações esquemáticas de
decisões e seqüência de atividades para
execução de algum procedimento.

“... podemos construir modelos de maneira
a realçar ou enfatizar certos recursos
decisivos
do
sistema,
enquanto,
simultaneamente, podemos ignorar outros
aspectos do sistema. Isto permite que nos
comuniquemos com o usuário de uma
maneira clara...”

Edward Yourdon




Entidade Relacionamento
Diagrama de Fluxo de Dados
Especificação de Processos
Dicionário de Dados

Percepção de que o mundo real é formado
por um conjunto de objetos chamados
entidades e pelo conjunto dos
relacionamentos entre estes objetos.

Mostram as funções e sub-funções que
transformam o fluxo de dados.

Fornecem uma indicação de como os dados
são transformados.

É uma listagem organizada, com descrições
de todos os elementos de dados pertinentes
ao sistema.




Fazer uso de ferramentas, facilitando a
comunicação com o usuário e a organização
das informações;
Retirar a redundância do documento gerado
(especificação estruturada);
Substituir o excesso de texto do documento
gerado, por gráficos;
Tornar mais fácil o processo de manutenção,
após a codificação.



Possibilidade de focalizar a atenção nas
características importantes do sistema,
deixando um pouco de lado as menos
importantes;
Discutir modificações e correções nos
requisitos do usuário com baixo custo e
mínimo risco;
Mostrar ao usuário o sistema que será
implementado de forma mais clara e objetiva.



Descrever o que o cliente deseja;
Estabelecer uma base para a criação de um
projeto do sistema;
Definir um conjunto de requisitos que possa
ser validado quando o sistema for construído.

Para desenvolver sistemas úteis, de alta
qualidade e que realmente satisfaçam as
necessidades dos utilizadores, é necessário
considerar os seguintes aspectos:
◦
◦
◦
◦
◦
◦
Produtividade;
Confiabilidade;
Manutenibilidade;
Qualidade;
Portabilidade;
Segurança.

Os dois aspectos mais importantes deste
problema são:
◦ A demanda reprimida (backlog) por novos sistemas;
◦ O tempo necessário para construir um novo
sistema.

Visível:
◦ Solicitados oficialmente pelos utilizadores e que foram
aceites e tiveram suas verbas aproveitadas pela gestão.
◦ Ainda não foram iniciados por falta de recursos
humanos (analistas, programadores, etc.)

Invisível:
◦ Sistemas que os utilizadores sabem que precisam, mas
não se dão ao trabalho de solicitar oficialmente porque
ainda estão a aguardar outros projectos

Desconhecido:
◦ Sistemas que os utilizadores ainda não sabem que
precisam mas que emergirão logo que sejam concluídos
outros sistemas dos backlogs visível e invisível.



Preocupação com a perda de oportunidades
de negócios.
Quando o sistema ficar pronto, as condições
terão se modificado.
Muitos projetos nem são terminados.





Problemas técnicos
Problemas gerenciais
Inexperiência da equipe
Falta de tempo para análise e projeto
Escasso envolvimento por parte da gerência
ou usuários







Contratação de mais profissionais
Contratação de profissionais mais talentosos,
com melhores condições de trabalho
Deixar que usuários desenvolvam seus
pequenos sistemas (Ex: planilhas de cálculos)
Melhores linguagens de programação
Atacar o problema da manutenção
Controles de Engenharia de Software
Ferramentas automatizadas (Ferramentas
CASE)



A produtividade e a qualidade do trabalho dos
programadores está diretamente ligada ao
serviço feito pelo analista
Algumas das técnicas de aumento de
produtividade têm importância direta para os
analistas
A produtividade da análise é um problema
politicamente sensível
◦ Utilizadores e gestor têm ansiedade pelo início da
programação
◦ Utilizadores não entendem a importância da
especificação


“Para que servem todas essas figuras e
palavras? Nós já explicamos o que queremos.
Para que escreveram tudo isso?”
“Quando vocês vão começar a escrever os
programas?”





É difícil descobrir como solucionar o erro;
Deve-se encontrar todos os pontos de
correção;
Alta probabilidade de introduzir novos erros
(efeitos colaterais);
Nem sempre são reportados pelos
utilizadores;
Dificuldade de reproduzir o erro.




Em 1979, o sistema SAC / NORAD (que significa
Strategic Air Command / Defesa Aérea NorteAmericana) registrou 50 alarmes falsos, incluindo um
ataque simulado, os resultados ou saídas
ocasionaram acidentalmente um combate ao vivo.
Um erro de programa em um simulador de vôo de
avião F16 o levava a ficar de cabeça para baixo, toda
vez que cruzava a linha do Equador.
Um míssil de um F18 iniciou sua propulsão quando
ainda ligado ao avião e fez a aeronave perder 6000
metros de altitude.
As portas do sistema de trem BART, controlado por
computador, em São Francisco, às vezes aberto no
tempo entre as estações.



Um sinal de alerta do NORAD, do Sistema de Aviso
Rápido de Mísseis Balísticos (BMNEWS), detectou a
lua, como um míssil que se aproximava;
O índice da bolsa de valores de Vancouver, no
Canadá, perdeu 574 pontos no período de 22 meses,
devido a um erro de arredondamento de decimais
(por exemplo, arredondar 3,14159 para 3,1416);
Em 28 de novembro de 1979, um avião da Air New
Zealand caiu em uma montanha. As investigações
posteriores mostraram que haviam sido detectados e
corrigidos um erro nos dados do curso do
computador, mas nunca foram reportados para o
piloto.





Inicialmente o nº de erros encontrados é pequeno (utilizadores sem segurança
para apontar erros), como indica T1.
À medida que os utilizadores se familiarizam com sistema os erros são percebidos
e reportados (entre T1 e T2).
Após um tempo (após T2) o nº de erros encontrados começa a diminuir (sistema
começa a tornar-se mais estável).
O número de erros volta a crescer devido a correções ou modificações que
introduzem novos erros (após T3).
A curva nunca atinge zero.






Modificações no hardware
Novos dispositivos
Necessidade de melhorar o desempenho
Garantir maior confiabilidade
Alterações dos requisitos
Principal dificuldade: documentação
desatualizada



A qualidade de um sistema pode ser
mensurada considerando a eficácia e a
eficiência obtidas:
Eficácia = Resultados Obtidos / Resultados
Pretendidos
Eficiência = Resultados Obtidos / Recurso
Consumido





Não contribuem para os objetivos da
empresa;
Não atendem às necessidades dos
utilizadores;
Não são confiáveis;
São ineficientes;
Têm manutenção constante, difícil e onerosa.





Consiste em escrever sistemas que podem
ser transferidos para outras plataformas.
Apesar de não ser um problema da alçada do
analista, ele deve especificar que há essa
necessidade.
A portabilidade geralmente provoca
ineficiência já que recursos disponíveis de
determinada
plataforma não são aproveitados.

A segurança de sistemas de informação
consiste basicamente em:
◦ Impedir o acesso de pessoas não autorizadas;
◦ Conceder acesso a certas funcionalidades apenas a
algumas pessoas.







Ausência de Planeamento de Sistemas;
Ausência de Administração de Dados;
Não utilização de Métodos e Técnicas Formais de
Desenvolvimento;
Não utilização de Técnicas e Ferramentas;
Adoção de Metodologias não ambientadas à realidade da
empresa;
Falta de definição precisa dos objetivos e requisitos do
sistema;
Dificuldade de comunicação e/ou falta de entrosamento
entre as pessoas envolvidas no processo;
◦ Dificuldade de comunicação entre Utilizadores e Desenvolvedores
(linguagem);
◦ Rivalidade entre utilizadores;

Falta de precisão e clareza na especificação dos sistemas.



Um ciclo de vida de projeto bem definido oferece
mecanismos para planejar e acompanhar atividades
de forma mais precisa, possibilitando a detecção
de problemas de forma mais rápida.
Também conhecido como:
Metodologia de Desenvolvimento de Sistemas ou
Plano de Projeto.



São relativamente informais;
São iniciados após um entendimento verbal
entre os usuários e a equipe de projeto;
O trabalho de desenvolvimento é feito sem
muito alvoroço.




Tudo é feito de maneira mais formal;
As comunicações entre os usuários, a
gerência e a equipe de projeto são
documentadas;
Todos estão cientes da existência de várias
fases;
Normalmente o gerente é responsável por
definir as fases e atividades do projeto.

Definir as atividades a serem executadas no
projeto;
◦ Participantes têm uma visão do que estão fazendo
no projeto.


Manter consistência entre projetos de uma
mesma organização;
Introduzir pontos de verificação para o
controle gerencial de decisões;
◦ Permite identificar se o projeto está atrasado e
como corrigir o problema.

Implementação Bottom-Up (de baixo para
cima):
◦ Nada está terminado até que esteja totalmente
pronto.
◦ Os erros triviais são encontrados no início do
período de teste e os erros mais sérios são
encontrados no final.
◦ A depuração tende a ser extremamente difícil
durante os estágios finais dos testes do sistema.
◦ A necessidade de tempo para testes normalmente
aumenta exponencialmente durante os estágios
finais do projeto.

Progressão Sequencial:
◦ As fases são seguidas de forma sequencial.
◦ As especificações produzidas em cada fase são
"congeladas".
◦ Os requisitos mudam e é necessário voltar à fase
inicial.
◦ Erros são encontrados na especificação e devem ser
corrigidos.



Também conhecida como estudo de
viabilidade ou estudo inicial das atividades.
Normalmente é iniciado quando o usuário
solicita que algo seja automatizado.
É importante peça para tomada de decisão e
no planejamento do sistema.

Principais objetivos:
◦ Identificar os usuários responsáveis e desenvolver
um "escopo" inicial do sistema:
 Entrevistas
 Diagrama de Contexto
 Diagrama(s) de Fluxo de Dados
◦ Identificar as atuais deficiências no ambiente do
usuário.
◦ Estabelecer metas e objetivos para um novo
sistema.

Problema que pode ocorrer:
◦ Dificuldade em entender o problema a ser
resolvido.
Usuários
Requisitos do
Sistema
1.Levantamento
Relatório
experimental
de custo/
benefícios
Direção
Restrições
Charter


Gerar uma especificação estruturada do
projeto do sistema a partir do critério do
usuário e da previsão do projeto.
Isso envolve a modelagem do ambiente do
usuário usando as seguintes ferramentas:
◦ Diagramas de Fluxo de Dados
◦ Diagramas de Entidades-Relacionamentos
◦ Diagramas de Transições de Estado

Envolve o desenvolvimento de um modelo
ambiental e um comportamental.
Usuários
Políticas do
Usuário
Requisitos
do Sistema
1. Levantamento
Relatório
experimental
de custo/
benefícios
Operações
Charter
Restrições
Direção
Restrições
2. Análise
Relatório
de custo/
benefícios
Especificação
Estruturada




Alocação de partes da especificação (modelo
essencial) aos processadores apropriados
(pessoas ou máquinas).
Desenvolvimento de uma hierarquia de módulos
de programas e interfaces entre esses módulos.
Transformação do modelo de dados em um
projeto de banco de dados (dependente da
tecnologia adotada).
Deve ser desenvolvido o modelo de
implementação do usuário (fronteira homemmáquina e interface homem-máquina).
Usuários
Operações
Políticas do
Usuário
Requisitos
do Sistema
1. Levantamento Charter 2. Análise
Relatório
experimental
de custo/
benefícios
Restrições
Direção
Relatório
de custo/
benefícios
Restrições
Especificação
Estruturada
3. Projeto
Especificação
de projeto



Codificação e integração dos módulos.
Programação Estruturada e Implementação
Top-Down.
O sistema vai ficando completo
progressivamente.


Criar os testes de aceitação a partir da
especificação estruturada.
Pode ser feita paralelamente ao projeto e à
implementação.
2. Análise
Especificação
Estruturada
5. Geração do
Teste de
Aceitação
Conjunto de
teste de controle
de qualidade
3. Projeto
Especificação
de projeto
4.Implementação
Sistema
integrado


Também chamada de teste final ou teste de
aceitação.
Exige como entrada os testes de aceitação e
um sistema integrado.


Descrição formal das partes do novo sistema:
manuais
Descrição de como será a interação com o
usuário (parte automatizada).
2.Análise
Especificação
Estruturada
7. Descrição de
Procedimentos
Manual do Usuário
5. Geração do
Teste de
Aceitação
4.Implementação
Conjunto de
teste de controle
de qualidade
Sistema
integrado
6. Controle de
Qualidade
Sistema
aceito

Desenvolver programas para converter os
dados existentes para o novo banco de
dados.


Passagem imediata x gradual.
Treinamento dos usuários.
Operações
3.Projeto
Banco de Dados
existente
Especificação
de projeto
8.Conversão
de Banco de
Dados
Banco de Dados
convertido
6.Controle de
Qualidade
Sistema
aceito
9. Instalação
Sistema
instalado

Abordagem Radical do ciclo de vida:

Abordagem Conservadora do ciclo de vida:


◦ As atividades do projeto são executadas em paralelo (a
codificação começa no primeiro dia).
◦ Uma atividade só é iniciada quando a anterior foi
concluída.
Ambas as abordagens são perigosas pois são os
extremos.
Podem ser adotadas abordagens intermediárias:
◦ Iniciar uma fase quando 75% ou 50% da anterior estiver
concluída.
◦ Executar duas atividades em paralelo (levantamento e
análise).


Para cada projeto, uma abordagem diferente
pode ser usada, baseada nos seguintes
fatores:
Quão inconstante é o usuário?
◦ Usuários inconstantes ou inexperientes requerem
uma abordagem mais radical.
◦ Usuários veteranos se adequam mais a uma
abordagem mais conservadora.

Pressão para produzir resultados imediatos e
palpáveis.

Para cada projeto, uma abordagem diferente
pode ser usada, baseada nos seguintes
fatores:
◦ Pressão sobre o gerente do projeto para produzir
um cronograma, um orçamento e avaliação de
pessoas e outros recursos:
 Radical (precoce) -> maior erro.
 Conservadora -> menor erro.
◦ Perigo em cometer um erro técnico (implementação
inviável).




Na prototipação cada necessidade levantada é
simulada no protótipo, que é expandido e
refinado gradualmente.
Também conhecido como desenvolvimento
heurístico.
É uma alternativa atraente para lidar com a
incerteza, a ambiguidade e a inconstância
dos projetos.
No final da modelagem o protótipo será
desprezado e substituído por um programa
real pois ele é apenas um modelo.

Os prototipadores normalmente utilizam os
seguintes tipos de ferramentas:
◦
◦
◦
◦
◦
◦
Dicionário de dados integrado.
Gerador de tela.
Gerador de relatórios não-procedural.
Linguagem de programação de quarta geração.
Linguagem de consultas não-procedural.
Recursos poderosos de gerenciamento de banco de
dados.

Projetos que são bons candidatos para a
abordagem de prototipação têm as seguintes
características:
◦ O usuário é incapaz ou não deseja examinar
modelos abstratos de papel como DFD's.
◦ O usuário é incapaz de exprimir os seus requisitos,
podendo identificá-los através de tentativas e erros
("Eu não sei o que quero, mas eu saberei, se o vir").
◦ O sistema está previsto para ser on-line (a maioria
das ferramentas de apoio são orientadas para a
abordagem on-line).
◦ Não exige a especificação de grandes quantidades
de detalhamento algorítmico.
◦ O usuário está mais interessado no formato e na
diagramação da entrada e da saída.


A abordagem da prototipação pode ser
combinada à análise estruturada como uma
forma de auxiliar a descoberta/especificação
dos requisitos.
A abordagem Top-Down pode funcionar
como uma forma de prototipação, na qual
cada versão contém mais funcionalidades e
está mais próxima do desejo do usuário.

O risco em adotar o protótipo com um
sistema de produção é grande e pode ser
desastroso porque:
◦ Não foi preparado para manipular eficientemente
grandes volumes de transações.
◦ Carece de detalhes operativos como: Recuperação
de erros, documentação do usuário, procedimento
de conversão.
◦ O projeto pode terminar sem que tenha sido
produzida qualquer documentação formal, que
deveria ser mantida ao longo da vida do sistema.





Principal técnica de modelação funcional
Modela o sistema como uma rede de processos
funcionais, interligados por dutos e tanques de
armazenamento
Pode ser usado para descrever processos
computadorizados e não computadorizados
Também chamado de DFD (abreviatura),
Diagrama de Bolhas, Modelo de Processo,
Diagrama de Fluxo de Trabalho e Modelo
Funcional
Um DFD é composto de Processos, Fluxos de
Dados, Depósitos de Dados e Entidades Externas





Também conhecido como bolha, função ou
transformação;
Representam transformações de fluxo(s) de
dados de entrada em fluxo(s) de dados de
saída;
O nome do processo deve descrever o que ele
faz;
Nome = verbo (infinitivo) + objeto direto;
Geralmente provoca mudanças de estrutura,
conteúdo ou estado;

Representações gráficas possíveis:





Representam caminhos por onde passam os
dados;
São representados através de setas que
indicam o destino do dado
Têm nomes que devem constar no dicionário
de dados;
Um mesmo fragmento de dados pode ter
significados diferentes em pontos distintos
de um DFD (CPF-Válido e CPF-Inválido);
Um fluxo apenas não modifica os dados
durante o transporte;

Transportam dados entre os elementos do
DFD:
◦ Processo ⇔ Processo
◦ Entidade Externa ⇔ Processo
◦ Depósito de Dados ⇔ Processo

Tipos de fluxos:
◦ Fluxo externo: entre Entidade Externa e Processo
◦ Fluxo interno: entre dois Processos
◦ Fluxo de acesso à memória: entre Processo e
Depósito
◦ Fluxo de erro ou rejeição: para fora de um Processo

Nomenclatura:
◦ Cada fluxo deve ter um único nome;
◦ O nome deve identificar os dados transportados
pelo fluxo;
◦ Exemplos: Dados-Fatura, Recibo-Pagamento,
Dados-Cliente.

Representação gráfica:
Dados Pessoais



Representa uma coleção de pacotes de dados
em repouso;
Nem sempre um depósito de dados é um
arquivo ou SGBD. Pode representar
microfilmes, pastas de arquivos em papel e
diversas outras formas não
computadorizadas;
Nomenclatura:
◦ Deve estar no plural
◦ Pode receber o nome do fluxo de dados (no plural)

Representações gráficas de um depósito de
dados:




Também chamados de Terminadores;
Uma FONTE ou DESTINO uma pessoa, ou
empresa, ou departamento, existente fora do
contexto do sistema, que é o originador ou o
receptor de dados do sistema;
São as fontes/destinatários das informações
que entram/saem do sistema;
Os procedimentos executados pelas
entidades externas não são especificados no
modelo por não fazerem parte do sistema;



Normalmente é uma pessoa, um grupo de
pessoas, uma organização externa, um setor
dentro de uma empresa;
Pode representar um outro sistema;
Nomenclatura:
◦ No plural quando se referir a um grupo de pessoas
(Clientes);
◦ Deve conter o nome do setor ou entidade externa
(Diretoria de Negócios);
◦ Deve ser incluída a palavra sistema quando se tratar
de um sistema (Sistema de Contabilidade).

Representação gráfica de uma Entidade
Externa:

Escolher Nomes Significativos
◦ Evitar nomes para processos como: Fazer serviço,
Manipular entrada, Cuidar dos clientes e Processar
dados.

Devem-se numerar os Processos
◦ A numeração tem basicamente duas utilidades:
 Permitir localizar os processos no diagrama facilmente
 Facilita a identificação, a partir dos diagramas mais
detalhados, do processo que foi expandido
◦ Não importa a maneira desde que seja consistente
◦ A numeração não indica sequência pois o DFD é
uma rede de processos assíncronos que se
intercomunicam

Evitar DFD Complexos
◦ Evitar colocar elementos demais no digrama;
◦ Deve caber facilmente numa página;
◦ O DFD deve modelar corretamente as funções que um
sistema deve executar e as interações entre elas;
◦ Deve ser lido e entendido facilmente pelos utilizadores.

Refazer tantas vezes quantas forem necessárias
◦ Um DFD deve ser refeito até que:
 Esteja tecnicamente correto;
 Aceitável pelo utilizador;
 O Analista não tenha vergonha de apresentá-lo à diretoria.

Certificar-se de que o DFD seja logicamente consistente:

Posição dos elementos
◦ Evitar "poços sem fundo" (processos que só recebem entradas);
◦ Evitar processos com geração espontânea (processos que não
recebem entrada mas produzem saídas);
◦ Cuidado com fluxos e processos sem rótulos;
◦ Cuidado com depósitos que tenham somente leitura ou escrita.
◦ O processo origem deve ficar à esquerda ou acima do processo
destino;
◦ As entidades externas devem ser desenhadas nas bordas do
desenho:
 As de entrada, à esquerda ou acima;
 As de saída, à direita ou abaixo;
 Os depósitos de dados devem ser distribuídos no meio do desenho,
entre os processos.

Duplicação de elementos:
◦ Pode-se duplicar Entidades e Depósitos para evitar
cruzamento de fluxos e melhorar a organização do
diagrama
◦ Um mesmo fluxo de dados pode aparecer mais de
uma vez no mesmo DFD
◦ Não faz sentido duplicar processos
A Pousada Rivotril deseja cria um sistema online de
reservas de quartos. Durante a análise alguns
aspectos foram levantados:
 O cliente deverá fazer o seu cadastro no site,
para que possa efetuar a reserva;
 O cliente, após se cadastrar no site, pode
solicitar a reserva. O Sistema verifica a
disponibilidade de quarto e em caso positivo,
efetua a reserva do quarto, salva os dados da
reserva e envia uma confirmação para o cliente.
 O funcionário da Pousada pode consultar as
reservas e efetuar o cancelamento de uma
reserva se necessário.