Anlise de sistemas

Fernando Ribeiro
Janeiro de 2016
Citeforma

Contedos

Conceito de anlise e de sistema de informao

Modelos de entidades e relaes
Modelos fsicos de dados
Representao das fronteiras do sistema
Representao do comportamento do sistema
Representao da implementao do sistema

Fernando Ribeiro janeiro de 2016

Sistema de informao
Conjunto de pessoas, tecnologias e processos organizados
entre si de forma a reunir, armazenar, processar, distribuir e
transmitir informao.

Um sistema de informao pode ser manual ou

automatizado.
Fernando Ribeiro janeiro de 2016

Vantagens de um Sistema de Informao

A informao est melhor organizada, facilitando a sua
recolha, o seu armazenamento, o seu processamento e a
sua distribuio e transmisso.
A informao est mais estvel e melhor controlada.
A informao est mais segura.

Fernando Ribeiro janeiro de 2016

Vantagens de um Sistema de Informao

Numa empresa, estas vantagens resultam, normalmente:

Na reduo dos custos operacionais e administrativos.
No aumento da produtividade.

Fernando Ribeiro janeiro de 2016

Segurana de um Sistema de Informao

Consiste na proteo da informao contida no sistema,
pois a informao tem um determinado valor para a pessoa
ou organizao que cria, mantm ou utiliza o Sistema de
Informao.

Fernando Ribeiro janeiro de 2016

Segurana de um Sistema de Informao

A segurana do Sistema de Informao depende da
seguintes caractersticas da informao:
Confidencialidade;
Integridade;
Autenticidade;
Disponibilidade.

Fernando Ribeiro janeiro de 2016

Confidencialidade

Garantia de que apenas as pessoas ou organizaes

autorizadas tm acesso informao.

Fernando Ribeiro janeiro de 2016

Integridade

Garantia de que a informao mantm todas as

caractersticas originais e no foi adulterada.

Fernando Ribeiro janeiro de 2016

Autenticidade

Garantia de que a origem

correctamente identificada.

Fernando Ribeiro janeiro de 2016

da

informao

est

Disponibilidade

Garantia de que a informao estar sempre disponvel

para ser distribuda s pessoas e organizaes autorizadas.

Fernando Ribeiro janeiro de 2016

Implementao de um SI automatizado
A implementao de um Sistema de informao passa pelas
seguintes fases:
Especificao (requisitos do sistema): Identificao do problema a
resolver, recolha de informao, especificao dos requisitos do
sistema;
Desenho do sistema (caractersticas do sistema);
Construo do sistema;
Reviso do sistema;
Manuteno do sistema (prolonga-se enquanto existir o sistema).
Fernando Ribeiro janeiro de 2016

Fase de especificao
Identificao do problema a resolver: definio exata do problema
que o sistema de informao ir resolver, que resultados obter, que
informao processar, sempre de uma forma geral mas precisa.
Recolha de informao: entrevistas com utilizadores, gestores do
sistema, o dono do sistema, recolha de documentao relevante,
regulamentos, standards, anlise de sistemas existentes.
Especificao de requisitos: produo de um documento de
especificao completo, claro e abrangente e respetiva aceitao.

Fernando Ribeiro janeiro de 2016

Progresso da fase de especificao

Fernando Ribeiro janeiro de 2016

Levantamento de requisitos
Os requisitos do sistema so obtidos atravs de consultas
aos futuros donos e gestores do sistema, aos futuros
utilizadores, a documentao existente relevante para o
sistema, e atravs dos conhecimento do domnio e estudos
de mercado.
Este processo tambm conhecido como aquisio de
requisitos.
Fernando Ribeiro janeiro de 2016

Anlise e negociao de requisitos

