modelagem de sistemas de informação

Modelagem de Sistema de Informação

Introdução à disciplina

FreeDigitalPhotos.net

Plano De EstudoO que é?

● Modelagem um sistema de informação de acordo com determinado negócio.

● Modelagem: ○ Identificação das necessidades, apresentando as

vantagens e os possíveis problemas de implementação.

○ Viabiliza os processos e as tecnologias necessárias para a solução do problema.

Plano De EstudoNa pratica...

Abordaremos conceitos aplicáveis sobre:

● Arquiteturas de Sistemas de Informações:○ Arquitetura de Dados○ Planejamento Estratégico de Dados○ Planejamento Sistêmico de Dados○ Modelos lógicos○ Modelos Físicos○ Estratégias de Banco de Dados○ Bancos de Dados Distribuídos○ Tendências



● Arquitetura de Aplicações:○ Planejamento Estratégico de Sistemas○ Modelagem de Aplicações○ Engenharia de Sistemas○ Desenvolvimento Tradicional○ Desenvolvimento Estruturado○ Desenvolvimento Orientado a Objetos○ Engenharia de Informação



● Arquitetura de Tecnologia:○ Estratégias para Desenvolvimento de Aplicações

Cooperativas○ Estratégias para Desenvolvimento de Aplicações

Client-Server○ Desenvolvimento com ORACLE○ Tecnologia CASE



● Arquitetura de Organização:○ Quality Services em Sistemas○ Estratégicas para Manutenção de Sistemas○ Engenharia Reversa○ Re-engenharia

● O Inter-relacionamento das Arquiteturas:○ Modelagem de Sistema de Informação – caso real

Plano De EstudoBibliografia básica● LAUDON, Kenneth C.;LAUDON, Jane P. Sistema de Informações

Gerenciais 7ª Edição, São Paulo, Editora Pearson Prentice Hall

● OLIVEIRA, Jair Figueiredo de. Sistema de Informaçãoversus Tecnologia, São Paulo, Érica

● FERNANDES, A. A.; KUGLER, J. L. C. Gerência de projetos de sistemas. Rio de Janeiro, LTC.

● PAGE-JONES, Meillir. Gerenciamento de projetos. São Paulo, Makron Books.

Plano De EstudoFrequência em sala de aula

● Cada noite de aula correspondem a 3 (três) presenças:○ 2 (duas): Correspondem à presença em si.○ 1 (uma): Corresponde à elaboração da tarefa em

sala de aula.

● Exigência mínima de presença em sala de aula para aprovação: 75%

Plano De EstudoAvaliação

● Padrão UNIP: NP1 e NP2

● Avaliações com questões de múltipla escolha e dissertativas, totalizando 10 questões por avaliação.

● Média Semestral (MS) deverá ser igual ou superior a 5,0 para aprovação

MS = ((NP1 x 4) + (PIM x 2) + (NP2 x 4)) / 10

Qual a importância do uso sistemas gerenciais nas empresas?

Como são tratados os dados?

Qual é o limite financeiro?

Quais ferramentas precisam ser integradas?


Como a empresa faz seu

planejamento?

Em que é baseada tomada de decisão da empresa?


● Essas perguntas devem ser respondidas para a atingir as seguintes metas:

○ Excelência Operacional.○ Novos Produtos.○ Serviços e modelos de negócios○ Relacionamento com clientes e fornecedores.○ Melhor tomada de decisões.○ Vantagem competitiva.○ Sobrevivência.


● Tais metas são atingidas:

○ Projetando sistemas competitivos e eficazes, onde as pessoas possam controlar, entender e usar de maneira social e eticamente responsável.

○ Entendendo os requisitos de sistema do ambiente de negócios global.

○ Criando arquitetura de informação que apóie os objetivos da organização.

○ Determinando o valor dos sistemas de informação para o negócio.


● Para projetarmos um sistema de informação necessitamos de processos:


● Os processos devem ser integrados:


● A solução técnica deve ser convergente:


● A tecnologia deve ser interdependente e escalonável:


