Análise Sistemas

Análise e Projecto de Sistemas 1
ANÁLISE E PROJECTO DE SISTEMAS
Rafael Gomes Machado
Índice
Índice........................................................................................................................................ 1
1 – SISTEMAS DE INFORMAÇÃO..........................................................................................2
Porque surgiu a «Análise e Projecto de Sistemas de Informação»?.................................2
A importância da informação............................................................................................. 2
O que é a Análise e Projecto de Sistemas........................................................................3
Conceito de Sistema.......................................................................................................... 3
Teoria Geral de Sistemas.................................................................................................. 4
Os Processos da Análise de Sistemas..............................................................................5
Características de um Sistema de Informação..................................................................5
Fases que compõem a «Análise e Projecto de Sistemas»................................................6
Investigação Preliminar...................................................................................................... 6
Processos:......................................................................................................................... 7
Etapas:.............................................................................................................................. 7
Ferramentas de Análise de Sistemas..............................................................................10
2 - DIAGRAMAS DE FLUXO DE DADOS (DFD)...................................................................11
Conceitos, definições e simbologia..................................................................................11
Notação de um DFD........................................................................................................ 11
Regras para o Traçado de um DFD.................................................................................12
Exemplo de aplicação ..................................................................................................... 13
Traçado do DFD.............................................................................................................. 14
Diagrama de Contexto..................................................................................................... 14
Diagrama 0...................................................................................................................... 15
Diagrama 1...................................................................................................................... 15
Dicionário de Dados......................................................................................................... 16
Dicionário de Dados do DFD Geral.................................................................................16
3 - DEFINIÇÃO DO CONTEÚDO DOS DEPÓSITOS DE DADOS........................................20
Depósitos de Dados......................................................................................................... 20
NORMALIZAÇÃO DE TABELAS.....................................................................................22
Primeira Forma Normal (1FN)......................................................................................... 22
Segunda Forma Normal (2FN)........................................................................................ 22
Terceira Forma Normal (3FN)......................................................................................... 23
Modelo E-R Simplificado.................................................................................................. 24
4 - DEFINIÇÃO DOS PROCESSOS......................................................................................26
Pseudocódigo estruturado / Português estruturado.........................................................26
Árvores e Tabelas de Decisão......................................................................................... 27
1 – SISTEMAS DE INFORMAÇÃO
Porque surgiu a «Análise e Projecto de Sistemas de Informação»?
Quando uma empresa pretende informatizar uma secção, encarrega uma ou

várias pessoas para desempenhar esta tarefa. A estas pessoas vão colocar-
se questões e dúvidas, como:
 O que o sistema deve fazer

 Quais as suas entradas de dados
 Que documentos deve conseguir elaborar
 etc....
Há alguns anos, as pessoas encarregadas de transformar os sistemas

«tradicionais» em sistemas informáticos desempenhavam esta tarefa sem
elaborar qualquer estudo prévio, o que levava a que o sistema final obtido
não satisfizesse as necessidades e exigências da empresa. Estes sistemas
falhavam, exactamente porque os encarregados de os elaborar não
conheciam a fundo todo o sistema que lhes foi destinado informatizar. Não
conheciam em pormenor os dados que circulavam no sistema, como eram
processados, que resultados e que documentos seriam necessários produzir,
bem como que dados deviam constar destes documentos, etc.…, o que
levou a que os sistemas novos implementados não produzissem nem
satisfizessem em termos de informação aqueles que dele dependiam. Como
a base de qualquer sistema é exactamente o processamento mais correcto e
eficiente de informação, estes novos sistemas, que não eram satisfatórios,
levaram a que os gestores das empresas se mostrassem descontentes.
Surgiu então a necessidade de, sempre que houvesse um sistema
informático a elaborar, levar a cabo um estudo prévio de todos os dados e as
suas relações entre o sistema actual e o sistema a elaborar, de modo a ter
um profundo e completo conhecimento do sistema existente. É neste âmbito
que surge a «Análise e Projecto de Sistemas».
A análise de sistemas não tem como objectivo resolver os seus problemas,
mas sim recolher as informações sobre os processos existentes. É de
importância vital que, após ter sido feita a análise de um sistema, o analista
que a efectuou tenha a noção perfeita de como o sistema funciona e a
percepção de quais são os seus pontos fortes e fracos, pois só assim
conseguirá idealizar, projectar e realizar um sistema novo que possa
adequadamente substituir o existente, trazendo mais benefícios e reduzindo
ao máximo a falta de eficiência e falhas ocorrentes no anterior.
A importância da informação
Ao longo do dia, a empresa recebe muitas vezes mais informação do que

aquela para a qual está preparada para processar. Com o alto grau de
desenvolvimento tecnológico dos dias de hoje, face a um mercado cada vez
mais específico e exigente e uma concorrência feroz em praticamente todos
os sectores, tornam-se necessários agentes dessa tecnologia unicamente
voltados e especializados para armazenar, classificar, comparar e exibir essa

informação a alta velocidade.
Nas empresas, aplicamos em muitos casos estes meios nos novos sistemas
de informação, pois sabemos que com eles iremos melhorar o sistema
existente e eliminar alguns dos seus aspectos mais incorrectos. Com a
informatização iremos incrementar a velocidade com que obtemos, tratamos
e visualizamos informação, reduzindo o tempo para executar estas tarefas,
reduzindo o fluxo de trabalho necessário para processar esta informação e
obter resultados, eliminando a maioria dos erros humanos e obtendo maior
segurança. Como consequência de tudo isto, reduzimos os custos e
geramos mais receitas, além de termos acesso fácil e instantâneo a toda a
informação de vital importância para a empresa.
O que é a Análise e Projecto de Sistemas
Nos últimos tempos, as empresas têm vindo a implementar e melhorar

sistemas de informação, pois cada vez mais necessitam de processar a
informação que lhes diz respeito de forma correcta e rapidamente. Esta
informação é a base que conduz ao desenrolar de acções que levam a
firmar-se no mercado ou, pelo contrário, a levam à falência.
Com «Análise e Projecto de Sistemas» pretendemos analisar as áreas de
fragilidade dos sistemas, o tempo, os custos, o fluxo de trabalho, os
problemas de organização, de staff e os erros que eventualmente podem
ocorrer no processo existente, para assim podermos esquematizar um novo
sistema, tomando por base os requisitos pretendidos pela empresa.
Devemos assim aproveitar o que já existe e é bom para a empresa e eliminar
o que não está correcto ou que funciona mal, implementando novas formas,
mais correctas, de processamento de dados, introduzindo os controlos
necessários e tratamento de excepções. Resulta assim um novo sistema que
se aproxima da optimização em termos de velocidade na obtenção e
tratamento de informação relevante e vital à boa gestão da empresa.
Conceito de Sistema
Sistema:
 Conjunto de partes que formam um todo
 Conjunto de componentes que interagem para alcançar