Os requisitos so analisados em detalhe e as diferentes partes
negociam para decidirem que requisitos sero aceites.
Este processo necessrio visto que inevitvel o aparecimento de
conflitos entre requisitos de diferentes fontes, existncia de
informao incompleta ou incompatibilidade com o oramento
disponvel para o desenvolvimento do sistema. Existe, no entanto,
alguma flexibilidade na negociao de requisitos para que seja
possvel concordar acerca de conjunto de requisitos para o sistema.

Fernando Ribeiro janeiro de 2016

Documentao de requisitos
Os requisitos acordados durante o processo de negociao
so documentados com um nvel de detalhe apropriado.
Em geral, necessrio existir um documento de
especificao de requisitos que seja compreendido por
todas as partes. Isto significa que os requisitos devem ser
detalhados utilizando linguagem natural e diagramas.
Podem tambm ser produzidos documentos de sistema
mais detalhados tais como modelos de sistema.
Fernando Ribeiro janeiro de 2016

Validao de requisitos
Todos os requisitos obtidos nas atividades anteriores devem ser
cuidadosamente verificados para apurar se esto completos e so
consistentes. Este processo tem como finalidade detetar potenciais
problemas no documento de especificao de requisitos antes que
este seja utilizado como base para o desenvolvimento do sistema.
Tambm devem ser verificados os custos de implementao totais do
sistema e comparados com o oramento disponvel.
Deve existir um documento formal aceitao dos requisitos assinado
por todas as partes (por exemplo, pelo fornecedor e pelo cliente).
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Definio do problema: Implementar um sistema de venda
automtica de bilhetes de comboio nas estaes da CP

Alcance do problema: 50 estaes nas principais cidades do

continente com venda de bilhetes, e um escritrio em
Lisboa com sistema de gesto.
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Sistemas existentes: sistema manual
Documentao:
Norma ISO 9001
Normas do sistema Multibanco
Lista de estaes com localizao e horrio de passagem de cada
comboio
Tabela de preos para cada par origem/destino
Lista de comboios com capacidade de passageiros
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Requisitos funcionais da mquina de venda:

Vende bilhetes com escolha de origem, destino e horrio.

Bilhete vlido por 24 horas.
Pagamento com notas de 5, 10, 20 e moedas de 10, 20 e 50 cntimos e
moedas de 1 e 2

D troco em dinheiro
Pagamento com Multibanco
Imprime talo de venda

Imprime factura
Mantm registo da capacidade de cada comboio e s vende os bilhetes possveis
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Requisitos funcionais da mquina de venda:
Comunica todas as vendas ao servidor central atravs da rede
existente
Interface de utilizador em Portugus, Ingls e Espanhol
Interface de utilizador para invisuais

Requisitos funcionais do sistema central:

Consulta de vendas de bilhetes, por origem/destino, por estao, e
total de valor vendido.
Impresso de relatrios dirios para a contabilidade
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Requisitos de desempenho:

- 2 estaes com 1000 passageiros/hora, 12 estaes com 500 passageiros/hora, 26

estaes com 100 passageiros/hora.
- venda de bilhetes funcional 24 horas/dia, 365 dias/ano.
Requisitos de segurana:
- cofre de alta segurana para o dinheiro com sistema de tintagem
- requisitos necessrios ao sistema Multibanco

- sistema de autorizao no servidor central

Requisitos de portabilidade:
- ponto de rede para cada mquina de venda
Fernando Ribeiro janeiro de 2016

Exemplo de especificao de requisitos

Restries normativas:
Certificao de qualidade ISO 9001
Certificao Multibanco para pagamentos

Fernando Ribeiro janeiro de 2016

Desenho do Sistema de Informao

Consiste no desenho global do sistema a partir do documento de
especificao de requisitos, ou seja, a definio da arquitectura do
sistema. Inclui:
Diviso do sistema em mdulos
Criao de diagramas dos mdulos do sistema e de fluxo de dados
Criao dos modelos de dados do sistema
Especificao de interfaces do sistema
Listagem de produtos de software a integrar no sistema
Listagem de hardware necessrio ao sistema
Fernando Ribeiro janeiro de 2016

