Curso Profissional Técnico de Informática
e Sistemas
Análise de Sistemas de Informação
Liliana Ruivo
1
Escola Secundária D. Dinis
Definição de Sistemas de Informação
Sistema da organização responsável pela recolha,
tratamento, armazenamento e distribuição da informação
relevante para a organização com o propósito de facilitar o
planeamento, o controlo, a coordenação, a análise e a
tomada de decisão ou acção em qualquer tipo de
organização.
Sistema de actividade humana que pode envolver ou não o
uso de tecnologia da informação (TI).
Liliana Ruivo
2
O SI deve ser capaz de disponibilizar o máximo de “informação
útil” (oportuna, fiável, etc.) à organização.
Portanto, a informação está para as organizações como o
combustível está para o automóvel: se não é suficiente, é pouco
provável que chegue ao seu destino: se não é o combustível
indicado, o motor não funciona.
Ao reconhecer a importância do SI como crucial ao bom
desempenho numa organização, e sendo a própria informação
reconhecida como um recurso que deve ser gerido com a mesma
determinação que o são os restantes recursos da organização,
surge a necessidade da organização possuir mais uma actividade
de gestão, denominada gestão de sistemas de informação (GSI).
Esta actividade é responsável pelas tarefas que, numa
organização, são necessárias para gerir a informação, o sistema
de informação e a adopção de tecnologias de informação.
Liliana Ruivo
3
Conceitos de Sistema de Informação
Os sistemas de informação podem classificar-se em dois tipos
básicos:
Sistemas de Processamento de Transacções (Transaction
Processing Systems), cuja finalidade é registar e manter a
informação que resulta directamente da actividade
desenvolvida pela organização;
Sistemas de Apoio à Decisão (Decision Support Systems),
que tem por objectivo a produção de informação de apoio
à tomada de decisões.
Liliana Ruivo
4
Os sistemas de processamento de transacções constituem
a base a partir da qual se desenvolvem os restantes
sistemas de informação. Eles contêm a história da
organização, os factos relevantes, os dados de base que
permitem observar a evolução da empresa, etc.
Exemplos de sistemas de processamento de transacções:
Numa empresa, o sistema de facturação a clientes é
um sistema de processamento de transacções;
Num hipermercado, o sistema de registo de vendas,
através da leitura dos códigos de barras, pode efectuar
automaticamente a actualização do stock de produtos.
Trata-se, evidentemente, de um sistema de
processamento de transacções.
Liliana Ruivo
5
Os sistemas de processamento de transacções
O objectivo dos sistemas de apoio à decisão é o de permitir o
acesso a informações que auxiliem os processos de decisão na
empresa. Os dados brutos que resultam do processamento de
transacções devem ser tratados tendo em vista a produção da
informação relevante. É o sistema com o qual os agentes
decisores da empresa trabalham directamente.
Continuando a usar o exemplo de uma empresa e de um
hipermercado, vamos apresentar alguns exemplos hipotéticos de
utilização da informação para apoio à decisão.
Um gerente de marketing pode ter interesse em conhecer a
adesão de clientes a um determinado produto lançado pela
empresa e analisar a performance obtida em cada mês de venda
desse produto.
O gestor do hipermercado pode ter necessidade de avaliar a
rotação de determinados produtos, ou analisar os
comportamentos dos consumidores relativamente a várias
categorias dos produtos, em várias épocas do ano.
Liliana Ruivo
6
Sistemas de apoio à Decisão
Os dois exemplos anteriores mostram que os dados brutos
resultantes das transacções devem ser trabalhados no
sentido de produzirem a informação de que os decisores
necessitam. Para além das aplicações que asseguram o
processamento das transacções, os sistemas de apoio à
decisão exigem o recurso a software adicional para capturar
a informação relevante e efectuar o seu tratamento, de
acordo com as necessidades dos utilizadores (agentes
decisores).
O modo como os utilizadores podem aceder à informação,
bem como o tipo de informação disponibilizável, constituem
critérios a partir dos quais se pode estabelecer uma
classificação dos sistemas de apoio à decisão.
Liliana Ruivo
7
Sistemas interactivos de pesquisa de informação
Os sistemas de produção de relatórios apresentam alguma
inflexibilidade, e consequentemente alguma insuficiência, sempre
que as necessidades de informação apresentam características de
variabilidade e imprevisibilidade.
Na formulação da estratégia da empresa, ou mesmo para a tomada
de decisões operacionais, o decisor pode ser frequentemente
confrontado com a necessidade de interrogar o sistema de
informação, colocando questões do tipo:
“No último mês, qual foi o montante vendido do produto X a
clientes com saldo médio no último ano foi superior a Y? “
“Quantos e quais os empregados, com categoria superior à de
chefe de secção, que, nos últimos três meses, frequentaram
cursos de formação profissional? “
“Qual seria o impacto previsional sobre as vendas dos produtos
X, Y e Z, se os respectivos preços fossem aumentados de 10%,
nas hipóteses A, B e C. “
Liliana Ruivo
8
Definição de Análise de Sistemas
Por Análise de Sistemas (AS) entende-se a actividade inicial do
processo de desenvolvimento de sistemas em que se determina
e especifica o que um sistema deve fazer bem como as
circunstâncias sob as quais deve operar, envolvendo geralmente
um esforço colaborativo entre analistas de sistemas e
utilizadores, no qual os primeiros procuram obter a partir dos
segundos, num processo gradual e cumulativo, o maior
conhecimento possível acerca do domínio do discurso do sistema
e respectivo ambiente.
A análise de sistemas é urna actividade crítica no processo de
desenvolvimento de sistemas, por ser uma etapa inicial e cujas
falhas terão efeitos em cadeia nas etapas subsequentes assim
como no produto final. A determinação incorrecta dos requisitos
levará à obtenção e disponibilização de sistemas informáticos
inadequados ao sistema de informação e ao sistema
organizacional.
Liliana Ruivo
9
O papel do Analista de Sistemas
Concebe e projecta, no âmbito do tratamento automático da
informação, os sistemas que melhor respondam aos fins em vista,
tendo em conta os meios de tratamento disponíveis;
Consulta os interessados a fim de recolher os elementos elucidativos
dos objectivos em vista;
Examina os dados obtidos, determina qual a informação a ser
recolhida, com que periodicidade e em que ponto do seu circuito, bem
como a forma e a frequência com que devem ser apresentados os
resultados;
Determina as modificações a introduzir necessárias à normalização dos
dados e as transformações a fazer na sequência das operações;
Prepara organogramas e outras especificações para o programador;
Efectua testes a fim de se certificar se o tratamento automático da
informação se adapta aos fins em vista e, caso contrário, introduz as
modificações necessárias.
Liliana Ruivo
10
Ele tem de ser capaz de lidar, ao mesmo tempo, com
utilizadores, técnicos de informática e administração
(gestores/agentes decisores). Cada qual com formação, pontos
de vista, experiência e objectivos completamente distintos.
Os utilizadores esperam que o novo sistema resolva todos os
seus problemas de forma fácil, agradável (sentimento de
“companheirismo” entre utilizador e máquina), rápida e eficiente.
Os técnicos de informática preocupam-se com aspectos de
performance, bits, byts, estruturas de dados, componentes
hardware, etc.
Por fim, a administração só quer saber do retorno sobre o
investimento e da relação custo/ benefício lembrando, a cada
momento, que “aquilo que você está a fazer é necessário para
ontem!”.
Por causa deste contexto, onde impera uma absurda
diversidade, é necessário que o Analista de Sistema, tanto
quanto possível, possua os seguintes requisitos:
Liliana Ruivo
11
Liliana Ruivo
12
A maior desvantagem em estabelecer uma lista de requisitos para o
Analista de Sistemas, é que jamais encontrar-se-á alguém que venha a
possuir todos eles.
Mesmo assim, não deverá esquecer este panorama e tentar conciliar, o
máximo possível, a presença destes requisitos na sua formação
profissional.
O Analista de Sistemas deverá ter em conta algumas directrizes de conduta, que
servirão para facilitar e valorizar o seu trabalho (obter sucesso):
Procurar ser aceite profissionalmente, do nível mais alto ao mais baixo da
empresa;
Escutar muito primeiro e falar pouco depois;
Estar sempre familiarizado com os últimos progressos no âmbito das tecnologias
da informação e compreender como aplicá-los de forma eficiente ao serviço da
empresa;
Ter grande capacidade de expressão e comunicação (ser capaz de explicar
conceitos complexos usando termos simplificados);
Ser acessível (ter capacidade de descer ao nível de quem tem menor número de
conhecimentos);
Conhecer bem a área de negócio para a qual irá desenvolver os sistemas;
Esforçar-se por conseguir a total satisfação dos utilizadores (solução adequada às
suas necessidades);
Procurar desenvolver, sempre, sistemas com qualidade, profissionalismo e que
cumpram a missão para a qual irão ser desenhados;
Nunca descurar o cumprimento das previsões e custos.
Liliana Ruivo
13
Modelo Ambiental
O Modelo Ambiental define a fronteira entre o sistema e o
resto do mundo (i.e. o ambiente onde reside o sistema). É
composto de uma pequena definição dos objectivos do
sistema, uma lista de eventos do sistema e um diagrama de
contexto.
Qualquer sistema que seja desenvolvido, seja ele simples
ou complexo, fará sempre parte de um sistema ainda maior.
O modelo ambiental define as interfaces entre o sistema e
o resto do universo, ou seja, o ambiente. Modela a parte
exterior do sistema. O modelo do interior do sistema será
denominado de modelo comportamental.
Liliana Ruivo
15
Definição dos Objectivos
É uma declaração textual concisa e breve dos objectivos do
sistema. Uma declaração mais detalhada deve ser deixada para
quando do modelo comportamental.
Por Exemplo: “o propósito do Sistema de Processamento de
Livros da biblioteca Alfa é manipular todos os detalhes dos
pedidos de livros, bem como remessas, facturação e cobranças
a clientes com facturas em atraso. Informações sobre pedidos
de livros devem estar disponíveis para outros sistemas, tal como
marketing, vendas e contabilidade”.
Alguns analistas também inserem na declaração dos objectivos
a relação de benefícios tangíveis e quantificáveis que serão
obtidos pelo novo sistema.
Por exemplo: “o propósito do sistema é reduzir o tempo
necessário para processar um pedido de 3 para 1 dia”.
Liliana Ruivo
16
Lista de Eventos
Consiste numa lista narrativa dos estímulos que ocorrem no exterior do sistema
e aos quais o nosso sistema deve responder.
Exemplos:
Cliente entrega pedido (F)
Cliente cancela pedido (F)
Direcção solícita relatório de vendas (T)
Pedido de reimpressão de livros chega ao depósito (C)
Cada evento deve ser rotulado com um dos seguintes caracteres:
F – orientado por um fluxo de dados (chegada de dados);
T – disparados num determinado momento
Exemplos:
Um relatório diário de todos os pedidos de livros é solicitado às 9h;
As facturas devem ser geradas às 15 horas;
Os relatórios para a direcção devem ser gerados a cada hora;
C – caso especial de evento temporal. São eventos não previsíveis. Não se
relacionam com a passagem normal do tempo. São comuns em sistemas de
tempo real. Geralmente não existem em sistemas de gestão tradicionais.
Liliana Ruivo
17
Diagrama de Contexto
O diagrama de contexto é um caso especial de diagrama de
fluxos de dados. Um diagrama de contexto compõe-se de
terminadores (entidades externas), fluxos de dados e um único
processo que representa todo o sistema.
Processo: É a parte mais fácil do diagrama de contexto,
consiste de uma única bolha. O nome do processo é
normalmente o nome do sistema (Exemplos: sistema de
gestão da contabilidade e sistema de gestão da biblioteca).
Terminadores: São representados por um rectângulo. Os
terminadores comunicam directamente com o sistema através
de fluxos de dados ou de fluxos de controlo, ou através de
depósitos de dados externos. Os terminadores não podem
comunicar entre si.
Liliana Ruivo
18
O diagrama de contexto deve ser construído de modo a que as
entradas sejam causadas e iniciadas pelos terminadores e que as
saídas / respostas sejam causadas e iniciadas pelo sistema.
O modelo ambiental deve ser confirmado tendo em conta as
seguintes verificações:
Cada fluxo de entrada é necessário ao sistema para reconhecer
que um evento ocorreu, ou é necessário ao sistema para a
produção de uma resposta a um evento, ou ambas;
Cada fluxo de saída é uma resposta a um evento;
Cada evento não temporal da lista de eventos tem entradas a partir
das quais o sistema pode detectar que o evento ocorreu;
Cada evento produz urna saída imediata como resposta, ou
armazena dados para serem emitidos como saída posteriormente
(como resposta ou parte de resposta a alguma evento), ou faz com
que o sistema a mude de estado.
Liliana Ruivo
20
Modelo Comportamental
Depois de modelado e validado o modelo ambiental é
necessário passar para a modelação do comportamento do
interior do sistema.
Num sistema de informação complexo existe,
normalmente, muitos componentes e procedimentos sobre
os quais é difícil obter uma compreensão correcta e clara
sem uma análise detalhada do interior do sistema.
Liliana Ruivo
21
Diagrama de fluxo de dados
“Uma imagem vale por mil palavras”
Diagrama: É uma espécie de linguagem que permite expressar o
desenvolvimento de um raciocínio.
Diagramas claros e com bom conteúdo desempenham um papel
importante no desenho de sistemas e no desenvolvimento de programas.
Com os diagramas apropriados é obtida uma ajuda fundamental na
visualização, compreensão e criação de processos complexos.
Para uma pessoa, O diagrama constitui um auxiliar para um raciocínio
claro, acelera o seu trabalho e aumenta a sua qualidade.
Para várias pessoas, O diagrama constitui uma ferramenta essencial para
a comunicação, possibilitando a troca de ideias e interligando e integrando
o trabalho de cada um no conjunto da equipa a que pertence.
Liliana Ruivo
22
Um bom diagrama pode constituir também uma ajuda importante na
manutenção de um sistema:
novas pessoas podem ser introduzidas facilmente no sistema existente;
maior facilidade em remontar o sistema numa outra organização;
como documento de análise do sistema da organização;
como auxiliar no comportamento esperado do sistema.
Mas como linguagem, cada grupo (equipa) de trabalho precisa de
estabelecer standards (normas, regras) que tem de respeitar.
A necessidade de um esquema formal deve-se ao facto de todos os
elementos do grupo de trabalho terem a necessidade de falar a mesma
linguagem, para que o seu trabalho seja compreendido e integrado
num todo.
Quanto maior for a equipa de trabalho maior será também a
necessidade de precisão (formalismo) nas formas de representação
utilizadas.
Liliana Ruivo
23
O uso de diagramas é importante porque constitui:
um auxiliar para um raciocínio claro;
a comunicação com precisão entre os membros de uma equipa de
desenvolvimento;
documentação do sistema;
reforço para uma boa estruturação;
um auxiliar para a revisão e manutenção do sistema;
reforço do rigor nas especificações;
grande ponto de partida para os programadores.
Os DFDs mostram as características da parte lógica do sistema,
esquematizando o que ocorre e quando tem lugar.
Não especifica como ocorrem os acontecimentos (pseudocódigo).
Liliana Ruivo
24
O desenho de um DFD obedece a um conjunto de regras de construção,
geralmente através de uma abordagem top-down, das quais podemos
realçar algumas consideradas mais importantes:
as designações dos elementos devem ser o mais explícitos possíveis,
tentando documentar a realidade que representam;
desenha-se um processo para cada evento da lista de eventos;
os processos recebem um nome de acordo com a resposta que o
sistema deve dar ao evento associado (exemplo: evento - cliente
efectua pagamento; nome – actualizar contas a receber);
as designações dos outros elementos devem ser o mais explícitos
possíveis, tentando documentar a realidade que representam;
as entidades, os processos e os depósitos de dados interligam-se
pelos fluxos de dados;
Liliana Ruivo
25
um fluxo de dados constitui um fluxo de output de dados de uma
entidade, processo ou depósito de dados e constitui, ao mesmo tempo,
um fluxo de input para um destes elementos;
um DFD não deve ser constituído por mais de sete processos de forma
a garantir um melhor legibilidade do diagrama;
um DFD deve estar contido num diagrama que ocupe uma única folha
de papel;
a criação de um nível de DFD depende da necessidade de detalhar um
processo;
é necessário na explosão de um processo garantir as mesmas entradas
e as mesmas saídas, isto é, não devem ser criados fluxos de dados que
não tenham sido já referenciados em diagramas de nível superior;
o DFD resultante é verificado em relação ao diagrama de contexto e à
lista de eventos para que se confirme que está completo e consistente.
Liliana Ruivo
26
O nível de topo de detalhe é analisado. Com a recolha de informação mais
detalhada, específica de cada um dos processos envolvidos, permite a
expansão do diagrama e o aumento da qualidade de representação do
sistema.
Uma aproximação gradual do geral para o pormenor, permitindo uma
melhor compreenção do sistema, define a análise com base no método
top-down.
Por exemplo, num sistema de pagamento a fornecedores deveremos
considerar:
que dados o sistema recebe (input);
que dados o sistema produz (output);
que dados e de que forma, estão envolvidos no processo de
processamento de pagamentos a fornecedores.
Liliana Ruivo
28
Dicionário de dados
Um dicionário de dados pode ser visto como uma lista onde
descreve e detalha todos os elementos representados num
DFD: entidades, fluxos de dados, processos e depósitos de
dados.
O dicionário de dados deve ser criado e actualizado em
simultâneo com o desenho do DFD.
O dicionário de dados complementa o DFD na descrição e
representação da realidade, adicionando mais informação.
Liliana Ruivo
30
Diagramas de Entidades - Associações
Também conhecido por Diagrama Entidade – Relacionamento
(Diagrama E-R) procura criar uma simulação da realidade. Esta é
vista como um conjunto de entidades, interagindo umas com as
outras, através de um conjunto de relacionamentos ou
associações de vários tipos.
Entidades:
O conceito de entidade é utilizado para designar um conjunto de
elementos do mesmo tipo. É um objecto que existe e é
distinguível de outros objectos.
Por exemplo: Aluno, Cliente, Conta Bancária, Empregado, ...
Associações:
As associações representam os relacionamentos existentes
entre as várias entidades.
Por exemplo: Requisição é uma associação entre a entidade
Sócio e Filme, num clube de vídeo.
Liliana Ruivo
31
Atributos:
Propriedades ou características que permitem descrever
entidades ou associações.
Por exemplo: Altura, Idade, Salário, Preço, ...
Domínios:
Conjunto de todos os valores que um atributo pode assumir.
Só serão válidos os valores de atributos que pertençam ao
domínio definido para esse atributo.
Por exemplo: 0 < Classificação < 20.
Atributo identificador:
Atributo, ou conjunto de atributos, que identifica
inequivocamente cada elemento de uma entidade ou
associação, no contexto da base de dados.
Por exemplo: Matrícula para a entidade Automóvel.
Liliana Ruivo
32
Liliana Ruivo
33
Os nomes a dar às associações não são muito relevantes.
O que verdadeiramente importa, é que se compreenda o conteúdo
e o tipo de associação.
um-para-um
Um elemento da entidade A pode estar associado (R) a um e um
só elemento da entidade B e Vice-versa
Liliana Ruivo
36
Lê-se:
Numa empresa trabalham muitos empregados e um empregado
trabalha numa empresa.
vários-para-vários
Um elemento de A pode estar associado (R) a vários elementos de
B:
Um elemento de B pode estar associado a vários elementos de A.
Normalização de dados
A normalização é um processo que consiste em estruturar as tabelas e os
atributos na forma mais adequada, do ponto de vista das operações a executar
sobre a informação registada na base de dados, tendo em vista eliminar
redundâncias desnecessárias e evitar problemas com a inserção, eliminação e
actualização de dados.
Existe uma relação entre essas formas normais, que pode ser expressa do
seguinte modo:
Uma tabela pode estar na primeira forma normal (1FN), mas não obedecer aos
requisitos necessários para ser considerada na segunda forma normal (2FN).
Do mesmo modo, uma tabela pode obedecer à segunda forma normal (2FN)
mas não à terceira forma normal (3FN). No entanto, as tabelas que obedecem à
segunda forma normal (2FN) obedecem igualmente à primeira forma normal
(1FN).
As tabelas, na terceira forma normal (3FN), obedecem igualmente aos
requisitos definidos pela segunda forma normal (2FN) e pela primeira forma
normal (1FN).
Na prática, os procedimentos de normalização consideram-se geralmente
Liliana Ruivo
40