um objectivo comum
Sistema de Informação:
Existe numa organização, não como um departamento isolado

mas como uma rede espalhada pelos diversos componentes do
sistema.
Exemplos:
 S.I. de Contabilidade
 Sistema de controlo de stocks
 Sistemas de apoio a vendas...
Teoria Geral de Sistemas
A «Análise e Projecto de Sistemas» baseia-se na «Teoria Geral de

Sistemas», que consiste nos seguintes pontos:
1. As componentes de um sistema são interdependentes e

interrelacionadas; componentes independentes e não relacionados não
constituem um sistema. De facto, uma das tarefas importantes no estudo
de um sistema consiste em determinar as relações entre componentes.
2. Um sistema é visto como um todo; não temos que decompo-lo

necessariamente nas partes que o compõem, em particular se com isto
perdermos a visão do sistema global. Em muitos casos há que concentrar
a atenção nos subsistemas em que se decompõe um sistema grande,
mas não queremos ignorar o contexto global dado pelo sistema total.
3. Os sistemas procuram a realização de objectivos de algum tipo; as

componentes em interacção atingem um estado final ou meta, uma
posição de equilíbrio de obtenção do objectivo.
4. Os sistemas têm inputs e outputs; são dependentes de algum tipo de

inputs para que o processo atinja os objectivos do sistema. Todos os
sistemas produzem algum output necessariamente a outros sistemas.
5. Todos os sistemas transformam inputs em outputs; em geral, a forma do

output difere da do input.
6. Os sistemas exibem entropia, um termo emprestado pela termodinâmica.

Entropia descreve o estado de um sistema fechado (que não recebe
inputs de fora do sistema) em que todos os elementos se movimentam
em direcção à desorganização e à incapacidade para obter e processar
os inputs, de modo que o sistema é incapaz de produzir outputs. Por isso,
é necessário defender um combate à entropia.
7. Os sistemas têm de ter um modo de regulação das componentes

interactivas de modo a que os seus objectivos sejam atingidos.
Planeamento, controle e feedback estão associados com esta função
reguladora.
8. Os sistemas, normalmente, englobam subsistemas menores. A

integração destes sistemas menores nos maiores forma uma hierarquia
que é característica da teoria de sistemas.
9. Normalmente encontramos diferenciação em subsistemas complexos;

isto é, unidades especializadas realizam tarefas especializadas.
10. O sistema, em geral, exibe equifinalidade; um dado estado final pode ser
obtido a partir de estados diferentes ou de pontos de partida diversos. Por
outras palavras, há muitas maneiras de alcançar os objectivos do
sistema, havendo por isso que escolher as que proporcionam melhor

caminho, no contexto que a empresa exige.
Os Processos da Análise de Sistemas
a) Recolha e interpretação detalhada dos dados.
Neste processo o analista deve inteirar-se das informações e

documentos que servem o sistema, qual o seu conteúdo, como
são gerados, como circulam pelo sistema e que transformações
sofrem ao longo deste.
b) Apreensão dos problemas e alternativas existentes.
Neste processo o analista deve aperceber-se de quais problemas

que surgem no sistema e de como se podem evitar, ou que
alternativas existem para os minimizar.
b) Análise das fragilidades.
Neste processo o analista deve analisar aqueles que são

considerados os pontos frágeis do sistema, isto é, onde as
informações estão sujeitas a erros, demoras ou mau
aproveitamento.
c) Lista dos meios disponíveis e avaliação da sua performance.
Neste processo o analista deve listar todos os meios à disposição

para o processamento da informação do sistema e determinar qual
o rendimento de cada um destes meios em termos de eficiência e
rapidez no tratamento desta informação.
Estes processos estão presentes em todas as etapas da Análise de

Sistema e devem ser considerados como directivas a seguir pelo analista.
Características de um Sistema de Informação
Objectivo: Orientar a tomada de decisão numa organização
Componentes:
a) Dados: Constituem a entrada (INPUT) do Sistema
b) SPD: Ocupa-se da transformação dos dados em informação útil

para o Sistema
c) Canais de Comunicação: Meios pelos quais se transmite

informação entre os componentes dos Sistema e para o exterior.
d) Estrutura: Forma como os diversos Sistemas de Processamento

de dados estão relacionados entre si.
e) Comportamento: Cumprimento dos objectivos do S.I.

Fornecimento de informação para a organização
em formato, tempo e custo apropriados.
f) Ciclo vital: Evolução, desgaste, inadequadação, envelhecimento,

substituição, reparação e “morte” do Sistema.
Fases que compõem a «Análise e Projecto de Sistemas»
1. Investigação Preliminar
Processos:
 Recolha e interpretação detalhada dos factos, da apreensão dos
problemas e alternativas existentes;
 Lista dos meios disponíveis e avaliação da sua performance;
 Análise das fragilidades e erros do sistema (tempo, custo, trabalho,
etc.).
A investigação preliminar é a etapa da Análise de Sistemas que

consiste no esclarecimento de quais são os problemas que causam
o pedido da elaboração do novo sistema, qual será o volume
previsto em termos de recursos para elaborar e implementar o novo
sistema, se realizar o novo sistema será compensatório e se existe
viabilidade para essa realização. Os passos a seguir nesta etapa são
os seguintes:
Recolha do pedido - A essência de porque se necessita de um novo

sistema e qual a sua prioridade.
 Fontes do pedido (de quem e onde vem o pedido?)
 Quais as razões para o pedido (velocidade de processamento
das informações do sistema, eficiência e consistência
acrescidos, maior segurança, poupança de espaço físico,
integração de áreas de gestão, redução de custos, etc.)?
 Qual a prioridade do pedido (é urgente, é importante)?
Condução de investigação - Levantamento dos processos

existentes no sistema actual e averiguação do que se pensa à
primeira ser a solução.
 O que está a ser feito?
 O que se pretende?
 O que se pensa ser a solução?
Testes de previsão de viabilidade - Testes de viabilização para a

realização do projecto do novo sistema. Estes testes são
extremamente importantes, pois são eles que vão determinar a
decisão por parte da Direcção para a aprovação desta realização.
a) Prever a viabilidade operacional do novo sistema, isto é:

 O sistema novo, quando instalado, funcionará?
 Existem grandes barreiras à sua implementação?
 Existe o apoio suficiente por parte da Direcção para realizar o
novo sistema?
 São os actuais métodos de gestão aceitáveis por parte dos
utilizadores?
 Será frequente o contacto com os utilizadores durante o