Desenho informal do sistema

Dispens
ador de
notas e
moedas

Venda de
bilhetes
Impresso de
bilhetes

Impressora

Fernando Ribeiro janeiro de 2016

Sistema
Multibanco

Impresso
de
relatrios
Impressora

Base
de
dados

Cofre

Rede

Comunicaes

Pagamentos

Sistema central

Dados de pagamento

Mquina de venda
Comunicaes

Leitor de
cartes

Bilhetes
vendidos

Consulta de
vendas

Construo do sistema
Programao do software necessrio e interfaces
Integrao do software produzido com o hardware, restantes
produtos de software, rede, sistemas de backup, e outros.
Criao de ambiente de teste (cpia do sistema completo ou parcial
para teste do sistema)
Criao de ambiente de produo (sistema final a colocar em
produo)
Criao de toda a documentao do sistema (manuais tcnicos,
manuais de utilizador, e outros)
Fernando Ribeiro janeiro de 2016

Reviso do Sistema
Verificao dos requisitos, apurando se o sistema
construdo cumpre todos os requisitos especificados;
Realizao de testes de sistema, verificando se todos os
aspectos do sistema funcionam como esperado;
Se forem detectadas falhas no sistema, voltar fase de
desenho, e posteriormente construo;
Quando no houverem falhas detectadas no sistema,
colocao do sistema em produo.
Fernando Ribeiro janeiro de 2016

Manuteno do Sistema (Produo)

Depois de colocado o sistema em produo, entramos na
fase de manuteno que pode continuar durante todo o
tempo de vida til do sistema, e inclui:
Correco de falhas no detectadas durante a reviso do
sistema;
Adio de novas funcionalidades entretanto apuradas.
Fernando Ribeiro janeiro de 2016

Modelo de implementao do projecto

Tradicionalmente, controlar a implementao de um projecto de
software bastante difcil, sendo comum que um projecto termine
no cumprindo as previses feitas sobre:
-A sua durao
-O seu custo
-As suas funcionalidades
Como gerir um projecto em que constantemente os prazos no so
cumpridos, os custos excedem o previsto e os requisitos no so
satisfeitos?
Fernando Ribeiro janeiro de 2016

Modelo de implementao do projecto

Para facilitar a gesto do projecto adoptamos um modelo de
implementao.
O modelo usado para estruturar, planear e controlar o processo de
implementao do sistema de informao.

Cada modelo tem as suas caractersticas, mas todos se destinam a

auxiliar o cumprimento dos objectivos do sistema de informao
dentro do prazo e custo previsto.
Fernando Ribeiro janeiro de 2016

Modelo em cascata

Modelo assumidamente
com problemas, devido
falta de iteratividade
entre as fases
Fernando Ribeiro janeiro de 2016

Modelo em cascata
A fase seguinte s comea quando a anterior estiver completa:
No existe sobreposio de fases;
No se pode voltar a uma fase anterior;

Existe pouca flexibilidade e no permite iteraes, que so essenciais

ao desenvolvimento de software, portanto pouco til de um ponto
de vista prtico. No entanto pode ser til se sofrer algumas
modificaes.
Fernando Ribeiro janeiro de 2016

Prototipao
comum serem utilizados prottipos na construo de software com diferentes
propsitos:
a construo de uma prova de conceito, ou simulao;
a implementao parcial do sistema ou;
para testar aspectos tcnicos de um sistema.
O processo de prototipao consiste basicamente em diversos ciclos iterativos. Um
prottipo construdo a partir de requisitos iniciais. realizada uma avaliao
crtica do prottipo a qual considera os requisitos iniciais e requisitos que no
foram mencionados inicialmente. Caso o prottipo no cumpra os requisitos
pretendidos, so realizadas novas iteraes produzindo novos prottipos. As
iteraes so finalizadas quando os requisitos forem atendidos.
Fernando Ribeiro janeiro de 2016

