Faculdade Salesiana Dom Bosco de Piracicaba
Curso Sistemas de Informação
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
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
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
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
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
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”
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.
Tente entender 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






um
um
um
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

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
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

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

Chamado de clássico,
cascata ou linear por
possuir tendência na
progressão seqüencial
entre uma fase e a
seguinte.
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;
Ciclo de Vida do Sistema

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
Planejamento baseado nos
comentários do cliente
Análise de riscos
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