ANÁLISE E MODELAGEM DE SISTEMAS I

Apresentação em tema: "ANÁLISE E MODELAGEM DE SISTEMAS I"— Transcrição da apresentação:

1 ANÁLISE E MODELAGEM DE SISTEMAS I
Fabrício Costa Santana professorfabricio.net

2 Apresentação da Disciplina
Ementa: Visão geral de um sistema. Conceito de sistemas. Sistemas de informação. Análise de sistemas. Estudo do ciclo de vida de um sistema. Metodologias de desenvolvimento de sistemas. Técnicas de Entrevistas e de Coleta de Dados. Análise estruturada de sistemas. Ferramentas da Análise Estruturada.

3 Apresentação da Disciplina
OBJETIVO GERAL Capacitar o aluno a utilizar adequadamente as ferramentas da análise estruturada e projeto estruturado nas fases de desenvolvimento de modelos corretos de sistemas. Apresentar ao aluno as etapas seguidas pelo analista de sistemas na construção de um modelo do sistema até a sua implementação, usando essas técnicas. Deverá também saber como e quando utilizar as ferramentas de análise e projeto estruturados.

4 Apresentação da Disciplina
OBJETIVOS ESPECÍFICOS Compreender, de forma integrada, a natureza dos sistemas de informação, sua importância para as organizações para uma melhor compreensão do papel dos profissionais que atuam nessa área; Utilizar o pensamento sistêmico na solução de problemas, dando condições para que este apresente propostas de pesquisa e desenvolvimento na área de sistemas de informação; Ter uma visão clara de um sistema, com suas etapas de desenvolvimento e a complexidade implícita em cada uma delas; Entender e saber aplicar as ferramentas de análise estruturada de sistemas; Dominar as técnicas da análise essencial.

5 Referências YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, p. GANE, Chris; SARSON, Trish. Análise estruturada de sistemas. Rio de Janeiro: LTC, p. MARTIN, James; McCLURE, Carma. Técnicas estruturadas e CASE. São Paulo: Makron Books, p. DeMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989. HEUSER, Carlos. Projeto de Banco de Dados. 1998

6 SISTEMA

7

8

9

10

11

12 Significado de Sistema
Conjunto de elementos interdependentes (entidades relacionadas), ou um todo organizado, ou partes que interagem formando um todo unitário e complexo desenvolvendo atividades ou funções para atingir um ou mais objetivos.

13 Componentes Básicos de um Sistema

14 Objetivo O objetivo é a própria razão de existência do sistema

15 Entradas É tudo aquilo que o sistema necessita como material de operação e é obtido no meio ambiente com o qual interage. É a energia que entra no sistema.

16 Processamento Transformação de um insumo (entrada) em um produto, serviço, ou resultado (saída). Este processo é a maneira pela qual os elementos componentes de um sistema interagem no sentido de produzir as saídas desejadas.

17 Saídas São os resultados do processo de transformação das entradas;
É o produto final do processamento que será colocado no meio ambiente em que o sistema se insere; É a forma de o sistema influenciar o meio.

18 Realimentação A retroalimentação pode ser considerada como a reintrodução de uma saída sob a forma de informação. Essa realimentação é um instrumento de regulação retroativa, ou de controle, em que as informações realimentadas são resultados das divergências verificadas entre as respostas de um sistema e os parâmetros previamente estabelecidos.

19

20 Exercício Padaria Construção Consultório Médico

21 Tipos de Sistemas Sistemas Naturais Sistemas Feitos Pelos Homens

22 Sistemas Automatizados
Conceito: “Sistemas feitos pelo homem, que interagem com ou são controlados por um ou mais computadores” (YOURDON, Edward)

23 Sistemas Automatizados
Sistemas Batch Sistemas On-line Sistemas de Tempo Real Sistemas de Apoio à Decisão Sistemas Baseados no Conhecimento

24 Princípios Gerais dos Sistemas
Quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias diferentes. Quanto maior for um sistema, maior o número de recursos que serão necessários à manutenção diária. Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas menores. Os sistemas crescem

25 Sistemas de Informação
Um sistema de informação é um conjunto organizado de elementos, podendo ser pessoas, dados, atividades ou recursos materiais em geral. Estes elementos interagem entre si para processar informação e divulga-la de forma adequada em função dos objetivos de uma organização.

26 Componentes dos Sistemas de Informação
Hardware Software Dados Procedimentos Peopleware