Prototipao

Fernando Ribeiro janeiro de 2016

Prototipao Incremental
A abordagem incremental um tipo de prototipao em que o desenvolvimento
feito por etapas, ou estgios.
Normalmente os requisitos mais importantes so implementados primeiro e os
restantes so acrescentados em novas verses. O desenvolvimento ocorre
gradualmente e no fim de cada estgio produzida uma verso funcional. Cada
estgio utiliza o modelo em Cascata.
A abordagem pode oferecer diversas vantagens:
reduo de riscos
maior visibilidade sobre o processo de desenvolvimento
maior facilidade em estimar a durao do projeto.
No entanto, necessrio grande esforo na atualizao da documentao do
utilizador e as dependncias entre os diversos estgios podem ser difceis de
prever e planear.
Fernando Ribeiro janeiro de 2016

Prototipao Evolutiva
A abordagem evolutiva um tipo de prototipao em que o desenvolvimento
feito por etapas, ou estgios, e cada estgio representa um refinamento do
prottipo do estgio anterior. Os estgios vo-se sucedendo at que todos os
objectivos sejam antingidos.
Cada estgio utiliza o modelo em Cascata, e h uma sobreposio das fases da
operao e manuteno do sistema anterior com o novo desenvolvimento.
A abordagem adequada principalmente quando:
necessrio alguma experincia do usurio para refinar e completar requisitos;
algumas partes da implementao podem depender da existncia de tecnologia
ainda no disponvel;
existem requisitos que no so bem conhecidos ou so muito mais difceis de
serem implementados do que outros.
Fernando Ribeiro janeiro de 2016

Modelo em V
O modelo em V representa uma melhoria do modelo em cascata,
corrigindo o problema da falta de mecanismos de reaco a
problemas surgidos ou melhoramentos necessrios durante o
desenvolvimento. Este modelo permite retornar a uma fase anterior
em case de necessidade.
As fases posteriores devem devolver informao s fases anteriores,
quando os problemas so detectados, a fim de melhorar o programa.

Como principal desvantagem encontramos a dificuldade em seguir o

fluxo sequencial do modelo.
Fernando Ribeiro janeiro de 2016

Modelo em V

Fernando Ribeiro janeiro de 2016

Modelo em Espiral
O modelo em Espiral rene caractersticas do modelo em Cascata e da
Prototipao, introduzindo ainda o conceito de anlise de risco. Cada volta da
espiral (iniciando a partir do centro) representa uma nova iterao do processo de
implementao. Estas iteraes frequentes permitem que novas verses possam
ser construdas progressivamente.

Tipicamente, o modelo pode ser dividido em 4 etapas:

1. Identificao dos objectivos para a fase decorrente
2. Anlise dos riscos e sua preveno e controle
3. Desenvolvimento e verificao
4. Planeamento da fase seguinte
Fernando Ribeiro janeiro de 2016

Modelo em Espiral

Fernando Ribeiro janeiro de 2016

Modelo em Espiral
O modelo em espiral apresenta algumas vantagens importantes:
Quanto mais tempo e recursos forem destinados ao projeto, ou
seja, quanto mais iteraes forem feitas na espiral, menor sero os
riscos do projeto no cumprir os requisitos, os prazos e o
oramento estabelecido.
A verificao presente no final de cada iterao permitem um
melhor controle do projeto.

No entanto, em projectos simples e de baixo risco a utilizao do

modelo
em janeiro
Espiral
Fernando Ribeiro
de 2016torna-se demasiado pesada e dispendiosa.

Test Driven Development

Test Driven Development (ou Desenvolvimento Orientado aos
Testes) um modelo de desenvolvimento de software baseado em
iteraes curtas, em que o teste do software usado como
orientao do mtodo de desenvolvimento.
Inicialmente o programador escreve um caso de teste automatizado
que se debrua sobre uma funcionalidade ou melhoria a
implementar. Posteriormente produzido cdigo que possa ser
validado pelo teste, implementando-se assim a funcionalidade
desejada.
Fernando Ribeiro janeiro de 2016

