Faculdade Salesiana Dom Bosco de Piracicaba Curso Sistemas

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

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

O papel do Analista n n 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

Atividades do Analista n n Dialogar com o Usuário/Especialista Escolher: n n 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

Atividades do Analista n n 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

Habilidades do Analista de Sistemas n n 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”

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

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

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

Os mandamentos para ser um bom Analista de Sistemas 8. 9. Conheça a área de negócio, passando boa parte de seu tempo com o usuário. 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 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 Um analista de sistemas deve ser uma combinação entre n n n um um um jornalista, auditor, consultor, padre, psicólogo e bom diplomata.

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. ”

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

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;

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;

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; Ø

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;

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; ü

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; ü

Usuários - Resumo Em resumo suas características principais são descritas abaixo: Usuário Operativo Usuário Supervisor Usuá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

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.

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. Ø

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;

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

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

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

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.

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

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

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

Problemas do ciclo de vida clássico n n n 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;

Ciclo de Vida do Sistema n Incremental e Interativo:

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

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

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