planeamento e desenvolvimento do projecto novo?
 Provocará o sistema novos atritos entre as pessoas?
 Produzirá resultados piores que o sistema actual?
 Resultará perda de controle?
 Perder-se-á acessibilidade de informação?
 Tornar-se-á performance individual mais pobre?
 Serão de algum modo não desejável afectados os clientes?
 Satisfará o sistema todas as exigências e necessidades dos
que dele dependem?
 Sairá empobrecida a performance global do sistema?
b) Prever a viabilidade técnica do novo sistema, isto é:

 Existe a tecnologia necessária para se fazer o que se
pretende?
 Tem o equipamento proposto a capacidade técnica para manter
os dados requeridos para usar o novo sistema?
 Dará este equipamento as respostas adequadas em termos de
manutenção, rapidez de consulta, rigor, confiança, facilidade de
acesso e segurança dos dados, apesar do número e
localização dos utilizadores?
 Pode expandir-se o sistema, se desenvolvido?
c) Prever a viabilidade económica/financeira do novo sistema,

isto é:
 Estimar os seus custos.
 Estimar os benefícios que trará.
 Calcular o período de tempo necessário a que o novo sistema
se comece a tornar lucrativo.
 Calcular o gráfico de custos, onde se representem os custos do
sistema actual e da estimativa dos custos do novo, ao longo do
tempo.
 Calcular o gráfico de benefícios, onde se representem os
benefícios do sistema actual e da estimativa dos benefícios que
advirão do novo, ao longo do tempo.
 Calcular o gráfico de rendimento, onde se representem a
diferença entre os benefícios e custos do sistema actual e da
diferença entre a estimativa dos benefícios e custos do sistema
novo, ao longo do tempo.
d) Elaboração da Proposta (Caderno de Encargos) - Elaboração da

proposta do novo sistema para ser avaliada pela Direcção. Elaborar
um relatório enumerando a dimensão do projecto, suas alternativas e

os testes de previsão de viabilidade Só após a aprovação deste
relatório pela Direcção deve o analista prosseguir o seu trabalho, caso
contrário o projecto deverá ser adiado ou mesmo abandonado.
2. Análise (Projecto Lógico)
Etapas:
Diagramas de Relação de Entidades
Diagramas de Fluxo de Dados
Dicionários de Dados
Árvore de Decisão
Lista de requisitos
3. Projecto Físico
Processos:
 Construção de inputs e outputs eficientes, isto é, que

contenham todos os dados necessários e ao mesmo tempo
organizados e dispostos da maneira mais prática e agradável a
quem os utiliza;
 Elaboração dos ficheiros que irão conter a informação, bem
como o seu tipo de organização;
 Estruturação de como será o novo sistema, dando indicadores
de controlos, validações e dependências.
 Estes processos devem ser todos baseados nos requisitos do
sistema determinados na análise.
 Elaboração algorítmica das rotinas-base que devem constituir o
Software do sistema;
 Elaboração do Software do sistema;
 Elaboração do manual do sistema.
Etapas:
 Layouts
 Ficheiros
 Estrutura
 Rotinas-Base
 Fontes
 Documentação
4. Implementação e Manutenção
Processos:
 Instalação do novo sistema;
 Ensino ao pessoal utilizador de como lidar com o novo sistema
e interpretá-lo;
 Determinar a performance do sistema novo e compará-lo com
alternativas de outros sistemas que já foram construídos;
 Análise de ganhos e perdas em relação ao sistema anterior;
 Manter o sistema funcional ao longo do tempo, correcção de

erros, desenvolvimento, etc.
Etapas:
 Instalação do Sistema
 Formação do Pessoal
 Performance
 Análise de ganhos/Perdas
 Manutenção
O Analista de Sistemas
Para levar a cabo uma Análise e projecto de um sistema, o analista deve ser
uma pessoa que procura trabalhar e refinar várias técnicas que lhe
possibilitam, como analista, cada vez mais, aperceber-se dos problemas e
das suas respectivas soluções.
As técnicas e perícias a desenvolver por um Analista de Sistemas são as

seguintes:
 Capacidade para analisar um pedido de assistência por computador e

determinar se a oportunidade para informatizar deve ser ou não
concretizada.
 Know-how para juntar e interpretar factos que ajudam no diagnóstico
de um problema empresarial, na medida em que relacionam sistemas
de informação e de computador.
 Compreensão para determinar, após análise do problema colocado,
que tipo de ajuda por computador é desejável e que procedimentos e
sistemas manuais são mais efectivos.
 Capacidade para desenhar e desenvolver especificações para um
sistema de informação determinado pela análise de um sistema em
vigor.
 Conhecimento para seleccionar os melhores métodos de introdução
de dados, gravação e acesso de ficheiros, processamento e output
para uma dada situação.
 Ideia do desenvolvimento de software, métodos de testes e
estratégias de implementação.
 Capacidade para comunicar efectivamente com outros.
 Experiência em cada um dos pontos referidos atrás e de estudo de
casos.
Ferramentas de Análise de Sistemas (Projecto Lógico)
As ferramentas utilizadas para efectuar uma análise de sistema são as

seguintes:
a) Entrevistas e Questionários
Devem ser efectuadas entrevistas e questionários às pessoas que

pertencem ao sistema e que lidam directa ou indirectamente com os
documentos e a informação que nele circula. É importante estruturar
estas entrevistas e questionários, de modo a que:
 No final destas se saibam que dados necessitam ser recolhidos e

quais são as pessoas ou entidades mais habilitadas para as
recolher.
 As questões sejam seleccionadas, de modo a obter as respostas
mais úteis e relevantes.
 Permitir que algumas das respostas possam conter mais que um
ponto de vista ou ser respondida de uma só maneira, de modo a
que se retenham a maior variedade de problemas ou soluções.
 A entrevista ou questionário não deve ser enfadonha ou exagerado
(normalmente deve durar o máximo de uma hora).
 Tipos de perguntas em questionários:
Resposta aberta – Tem 2 inconvenientes: as pessoas evitam
a resposta e o tratamento de dados é complicado.
Resposta fechada – Várias possibilidades:
a) 2 alternativas (Sim/Não)
b) várias possibilidades, mas uma só resposta
c) várias possibilidades e várias respostas
d) respostas em escala (geralmente de 1 a 5)
b) Revisão de Registos
Devem ser feitas revisões aos documentos, manuais e relatórios
existentes no sistema e determinados os detalhes e factos das
informações circulantes, no que diz respeito à sua forma, conteúdo e
quantidade.
c) Observação
«Ver para crer!». Observar os processos e operações do sistema em
funcionamento permite aos analista uma constatação dos factos que
realmente acontecem em primeira mão. As perguntas e as dúvidas de
um analista podem ser mais fácil e rapidamente esclarecidas através
desta técnica.
d) Diagramas de Entidades Relação (E-R)

