O documento discute as vantagens da aplicação de metodologias de análise e projeto de sistemas de informação, incluindo a padronização de técnicas e ferramentas, facilitando a integração entre equipes. Também aborda conceitos como ciclo de vida de projetos, diferenças entre análise e projeto, e participantes do desenvolvimento de sistemas, como usuários e analistas.

1. Análise e Projeto de Sistemas
de Informação
Material criado por: Prof. Edinelson
Revisão e atualização: Prof. Sergio Luiz da Silveira

3. Vantagens da aplicação
de uma
Metodologia
De
Análise e Projeto de Sistemas

4. Vantagens
Padronização de
técnicas, ferramentas e
métodos para que toda a
organização "fale a mesma
língua".

5. Existe uma padronização da
forma de trabalho em toda a
organização, e uma adesão às
técnicas, ferramentas e
métodos propostos.
Vantagens

6. Como consequência, torna-se
mais fácil a integração interna
entre as equipes e com outras
áreas da empresa, além de
facilitar a tarefa de manutenção
dos sistemas em produção.
Vantagens

7. O que é um projeto?

8. O QUE É UM PROJETO?
Quais são os pilares
que garantem um projeto
executado com sucesso?
 Objetivo
 Metodologia
 Controle

9. A palavra projeto tem
origem no latim “projectu”
que significa “lançado para
diante”.
É uma tarefa ou conjunto de
ações com objetivo comum.
O QUE É UM PROJETO?

10. Diversos tipos de projetos:
Projeto de lei;
Projetos de engenharia;
Projetos paisagístico, etc.
O QUE É UM PROJETO?

11. O trabalho em equipe é a
essência do projeto.
O gerente tem como meta
controlar e garantir que a
ideia principal seja cumprida e
evitar distorções.
O QUE É UM PROJETO?

12. Exemplo de projeto:
Objetivo: publicar um livro
Metodologia: editora fornece uma
série de regras (fontes,
espaçamentos...)
Controle: enviar de tempos em
tempos as novas páginas para ser
verificado se as regras estão sendo
cumpridas.
O QUE É UM PROJETO?

13. Ciclo de Vida de um Projeto
Três grandes fases:
 O início;
 A maturidade;
 A conclusão.

14. Ciclo de Vida de um Projeto
Sem o apoio de uma metodologia,
a equipe de desenvolvimento terá
sempre a tendência de cair nos
mesmos erros de projetos anteriores.
As fases inicial e final de qualquer
projeto são repletos de dificuldades e
situações delicadas.

15. Ciclo de Vida de um Projeto
 No início as atividades e os recursos
não estão bem definidos;
 No final também existirão situações
críticas, pois quase sempre não é
formalizado o final do projeto;
 As pessoas não sabem se o projeto
realmente acabou.

16. 1. No prazo e orçamento
previstos;
Pode-se considerar um
projeto bem sucedido aquele que
foi desenvolvido/realizado.
2. Dentro das especificações
técnicas e qualidade previstas;

17. 3. Cliente/usuário satisfeito com o
produto/serviço recebido;
Pode-se considerar um
projeto bem sucedido aquele que
foi desenvolvido/realizado.
4. Produto/serviço obtido é usado
em sua totalidade.

18. O QUE É ANÁLISE?

19. ANÁLISE
 A análise enfatiza a investigação do
problema;
 O objetivo da análise é levar o analista
a investigar e a descobrir;
 Para que esta etapa seja realizada em
menos tempo e de forma mais precisa,
deve-se ter um bom método de
trabalho.

20.  Pode-se dizer que o resultado da
análise é o enunciado do problema,
e que o projeto será a sua
resolução;
 Problemas mal enunciados podem até
ser resolvidos, mas a solução não
corresponderá às expectativas.
ANÁLISE

21.  A qualidade do processo de análise é
importante porque um erro de
concepção resolvido na fase de análise
tem um custo;
 Na fase de projeto tem um custo maior;
 Na fase de implementação maior ainda;
 E na fase de implantação do sistema
tem um custo relativamente
astronômico.
ANÁLISE

22.  Estuda um problema com o
propósito de modelar um
sistema para que ele possa ser
entendido.
 Você deve conhecer todo o
sistema o qual irá interagir.
O QUE É ANÁLISE?

23.  A fase de projeto enfatiza a
proposta de uma solução
que atenda os requisitos da
análise.
PROJETO

24.  Então, se a análise é uma
investigação para tentar
descobrir o que o cliente quer,
o projeto consiste em
propor uma solução com
base no conhecimento
adquirido na análise.
PROJETO

25. POR QUE FAZER ANÁLISE E
PROJETO?
 Diagramas são figuras bonitas e o
usuário quer o software
executando corretamente!
 Por que perder o tempo projetando
se podemos começar logo a
programar?