Test Driven Development

O modelo TDD segue normalmente esta sequncia:
1. Adicionar um teste - Cada nova funcionalidade inicia-se com a
criao de um teste. Para tal, o programador precisa conhecer as
especificaes e requisitos da funcionalidade.
2. Executar o teste - O novo teste deve falhar pois a funcionalidade
ainda no foi desenvolvida.
3. Escrever cdigo - Escrever o cdigo necessrio para que o teste
no falhe.
4. Execute o teste automatizado com sucesso O sucesso do teste
indica que os requisitos esto a ser cumpridos.
5. Repetir para nova funcionalidade
Fernando Ribeiro janeiro de 2016

Modelos geis

O desenvolvimento gil de software (do ingls agile software

development) um conjunto de metodologias de desenvolvimento
de software que tentam minimizar o risco de no cumprir prazos,
oramentos ou objectivos utilizando iteraes muito curtas
(tipicamente de uma a quatro semanas) ao fim das quais produzida
uma nova verso do software. Cada iterao como um projecto de
software em miniatura e inclui todas as tarefas necessrias para
implementar a nova funcionalidade: planeamento, anlise de
requisitos, projecto, desenvolvimento, teste e documentao.
O desenvolvimento gil prefere as comunicaes em tempo real, face
a face, a documentos escritos. A maioria dos elementos da equipa
deve
estar agrupada na mesma sala.
Fernando Ribeiro janeiro de 2016

Rapid Application Development

O modelo RAD (Desenvolvimento Rpido de Aplicaes) um
modelo gil de desenvolvimento de software iterativo e incremental
que enfatiza um ciclo de desenvolvimento extremamente curto
(entre 2 a 3 meses).
Este modelo baseia-se na modularizao do software e no
reaproveitamento de mdulos.

Fernando Ribeiro janeiro de 2016

Rapid Application Development

O modelo segue as fases seguintes:
Modelao de Negcio
Modelao dos Dados
Modelao do Processo
Gerao da Aplicao, usando ferramentas automatizadas para
facilitar a construo da aplicao e a reutilizao de mdulos.
Teste e Modificao

Fernando Ribeiro janeiro de 2016

eXtreme Programing
Programao extrema (XP) um mtodo gil de desenvolvimento de
software que utiliza equipes de trabalho pequenas e requisitos pouco
definidos e em constante mudana. Para isso criado um constante
acompanhamento do projecto pelo cliente, que chega a participar no
planeamento e teste, e so realizados vrios pequenos ajustes
durante o desenvolvimento de software.
O mtodo XP possui como princpios bsicos o feedback rpido, a
simplicidade de requisitos, a utilizao de iteraes curtas e
incrementais e o constante controlo de qualidade.
Fernando Ribeiro janeiro de 2016

Scrum

O mtodo Scrum um mtodo gil de desenvolvimento de software, iterativo e

incremental, que utiliza pequenas equipas e baseado em alguns conceitos chave:
O ScrumMaster, pessoa responsvel pelos processos de desenvolvimento.
O Dono do Produto, ou Product Owner, que representa o negcio e os utilizadores
do produto.
A Equipe, ou Team, o pequeno grupo de pessoas que fazem a anlise,
implementao, teste, etc.
O backlog, conjunto de requisitos do produto priorizados pelo Product Owner.
O sprint, iterao de durao curta (um ms) que resulta sempre na produo de
mais um incremento no projecto e que parte de um subconjunto do backlog (o
sprint backlog).
O daily scrum, pequena reunio do incio do dia em que cada participante fala
sobre o progresso conseguido, o trabalho a ser realizado e os impedimentos
existentes.
Fernando Ribeiro janeiro de 2016

Scrum

Fernando Ribeiro janeiro de 2016

Fernando Ribeiro janeiro de 2016