Tratam-se de diagramas onde o analista deve representar todas as
entidades do sistema e suas interligações em termos de circulação de
informação, bem como a lista das informações de cada ligação.
e) Diagramas de Fluxo de Dados

Tratam-se de diagramas lógicos onde são representados os fluxos
dos dados do sistema desde as suas origens até aos seus destinos,
passando pelos processos de tratamento da informação que o
compõem e os armazenamentos de informação.
f) Dicionário de Dados
É um dicionário de identificação de cada origem, destino, processo,

entidade de armazenamento e dado representado nos diagramas de
fluxos de dados.
g) Árvore e Tabelas de Decisão

Trata-se da representação de todas as decisões que podem e têm de
ser tomadas no sistema e as acções consequentes dessas decisões.
2 - DIAGRAMAS DE FLUXO DE DADOS (DFD)
Conceitos, definições e simbologia
Um Diagrama de Fluxo de Dados (DFD) é uma gráfico lógico do sistema ou

de uma parte do sistema onde representamos de onde vêm, para onde vão e
como são processados os dados do sistema.
Os DFD mostram o uso de dados num sistema, de modo gráfico,

considerando:
 todos os componentes essenciais
 o modo como os componentes estão interligados.
Notação de um DFD
Existem apenas quatro (4) elementos básicos:
1. Entidade externa
E1
Cliente
Fonte ou destino de dados (Fonte ou Terminador)
 Podem ser pessoas, programas, organizações exteriores ao

sistema. Contem um nome.
 Se a entidade ocorrer mais de uma vez no sistema, utiliza-se
uma linha inclinada no canto inferior direito.
E1 E1 E1
Cliente Cliente Cliente
2. Fluxo de Dados
Dados Cliente
 Possui um sentido bem determinado e contém um nome.

 Os dados são transmitidos ou recebidos pelas fontes e
terminadores, pelos processos e pelos depósitos de dados.
3. Processo
- P1 -
Obter Vendas
Mensais
Cada processo recebe fluxos de dados de entrada e transforma-os em

fluxo de dados de saída. O nome utilizado deve ser um verbo forte
(extrair, verificar, enviar, …). Pode ser visto como sendo uma ordem.
4. Depósito de dados
D1 Clientes
 Armazena os dados
 Tem um nome
 Recebe ou envia pelo menos um fluxo de dados
 Pode ser um ficheiro ou uma Base de Dados
Regras para o Traçado de um DFD
Identificar as componentes estáticas
 Entidades Externas (fontes e terminadores)

 Identificar os principais depósitos de dados
Identificar os principais Processos e Fluxos de Dados
 Identificar os fluxos que partem das fontes e convergem para os

terminadores, e ainda os principais processos que surgem nesses
percursos.
 Rotular os Fluxos:
a) Garantir que cada Fluxo é rotulado
b) Garantir que o nome do Fluxo se refere a todos os dados
transportados pelo mesmo
c) Evitar nomes vagos
Expandir e refinar o Diagrama
 Expandir e melhorar o diagrama (novas entrevistas, rever notas

anteriores)
 Rotular os Processos
 Seguir das Fontes para os terminadores
 Usar um verbo forte
 Ao rotular um Processo, procurar oportunidades para o

expandir:
 Um nome que inclui conjunção pode sugerir divisão do
processo em dois
 Se o fluxo é uma entrada de um utilizador, deve-se prever um
processo de validação
 Evitar muitos pormenores no diagrama.
Rever o Diagrama
Rever todos os aspectos importantes.
Convenções de expansão
Um Processo de nível superior pode ser expandido em novos

processos de nível inferior.
Exemplo: 28 -------- > 28.1 e 28.2
Exemplo de aplicação:
Aplicação: Sistema de Marcação de Hotéis
Análise da Organização
Descrição da organização com base em entrevistas e recolha de informação.

Determinação dos processos mais correntes, que podem ser de vários tipos
e com objectivos distintos, desde registar informação, consultar informação
registada anteriormente, tomar decisões e ainda efectuar listagens periódicas
que podem ter múltiplos fins.
Determinação do ciclo vital (Tempo de duração da empresa, em que a
organização passa por vários estados ao longo da sua vida útil).
Descrição dos Objectos de Informação
No funcionamento diário de uma empresa a necessidade de informação é

um factor de extrema importância para a sua manutenção, e de vital
significado para a própria empresa. No entanto deverá ser manipulada e
requerida de uma forma cuidada e adequada para se tornar útil.
A importância dos objectos de informação deve-se a que os acontecimentos
ou eventos descrevem as acções particulares realizadas na empresa e num
Sistema de Informação, os Objectos necessitarem de ser manipulados e
controlados.
Existem 3 tipos de Objectos de Informação:
 As Entidades, que podem pertencer a diversas categorias (pessoas,

coisa ou lugar)
 Os Eventos, que é algo que ocorre num determinado instante.
 Os Depósitos de Dados, que é onde se armazenam os dados
Para o nosso exemplo:
Entidades: Cliente
Hotel
Eventos: Escolher a estância e o quarto,

Confirmar os pormenores.
Depósitos de Dados: Clientes

Hotéis
Disponibilidade dos Quartos
Traçado do DFD
Diagrama de Contexto ou Diagrama de Nível Zero
E1
D1 Hoteis
Cliente
-0-
Sistema de Disponibilidade dos

Clientes D3 Marcação de D2
Quartos
Hoteis
E2
Hotel
Diagrama de Nível 1
D1 Hoteis
I2 - dados do
Hotel
E1
- P1 -
I1 - Pedido
Cliente
Escolher a Disponibilidade dos
Estância e o I3 -Dados do quarto D2
Quartos
Quarto
O2 - Dados do
Quarto
O1 - Pormenores Actualizados
do Quarto
- P2 -
O3 - Pormenores do Cliente E2
I4 - Dados do
Cliente Confirmar os e do Quarto
Clientes D3 Pormenores Hotel
Diagrama de Nível 2
- 1.1 - - P1.2 -
E1
I2 - Dados
I1 - Pedido Validar O1.1 - Pedido Validado Verificar do Hotel
Pedido Estância D1 Hoteis
Cliente
O1.2 - Lista de
I1.1 - Elementos do Hoteis
Cliente
Clientes D3 - P1.3 -
O1.3 - Pormenores do
Quarto Seleccionar Disponibilidade dos
I4 - I3 -Dados do quarto D2
Quarto Quartos
Dados
do
Cliente
O2 - Dados do
- P2.1 - Quarto
Actualizados
Calcular
Pagamento
- P2.2 -
E2
O2.1 -pormenores da O3 - Pormenores do Cliente
Marcação e Facturação Confirmar e do Quarto
Marcação Hotel
Dicionário de Dados
É uma lista onde é incluída uma descrição de todos os elementos representados num DFD:
Fluxos de Dados, Depósito de Dados, Processos e Entidades.
Dicionário de Dados do DFD Geral
Definição de Fluxo de Dados
Definição dos Inputs
Código do Nome Dados Origem Destino