Conceitos sobre modelagem de sistemas


Fundamentos

● Modelagem um sistema de informação tem como objetivo melhorar a tomada de decisão.

● Em situação de decisão deve-se saber: ○ Quais são as questões fundamentais. ○ Quais alternativas devem ser investigadas.○ Onde focar a atenção.

Fundamentos

Abordagem simples para tomada de decisão:

Situação

Decisões

Implementação

Retorno

Fundamentos

Abordagem no mundo real para tomada de decisão:

Fundamentos

Abordagem sistemática para tomada de decisão:

Situação Decisões

Modelo Resultados

Mundo simbólico

Mundo real

Análise

Intuição

Inte

rpre

taçã

o

Abs

traç

ão

Validação

Fundamentos

Em resumo...

● Definição do modelo, interpretação e implementação:○ São processos essenciais para a tomada de

decisão.

● Perguntas que sempre devem ser respondidas:○ Quais situações são passíveis de serem

modeladas?○ Qual é a disponibilidade de dados para análise do

modelo e para obter resultados em tempo hábil e a custos coerentes.

○ O que fazer para obter o máximo do modelo em termos da interpretação do modelo e da implementação de decisões.

Fundamentos

Em resumo...

● Modelos possuem funções diferentes, de acordo com o nível onde será implementado:○ Alto nível: planejamento estratégico, planos

contingência, tempo reação;○ Médio nível: planejamento, coordenação, logística,

adaptação;○ Baixo nível: programação, operação, expansão,

análise impacto

Uso de modelos. Para que serve?

Modelos são ferramentas de análises lógicas consistentes:

● Forçam a explicitação dos objetivos.● Identificam dos tipos de decisões que influenciam os objetivos.● Forçam a identificação das interações entre as decisões.● Forçam raciocínio criterioso sobre variáveis e definições

quantificáveis.● Mostram a consideração de dados que são pertinentes para

quantificação das variáveis e a determinação de interações entre elas.

● Identificam restrições ou limitações dos valores das variáveis.● Facilitam comunicação e o trabalho em grupo.● Podem ser ajustados e melhorados com a experiência e a

histórica, isto é, aprendizagem adaptativa.


Tipo de modelo Características Exemplos

Físico TangívelFácil compreensãoReprodução difícilManipulação difícilEscopo uso: muito baixo

Modelo aeronavesModelos de residênciasModelos de cidades

Analógico IntangívelCompreensão difícilReprodução mais fácilManipulação mais fácilEscopo de uso: baixo

Mapas de estradasVelocímetroGráficos

Simbólico IntangívelCompreensão mais difícilReprodução muito fácilManipulação muito fácilEscopo de uso: amplo

Modelos simulaçãoModelos algébricosModelos planilhas

Uso de modelos. Para que serve?Um exemplo

Eu gostaria de saber o tempo gasto em uma viagem. Preciso implementar isso em um computador de bordo, como fazer?



Eu gostaria de saber o tempo gasto em uma viagem. Preciso implementar isso em um computador de bordo, como fazer?


● Modelo: abstração (aproximação) cuidadosa (tratável) da realidade

● Detalhar o modelo o suficiente para que:○ Os resultados satisfaçam as necessidades.○ Seja consistente com os dados disponíveis.○ Haja alta correlação entre o previsto pelo

modelo e a realidade.○ Possa ser analisado dentro das

disponibilidades.


● Definir variáveis

TEMPO(T)

DISTÂNCIA(D)

VELOCIDADE(V)

TEMPO MÉDIO DE PARADA

(TMP)

NÚMERO ESPERADO DE PARADAS

(NEP)


● Modelo de alto nível

TEMPO(T)

DISTÂNCIA(D)

VELOCIDADE(V)


(TMP)


(NEP)

Processamento(análise)

Saída(Resultado)


● Modelo de médio nível

TEMPO(T)

DISTÂNCIA(D)

VELOCIDADE(V)


(TMP)


(NEP)


T=(D/V) + (TMP*NEP)

Saída(Resultado)


● Modelo de baixo nível