26.  Gerenciamento da complexidade;
 Comunicação entre as pessoas envolvidas;
 Redução dos custos no desenvolvimento;
 Predição do comportamento futuro do
sistema.
POR QUE FAZER ANÁLISE E
PROJETO?

27.  Entender o que o usuário
realmente quer ou necessita
para resolver um problema.
POR QUE FAZER ANÁLISE?

28. Diferenças entre análise e projeto
Tem mais do que uma definição
empregada.
 Primeira Alternativa:
1) A análise modela o problema e consiste das
atividades necessárias para entender o
domínio do problema (o que deve ser feito). É
uma atividade de investigação.
2) O projeto modela a solução e consiste das
atividades de criação (como pode ser feito)

29.  Segunda Alternativa
1. A análise consiste de todas as atividades feitas
com ou para o conhecimento do cliente. A
informação produzida é aquela que o cliente
deve discutir e aprovar;
2. O projeto inclui as atividades que resultam em
informação que interessa apenas ao
programador.
Diferenças entre análise e projeto

30.  Com essa definição, a análise
invade um pouco o “lado da
solução”, pois o cliente deve
discutir alguns tipos de
interações que ocorrerão na
interface do usuário, etc.
Diferenças entre análise e projeto

31.  Os projetos de desenvolvimento de
software apresentam um desafio
diferente comparado à maioria dos
outros tipos de projetos como projetos
de engenharia ou manufatura.
 Nesses casos, quase sempre se conhece
a priori todos os requisitos claramente.
PROJETO

32.  Além disso, projetos deste tipo possuem
as seguintes características:
 Não são sujeitos a frequentes mudanças;
 É bastante raro que, quando uma parte do
produto apresente algum tipo
funcionamento inadequado, ocorram efeitos
colaterais em outros pontos do produto que
sejam de difícil diagnóstico.
PROJETO

33.  Esse não é o caso na grande maioria
dos projetos de software, embora
muitos tentem aproximar a indústria
de software à da construção civil ou às
indústrias de manufatura.
 Hoje existem as "fábricas de
software"! A crença tem sido de que a
construção de software é similar à
construção de prédios ou de bons
produtos manufaturados.
PROJETO

34.  Na opinião do professor, infelizmente,
nada poderia ser tão distante da
realidade. Não é normal na construção
civil ou nas indústrias tradicionais as
especificações e design serem alteradas
nas fases de construção ou produção.
 Quando isso ocorre os estouros de
orçamento são, em geral, monstruosos.
PROJETO

35.  Essa "fluidez" nos requisitos é o maior
desafio para o sucesso no
gerenciamento de projetos de software.
 Gerentes que usam a construção ou a
produção industrial como referência,
frequentemente subestimam os
problemas que são causados para a
equipe e também para os custos do
projeto o congelamento prematuro dos
requisitos.
PROJETO

36.  Executar projetos de informática é
bastante peculiar
 Pela complexidade do empreendimento
 Pela constante dificuldade de visualizar
claramente o produto que está sendo
desenvolvido
 Pelas dificuldades de comunicação
entre executor e usuário ou cliente
PROJETOS

37. Desenvolver Sistemas
Então:
Processo de Engenharia?
é uma Arte
ou

38. Desenvolver Sistemas é uma Arte ou Processo de
Engenharia?
A quase totalidade do software
produzido é criada como objeto de
arte:
1) o construtor é um artista ou artesão;
2) criatividade é a grande ferramenta.

39. Desenvolver Sistemas é uma Arte ou Processo de
Engenharia?
O ideal seria que o software
estivesse sendo desenvolvido como
artefato de manufatura
1) o construtor é um técnico;
2) e o rigor científico - as bases de seu
desenvolvimento - sua principal
ferramenta.

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

41.  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.
O papel do Analista

42.  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

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

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

45. Habilidades
do
Analista de Sistemas
 Capacidade de se comunicar bem de
forma escrita e verbal.
 Capacidade de "ver a floresta ao
invés das árvores”

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

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

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

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

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

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

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

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

54. 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 Projeto
Desenvolvido;

55. 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;

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

57. 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 TIPO DE FUNÇÃO

58. 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;

59. 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ÁRIO POR NÍVEL DE EXPERIÊNCIA

60. 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
USUÁRIO - RESUMO

61. 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.
GERENCIA

62. 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.
AUDITORES

63. 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;
ANALISTA DE SISTEMAS

64. Responsáveis pela modelagem e
elaboração das ferramentas usadas
na metodologia.
PROJETISTAS DE SISTEMAS

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

66. PESSOAL DE OPERAÇÕES
Responsáveis pelo centro de
processamento de dados, operação
dos sistemas, Redes, Segurança do
hardware…

67. Material criado por Prof. Edinelson
Revisão e atualização: Prof. Sergio Luiz da Silveira
Faculdade Salesiana Dom Bosco de Piracicaba
Curso Sistemas de Informação
REFERENCIA: