A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Revisão e Exercícios APS – 1º Bimestre 2010.

Apresentações semelhantes


Apresentação em tema: "Revisão e Exercícios APS – 1º Bimestre 2010."— Transcrição da apresentação:

1 Revisão e Exercícios APS – 1º Bimestre 2010

2 Análise Análise (análysis, "dissolução") é o processo de decomposição de uma substância ou tópico complexo em seus diversos elementos constituintes, a fim de se obter uma melhor compreensão sua.

3 Análise de sistemas O processo de informatização (criação de sistemas de informação) dentro de uma empresa ou qualquer outro tipo de organização, traz inúmeras implicações, que vão desde mudanças nas rotinas de trabalho até reestruturações organizacionais, com toda a problemática que daí, invariavelmente, decorre.

4 Análise A tarefa de construir estes sistemas de informação é uma das mais complexas e, em ultima análise, é um processo de solução de problemas.

5 Analista A principal tarefa de um Analista de Sistemas é descobrir o que um sistema deverá fazer. Ao conjunto de necessidades a serem atendidas, usualmente, chama-se de requisitos do sistema.

6 O que um Sistema? “Conjunto de partes coordenadas, que concorrem para a realização de um conjunto de objetivos” (DIAS & GAZZANEO, 1989).

7 Sistema: definição “Um sistema é um conjunto de objetos unidos por alguma forma de interação ou interdependência” (CHIAVENATO, 1983).

8 Sistema “Conjunto de elementos, entre os quais haja alguma relação. Disposição das partes ou elementos de um todo, coordenados entre si, e que formam uma estrutura organizada” (FERREIRA, 1988).

9 Sistema Portanto, um sistema é um conjunto de entidades relacionadas, que interagem entre si, buscando atingir um objetivo declarado e outros correlatos. Alunos Disciplinas

10 Sistemas Abertos Todos os sistemas conhecidos até o momento, possuem alguma interação com o seu meio ambiente (trocam algo com o seu meio – recebem – enviam), sendo portanto, conhecidos como sistemas abertos.

11 Sistemas Fechados Os sistemas fechados, no rigor de sua definição, não foram até o momento observados, portanto, existem apenas em teoria (por enquanto). Um sistema fechado é aquele que existe sem qualquer tipo de interação com seu meio ambiente, é totalmente auto-suficiente; jamais, em momento algum, precisa de algo que esteja fora dele.

12 A análise de sistemas Consiste nos métodos e técnicas de investigação e especificação da solução de problemas, a partir dos requisitos levantados, para criação e implementação de software em algum meio que o suporte.

13 Exercício em Grupo Considere que estamos propondo uma solução para um sistema de comércio eletrônico para uma pequena loja de artigos esportivos. Que etapas seguiria para iniciar a formulação da proposta? Organize hierarquicamente algumas ações para a apresentação do projeto.

14 Exemplos de Ações Dimensionar hardware (memória, discos, processadores , etc.) Especificar a estrutura de rede Definir linguagem de programação utilizada Ferramentas de modelagem Ferramentas de controle de versão do código fonte Entrevistar os usuários Entrevistar os gerentes e diretores Rascunhar projeto das telas do sistema SO (qual distribuição escolhida) Serviços disponíveis Escrever código do sistema Implementar BD Tente justificar/argumentar junto a gerência de TI suas escolhas.

15 Plano de Ação ( Ciclo de Vida)
Fase I Análise de Requisitos Entrevistar os usuários Entrevistar os gerentes e diretores Definir entradas, relatórios e consultas Reunir e organizar todas as informações Projeto Elaborar projeto utilizando Ferramentas de modelagem Discutir com equipe e coordenação a proposta Definir e iniciar a construção da pasta de documentação Desenvolvimento/Implementação Implementar modelos criados utilizando Linguagem adequada ao cenário proposto Ferramentas de controle de versão do código fonte Rascunhar projeto das telas do sistema Escrever código fonte respeitando os padrões de documentação Implementar interfaces Implementar relatórios e consultas