DISTÂNCIA(D)

VELOCIDADE(V)


(TMP)


(NEP)


T=(D/V) + (TMP*NEP)

Saída(Resultado)


Logo, um modelo é construído com:

1. Estudo de características da situação de decisão.2. Formulação de uma representação da situação.3. Analise do modelo simbólico.4. Quantificação e alimentação do modelo com dados.5. Validação e testes do modelo x realidade.

Uso de modelos: Tipos.

Modelagem dedutiva

Modelagem inferencial

Modelos Determinísticos

Modelos Estocásticos

É o modelo matemático que determina os resultados, exatamente, a partir das condições iniciais.

Modelo matemático que incorpora elementos probabilísticos.

Projeções e otimizações

Projeções e análisede decisões

Consulta base de dadose cálculo de parâmetros

Previsão, análise desimulação, análise estatística e estimação de parâmetros


● Modelagem dedutiva: Presume-se que o modelo pode desenvolver-se inicialmente focando nas variáveis, relacionando-as no modelo com suposições matemáticas. ○ Resultado: Valoriza o conhecimento

prévio do modelador em relação aos dados e suas aplicabilidades. Modelagem "de cima para baixo". Usa-se poucos dados.


● Modelagem inferencial: Presume-se que os dados refletem a realidade, relacionando as variáveis para estimar seus valores.○ Resultado: Valoriza os dados exatos.

Modelagem "de baixo para cima". Usa-se muitos dados.

Uso de modelos

● Representação limitada da realidade.● Os resultados de um modelo não é,

necessariamente, a solução para a situação original.

● A noção de "ótimo" é um conceito matemático em oposição a um conceito do mundo real.

● Um modelo formulado e implementado corretamente for cuidadosamente interpretado, ele fornecerá informações robustas para a tomada de decisão.


Ferramentas para Análise de Sistemas: DFD


Fundamentos

● Devem focalizar características importantes do sistema.

● Devem permitir: ○ Entendimento do ambiente. ○ Documentar os dados necessários para a correta

construção do sistema.

Fundamentos

● Ferramenta CASE (Computer-Aided Software Engineering).

● Os modelos devem contemplar: ○ Consultas e/ou relatórios do sistema do mundo real

(se existirem). ○ Informações a respeito das entidades relevantes,

envolvidas nessas consultas e/ou relatórios.

Fundamentos

● Exemplo: Sistema de Controle de Transportadora:

○ Entidades: motoristas e cliente.

○ Consultas: lista de entregas feitas em um dia, número de viagens que um motorista realiza em um mês.

Fundamentos

● Modelos coerentes devem possuir vários "pontos de vista":

○ Diagrama de Fluxo de Dados (DFD): perspectiva funcional e foco de nosso estudo.

○ Diagrama Entidade-Relacionamento (DER): perspectiva dos dados.

○ o Diagrama de Transição de Estado (DTE): perspectiva comportamental

O DFD

● O Modelo Funcional representa o processamento de dados do sistema e deve retratar as informações obtidas durante a extração de requisitos:

○ As funções que o sistema deve ter e a interação entre as funções.

○ As transformações que o sistema deve executar e a correspondência entre as entradas e as saídas.

○ O tipo de serviço oferecido pelo sistema e as fontes de informação.

○ O destino dos resultados produzidos pelo sistema.

O DFD

● É uma ferramenta gráfica que permite imaginar o sistema como uma rede de processos funcionais interligados por condutores de dados e contendo depósitos para esses dados.

● É necessário realizar duas tarefas importantes. Reconhecer o Problema e Avaliar sinteticamente esse problema:○ Entrevistas.○ Memorandos.○ Manuais.○ Documentação.○ Anotações.○ Conversações casuais.

O DFD - Notação

● O modelo gráfico utiliza somente quatro símbolos.

○ Processos○ Fluxos de Dados○ Depósitos de Dados○ Entidades Externas.

O DFD - Notação

● O Processo (Função) representa processos individuais que o sistema executa para transformar dados de entrada em dados de saída e que residem dentro dos limites do sistema (automatizado ou manual).