Input
I1 Pedido Nome, data, nº dias, E1 - Cliente P1 - Escolher a
Tipo de quarto, nº estância e o
pessoas, local quarto
I2 Dados do Hotel Nome do Hotel, D1 - Hotéis P1 - Escolher a
localização, telefone estância e o
quarto
I3 Dados do Quarto Nome do Hotel, nº D2 - P1 - Escolher a
Quarto, Local, tipo de Disponibilidade estância e o
quarto, preço, nº de Quartos quarto
pessoas, DataInicio,
DataFim
I4 Dados do Cliente Nome, morada, D3 - Clientes P2 - Confirmar
nacionalidade, nº BI, nº os pormenores
Contribuinte
Definição dos Outputs

output
O1 Pormenor do quarto Nome do Hotel, nº P1 - Escolher a P2 - Confirmar
Quarto, Local, tipo de estância e o os pormenores
quarto, preço, nº quarto
pessoas, DataInicio,
DataFim
O2 Dados do quarto Nome do Hotel, Nº P2 - Confirmar D2 -
actualizados Quarto, Local, Data os pormenores Disponibilidade
Início, Data fim de Quartos
O3 Pormenores do Nome do Hotel, nº P2 - Confirmar E2 - Hotel
Cliente e do Quarto Quarto, Local, tipo de os pormenores
quarto, preço, nº
pessoas, Nome Cliente,
Morada, Nº Cont, data
Início, Data fim
Definição dos Processos
Código do Nome Fluxos de Input Fluxos de Output

Processo
P1 Escolher a estância I1, I2, I3 O1
e o quarto
P2 Confirmar os O1, I4 O2, O3
pormenores
Depósitos de Dados
Código do Nome Fluxos de Input Fluxos de Output

D. Dados
D1 Hotéis - I2
D2 Disponibilidade de O2 I3
Quartos
D3 Clientes - I4
Entidades
Código da Nome Do Processo Para o Processo

Entidade
E1 Cliente - P1
E2 Hotel P2 -
Dicionário de Dados do DFD Detalhado
Processo 1 - Escolher a Estância e o Quarto
Subprocesso: 1.1 Validar Pedido
Fluxos de Dados

Input
I1 Pedido Nome, data, nº dias, E1 - Cliente P1.1 - Validar
Tipo de quarto, nº Pedido
pessoas, local
I1.1 Elementos do Nome, morada, D3 - Clientes P1.1 - Validar
Cliente nacionalidade, nº BI, nº Pedido
Contribuinte

output
O1.1 Pedido validado Nome, data, nº dias, P1.1 - Validar P1.2 - Verificar
Tipo de quarto, nº Pedido Estância
pessoas
Subprocesso: 1.2 Verificar Estância
Fluxos de Dados

Input
I2 Dados do Hotel Nome do Hotel, D1 - Hotéis P1.2 - Verificar
localização, telefone Estância
O1.1 Pedido validado Nome, data, nº dias, P1.1 - Validar P1.2 - Verificar
Tipo de quarto, nº Pedido Estância
pessoas

output
O1.2 Lista dos Hotéis Nome do Hotel, P1.2 - Verificar P1.3 -
localização, telefone, Estância Seleccionar
DataInicio, Nºdias Quarto
Subprocesso 1.3 - Seleccionar Quarto
Fluxos de Dados

Input
O1.2 Lista dos Hotéis Nome do Hotel, P1.2 - Verificar P1.3 -
localização, telefone, Estância Seleccionar
DataInicio, Nºdias Quarto
I3 Dados do Quarto Nome Hotel, nº Quarto, D2 - P1.3 –
Local, tipo de quarto, Disponibilidade Seleccionar
preço, nº pessoas, de Quartos Quarto
dataInicio, DataFim

output
O1.3 Pormenores do Nome do Hotel, Nº P1.3 - P2.1 - Calcular
Quarto Quarto, Local, tipo de Seleccionar Pagamento
Quarto, preço nº quarto
pessoas, datainicio,
Datafim
Processo 2 - Confirmar Pormenor
Subprocesso 2.1 - Calcular Pagamento
Fluxos de Dados

Input
O1.3 Pormenores do Nome do Hotel, Nº P1.3 - P2.1 - Calcular
Quarto Quarto, Local, tipo de Seleccionar Pagamento
Quarto, preço nº quarto
pessoas, datainicio,
Datafim
I4 Dados do Cliente Nome, morada, D3 - Clientes P2.1 - Calcular
nacionalidade, nº BI, nº Pagamento
Contribuinte

output
O2.1 Pormenores da Nome, Morada, Nº P2.1 - Calcular P2.2 - Confirmar
Marcação e Contribuinte, data de Pagamento Marcação
Facturação início, nº dias, Nome
Hotel, Nº quarto, Local,
nº pessoas, Nº factura,
Preço Quarto, preço
total
Subprocesso 2.2 - Confirmar Marcação
Fluxos de Dados

output
O2.1 Pormenores da Nome, Morada, Nº P2.1 - Calcular P2.2 - Confirmar
Marcação e Contribuinte, data de Pagamento Marcação
Facturação início, nº dias, Nome
Hotel, Nº quarto, Local,
total

output
O3 Pormenores do Nome, Morada, Nº P2.2 - Confirmar E2 - Hotel
Cliente e do Quarto Contribuinte, data de Marcação
início, nº dias, Nome
Hotel,Nº quarto, Local,

total
3 - DEFINIÇÃO DO CONTEÚDO DOS DEPÓSITOS DE DADOS
Para determinarmos o conteúdo dos Depósitos de Dados, deveremos

analisar os Fluxos de Input e de Output dos respectivos Depósitos de Dados.
Assim, teremos:
Depósitos de Dados
D1 - HOTÉIS
Nome do Hotel
Localização
Telefone
D2 - Disponibilidade dos Quartos

Nome do Hotel
Nº Quarto
Local
Tipo de Quarto
Preço
Nº Pessoas
Data Início
Data Fim
D3 - Clientes
Nome
Morada
Nacionalidade
Nº B.I.
Nº Contribuinte
Para além dos dados que foram armazenados nos respectivos Depósitos de
Dados, existem outros que deverão ser armazenados, correndo o risco de se
perderem, se tal não ocorrer. Assim:
D4 - Pedido do Cliente
Nome
Morada
Nacionalidade
Nº B.I.
Nº Contribuinte
Local
Nome do Hotel
Nº Quarto
Tipo de Quarto
Nº Pessoas
Data Início
Nº Noites
D5 - Factura
Nº Factura
Data Factura
Nome
Morada
Nº Contribuinte
Nome do Hotel
Nº do Quarto
Nº Noites
Preço Diário
Total a Pagar
Obtemos, então, as seguintes tabelas não normalizadas, com as respectivas