16 Plano de Ação Fase II Testes Manutenção corretiva Repetir Testes
Utilizar metodologia de testes para localização de possíveis falhas Registrar falhas adaptando correções possíveis Manutenção corretiva Implementar correções Repetir Testes Implementar correções possíveis

17 Plano de Ação Fase III Implantação Treinamento Manutenção
Especificar a estrutura de rede Especificar requisitos de software hardware SO (qual distribuição escolhida) Serviços disponíveis Requisitos para Servidor Requisitos para Cliente Treinamento Elaborar manuais e tutoriais Desenvolver e aplicar programa de treinamento para usuários e administradores Disponibilizar canal de comunicação para sugestões, alterações e reclamações. Manutenção Verificar ocorrências , analisar e implementar correções melhorias ( Fase II )

18 Papel do Analista Outros profissionais de informática,
Ele tem de ser capaz de lidar, ao mesmo tempo, com: Usuários, Outros profissionais de informática, Administração (gerentes/diretores). Cada qual trazendo formações, pontos de vista, vivências e experiências totalmente distintas.

19 Papel do Analista

20 Papel do Analista Os usuários (as pessoas) geralmente desejam:
Dinamizar seu processo de trabalho; Torná-lo automático e rápido; Ter seu esforço reconhecido pela administração ( transparência nos resultados); Aumentar a confiabilidade de resultados. Porém: Ainda existe o medo/resistência à mudança; Alguns podem tentar obstruir o trabalho do Analista de Sistemas.

21 Papel do Analista O pessoal técnico deve manter e cuidar:
Aspectos de performance; Aspectos físicos como bits, bytes, estruturas de dados; Técnicas de programação ; Topologia de hardware; Disponibilidade de recursos.

22 Papel do Analista A administração: Retorno sobre o investimento;
Relação custo/benefício; Prazos monitorando a execução das tarefas.

23 Papel do Analista Este contexto, de diversidade de interesses, faz com que o Analista de Sistemas, busque os requisitos apresentados a seguir:

24 Papel do Analista Algumas diretrizes de conduta:
Procure ser aceito profissionalmente, do nível mais alto ao mais baixo da empresa; Tente entender o que o usuário “quer dizer” e não o que “você pensa” que ele quer dizer; Escute muito primeiro, fale muito pouco depois! Esteja sempre familiarizado com os últimos progressos da tecnologia de informação e compreenda como aplicá-los; Seja capaz de explicar conceitos complexos em termos simplificados.

25 Papel do Analista Não se esconda em jargão da informática;
Fale a linguagem da empresa; Conheça a área de negócio para a qual desenvolverá sistemas, passando boa parte de seu tempo com o usuário.

26 Papel do Analista Sugira soluções inovadoras aos requisitos de informação e desenvolva com clareza, analisando sempre a relação custo / benefício, utilizando alternativas viáveis.

27 Análise Estruturada

28 Introdução Análise: Estrutura: Exame de cada parte de um todo.
Objetivo de conhecer a natureza do problema e as funções que este venha a executar. Estrutura: Reunião das partes ou elementos. O modo como as partes se relacionam dá ao sistema características próprias.

29 Definição - AE Análise estruturada é uma atividade de construção de modelos. Utiliza uma notação que é própria ao método de análise estruturada para com a finalidade de retratar o fluxo e o conteúdo das informações utilizadas pelo sistema, dividir o sistema em partições funcionais e comportamentais e descrever a essência daquilo que será construído.

30 A analise estruturada é :
Conjunto de técnicas e ferramentas cujo objetivo é auxiliar na análise e definição de sistemas Conceito fundamental  construção de um modelo do sistema utilizando técnicas gráficas A metodologia envolve a construção “top- down” do sistema por refinamentos sucessivos