27 Classificação quanto ao nível organizacional
Estratégico Tático Operacional

28 Operacional Operacional Sistema de Processamento de Transações
Dados reais e precisos. Saída: relatórios analíticos Frequência: periódica Ex: faturamento, estoque, contabilidade Operacional

29 Tático Tático Sistema de Controle Operacional Supervisão
Compara o realizado com o previsto Relatórios consolidados Frequência: periódica Ex: custos, planejamento e controle de produção Tático

30 Tático Tático Sistema de Apoio à Decisão Média Gerência
Análise matemática e estatística dos dados Saída: gráficos e tabelas Frequência: a pedido Ex: simulação de cenários, análise de investimentos Tático

31 Estratégico Estratégico Sistema de Planejamento Estratégico
Alta administração Analisa os fatores críticos de sucesso Trabalha com projeções a longo prazo e tendências do mercado Saídas: gráficos e tabelas sofisticados Frequência: a pedido Ex: sistemas de informações executivas, BI Estratégico

32 Participantes no Desenvolvimento de Sistemas
Usuários Gerente de Projeto Auditores, Controle de Qualidade e Padronizadores Analista Projetista Programador Operador

33 Usuários Para quem o sistema é construído;
O analista deve manter contato constante com eles; A frase “o cliente tem sempre razão” deve ser respeitada; Devem ser chamados de Clientes ou Proprietários.

34 Classificação por Tipo de Função
Operadores Têm visão local, isto e, não conhecem o processo de forma global Responsáveis por executar as funções do sistema Têm uma visão física do sistema, ou seja, imaginam o funcionamento do sistema considerando a tecnologia de implementação

35 Classificação por Tipo de Função
Supervisores Podem ou não ter uma visão local Geralmente conhecem as operações pois muitos já foram Utilizadores operadores. Além disso, têm que supervisionar os Utilizadores operadores Orientado por considerações orçamentais (reduzir o quadro de funcionários ou aproveitá-los melhor) Normalmente agem como intermediários em relação aos níveis mais elevados

36 Classificação por Tipo de Função
Executivos Não têm experiência operativa Têm a iniciativa do projeto Possuem uma visão global Têm preocupações estratégicas Capazes de lidar com modelos abstratos

37 Classificação por Nível de Experiência
Amador Nunca trabalhou com um computador Tem dificuldade para entender os modelos produzidos pelos analistas Receia ser substituído pelo sistema ou ter sua importância minimizada

38 Classificação por Nível de Experiência
Novato arrogante Participou de alguns projetos Possui ou trabalha com computadores Por conhecer algumas ferramentas, gosta de opinar sobre as tecnologias a serem usadas para implementar o sistema

39 Classificação por Nível de Experiência
Experiente Conhecem a análise de sistemas Têm experiência de outros projetos Discutem sobre as técnicas de modelação sendo utilizadas

40 Gerente do Projeto Principais funções:
Gerenciar e alocar recursos de toda a equipe técnica Prestar contas junto à administração superior Encaminhar problemas identificados no decorrer do projeto

41 Auditores, Controle de Qualidade e Padronizadores
Responsáveis por garantir que o sistema será desenvolvido de acordo com os vários padrões internos e externos da organização, especialmente aqueles voltados à segurança e ao controle de qualidade do produto final.

42 Analista de Sistemas O analista de sistemas precisa ter aptidões interpessoais (além do conhecimento da tecnologia), ou seja, deve falar com outras pessoas usando a “linguagem” que elas usam, para não ser considerado amedrontador ou alienígena.

43 Analista de Sistemas Desempenha vários papéis: Arqueólogo e escriba
Mediador Inovador Líder de projeto

44 Analista de Sistemas Características de um bom analista:
Possui habilidade com pessoas. Possui conhecimento de aplicações (ajuda a compreender a empresa do usuário). Possui habilidade em tecnologia. Mente lógica e organizada (visualizar o sistema sob diferentes perspectivas).

45 Projetista de Sistemas
Tem a função de transformar os requisitos dos usuários, modelados pelo analista de sistemas, em um projeto implementável em um computador. Normalmente o analista e o projetista são a mesma pessoa, ou membros do mesmo grupo de pessoas.

46 Projetista de Sistemas
O analista de sistemas deve fornecer informações suficientemente detalhadas para que o projetista elabore um projeto tecnologicamente bom. O projetista deve fornecer informações suficientes para que o analista possa dizer se os requisitos dos usuários podem ser completamente atendidos ou devem ser modificados.