chaves primárias.
Hotéis (Nome do Hotel, Localização, Telefone)
Disponibilidade dos Quartos (Nome do Hotel, Nº Quarto, Local, Tipo de Quarto, Preço, Nº
Pessoas, Data Início, Data Fim)
Clientes (Nome, Morada, Nacionalidade, Nº B.I., Nº Contribuinte)
Pedido do Cliente (Nome, Morada, Nacionalidade, Nº B.I., Nº Contribuinte, Local, Nome

do Hotel, Nº Quarto, Tipo de Quarto, Nº Pessoas, Data Início, Nº Noites)
Factura (Nº Factura, Data Factura, Nome, Morada, Nº Contribuinte, Nome do Hotel, Nº do
Quarto, Nº Noites, Preço Diário, Total a Pagar)
De seguida, devemos normalizar todas as tabelas, de forma a garantir a

eliminação de toda a informação redundante para o nosso Sistema de
Informação.
NORMALIZAÇÃO DE TABELAS
Primeira Forma Normal (1FN)
 Para que uma tabela se encontre na 1FN, todos os seus atributos devem
ser elementares.
Analisando as tabelas verificamos que a localização do Hotel não nos

fornece directamente o local do mesmo (elemento necessário no pedido do
cliente), pelo que este atributo poderá ser decomposto em:
localização - morada, código postal, local
obtendo, assim, a seguinte tabela normalizada,
Hotéis (Nome do Hotel, morada, código postal, local, Telefone)
Segunda Forma Normal (2FN)
 Para que uma tabela se encontre na 2FN, todos os atributos que não são
chave devem depender na totalidade da chave primária. Por conseguinte,
a 2FN só se aplica quando tivermos chaves compostas.
Analisando as tabelas cuja chave primária seja composta, verificamos:
1. Disponibilidade dos Quartos
a) o atributo local só depende do Nome do Hotel

b) os atributos Tipo de Quarto, Preço e Nº Pessoas só dependem de
Nome do Hotel e Nº Quarto
Obtemos, então as seguinte tabelas normalizadas:
Disponibilidade dos Quartos (Nome do Hotel, Nº Quarto, Data Início, Data Fim)
Quartos (Nome do Hotel, Nº Quarto, Tipo de Quarto, Preço, Nº Pessoas)
2. Pedido do Cliente
a) os atributos Morada, Nacionalidade, Nº B.I. e Nº Contribuinte só

dependem do Nome
b) o atributo local só depende do Nome do Hotel
c) o atributo Tipo de Quarto só depende de Nome do Hotel e Nº
Quarto
Obtemos, então a seguinte tabela normalizada:
Pedido do Cliente (Nome, Nome do Hotel, Nº Quarto, Nº Pessoas, Data Início, Nº Noites)
Terceira Forma Normal (3FN)
 Para que uma tabela se encontre na 3FN, todos os atributos que não são
chave não podem depender de outro atributo que também não seja
chave.
Analisando as tabelas, verificamos que na tabela Factura:
a) os atributos Morada e Nº Contribuinte dependem de Nome

b) o atributo Total a Pagar depende de Nº Noites e Preço Diário
Obtemos, então, a seguinte tabela normalizada:
Factura (Nº Factura, Data Factura, Nome, Nome do Hotel, Nº do Quarto, Nº Noites, Preço Diário)
Utilização de Códigos
Depois de as tabelas se encontrarem na 3FN, ainda podemos tentar

simplificar o conteúdo das respectivas tabelas, utilizando códigos.
Utilizam-se códigos em 3 situações:
1) Quando não temos a garantia que o conteúdo de uma Chave

Primária é único.
Exemplo: Na tabela de Clientes:
Clientes (Nome, Morada, Nacionalidade, Nº B.I., Nº Contribuinte)
não podemos ter a certeza que não existam 2 clientes com o nome
António Silva.
A solução será colocar um código que passará a ser a nova Chave
Primária.
Clientes (CodCliente, Nome, Morada, Nacionalidade, Nº B.I., Nº

Contribuinte)
2) Quando o conteúdo de um campo é uma palavra comprida que se

repete várias vezes.
Exemplo:
Armazém é um atributo que se vai repetir várias vezes na tabela

Existência de Peças, pelo que deveremos criar um novo código para
os armazéns, obtendo desta forma:
Existência de Peças (NºPeça, CodArmazem, Qtd_Stock)

Armazéns (CodArmazem, Armazém, Telefone)
3) Quando queremos garantir que o conteúdo de um determinado

atributo tem o mesmo valor para a mesma situação.
Exemplo: Se tivermos a seguinte tabela:
Filme (CodFilme, Titulo, Género, AnoEdição)
e quisermos garantir que para o atributo Género, tenhamos sempre,

por exemplo, o valor Acção (e não ACCÇÃO, Action, ACT, Acc.,
etc.), para todos os filmes cujo género seja Acção, deveremos criar
uma nova tabela:
Géneros (CodGénero, Género)

Filme (CodFilme, Titulo, CodGénero, AnoEdição)
Modelo E-R Simplificado
Depois de termos as tabelas devidamente normalizadas, com os respectivos

códigos, podemos desenhar o nosso Modelo E-R Simplificado.
O Modelo E-R Simplificado consiste no conjunto das tabelas normalizadas
com as respectivas relações. De notar que neste tipo de Modelo, nunca
poderá aparecer uma relação do tipo N:N.
Técnica:
1. Identificar o tipo de relações que existem

2. Para cada relação verificar o campo comum entre as 2 tabelas.
3. Na tabela em que o campo comum é uma Chave Primária, a relação será do
tipo 1.
Na tabela em que o campo comum é uma Chave Externa, a relação será do tipo N.
Notação:
A relação do tipo 1 representa-se por:

___________
A relação do tipo N representa-se por:
Para o nosso exemplo:
Depois de as tabelas se encontrarem na 3FN, poderemos ainda utilizar

códigos, de forma a simplificar o conteúdo dos depósitos de dados. Assim:
a) podemos substituir a chave primária composta da tabela Pedido do

Cliente por Nº Reserva
b) podemos criar duas tabelas, uma para a nacionalidade dos clientes

e outra para os Tipos de Quarto, de forma a reduzir o tamanho
ocupado.
Obtemos então o conjunto final de Tabelas Normalizadas com os respectivos