31 A análise estruturada objetiva:
Facilitar a comunicação entre o usuário, analistas e projetistas; Criar um modelo móvel; Produzir uma especificação de sistema rotativa e melhorada; Resolver dificuldades etapa por etapa.

32 Especificando Foi projetada para ser compatível com o projeto estruturado e fornecer a melhor entrada possível para ele. Utiliza uma notação própria. Não é um método único aplicado constantemente por todos que a usam. Foi e ainda é um método de modelagem de requisitos amplamente usado.

33 O Analista Traços característicos:
Capacidade de compreender conceitos abstratos, reorganizá-los em divisões lógicas e sintetizar "soluções" baseadas em cada divisão. Capacidade de absorver fatos pertinentes de fontes conflitantes ou confusas. Capacidade de entender os ambientes do usuário/cliente.

34 O analista serve de intermediário entre a comunidade de usuários e a comunidade de programadores
Comunica-se com o usuário/cliente a fim de conhecer as características do ambiente existente. Convoca o pessoal de desenvolvimento durante as tarefas de avaliação e síntese, de forma que as características do software sejam corretamente definidas. O analista geralmente é o responsável pelo desenvolvimento de uma Especificação de Requisitos de Software  e participa de todas as revisões.

35 Entrevistas O analista procede diversas entrevistas com usuários, gerentes, programadores que fazem a manutenção de um sistema já existente, entre outras pessoas. Motivos: ● Necessidade de coletar informações sobre o comportamento de um sistema atual ou sobre requisitos de um novo sistema; ● Necessidade de verificar a própria compreensão, como analista de sistemas, do comportamento de um sistema atual ou dos requisitos de um novo sistema. ● Necessidade de coletar informações sobre o sistema atual para execução de estudos de custo-benefício.

36 Problemas fundamentais
Apesar de parecer um processo simples, muitos problemas podem ocorrer em uma entrevista. Em muitos projetos de alta tecnologia, a maioria dos problemas difíceis não envolvem hardware ou software, mas sim o “peopleware”, ou seja, as pessoas. É bom lembrar que as técnicas de análise estruturada de sistemas estão em constante evolução, e portanto o futuro analista de sistemas não deve decorá-las, mas entender a filosofia de trabalho.

37 Problemas fundamentais
O analista acha difícil aprender o bastante sobre a empresa para conseguir determinar os requisitos do sistema através dos olhos do usuário. Os usuários ainda não conhecem o suficiente sobre PD para saberem o que é, ou não viável. Em geral, a propaganda a respeito de TI não proporciona às pessoas idéias específicas ou precisas sobre o que tal tecnologia pode ou não acrescentar em seu trabalho.

38 Problemas fundamentais
O documento que define os detalhes de um novo sistema (projeto geral) forma um contrato entre o usuário e a equipe de desenvolvimento. Apesar de muitas vezes ser impossível aos usuários entenderem, por causa de seu tamanho e dos conceitos técnicos associados a ele. Se o documento da especificação for escrito de forma que os usuários entendam, poderá não ser muito útil para os projetistas e programadores que irão construir o sistema. Ele deve ser escrito de forma que os usuários entendam e que seja útil à equipe de desenvolvimento.

39 Fluxograma O Diagrama de Fluxo de Dados (DFD) utiliza do Fluxograma para modelagem e documentação de sistemas computacionais. Não há como mostrar um modelo concreto e claro do sistema para os usuários, até que ele esteja pronto.

40 Diagrama de Fluxo de Dados Lógicos (D.F.D.)
É uma representação em rede dos processos de um sistema e os dados que ligam estes processos. Um DFD é uma ferramenta de modelagem que nos permite imaginar um sistema como uma rede de processos funcionais, interligados por “dutos e “tanques” de armazenamento de dados”.(Edward Yourdon).

41 Diagrama de Fluxo de Dados Lógicos (D.F.D.)
O DFD mostra o que um sistema/procedimento faz, mas não de que forma faz. É a ferramenta mais usada para documentar a fase de análise do convencional ciclo de desenvolvimento de sistemas de informação.