47 Programador Responsável por codificar e testar (usando uma linguagem de programação) os módulos do sistema modelados pelos projetistas. Em um cenário ideal, o programador não deveria ter contato com o analista já que se baseia apenas no trabalho feito pelo projetista.

48 Operador Pessoa encarregada de operar os computadores, da rede, da segurança do hardware e das bases de dados, da execução dos programas e da saída das impressoras.

49 Análise Conceito: Estudo de um problema, que antecede à tomada de uma decisão/ação (antes de passar à sua resolução). Em Sistemas de Informação: Estudo de alguma área de trabalho ou de uma aplicação, descrição das suas características e funcionalidades, levando geralmente à especificação de um novo sistema. Análise Estruturada: É a utilização de ferramentas que permitem a especificação formal dos requisitos do sistema a ser desenvolvido.

50 Análise Estruturada Etapa onde ocorre uma análise detalhada dos requisitos levantados; São construídos modelos para representar o sistema a ser desenvolvido; Uma especificação formal dos requisitos é produzida, representando todos os requisitos analisados; Uma revisão da especificação é realizada, de forma a garantir que a mesma esteja completa, consistente e precisa quanto às informações nela apresentadas.

51 Princípios da Análise Estruturada
O Domínio da Informação de um problema precisa ser representado e entendido; As funções a serem desenvolvidas pelo sistema devem ser definidas (modelos devem ser desenvolvidos descrevendo a informação, a função e o comportamento do sistema); Os modelos devem ser particionados de modo que revelem detalhes em forma de camadas; O processo de análise deve ir da informação essencial até os detalhes de implementação.

52 Modelo É uma representação em pequena escala de um objeto que se pretende executar ou reproduzir em tamanho natural.

53 Modelos Mapas: modelos bidimensionais do mundo em que vivemos;
Globos: modelos tridimensionais do mundo em que vivemos; Pautas musicais: representações gráficas / textuais das notas musicais; Desenhos arquitetônicos: planta de uma casa, ou edifício, ou ponte...; Fluxograma: representações esquemáticas de decisões e seqüência de atividades para execução de algum procedimento.

54 Por que Construir Modelos
“... podemos construir modelos de maneira a realçar ou enfatizar certos recursos decisivos do sistema, enquanto, simultaneamente, podemos ignorar outros aspectos do sistema. Isto permite que nos comuniquemos com o usuário de uma maneira clara...” Edward Yourdon

55 Tipos de Modelos da Análise Estruturada
Entidade Relacionamento Diagrama de Fluxo de Dados Especificação de Processos Dicionário de Dados

56 Diagrama de Entidade-Relacionamento
Percepção de que o mundo real é formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre estes objetos.

57 Diagrama de Entidade-Relacionamento

58 Diagrama de Fluxo de Dados
Mostram as funções e sub-funções que transformam o fluxo de dados.

59 Diagrama de Fluxo de Dados

60 Especificação de Processos
Fornecem uma indicação de como os dados são transformados.

61 Especificação de Processos

62 Dicionário de Dados É uma listagem organizada, com descrições de todos os elementos de dados pertinentes ao sistema.

63 Dicionário de Dados

64 Vantagens do Uso de Modelos
Fazer uso de ferramentas, facilitando a comunicação com o usuário e a organização das informações; Retirar a redundância do documento gerado (especificação estruturada); Substituir o excesso de texto do documento gerado, por gráficos; Tornar mais fácil o processo de manutenção, após a codificação.

65 Vantagens do Uso de Modelos
Possibilidade de focalizar a atenção nas características importantes do sistema, deixando um pouco de lado as menos importantes; Discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco; Mostrar ao usuário o sistema que será implementado de forma mais clara e objetiva.

66 Objetivos do Uso de Modelos
Descrever o que o cliente deseja; Estabelecer uma base para a criação de um projeto do sistema; Definir um conjunto de requisitos que possa ser validado quando o sistema for construído.

67 Principais Problemas no Desenvolvimento de Sistemas
Para desenvolver sistemas úteis, de alta qualidade e que realmente satisfaçam as necessidades dos utilizadores, é necessário considerar os seguintes aspectos: Produtividade; Confiabilidade; Manutenibilidade; Qualidade; Portabilidade; Segurança.

68 Produtividade