códigos:
Hotéis (Nome do Hotel, morada, código postal, local, Telefone)
Disponibilidade dos Quartos (Nome do Hotel, Nº Quarto, Data Início, Data Fim)
Quartos (Nome do Hotel, Nº Quarto, CodTipoQuarto, Preço, Nº Pessoas)
Clientes (CodCliente, Nome, Morada, CodNacionalidade, Nº B.I., Nº Contribuinte)
Pedido do Cliente (Nº Reserva, CodCliente, Nome do Hotel, Nº Quarto, Nº Pessoas, Data
Início, Nº Noites)
Factura (Nº Factura, Data Factura, CodCliente, Nome do Hotel, Nº do Quarto, Nº Noites,
Preço Diário)
Nacionalidades (CodNacionalidade, Nacionalidade)
TiposQuartos (CodTipoQuarto, Tipo de Quarto)
MODELO E-R SIMPLIFICADO
Disponibilidade
TiposQuartos Hotéis
dos Quartos
Quartos Factura
Pedido do
Clientes Nacio nalidades
Cliente
4 - DEFINIÇÃO DOS PROCESSOS
Na definição dos Processos, podemos ainda recorrer a um resumo de

funcionamento (lógica) dos mesmos, recorrendo a:
. Pseudocódigo (algoritmos) / Português Estruturado

. Tabelas de decisão
. Árvores de Decisão
Pseudocódigo estruturado / Português estruturado
- Conjunto limitado de instruções lógicas e condicionais, com substantivos e

verbos fortes.
- Usado com o objectivo de concisão, precisão e ausência de ambiguidade.
- Pretende-se exprimir:
- Acções primitivas
- Estruturas de controlo
Acções primitivas
- Informam de algo que deve ser feito e não quando deve ser feito
- São afirmações imperativas, com base em verbos fortes
- Os objectos de afirmação devem ser retirados do dicionário de dados do
DFD
Exemplo: Ler_Ficheiro, Pormenores Dados
Estruturas:
Sequenciais: < instrução >

< instrução >
< instrução >
Selecção: Se < condição > Caso

< instrução > Quando < condição > < instrução >
Senão Quando < condição > < instrução >
< instrução > Quando < condição > < instrução >
Iteração (Repetição) Faz Enquanto < condição > Repete

< instrução > < instrução >
< instrução > < instrução >
Até < condição >
Exemplo:
Total = 0
Repete
Ler_Quarto_Seguinte
Se Tipo_Quarto = “Executivo”
Total = Total + 12 000
Senão
Total = Total + 8 000
Até Todos_Os_Quartos_Processados ou Total > Limite_De_crédito
Árvores e Tabelas de Decisão
Problemas sobre a maneira como expressar a lógica
Ao definirmos o processo no dicionário de dados, especificamos as entradas

e saídas e escrevemos, em português, um resumo da lógica, na forma mais
clara e possível. Existe, no entanto, um certo número de armadilhas, quando
a lógica é expressa em forma narrativa.
Exemplos serão:
. Não somente, mas, todavia, e/ou, a menos que, etc.
. Somar A e B a menos que A seja menor que B onde, nesse caso, subtrair A de B.
Pseudocódigo:
Se A < B
Então
B-A
Senão
A+B
Embora este seja um exemplo muito simples, tivemos de pensar para

conseguirmos reduzir a declaração lógica, por forma a usá-la como
especificação dum programa.
À medida que os exemplos vão sendo mais complexos, maior a dificuldade
em traduzir para especificação de um programa. Para conseguirmos,
deveremos reduzir as declarações lógicas, a frases e condições imperativas.
Utilizaremos o termo acção, para fazer referência a frases imperativas como
“somar A e B” e condição, para fazer referência a factos que determinam a
acção que deve ser tomada “A é menor que B”. No nosso exemplo, teríamos:
Se condição_1
Então
acção_1
Senão
acção_2
Maior que, menor que (mais de, menos de, …)
Além da confusão causada pela variedade de estruturas, a língua portuguesa

causa problemas, quando necessitamos de expressar um domínio de
valores, como parte de uma condição.
Exemplo:
“Até 20 unidades, sem desconto. Mais de 20 unidades, 5% de desconto”
Então, para 20 unidades, qual o desconto?

O problema reside no facto de que precisamos do termo deselegante

“inclusive” ou “até e incluído”.
Deveremos assim, e em casos destes, certificarmo-nos de qual será a acção
a tomar na condição de fronteira, para que assim não surjam problemas de
interpretação de lógica.
Ambiguidade E/OU
Considere a seguinte declaração:
“Clientes que comprem mais de 5 000 contos por ano e possuam um bom histórico de pagamentos,
ou que estejam connosco há mais de 20 anos, devem receber um tratamento prioritário.”
P: Será suficiente gerar mais de 5 000 contos por ano, para receber um tratamento
prioritário?
R: Não, porque existe na frase “e possuam um bom histórico de pagamentos”
P: Mas será suficiente estar connosco há mais de 20 anos?

R: Depende como a frase for lida:
Se lermos “mais de 5 000 mil contos por ano” e “bom histórico de

pagamentos”, é óbvio que não.
Mas se lermos “mais de 5 000 mil contos por ano” e “bom histórico de
pagamentos” ou “connosco há mais de 20 anos”, é óbvio que sim.
Devemos ter cuidado com as ambiguidades.
Como representar as Combinações de Condições?
No nosso exemplo:
“Mais de 5 000 contos por ano” e “Bom histórico de pagamentos”

ou
“Mais de 5 000 contos por ano” e “Connosco há mais de 20 anos”
A política da organização especifica que essas condições conduziriam a uma

certa acção (prioridade no tratamento).
Poderemos assim traçar um quadro, que mostre esta política, sob a forma de
uma Árvore de Decisão, ou colocá-la sob o formato Se-Então-Senão.
ÁRVORE DE DECISÃO
______ Bom histórico

| de pagamentos _____________________ Tratamento Prioritário
|
__ mais de 5 mil contos _| ___ connosco há mais __ Tratamento Prioritário
| de compras | | de 20 anos
| |______ Mau histórico _|
| de pagamentos | connosco há 20
| |__ anos ou menos ______ Tratamento Normal
|
| __ 5 mil contos ou menos _________________________________________ Tratamento Normal
Se Compras_Cliente > 5 000

Se Hist_Pagamento = “Bom”
Então
Tratamento_Cliente = “Prioritário”
Senão
Se Idade_Cliente > 20
Então
Tratamento_Cliente = “Prioritário”
Senão
Tratamento_Cliente = “Normal”
Senão
Tratamento_Cliente = “Normal”
A estrutura Se-Então-Senão é mais fácil de escrever e permite que as