● Ele pode representar um único programa, uma série de programas, um módulo dentro de um programa ou, até mesmo, um processo manual.

● Usa-se na descrição um verbo e um substantivo.

1Realizar cálculos

1Realizar cálculos

O DFD - Notação

● O Fluxo de Dados representa o movimento de fragmentos ou de pacotes de informação ao longo do sistema que está sendo modelado.

● Pode ocorrer entre:○ Dois processos.○ Processo e entidade externa.○ Processo e depósito de dados.

● Os nome dos fluxos de dados são compostos por substantivos.

Dados do cliente

O DFD - Notação

● Os Fluxos de Dados podem ser convergentes ou divergentes.

O DFD - Notação

● O Depósito de Dados representa o armazenamento de dados.

● Coleção de dados em repouso, enquanto o fluxo de dados representa os dados em movimento.

● É a abstração de um arquivo de dados. Ele pode representar um arquivo, uma parcela de um arquivo ou elementos de um banco de dados.

● O nome do depósitos de dados é o mesmo nome do fluxo de dados no plural.

O DFD - Notação

● As Entidades Externas (ou Terminadores) indicam origem ou destino dos dados do sistema.

● Representam entidades fora da modelagem do sistema.

O DFD - Como fazer

● Escolher nomes significativos para processos, fluxos, depósitos de dados e entidades externas:

○ Utilizar nomes relacionados à rotina do usuário (normalmente consultado pelo analista).

○ Cuidado para não abusar de siglas e abreviações.○ Evitar utilizar nomes técnicos (a não ser quando conhecida pelo

usuário);○ Não colocar nomes de pessoas em processos ou entidades externas. ○ Não utilizar nomes vagos e muito gerais para os processos, tais

como: Fazer Serviço, Funções Diversas ou Processar Dados.

O DFD - Como fazer

● Numerar os processos:

○ Facilita a identificação das hierarquias de processos.○ Sequência de operação.

● Refazer o DFD quantas vezes for necessário até obter uma boa estética.

● Evitar DFDs muito complexos.

O DFD - Como fazer

● Certificar-se que o DFD é inteiramente consistente, além de manter consistência com outros DFDs○ Cuidado com fluxos de dados e processos sem

nome.○ Evitar processos que só tenham entradas (“buracos

negros”).○ Evite processos que não possuam saídas (“geração

espontânea”).○ Cuidado com depósitos de dados “somente-leitura”

(“geração espontânea”) ou “somente-escrita” (“buracos negros”). A única exceção é quando o depósito é externo e serve como interface entre o sistema e o usuário.

O DFD - Como fazer

O DFD - Exemplo

Um distribuidor de peças para aparelhos eletrodomésticos pretende automatizar seu sistema de vendas.

● Os pedidos dos clientes são recebidos normalmente (mas não necessariamente) por telefone, pelo vendedor que preenche o pedido no formulário padrão verde.

● O pedido, então, passa para uma outra pessoa que checa o pedido com o arquivo de fichas de peças e coloca o número do código da peça pedida ao lado do nome e verifica se o preço está correto.

● Algumas vezes, o pedido é para uma peça cujo nome não consta no arquivo ou o preço está incorreto e, então, o pedido é marcado como inválido e colocado de lado.

● Pedidos válidos são passados para o pessoal da área de estoque, que checa o livro de inventário de mercadorias, para verificar se há componente suficiente para atender ao pedido.

● Se o estoque é insuficiente, o pessoal rejeita o pedido e envia uma nota à área de compras para reposição do estoque.

● Se o estoque é suficiente, a quantidade pedida é marcada como pendente de expedição e a via cor-de-rosa do pedido é enviada para a contabilidade, para que seja gerada uma fatura para o cliente.

● O pessoal da expedição envia as peças pedidas ao cliente e dá baixa no inventário de mercadorias.

● O pessoal de compras atualiza o inventário de mercadorias quando recebe componentes do fornecedor.

O DFD - Exemplo

