Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014 Material criado por Prof. Edinelson Revisão e atualização: Prof. Gustavo Gonzalez Faculdade.

Apresentação em tema: "Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014 Material criado por Prof. Edinelson Revisão e atualização: Prof. Gustavo Gonzalez Faculdade."— Transcrição da apresentação:

1 Análise e Projeto de Sistemas de Informação 2o. Semestre de 2014 Material criado por Prof. Edinelson Revisão e atualização: Prof. Gustavo Gonzalez Faculdade Salesiana Dom Bosco de Piracicaba Curso Sistemas de Informação

2 O papel do Analista Aumentar a eficiência e qualidade dos fluxos de informações que fluem entre os vários processos; Otimizar e racionalizar tais processos Sistemas de Informações conjuntos de processos e informações inter-relacionadas com o objetivo de possibilitar tomada de decisões

3 O papel do Analista Utilizar modernas técnicas para a construção de modelos, dos processos e dados da área alvo Analisar o comportamento dos sistemas existentes e propor soluções Criar métodos para padronização e/ou automação das atividades Planejar, analisar, projetar, programar e manter aplicações computacionais

4 Atividades do Analista Dialogar com o Usuário/Especialista Escolher: Modelo de desenvolvimento (ciclo de vida) Padrões de documentação, codificação, verificação e testes Ambientes de desenvolvimento e/ou linguagens de programação adequadas Métodos para medir e reportar o progresso do desenvolvimento

5 Atividades do Analista Organizar e coordenar as equipes de desenvolvimento de software Indicar e/ou comprar hardware e ferramentas de software necessários ao projeto Avaliar a viabilidade do produto e de seu desenvolvimento Efetuar a estimativa de custos, riscos e preço do produto

6 Habilidades do Analista de Sistemas Capacidade para compreender conceitos abstratos, reorganizar esses conceitos em divisões lógicas e sintetizar "soluções“ baseado em cada divisão. Capacidade de absorver fatos pertinentes a partir de fontes conflitantes ou confusas. Capacidade de se comunicar bem de forma escrita e verbal. Capacidade de "ver a floresta ao invés das árvores”

7 1. Seja aceito profissionalmente, do nível mais alto ao mais baixo da empresa. 2. Tente entender o que o usuário “quer dizer” e não o que “você pensa” que ele quer dizer 3. Escute primeiro, depois fale! (desenvolva grandes orelhas e boca pequena!) Os mandamentos para ser um bom Analista de Sistemas

8 4. Familiarize-se com os últimos progressos da tecnologia de informação e compreenda como aplicá-los na sua empresa 5. Seja capaz de explicar conceitos complexos em termos simplificados Os mandamentos para ser um bom Analista de Sistemas

9 6. Não se esconda em jargão da informática; fale a linguagem da empresa. 7. Utilize os princípios básicos da qualidade, seja em produtos ou serviços. Os mandamentos para ser um bom Analista de Sistemas

10 8. Conheça a área de negócio, passando boa parte de seu tempo com o usuário. 9. Sugira soluções inovadoras aos requisitos de informação e desenvolva com clareza, analisando sempre a relação custo/benefício, utilzando alternativas viáveis. Os mandamentos para ser um bom Analista de Sistemas

11 10. Especialize-se em sistemas de informação, arquitetura de dados e ferramentas de processo de informação, e não em tecnologia da informação Os mandamentos para ser um bom Analista de Sistemas

12 Um analista de sistemas deve ser uma combinação entre um jornalista, um auditor, um consultor, um padre, um psicólogo e um bom diplomata.

13 Participantes do Desenvolvimento de Sistemas “Ao iniciarmos um projeto de desenvolvimento de sistemas é extremamente importante conhecermos um pouco das características das pessoas que iremos interagir.”

14 Participantes Os analistas de sistemas envolvem-se com uma grande quantidade e diversidade de pessoas: Usuários Gerentes Auditores, controladores e padronizadores Analistas de Sistemas Projetistas de Sistemas Programadores Pessoal Operativo

15 USUÁRIOS Usuários: Pessoa ou grupo de pessoas para que o sistema é construído Geralmente são classificados por:  Por tipo de função;  Por nível de experiência com PD;

16 Usuário por tipo de função Usuários Operativos  Geralmente tem visão local;  Executam a função do sistema;  Preocupam-se com os recursos físicos do sistema;