69 Problemas Relacionados à Produtividade
Os dois aspectos mais importantes deste problema são: A demanda reprimida (backlog) por novos sistemas; O tempo necessário para construir um novo sistema.

70 Demanda reprimida Visível: Invisível: Desconhecido:
Solicitados oficialmente pelos utilizadores e que foram aceites e tiveram suas verbas aproveitadas pela gestão. Ainda não foram iniciados por falta de recursos humanos (analistas, programadores, etc.) Invisível: Sistemas que os utilizadores sabem que precisam, mas não se dão ao trabalho de solicitar oficialmente porque ainda estão a aguardar outros projectos Desconhecido: Sistemas que os utilizadores ainda não sabem que precisam mas que emergirão logo que sejam concluídos outros sistemas dos backlogs visível e invisível.

71 Tempo de desenvolvimento
Preocupação com a perda de oportunidades de negócios. Quando o sistema ficar pronto, as condições terão se modificado. Muitos projetos nem são terminados.

72 Motivos do Fracasso em Alguns Projetos de Software
Problemas técnicos Problemas gerenciais Inexperiência da equipe Falta de tempo para análise e projeto Escasso envolvimento por parte da gerência ou usuários

73 Soluções Para Diminuição do Tempo de Desenvolvimento
Contratação de mais profissionais Contratação de profissionais mais talentosos, com melhores condições de trabalho Deixar que usuários desenvolvam seus pequenos sistemas (Ex: planilhas de cálculos) Melhores linguagens de programação Atacar o problema da manutenção Controles de Engenharia de Software Ferramentas automatizadas (Ferramentas CASE)

74 Razões Para a Conscientização dos Analistas Quanto à Produtividade
A produtividade e a qualidade do trabalho dos programadores está diretamente ligada ao serviço feito pelo analista Algumas das técnicas de aumento de produtividade têm importância direta para os analistas A produtividade da análise é um problema politicamente sensível Utilizadores e gestor têm ansiedade pelo início da programação Utilizadores não entendem a importância da especificação

75 Problemas Que o Analista Enfrenta Com os Usuários
“Para que servem todas essas figuras e palavras? Nós já explicamos o que queremos. Para que escreveram tudo isso?” “Quando vocês vão começar a escrever os programas?”

76 Confiabilidade

77 Dificuldades na Detecção de Erros de Sistemas
É difícil descobrir como solucionar o erro; Deve-se encontrar todos os pontos de correção; Alta probabilidade de introduzir novos erros (efeitos colaterais); Nem sempre são reportados pelos utilizadores; Dificuldade de reproduzir o erro.

78 Exemplos de Erros de Software e Suas Implicações
Em 1979, o sistema SAC / NORAD (que significa Strategic Air Command / Defesa Aérea Norte- Americana) registrou 50 alarmes falsos, incluindo um ataque simulado, os resultados ou saídas ocasionaram acidentalmente um combate ao vivo. Um erro de programa em um simulador de vôo de avião F16 o levava a ficar de cabeça para baixo, toda vez que cruzava a linha do Equador. Um míssil de um F18 iniciou sua propulsão quando ainda ligado ao avião e fez a aeronave perder metros de altitude. As portas do sistema de trem BART, controlado por computador, em São Francisco, às vezes aberto no tempo entre as estações.

79 Exemplos de Erros de Software e Suas Implicações
Um sinal de alerta do NORAD, do Sistema de Aviso Rápido de Mísseis Balísticos (BMNEWS), detectou a lua, como um míssil que se aproximava; O índice da bolsa de valores de Vancouver, no Canadá, perdeu 574 pontos no período de 22 meses, devido a um erro de arredondamento de decimais (por exemplo, arredondar 3,14159 para 3,1416); Em 28 de novembro de 1979, um avião da Air New Zealand caiu em uma montanha. As investigações posteriores mostraram que haviam sido detectados e corrigidos um erro nos dados do curso do computador, mas nunca foram reportados para o piloto.

80 Erros Descobertos em Função do Tempo
Inicialmente o nº de erros encontrados é pequeno (utilizadores sem segurança para apontar erros), como indica T1. À medida que os utilizadores se familiarizam com sistema os erros são percebidos e reportados (entre T1 e T2). Após um tempo (após T2) o nº de erros encontrados começa a diminuir (sistema começa a tornar-se mais estável). O número de erros volta a crescer devido a correções ou modificações que introduzem novos erros (após T3). A curva nunca atinge zero.

81 Manutenibilidade

82 Manutenibilidade Modificações no hardware Novos dispositivos
Necessidade de melhorar o desempenho Garantir maior confiabilidade Alterações dos requisitos Principal dificuldade: documentação desatualizada

83 Qualidade

84 Qualidade A qualidade de um sistema pode ser mensurada considerando a eficácia e a eficiência obtidas: Eficácia = Resultados Obtidos / Resultados Pretendidos Eficiência = Resultados Obtidos / Recurso Consumido

85 Problemas Relacionados à Falta de Qualidade do Sistema
Não contribuem para os objetivos da empresa; Não atendem às necessidades dos utilizadores; Não são confiáveis; São ineficientes; Têm manutenção constante, difícil e onerosa.

86 Portabilidade

87 Portabilidade Consiste em escrever sistemas que podem ser transferidos para outras plataformas. Apesar de não ser um problema da alçada do analista, ele deve especificar que há essa necessidade. A portabilidade geralmente provoca ineficiência já que recursos disponíveis de determinada plataforma não são aproveitados.

88 Segurança

89 Segurança A segurança de sistemas de informação consiste basicamente em: Impedir o acesso de pessoas não autorizadas; Conceder acesso a certas funcionalidades apenas a algumas pessoas.

90 Principais Causas dos Problemas Relacionados à Segurança
Ausência de Planeamento de Sistemas; Ausência de Administração de Dados; Não utilização de Métodos e Técnicas Formais de Desenvolvimento; Não utilização de Técnicas e Ferramentas; Adoção de Metodologias não ambientadas à realidade da empresa; Falta de definição precisa dos objetivos e requisitos do sistema; Dificuldade de comunicação e/ou falta de entrosamento entre as pessoas envolvidas no processo; Dificuldade de comunicação entre Utilizadores e Desenvolvedores (linguagem); Rivalidade entre utilizadores; Falta de precisão e clareza na especificação dos sistemas.

91 Ciclo de Vida do Projeto de Sistemas

92 Ciclo de Vida do Projeto
Um ciclo de vida de projeto bem definido oferece mecanismos para planejar e acompanhar atividades de forma mais precisa, possibilitando a detecção de problemas de forma mais rápida. Também conhecido como: Metodologia de Desenvolvimento de Sistemas ou Plano de Projeto.

93 Pequenas Organizações
São relativamente informais; São iniciados após um entendimento verbal entre os usuários e a equipe de projeto; O trabalho de desenvolvimento é feito sem muito alvoroço.

94 Grandes Organizações Tudo é feito de maneira mais formal;
As comunicações entre os usuários, a gerência e a equipe de projeto são documentadas; Todos estão cientes da existência de várias fases; Normalmente o gerente é responsável por definir as fases e atividades do projeto.

95 Objetivos Para o Ciclo de Vida dos Projetos
Definir as atividades a serem executadas no projeto; Participantes têm uma visão do que estão fazendo no projeto. Manter consistência entre projetos de uma mesma organização; Introduzir pontos de verificação para o controle gerencial de decisões; Permite identificar se o projeto está atrasado e como corrigir o problema.

96 Ciclo de Vida Clássico

97

98 Desvantagens do Ciclo de Vida Clássico
Implementação Bottom-Up (de baixo para cima): Nada está terminado até que esteja totalmente pronto. Os erros triviais são encontrados no início do período de teste e os erros mais sérios são encontrados no final. A depuração tende a ser extremamente difícil durante os estágios finais dos testes do sistema. A necessidade de tempo para testes normalmente aumenta exponencialmente durante os estágios finais do projeto.

99 Desvantagens do Ciclo de Vida Clássico
Progressão Sequencial: As fases são seguidas de forma sequencial. As especificações produzidas em cada fase são "congeladas". Os requisitos mudam e é necessário voltar à fase inicial. Erros são encontrados na especificação e devem ser corrigidos.

100 Ciclo de Vida Estruturado

101 Fase 1 - Levantamento Também conhecida como estudo de viabilidade ou estudo inicial das atividades. Normalmente é iniciado quando o usuário solicita que algo seja automatizado. É importante peça para tomada de decisão e no planejamento do sistema.

102 Fase 1 - Levantamento Principais objetivos:
Identificar os usuários responsáveis e desenvolver um "escopo" inicial do sistema: Entrevistas Diagrama de Contexto Diagrama(s) de Fluxo de Dados Identificar as atuais deficiências no ambiente do usuário. Estabelecer metas e objetivos para um novo sistema.

103 Fase 1 - Levantamento Problema que pode ocorrer:
Dificuldade em entender o problema a ser resolvido.

104 Fase 1 - Levantamento Usuários Requisitos do Sistema Charter
Direção Relatório experimental de custo/ benefícios Restrições Charter

105 Fase 2 - Análise Gerar uma especificação estruturada do projeto do sistema a partir do critério do usuário e da previsão do projeto. Isso envolve a modelagem do ambiente do usuário usando as seguintes ferramentas: Diagramas de Fluxo de Dados Diagramas de Entidades-Relacionamentos Diagramas de Transições de Estado Envolve o desenvolvimento de um modelo ambiental e um comportamental.

106 Fase 2 - Análise Usuários Operações Políticas do Usuário
Requisitos do Sistema 1. Levantamento Usuários Direção Relatório experimental de custo/ benefícios Restrições Charter 2. Análise Políticas do Usuário Operações Restrições Relatório de custo/ benefícios Especificação Estruturada

107 Fase 3 - Projeto Alocação de partes da especificação (modelo essencial) aos processadores apropriados (pessoas ou máquinas). Desenvolvimento de uma hierarquia de módulos de programas e interfaces entre esses módulos. Transformação do modelo de dados em um projeto de banco de dados (dependente da tecnologia adotada). Deve ser desenvolvido o modelo de implementação do usuário (fronteira homem- máquina e interface homem-máquina).

108 Fase 3 - Projeto Usuários Operações Políticas do Usuário
Especificação de projeto Políticas do Usuário Requisitos do Sistema Restrições 1. Levantamento 2. Análise Charter Especificação Estruturada Relatório experimental de custo/ benefícios Relatório de custo/ benefícios Restrições Direção

109 Fase 4 - Implementação Codificação e integração dos módulos.
Programação Estruturada e Implementação Top-Down. O sistema vai ficando completo progressivamente.

110 Fase 5 - Geração de testes de Aceitação
Criar os testes de aceitação a partir da especificação estruturada. Pode ser feita paralelamente ao projeto e à implementação.

111 Fases 4 e 5 Especificação Estruturada Especificação de projeto
2. Análise 3. Projeto Especificação Estruturada Especificação de projeto 5. Geração do Teste de Aceitação 4.Implementação Conjunto de teste de controle de qualidade Sistema integrado

112 Fase 6 - Controle de Qualidade
Também chamada de teste final ou teste de aceitação. Exige como entrada os testes de aceitação e um sistema integrado.

113 Fase 7 - Descrição dos Procedimentos
Descrição formal das partes do novo sistema: manuais Descrição de como será a interação com o usuário (parte automatizada).

114 Fases 6 e 7 Especificação Estruturada Manual do Usuário
2.Análise 7. Descrição de Procedimentos Especificação Estruturada Manual do Usuário 5. Geração do Teste de Aceitação 4.Implementação Conjunto de teste de controle de qualidade Sistema integrado 6. Controle de Qualidade Sistema aceito

115 Fase 8 - Conversão do Banco de Dados
Desenvolver programas para converter os dados existentes para o novo banco de dados.

116 Fase 9 - Instalação Passagem imediata x gradual.
Treinamento dos usuários.

117 Fases 8 e 9 Operações Banco de Dados existente
9. Instalação 6.Controle de Qualidade Sistema aceito Sistema instalado 8.Conversão de Banco de Dados Banco de Dados convertido 3.Projeto Especificação de projeto Operações Banco de Dados existente

118 Abordagem Radical X Conservadora do Ciclo de Vida
Abordagem Radical do ciclo de vida: As atividades do projeto são executadas em paralelo (a codificação começa no primeiro dia). Abordagem Conservadora do ciclo de vida: Uma atividade só é iniciada quando a anterior foi concluída. Ambas as abordagens são perigosas pois são os extremos. Podem ser adotadas abordagens intermediárias: Iniciar uma fase quando 75% ou 50% da anterior estiver concluída. Executar duas atividades em paralelo (levantamento e análise).