O DFD - ExemploConsidere o DFD que segue e que representa as funções de desenvolvimento na construção emanutenção de um sistema de software.

O DFD - Exemplo de vários níveisDiagrama de contexto.

O DFD - Exemplo de vários níveisDFD nível 0.

O DFD - Exemplo de vários níveisDFD nível 1.

O DFD - Exercício de fixação


Usuário e requisitosBaseado no material de Geraldo Xexéu, Prof.


Usuários

● Usuários○ São todos aqueles que usam o sistema com algum

objetivo, ou seja, realmente usam o sistema dentro do escopo do seu objetivo.

● Stakeholders○ São todos aqueles com algum interesse no sistema,

afetando ou sendo afetados por seus resultados. ○ É a pessoa que possui algum interesse no sistema,

em especial um interesse que envolve algum risco.

Interesses e objetivos

● Usuários○ Resposta planejada do sistema.

● Stakeholders○ Sistema pode afetar o negócio de alguma forma.

Lista de objetivos e interessesAgente ou

InteressadoObjetivo Interesse Prioridade

Cliente Fazer o pedido Receber a mercadoria 1

Cliente Obter status do pedido

Prever o prazo de chegada do pedido 2

Gerente Obter lista de pedidos diária Saber a produção diária 1


● Perspectivas dos usuários○ Interagimos com pessoas com visões e descrições

diferentes do que é o sistema.

○ Um cuidado importante que devemos ter é quanto à posição da descrição que está sendo feita em relação ao sistema.

○ É recomendado utilizar uma perspectiva externa, ou seja, fatores que afetam o sistema de fora para dentro.


● Entrevistado onisciente: ○ Descreve o sistema indicando coisas que ele “deve fazer”. Vê tanto o

sistema como os seus usuários de uma perspectiva externa, conhecendo os mecanismos tanto por dentro quanto por fora.

○ Normalmente é a posição da alta gerência e de quem contratou o sistema.

○ É comum que não conheça os procedimentos internos do sistema como acontecem realmente, mas apenas de forma geral ou como aconteciam no passado.

○ Exige funcionalidade do sistema, principalmente para atender o nível gerencial.


● Entrevistado usuário: ○ Descreve o sistema como se o estivesse usando diretamente, muitas

vezes já usando o sistema atual.

○ Exige funções do sistema, principalmente para atender o seu nível de atuação (gerencial ou operacional).

○ Pode apresentar alguma desconfiança, pois o novo sistema pode exigir novos conhecimentos.

○ Conhece a entrada e a saída do sistema, mas não necessariamente os procedimentos internos.


● Entrevistado parte do sistema: ○ Descreve o sistema visto por dentro.

○ Muitas vezes é quem vai ter o trabalho substituído, em todo ou em parte, pelo sistema, o que pode causar desconfiança e até mesmo franca hostilidade.

○ Conhece os procedimentos na forma como são realizados e as exceções que podem acontecer.

Requisitos

● O que é requisito?

○ Uma sentença identificando uma capacidade, uma característica física ou um fator de qualidade que limita um produto ou um processo (IEEE 1220-1994).

Requisitos

● Requisito do usuário:

○ É algum comportamento ou característica que o usuário deseja do software ou o sistema como um todo; o que o usuário quer.

○ São escritos pelo próprio usuário ou levantados por um analista de sistemas que consulta o usuário.

Requisitos

● Requisito do sistema:

○ É algum comportamento ou característica exigido do sistema como um todo, incluindo hardware e software.

○ O comportamento desejado do sistema.

○ São normalmente levantados por engenheiros ou analistas de sistemas, refinando os requisitos dos usuários e os transformando em termos de engenharia.

Requisitos

● Características de um Bom Requisito: ○ Necessário: Se retirado, ele não atenderá plenamente

as expectativas do usuário.■ Não devem existir requisitos do tipo “seria

interessante ter”. ■ Deve ser levado em conta que cada requisito

aumenta a complexidade e o custo do projeto.

○ Não-ambíguo: Possui uma e apenas uma interpretação.

○ Verificável: Não ser vago ou geral e sendo quantificado de uma maneira que permita a verificação de uma das seguintes formas: inspeção, análise, demonstração ou teste.

Requisitos

● Características de um Bom Requisito: ○ Conciso: Cada requisito define apenas um requisito

que deve ser feito e apenas o que deve ser feito, de maneira clara e simples.■ Não inclui explicações, motivações, definições ou

descrições do seu uso.

○ Alcançável: Realizável a um custo definido por uma ou mais partes do sistema.

○ Consistente: Não contradiz ou duplica outro requisito.

○ Ordenável: Por estabilidade e/ou importância.

○ Aceito: Pelos usuários e desenvolvedores.

Requisitos

● Características de um Bom Requisito:

○ Requisito for funcional, deverá ser também Independente da Implementação.

○ O requisito define o que deve ser feito, mas não como!

Requisitos: Está bem, como eu faço isso???

● Devemos chegar ao problema: ○ É necessário que todos concordem com a definição

do problema.

○ Entender as causas do problema:■ O problema por trás do problema pode ser mais

importante, sendo que o problema visto inicialmente é apenas um sintoma.

○ Identificar todos os stakeholders e usuários.

○ Definir a fronteira do sistema de solução.

○ Identificar as restrições impostas à solução.

Requisitos: Está bem, como eu faço isso???

● Preencha o formulário:

○ O problema de <descrição do problema>, afeta <stakeholders afetados> e resulta em <impacto nos stakeholders>.

○ A solução <indicar a solução> trará os benefícios de <lista dos principais benefícios>.

Requisitos funcionais e de informação

● Requisito funcional: ○ Representa algo que o sistema deve fazer, ou seja,

uma função esperada do sistema que agregue algum valor a seus usuários.

● Requisito informação: ○ Representa a informação que o cliente deseja obter

do sistema. ○ São as respostas fundamentais do sistema.

Requisitos não funcionais

● São a forma como os requisitos funcionais devem ser alcançados.

● Eles definem propriedades e restrições do sistema.

● Muitos requisitos não funcionais são também requisitos de qualidade, como exigências de desempenho e robustez.

● Outros são restrições ou exigências de uso de tecnologia.

Requisitos não funcionais

Requisitos: Exemplo● O sistema deverá permitir que um paciente marque uma consulta.● O sistema deverá confirmar que a consulta foi aceita pelo paciente.

● O sistema deverá permitir que um condômino solicite a segunda via de sua conta condominial.

● O sistema deverá permitir um aviso ao condômino que não pagar sua no prazo correto.

● O sistema deverá permitir que um fornecedor cadastre um produto no catálogo.

● O sistema deverá informar ao sistema de estoques que um produto foi vendido.

Requisitos: Dicas

● Use sentenças e parágrafos curtos.● Use a voz ativa.● Use verbos no futuro.● Use os termos de forma consistente e mantenha um

glossário.● Para cada requisito, avalie se a partir de sua definição

é possível determinar se ele está pronto ou não.● Garanta que todos os requisitos são verificáveis

imaginando (e possivelmente documentando) uma forma de fazê-lo.

● Verifique requisitos agregados e divida-os.● Mantenha um nível de detalhe único em todos os

requisitos.

Requisitos: Exemplo de documentaçãoSumário1. Introdução

1.1 Objetivo1.2 Escopo1.3 Definições, acrônimos e abreviações1.4 Referencias1.5 Visão Geral

2. Descrição Geral2.1 Perspectiva do Produto

2.1.1 Interfaces do Sistema

2.1.2 Interfaces do Usuário

2.1.3 Interfaces de Hardware

2.1.4 Interfaces de Software

2.1.5 Interfaces de Comunicação

2.1.6 Memória

2.1.7 Operações

2.7.8 Adaptações necessários no ambiente

2.2 Funções do Produto2.3 Características do Usuário2.4 Restrições2.5 Suposições e Dependências

3. Requisitos EspecíficosApêndicesÍndices

modelagem de sistemas de informação

Education