42 Um D.F.D. representa: Imagem do sistema, projeto ou produto;
Modelo de organização; Apresentação em etapas com aumento gradativo de detalhes; Utilização dos princípios da modularização e da hierarquização.

43 Níveis de D.F.D. Podemos ter diversos níveis de D.F.D. de forma a representar o fluxo de dados da aplicação, dentre eles: D.F.D. nível 0; D.F.D. nível 1.

44 Simbologia do D.F.D. A seguir, temos as simbologias usadas na representação DFD Entidades Externas; Fluxo de Dados; Processos; Depósito de dados.

45 Entidade externa Processo Depósito de dados Fluxo de dados 1

46 Simbologia do D.F.D.

47 Características da Técnica de Análise Estruturada de Sistemas
A análise estruturada de sistemas é uma técnica que consiste em construir, graficamente, um modelo lógico para o sistema de informações gerenciais, a qual permite que usuários e analistas de sistemas, encontrem uma solução clara e única para o sistema, de modo que este transmita as reais necessidades dos usuários.

48 Entidades externas Geralmente, são classes lógicas, de atividades e/ou pessoa que interagem com o sistema sendo fontes ou destinos das informações. X- letra pra identificação NOME- Nome da entidade: Ex.: clientes, banco, etc. nome X

49 Fluxo de dados São o meio por onde os dados e as informações trafegam;
NOME-nome do dado. Ex.:Pedido, nota fiscal, etc. ARG- argumento de acesso a um depósito. Ex: CPF,CEP,código, matrícula, etc.

50 Processos São as várias atividades realizadas no sistema. São representados graficamente por um retângulo de bordas arredondadas, opcionalmente dividido em três áreas. Nos processos têm-se as seguintes atividades : Identificação; Descrição; Localização Física.

51 Depósito de dados São os “armazéns” que guardam dados e informações entre os vários processos; são representados graficamente por um par de linhas paralelas, fechadas apenas de um lado por duas outras linhas, formando, portanto, um pequeno quadrado do lado esquerdo.

52 Bibliografia BIBLIOGRAFIA BÁSICA
1. DEMARCO, T., Análise Estruturada E Especificação De Sistemas, Editora Campus 2. YOURDON, E. Análise Estruturada Moderna. Editora Campus, 1990 3. MCMENAMIN P. Análise essencial de sistemas. Makron 1990 BIBLIOGRAFIA COMPLEMENTAR 1. FOURNIER R. Guia Prático para o Desenvolvimento de Sistemas Estruturados. Makron, 1994 2. GANE C. Desenvolvimento Rápido de Sistemas. LTC, 1992 3. POMPILHO, S., Análise Essencial: Guia Prático de Análise de Sistemas, Ibpi Press 4. DEMARCO, T., Controle De Projeto De Software, Editora Campus 5. PRESSMANN, R. S., Engenharia de Software, Makron Books

53 Exercícios Defina: sistema, sistemas abertos e sistemas fechados.
O que é análise de sistemas? Qual o papel do analista de sistemas? Qual a sequência e quais as ações necessárias para implementação do sistema. O que entende por análise estruturada? Quais os objetivos ? O que é um DFD? Quais os elementos componentes de um DFD? Explique sucintamente a função de cada um destes elementos.

54 Exercício – Discussão de Tema
De acordo com sua experiência, indique pelo menos 3 características pessoais exigidas para o analista de sistemas e determine qual sua principal função dentro de uma organização.

55 Exercício Considere que estamos propondo uma solução para um sistema de comércio eletrônico para uma pequena loja de artigos esportivos. Que etapas seguiria para iniciar a formulação da proposta? Organize hierarquicamente algumas ações para a apresentação do projeto.


Carregar ppt "Revisão e Exercícios APS – 1º Bimestre 2010."

Apresentações semelhantes


Anúncios Google