119 Abordagem Radical X Conservadora do Ciclo de Vida
Para cada projeto, uma abordagem diferente pode ser usada, baseada nos seguintes fatores: Quão inconstante é o usuário? Usuários inconstantes ou inexperientes requerem uma abordagem mais radical. Usuários veteranos se adequam mais a uma abordagem mais conservadora. Pressão para produzir resultados imediatos e palpáveis.

120 Abordagem Radical X Conservadora do Ciclo de Vida
Para cada projeto, uma abordagem diferente pode ser usada, baseada nos seguintes fatores: Pressão sobre o gerente do projeto para produzir um cronograma, um orçamento e avaliação de pessoas e outros recursos: Radical (precoce) -> maior erro. Conservadora -> menor erro. Perigo em cometer um erro técnico (implementação inviável).

121 Ciclo de Vida da Prototipação
Na prototipação cada necessidade levantada é simulada no protótipo, que é expandido e refinado gradualmente. Também conhecido como desenvolvimento heurístico. É uma alternativa atraente para lidar com a incerteza, a ambiguidade e a inconstância dos projetos. No final da modelagem o protótipo será desprezado e substituído por um programa real pois ele é apenas um modelo.

122 Ciclo de Vida da Prototipação
Os prototipadores normalmente utilizam os seguintes tipos de ferramentas: Dicionário de dados integrado. Gerador de tela. Gerador de relatórios não-procedural. Linguagem de programação de quarta geração. Linguagem de consultas não-procedural. Recursos poderosos de gerenciamento de banco de dados.

123 Ciclo de Vida da Prototipação
Projetos que são bons candidatos para a abordagem de prototipação têm as seguintes características: O usuário é incapaz ou não deseja examinar modelos abstratos de papel como DFD's. O usuário é incapaz de exprimir os seus requisitos, podendo identificá-los através de tentativas e erros ("Eu não sei o que quero, mas eu saberei, se o vir"). O sistema está previsto para ser on-line (a maioria das ferramentas de apoio são orientadas para a abordagem on-line).

124 Ciclo de Vida da Prototipação
Não exige a especificação de grandes quantidades de detalhamento algorítmico. O usuário está mais interessado no formato e na diagramação da entrada e da saída.

125 Ciclo de Vida da Prototipação
A abordagem da prototipação pode ser combinada à análise estruturada como uma forma de auxiliar a descoberta/especificação dos requisitos. A abordagem Top-Down pode funcionar como uma forma de prototipação, na qual cada versão contém mais funcionalidades e está mais próxima do desejo do usuário.

126 Ciclo de Vida da Prototipação
O risco em adotar o protótipo com um sistema de produção é grande e pode ser desastroso porque: Não foi preparado para manipular eficientemente grandes volumes de transações. Carece de detalhes operativos como: Recuperação de erros, documentação do usuário, procedimento de conversão. O projeto pode terminar sem que tenha sido produzida qualquer documentação formal, que deveria ser mantida ao longo da vida do sistema.

127 Diagrama de Fluxo de Dados

128 Diagramas de Fluxo de Dados
Principal técnica de modelação funcional Modela o sistema como uma rede de processos funcionais, interligados por dutos e tanques de armazenamento Pode ser usado para descrever processos computadorizados e não computadorizados Também chamado de DFD (abreviatura), Diagrama de Bolhas, Modelo de Processo, Diagrama de Fluxo de Trabalho e Modelo Funcional Um DFD é composto de Processos, Fluxos de Dados, Depósitos de Dados e Entidades Externas

129 Processos Também conhecido como bolha, função ou transformação;
Representam transformações de fluxo(s) de dados de entrada em fluxo(s) de dados de saída; O nome do processo deve descrever o que ele faz; Nome = verbo (infinitivo) + objeto direto; Geralmente provoca mudanças de estrutura, conteúdo ou estado;

130 Processos Representações gráficas possíveis:

131 Fluxo de Dados Representam caminhos por onde passam os dados;
São representados através de setas que indicam o destino do dado Têm nomes que devem constar no dicionário de dados; Um mesmo fragmento de dados pode ter significados diferentes em pontos distintos de um DFD (CPF-Válido e CPF-Inválido); Um fluxo apenas não modifica os dados durante o transporte;

132 Fluxo de Dados Transportam dados entre os elementos do DFD:
Processo ⇔ Processo Entidade Externa ⇔ Processo Depósito de Dados ⇔ Processo