17 Usuário por tipo de função Usuários Supervisores  Podem ou não ter visão local;  Normalmente conhecem a operação;  Orientados por considerações orçamentárias;  Agem como intermediários entre usuários e analistas de sistemas;

18 Usuário por tipo de função Usuários Executivos  Tem visão global;  Tem iniciativas sobre o projeto;  Não tem experiência operativa;  Tem preocupações estratégicas;

19 Usuário por nível de experiência Usuário amador Geralmente fala que “Não entende nada de computador” Não procura entender a terminologia do PD, dificultando a aceitação do sistema;

20 Usuário por nível de experiência Usuários “Novato arrogante” Já participou de projetos de sistemas; As vezes já escreveu algum programa; Tomar cuidado para não perder o foco do principal objetivo do projeto = Sistema Eficaz;

21 Usuários - Resumo Em resumo suas características principais são descritas abaixo: Usuário Operativo Usuário SupervisorUsuário Executivo Normalmente tem visão local Pode ou não ter visão local Tem visão global Executa a função do sistema Normalmente conhece a operação Tem iniciativa sobre o projeto Tem visão física do sistema Orientado por considerações orçamentárias Não tem experiência operativa Muitas vezes age como intermediário entre os usuários e os níveis mais elevados da direção Tem preocupações estratégicas

22 Gerências Gerente Usuários => Usuários supervisores Gerentes de PD/SIG => Encarregados de desenvolvimento de sistemas, preocupam-se com o gerenciamento local e alocação de recursos da equipe técnica. Gerentes gerais => Não estão diretamente envolvidos nos projetos – Presidentes, vice-presidentes… Geralmente a interação entre analista de sistema e gerência tem a ver com os recursos destinados ao projeto.

23 Auditores  Preocupam-se em garantir que os sistemas sejam desenvolvidos dentro de padrões externos;  Geralmente não se envolvem diretamente no processo de desenvolvimento do projeto;  Faz-se necessário explicar a documentação adotada pelos analistas de sistemas;  Auditores pós implementação: garantir que o sistema faça aquilo especificado.

24 Analista de Sistemas Arqueólogos e escriba: Visualizar detalhes e documentar as orientações comerciais; Inovador: Auxiliar o usuário a explorar novas e úteis aplicações de PD; Mediador: Obter consenso entre a equipe, usuários, gerentes, programadores; Líder de projeto: Habilidade com pessoas;

25 Projetistas de Sistemas Responsáveis pela modelagem e elaboração das ferramentas usadas na metodologia.

26 Programadores Responsáveis pela codificação das especificações dos programas.

27 Pessoal de Operações Responsáveis pelo centro de processamento de dados, operação dos sitemas, Redes, Segurança do hardware…

28 Ciclo de Vida Seqüência e Interação em que as atividades de desenvolvimento de sistemas são executadas, envolvendo todos os passos desde a concepção do sistema até sua implementação.

29 Modelo de ciclo de vida O envolvimento de uma fase com a outra é conhecido por ciclo de vida do sistema.

30 Ciclo de vida – cont. Define as atividades a serem executadas; Introduz consistência entre muitos projetos; Introduz pontos de verificação para controle dos projetos;

31 Ciclo de vida Clássico Chamado de clássico, cascata ou linear por possuir tendência na progressão seqüencial entre uma fase e a seguinte.

32 Problemas do ciclo de vida clássico Os projeto raramente seguem o fluxo sequencial proposto modelo; Dificuldades para o usuário definir requisitos de sistema de uma só vez; Os primeiros resultados são obtidos em fases avançadas do processo, podendo inviabilizar alguma possível alteração;

33 Ciclo de Vida do Sistema Incremental e Interativo:

34 Início Fim Coleta e refinamento dos requisitos Projeto rápido Construção do protótipo Avaliação do protótipo pelo cliente Refinamento do protótipo Engenharia do produto Ciclo de Vida Prototipação

35 Abordagem alternativa para a definição de requisitos, obtendo um conjunto inicial de necessidades e implementado-as rapidamente.

36 Ciclo de Vida do Modelo Espiral Planejamento Análise de riscos Engenharia Avaliação pelo cliente Análise de riscos baseada nos requisitos iniciais Decisão de prosseguir ou não prosseguir Protótipo de software inicial Protótipo no nível seguinte Sistema construído pela engenharia Avaliação pelo cliente Coleta inicial dos requisitos e planejamento do projeto Planejamento baseado nos comentários do cliente Análise de riscos baseada na reação do cliente