condições e acções sejam escritas por completo, mas não mostra tão
claramente a estrutura da política da empresa.
Põe-se ainda um problema. E se a natureza da decisão for mais complexa?
Vamos supor que os clientes que comprem menos de 5 000 contos, mas que
tenham um bom histórico de pagamentos, também têm tratamento prioritário.
A árvore de decisão torna-se um pouco mais complexa (deixa-se ao aluno a
tarefa de executá-la).
Para situações ainda mais complexas, ou seja, com mais condições, a árvore
de decisão ficaria muito extensa, tornando-se confusa e não prática, devendo
usar-se alternativamente a chamada Tabela de Decisão.
TABELA DE DECISÃO
Para o nosso exemplo, teremos as seguintes condições:
C1 - Mais de 5.000 contos por ano

C2 - Bom histórico de pagamento
C3 - Connosco há mais de 20 anos
e as seguintes acções:
A1 - Tratamento prioritário
A2 - Tratamento normal
Como temos 3 condições, teremos 23 = 8 combinações possíveis, obtendo a

seguinte tabela:
C1 S S S S N N N N
C2 S S N N S S N N
C3 S N S N S N S N
A1 X X X
A2 X X X X X
Noção de Indiferença
Vamos verificar se alguma das colunas pode ser eliminada, obtendo, desta
forma uma lógica de programação mais simples.
Técnica
1. Encontrar um par de regras para as quais:

- a acção a tomar seja a mesma
- os valores das condição sejam o mesmo, excepto para uma e
somente uma condição onde eles forem diferentes.
2. Substituir aquele par por uma regra e utilizar o símbolo de indiferença (--)
para a única condição que for diferente.
3. Repetir a operação para qualquer outro par que atenda aos critérios.
Para o nosso exemplo teremos:
Simplificação das regras 1 e 2
C1 S S S N N N N
C2 S N N S S N N
C3 -- S N S N S N
A1 X X
A2 X X X X X
de seguida, simplificação das regras 5 e 6
C1 S S S N N N
C2 S N N S N N
C3 -- S N -- S N
A1 X X
A2 X X X X
de seguida, simplificação das regras 7 e 8
C1 S S S N N
C2 S N N S N
C3 -- S N -- --
A1 X X
A2 X X X
obtendo finalmente, através da simplificação das novas regras 4 e 5

C1 S S S N
C2 S N N --
C3 -- S N --
A1 X X
A2 X X
produzindo o respectivo pseudocódigo:
SE C1 e C2
ENTÃO Tratamento=“PRIORITÁRIO”
SENÃO SE C1 e não C2 e C3
ENTÃO Tratamento=“PRIORITÁRIO”
SENÃO SE C1 e não C2 e não C3
ENTÃO Tratamento=“NORMAL”
SENÃO SE não C1
ENTÃO Tratamento=“NORMAL”
TABELA DE ENTRADA MISTA
NOTA: Uma condição pode ter mais de 2 valores possíveis.
Exemplo:
Crédito Aprovado N S S S
Quantidade Encomendada -- 0-24 25-55 >55
Desconto -- 0 5 10
Aceita Encomenda X X X
Rejeita Encomenda X

Análise Sistemas

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Análise Sistemas

Enviado por

Direitos autorais:

Formatos disponíveis

Análise e Projecto de Sistemas 1

ANÁLISE E PROJECTO DE SISTEMAS

Rafael Gomes Machado

Porque surgiu a «Análise e Projecto de Sistemas de Informação»?

Quando uma empresa pretende informatizar uma secção, encarrega uma ou

 O que o sistema deve fazer

Há alguns anos, as pessoas encarregadas de transformar os sistemas

Ao longo do dia, a empresa recebe muitas vezes mais informação do que

voltados e especializados para armazenar, classificar, comparar e exibir essa

O que é a Análise e Projecto de Sistemas

Nos últimos tempos, as empresas têm vindo a implementar e melhorar

Existe numa organização, não como um departamento isolado

Teoria Geral de Sistemas

A «Análise e Projecto de Sistemas» baseia-se na «Teoria Geral de

1. As componentes de um sistema são interdependentes e

2. Um sistema é visto como um todo; não temos que decompo-lo

3. Os sistemas procuram a realização de objectivos de algum tipo; as

4. Os sistemas têm inputs e outputs; são dependentes de algum tipo de

5. Todos os sistemas transformam inputs em outputs; em geral, a forma do

6. Os sistemas exibem entropia, um termo emprestado pela termodinâmica.

7. Os sistemas têm de ter um modo de regulação das componentes

8. Os sistemas, normalmente, englobam subsistemas menores. A

9. Normalmente encontramos diferenciação em subsistemas complexos;

sistema, havendo por isso que escolher as que proporcionam melhor

Os Processos da Análise de Sistemas

a) Recolha e interpretação detalhada dos dados.

Neste processo o analista deve inteirar-se das informações e

b) Apreensão dos problemas e alternativas existentes.

Neste processo o analista deve aperceber-se de quais problemas

b) Análise das fragilidades.

Neste processo o analista deve analisar aqueles que são

c) Lista dos meios disponíveis e avaliação da sua performance.

Neste processo o analista deve listar todos os meios à disposição

Estes processos estão presentes em todas as etapas da Análise de

Características de um Sistema de Informação

Objectivo: Orientar a tomada de decisão numa organização

a) Dados: Constituem a entrada (INPUT) do Sistema

b) SPD: Ocupa-se da transformação dos dados em informação útil

c) Canais de Comunicação: Meios pelos quais se transmite

d) Estrutura: Forma como os diversos Sistemas de Processamento

e) Comportamento: Cumprimento dos objectivos do S.I.

f) Ciclo vital: Evolução, desgaste, inadequadação, envelhecimento,

Fases que compõem a «Análise e Projecto de Sistemas»

A investigação preliminar é a etapa da Análise de Sistemas que

Recolha do pedido - A essência de porque se necessita de um novo

Condução de investigação - Levantamento dos processos

Testes de previsão de viabilidade - Testes de viabilização para a

a) Prever a viabilidade operacional do novo sistema, isto é:

b) Prever a viabilidade técnica do novo sistema, isto é:

c) Prever a viabilidade económica/financeira do novo sistema,

d) Elaboração da Proposta (Caderno de Encargos) - Elaboração da

um relatório enumerando a dimensão do projecto, suas alternativas e

2. Análise (Projecto Lógico)

 Construção de inputs e outputs eficientes, isto é, que

 Manter o sistema funcional ao longo do tempo, correcção de

As técnicas e perícias a desenvolver por um Analista de Sistemas são as

 Capacidade para analisar um pedido de assistência por computador e

Ferramentas de Análise de Sistemas (Projecto Lógico)

As ferramentas utilizadas para efectuar uma análise de sistema são as

Devem ser efectuadas entrevistas e questionários às pessoas que

 No final destas se saibam que dados necessitam ser recolhidos e

d) Diagramas de Entidades Relação (E-R)

e) Diagramas de Fluxo de Dados

É um dicionário de identificação de cada origem, destino, processo,