133 Fluxo de Dados Tipos de fluxos: Nomenclatura:
Fluxo externo: entre Entidade Externa e Processo Fluxo interno: entre dois Processos Fluxo de acesso à memória: entre Processo e Depósito Fluxo de erro ou rejeição: para fora de um Processo Nomenclatura: Cada fluxo deve ter um único nome; O nome deve identificar os dados transportados pelo fluxo; Exemplos: Dados-Fatura, Recibo-Pagamento, Dados-Cliente.

134 Fluxo de Dados Representação gráfica: Dados Pessoais

135 Depósito de Dados Representa uma coleção de pacotes de dados em repouso; Nem sempre um depósito de dados é um arquivo ou SGBD. Pode representar microfilmes, pastas de arquivos em papel e diversas outras formas não computadorizadas; Nomenclatura: Deve estar no plural Pode receber o nome do fluxo de dados (no plural)

136 Depósito de Dados Representações gráficas de um depósito de dados:

137 Entidade Externa Também chamados de Terminadores;
Uma FONTE ou DESTINO uma pessoa, ou empresa, ou departamento, existente fora do contexto do sistema, que é o originador ou o receptor de dados do sistema; São as fontes/destinatários das informações que entram/saem do sistema; Os procedimentos executados pelas entidades externas não são especificados no modelo por não fazerem parte do sistema;

138 Entidade Externa Normalmente é uma pessoa, um grupo de pessoas, uma organização externa, um setor dentro de uma empresa; Pode representar um outro sistema; Nomenclatura: No plural quando se referir a um grupo de pessoas (Clientes); Deve conter o nome do setor ou entidade externa (Diretoria de Negócios); Deve ser incluída a palavra sistema quando se tratar de um sistema (Sistema de Contabilidade).

139 Entidade Externa Representação gráfica de uma Entidade Externa:

140 Exemplos de DFD

141 Exemplos de DFD

142

143 Diretrizes Para a Elaboração de DFDs
Escolher Nomes Significativos Evitar nomes para processos como: Fazer serviço, Manipular entrada, Cuidar dos clientes e Processar dados. Devem-se numerar os Processos A numeração tem basicamente duas utilidades: Permitir localizar os processos no diagrama facilmente Facilita a identificação, a partir dos diagramas mais detalhados, do processo que foi expandido Não importa a maneira desde que seja consistente A numeração não indica sequência pois o DFD é uma rede de processos assíncronos que se intercomunicam

144 Diretrizes Para a Elaboração de DFDs
Evitar DFD Complexos Evitar colocar elementos demais no digrama; Deve caber facilmente numa página; O DFD deve modelar corretamente as funções que um sistema deve executar e as interações entre elas; Deve ser lido e entendido facilmente pelos utilizadores. Refazer tantas vezes quantas forem necessárias Um DFD deve ser refeito até que: Esteja tecnicamente correto; Aceitável pelo utilizador; O Analista não tenha vergonha de apresentá-lo à diretoria.

145 Diretrizes Para a Elaboração de DFDs
Certificar-se de que o DFD seja logicamente consistente: Evitar "poços sem fundo" (processos que só recebem entradas); Evitar processos com geração espontânea (processos que não recebem entrada mas produzem saídas); Cuidado com fluxos e processos sem rótulos; Cuidado com depósitos que tenham somente leitura ou escrita. Posição dos elementos O processo origem deve ficar à esquerda ou acima do processo destino; As entidades externas devem ser desenhadas nas bordas do desenho: As de entrada, à esquerda ou acima; As de saída, à direita ou abaixo; Os depósitos de dados devem ser distribuídos no meio do desenho, entre os processos.

146 Diretrizes Para a Elaboração de DFDs
Duplicação de elementos: Pode-se duplicar Entidades e Depósitos para evitar cruzamento de fluxos e melhorar a organização do diagrama Um mesmo fluxo de dados pode aparecer mais de uma vez no mesmo DFD Não faz sentido duplicar processos

147 Exemplo de DFD A Pousada Rivotril deseja cria um sistema online de reservas de quartos. Durante a análise alguns aspectos foram levantados: O cliente deverá fazer o seu cadastro no site, para que possa efetuar a reserva; O cliente, após se cadastrar no site, pode solicitar a reserva. O Sistema verifica a disponibilidade de quarto e em caso positivo, efetua a reserva do quarto, salva os dados da reserva e envia uma confirmação para o cliente. O funcionário da Pousada pode consultar as reservas e efetuar o cancelamento de uma reserva se necessário.

148 Exemplo de DFD