O documento discute conceitos fundamentais de sistemas de informação, incluindo: 1) A natureza dos sistemas e definições gerais de sistemas; 2) Componentes básicos de sistemas como entrada, saída, processamento e feedback; 3) Princípios gerais de sistemas como especialização, tamanho e inter-relacionamento.

1. Análise e Projeto de Sistemas
de Informação
2o. Semestre de 2013
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.  Plano de Ensino
 Cronograma
 Trabalhos

4.  Antes vamos ver/rever alguns conceitos

5. A Natureza dos Sistemas
 É importante conhecer-se os “sistemas” em geral
(e não apenas os sistemas computadorizados),
pois:
 A maioria dos sistemas computacionais são
substituições ou novas implementações de sistemas
não computacionais;
 A maioria dos sistemas computacionais interage com
vários sistemas existentes (computadorizados ou não);
 Além disso, existem princípios comuns, filosofias e
teorias que se aplica bem a quase todos os tipos
de sistemas. Portanto é importante conhecer algo
sobre a Teoria Geral dos Sistemas.

6. Definições Gerais para Sistemas
 um grupo de itens que interagem entre si ou que
sejam interdependentes, formando um todo
 um conjunto organizado de doutrinas, idéias ou
princípios, habitualmente previsto para explicas a
organização ou o funcionamento de um conjunto
sistemático
 um procedimento organizado ou estabelecido
 organização harmoniosa ou modelo

7. Sistemas
Conjunto de elementos inter-relacionados
e inter-conectados desenvolvendo uma
atividade ou função para atingir objetivos
ou propósitos.

8.  Sistema Solar
 “manter os planetas girando em torno do sol”
 Sistema de injeção eletrônica
 regular a mistura ótima de combustível e ar para o
funcionamento do motor
 Sistema digestivo
 incorporar, ao corpo de um animal, a energia e matéria
contidas em alimentos
 Biosfera
 manter a vida sobre a terra
O Conceito de Sistema

9. PROCESSOS
(transformação)
Entradas
input
Saídas
output
Realimentação
(feedback)
Realimentação pode ser um sub-sistema
Componentes de um Sistema

10. Componentes básicos de um
SI
PROCESSOS
(transformação)
Entradas
input
Saídas
output
Realimentação
(feedback)
DADOS
INFORMAÇÕES
DADOS
INFORMAÇÕES
ARMAZENAMENTO

11. Ambiente de um sistema
Sistema está ligado a uma ambiente que é o conjunto de elementos
que não pertencem ao sistema, mas qualquer alteração no sistema
pode mudar ou alterar os seus elementos e qualquer alteração nos
seus elementos pode mudar ou alterar o sistema.

12. Princípios Gerais de
Sistemas
 Todos os sistemas compartilham algumas
características comuns, também conhecidas como
princípios gerais de sistemas:
 Quanto mais especializado é um sistema, menos capaz
ele é de se adaptar a circunstâncias diferentes;
 Quanto maior for um sistema, maior o número de seus
recursos que serão destinados à sua manutenção diária;
 Os sistemas sempre fazem parte de sistemas maiores e
sempre podem ser divididos em sistemas menores;
 Os sistemas crescem.

13. Sistemas Automatizados
 Por definição, sistemas automatizados são aqueles
sistemas feitos pelo homem que interagem com ou são
controlados por computadores. Embora haja muitos tipos
diferentes destes sistemas, todos eles têm componentes
comuns:
 Hardware
 Software
 Pessoas
 Dados
 Procedimentos
 Uma maneira de se dividir estes sistemas classifica-os em 4
tipos diferentes: Sistemas on-line; Sistemas de tempo real;
Sistemas de apoio a decisão e Sistemas baseados em
conhecimento.

14. Sistemas de Informação
Computadorizados
 As Implicações dos Sistemas de
Computador
 Pode-se dizer que um sistema de computador, quando
estudado como uma função matemática, realiza o
simples ato de receber entradas de dados vindas do
meio externo e produzir saídas de dados que são
enviadas ao meio externo.
 Poderíamos entender a operação de um sistema
simples, conduzido por um software do tipo calculadora
ou editor de texto como a computação de uma função
mátemática.
 Este cenário fica bem mais complexo no momento em
que associamos um histórico de informações aos
sistemas de computador, criando Sistemas de
Informação Computacionais.

15. Sistemas de Informação
Computadorizados
 Sistemas de Informação Computadorizados
são criados quando agregamos vários
dispositivos computacionais através de uma
rede de computadores, que utilizam uma
base de dados e outros programas, os quais
são operados continuamente por uma ou
mais pessoas ao longo de um período de
tempo.

16. Sistemas de Informação
Computadorizados
 Estes sistemas realizam em geral um
conjunto de tarefas que suportam o
funcionamento de uma organização
(pública, privada, doméstica ou pessoal). No
momento que os dados manipulados pelo
sistema fazem sentido para o
funcionamento da organização eles criam
"informação".

17. Sistemas de Informação:
 Segundo o suporte às decisões
 Segundo a abrangência da
organização
 Segundo a forma evolutiva
 Segundo a entrada na organização

18. A EMPRESA COMO UM SISTEMA DE
INFORMAÇÃO
RH
MKT
PROD,
VEND.
FINAN.
CONT.
JURID. ADM
MAT.
- PESSOAS
- EQUIPAMENTOS
- INSUMOS
PROCESSOS
ECONOMIA
TECNOLOGIA
LEIS
RECURSOS NATURAIS
COMPETIVIDADE
SÓCIO
POLÍTICAS
.........
- BENS
- SERVIÇOS
ENTRADAS SAÍDAS

19. Análise e Projeto de SI
 A análise de sistemas de
informação é o estudo de um
problema de informação de uma
organização que possa ser
resolvido com o uso das
Tecnologias da Informação.

20. Tecnologia da Informação
 Conceito:
 Conjunto de recursos computacionais para
manipular dados e gerar informações e
conhecimentos.
 As empresas na atualidade perseguem três
metas básicas:
 Redução do esforço do trabalho
 Aumento da produtividade
 Melhoria da qualidade

21. IMPLEMENTAÇÃO DE SISTEMAS
DE INFORMAÇÃO
A implantação de um Sistema de Informação
deve estar de acordo com a estratégia de uso
da tecnologia da informação da organização,
e esta, por sua vez, deve ser coerente com a
sua estratégia de negócio.
 Existe um relação direta entre o nível de
sucesso de uma estratégia de TI e o nível de
apoio da alta gerência em um
desenvolvimento de sistema de informação.

22. Falhas de desenvolvimento
 Uma breve estatística (fonte Chaos
Report-Standish Group)
 10% dos projetos terminam no prazo
estipulado;
 60% dos orçamentos são ultrapassados;
 25% dos projetos são descontinuados antes de
chegarem ao fim;
 corrigir um erro, estimula outros;

23. Introdução
 A transformação da sociedade industrial na sociedade da
informação é uma realidade. *Quem tem a informação
tem o poder!*
 Os impactos desta transformação nos negócios são
profundos. Cresce cada vez mais a necessidade de
informação e de tecnologias que a suportem dentro da
organização.
 Hoje, nas empresas, as tecnologias de informação e as
aplicações por elas geradas diferenciam produtos, sistemas
e serviços, e proporcionam vantagens competitivas no
mercado.
 Aquelas que fornecerem os melhores produtos sobrevivem.

24. Introdução
 Os sistemas de informação estão se tornando cada vez mais
complexos.
 Em função da própria infra-estrutura propiciada pelas novas
tecnologias e do aumento do nível de solicitações por parte dos
usuários da informação na organização
 Apesar da complexidade destes sistemas, o seu
desenvolvimento e manutenção dentro das organizações é uma
tarefa realizada, na maioria das vezes
 sem padrões, métodos ou técnicas bem definidas e sem
práticas gerenciais de controle de qualidade e do
acompanhamento dos projetos
 gerando muitas vezes sistemas de informação que falham no
atendimento aos requisitos dos usuários e consomem mais
recursos (financeiros, humanos e computacionais) do que o
esperado.

25. Introdução
Para viabilizar o atendimento a estas
necessidades em relação ao
desenvolvimento e manutenção de
sistemas de informação, surgem as
metodologias de desenvolvimento de
sistemas (análise e projeto)

26.  Ao longo dos anos surgiram várias
metodologias e técnicas para tentar
resolver estes problemas: caos, análise
estruturada, análise essencial, OO.
 Com as novas demandas houve uma
série de tentativas para novas técnicas

27. O que as organizações
esperam:
 Melhor flexibilidade e
adaptabilidade;
 Possibilitando satisfazer novos requisitos de
negócios rapidamente facilmente
 Melhor manutenabilidade;
 Possibilitando atualizar uma aplicação,
masminimizando o impacto da maioria das
mudanças

28. O que as organizações
esperam:
 Melhor reusabilidade;
 Possibilitando rapidamente montar aplicações
únicas edinâmicas
 Melhor aproveitamento do legado;
 Possibilitando o aproveitamento do legado
corporativo
 Não queremos jogar fora o que a empresa já
tem!

29. O que as organizações
esperam:
 Melhor interoperabilidade
 Possibilitando integrar 2 aplicações
executando em plataformas diferentes
 Melhor escalabilidade
 Possibilitando distribuir e configurar a
execução da aplicação para satisfazer vários
volumes de transação

30. O que as organizações
esperam:
 Menor tempo de desenvolvimento;
 Possibilitando viver “on Internet Time” e com
baixo orçamento
 Melhor robustez;
 Possibilitando ter soluções com menos
defeitos
 Menor risco;
 Possibilitando tudo que falamos acima e
ainda não se arriscar a ter projetos
fracassados

31.  Então ... O que devemos fazer?
 Estudar novas metodologias de
desenvolvimento de software!
 Quais são elas e quais são as melhores?

32.  Tendências (ou já realidades)...
 Fábrica de Software
 Extreme Programming
 CMM
 RUP
 Frameworks

33.  Tendências (ou já realidades)...
 Métricas para estimativas de esforço
 Automatização de Testes
 Software baseado em Componentes
 Design Patterns
 Controle de Versões de Software
 Reutilização de Código
 UML
 Ferramentas de Workflow

34.  Tendências
 SOA – Services Oriented Architecture
 Arquitetura Orientada a Serviços possui diversas
definições mas pode ser entendida como um
paradigma arquitetural que viabiliza a criação de
serviços de negócio com baixo acoplamento
e interoperáveis entre si, os quais podem ser
facilmente compartilhados dentro e fora das
corporações.

35. Perspectiva histórica
 1940: os computadores foram
inventados
 1950: linguagem de montagem,
Fortran
 1960: COBOL, ALGOL, PL/1, Sistemas
Operacionais
 1970: Sistemas multi-usuário, Banco
de Dados, programação estruturada

36. Perspectiva histórica
 1980: redes, PCs, arquiteturas
paralelas
 1990: Internet, sistemas
distribuídos, Orientação a Objetos
 2000: Realidade Virtual,
reconhecimento de voz, vídeo-
conferência...

37. A Evolução do Software
 50 - 64
 Base: Hardware
 Orientação Batch
 Software customizado (sob medida)
 Distribuição Limitada
 Ausência de Documentação

38. A Evolução do Software
 65 - 74
 Multiusuário
 Tempo real
 Bancos de Dados
 Novos conceitos de IHC
 Produto de Software
 Advento das software houses
 Maior demanda e crescimento de produto de software
=> necessidade de manutenção
 CRISE do Software

39. A Evolução do Software
 75 - 90
 Sistemas Distribuídos
 “Inteligência” Embutida
 Hardware de Baixo Custo
 Impacto de Consumo
 Maior complexidade dos softwares
 Gastos com software > gastos com hardware

40. A Evolução do Software
 85 - ...
 Sistemas de Desktop poderosos
 Tecnologias Orientadas a Objetos
 Sistemas Especialistas
 Redes
 Sistemas Distribuídos
 Multimídia e Realidade Virtual
 CRISE ? Metodologia Sistemática?

41. “Crise” do software
“Conjunto de problemas que são encontrados no
desenvolvimento de software de computador.”
 Principais problemas:
 Estimativas de prazo e custos imprecisas
 Produtividade dos profissionais < demanda de
clientes
 Qualidade do software < desejada
 Tempo insuficiente para a coleta dos dados
 Falta de entendimento entre usuário e
desenvolvedor

42. •Continuação.....
•Desenvolvimento de Software como “arte” – desenho de telas e
arquivos
• Problemas de execução - erros
• Prazos extrapolados
• Custos inesperados – correção de erros e adaptação do código às
reais necessidades do usuário
• Empresas dependentes de computadores com sistemas legados que
necessitam modificações mas com código/documentação ilegível ou
inexistentes.
• Insatisfação de usuários
Crise do Software (~1970)

43. Antes...
 Início da era do computador:
 Engenharia de Hardware

administração orientada ao hardware

uso de controle, ferramentas e métodos
 Programação

tentativa e erro

mundo difícil de entender

44. Hoje
 Software: item de maior custo
 Hardware: mais barato e poderoso
 Preocupação:
 Por que demora tanto para a conclusão de um
programa?
 Por que custos tão elevados?
 Por que não se descobre todos os erros
ANTES?
 Por que a dificuldade em medir o progresso do
software enquanto está sendo desenvolvido?

45. na
História
 Anos 80:
 Avanços na área de microeletrônica (VLSI);
 Barateamento do hardware;
 Disseminação do uso de computadores;
 Surgimento de novas áreas de aplicação;
 Resultado: software - fator que diferencia
 Aumento da procura por software;
 Aumento da complexidade dos softwares.
 Aumento nos custos de produção e no preço final.

46. Afinal,
O que é software?

47. Software
“Instruções que, quando executadas,
produzem a função e o desempenho
desejados”
“Estruturas de dados que possibilitam que
os
programas manipulem adequadamente a
informação”
“Software é formado por programas,
documentos e dados”

48. Características do Software
 Software é desenvolvido; não é
manufaturado como hardware
 Software não se desgasta com o uso,
porém se deteriora
 A “maioria” é construída para o cliente,
em vez de ser projetada a partir de
componentes => necessidade de
reutilização
 Software é uma oportunidade de
negócios

49. Domínios de
Aplicação/Software
 Básico
 compiladores, editores, sistema operacional
 Negócios
 Banco de Dados
 Engenharia e Ciências
 CAD
 Simulação
 Inteligência Artificial
 Sistemas Especialistas
 Tempo Real
 Controle de máquinas

50. Problemas na Produção do
Software
 A sofisticação dos atuais softwares é
muito superior à nossa capacidade de
construir software que extraia o potencial
do hardware;
 A demanda por novos softwares é muito
maior que a capacidade de produzi-los
 A criação e manutenção de sistemas é
comprometida pela ausência ou deficiência
nos projetos.

51. Quesitos de Qualidade do
Software
 Manutenibilidade
 Confiabilidade
 Eficiência
 Testabilidade
 Compreensibilidade
 Interface apropriada
 Adaptabilidade

52.  Modelagem de Sistemas de
Informação
 Revendo....

53. Uma possível definição para Sistema de Informação
Como qualquer sistema,
 combinação de partes coordenadas para um mesmo resultado, ou
de maneira a formar um conjunto,
um Sistema de Informação é um
 sistema utilizado para coletar, armazenar, processar e apresentar
informações para apoiar as necessidades de informações de uma
empresa
e tem como principal objetivo
 melhorar o desempenho dos trabalhos realizados dentro de uma
organização.
Para tanto envolve um série de componentes:
 Hardware,
 Software,
 Pessoas,
 Dados e
 Procedimentos.

54. Modelagem
Modelar significa construir modelos.
 Como em diversas outras áreas do saber
(construção civil, engenharia aeronáutica,
automobilística etc.), também na Computação a
construção de um modelo, entre outras
vantagens, permite aos desenvolvedores
 antever o produto final almejado,
 facilitando, por exemplo,
 a interação com o cliente
 a descoberta de eventuais problemas,
 a definição de um cronograma de desenvolvimento
 e a definição de uma estimativa de custos.

55.  O modelo também serve de guia
para a construção do produto final.
 Que modelos vocês já estudaram?

56. Principais paradigmas para a Modelagem
de Sistemas de Informação
 Partindo-se do entendimento que um
paradigma pode ser entendido como
 um modelo ou padrão para se realizar algo,
 concebe-se a existência de dois
paradigmas principais para
modelagem de sistemas de
informação:
 paradigma estruturado e
 paradigma orientado a objetos.

57. Paradigma estruturado
 Baseia-se na combinação de uma série de princípios e
estratégias para a resolução de problemas:
 princípio da abstração,
 princípio da formalidade,
 conceito de dividir para conquistar
 e conceito de organização hierárquica.
 A partir destes, o paradigma estruturado advoga a
modelagem
 dos processos (funções, procedimentos) e
 dos dados (informações)
 que comporão o sistema de informação a partir do
desenvolvimento de uma série de atividades, as
quais convencionou-se denominar
 “desenvolvimento estruturado de sistemas”.

58.  Estas atividades podem ser resumidas em
 Estudo de viabilidade,
 Análise e especificação de requisitos,
 Análise e Projeto do sistema,
 Implementação do sistema,
 Teste e Manutenção do sistema.
 Para que estas atividades sejam desenvolvidas
de maneira organizada, diversas metodologias
de desenvolvimento estruturado foram
elaboradas no decorrer dos anos, sendo que
cada uma delas propõe uma série de métodos,
ferramentas e ciclos de desenvolvimento.
Paradigma estruturado

59.  Dentre as diversas metodologias, a Análise
Estruturada Moderna é a que recebeu maior
reconhecimento.
 Por esta razão, o processos que ela propõe
e/ou advoga (Análise, Projeto e Programação
Estruturada), assim também como suas
ferramentas (Diagrama de Fluxo de Dados,
Diagrama de Entidade- Relacionamento,
Dicionário de Dados etc.) e o ciclo de vida
estruturado foram os mais disseminados entre
os desenvolvedores de sistemas durantes alguns
anos.
Paradigma estruturado

60. Cronologia resumida do paradigma
estruturado
 início da década de 70: programação
estruturada
 meados da década de 70: projeto
estruturado
 fins da década de 70: análise
estruturada
 início da década de 80: técnicas
automatizadas
 fins da década de 80: técnicas CASE

61. Análise Estruturada - DFD
E1
Departamento
de produção
E2
Fornecedores
P1
Escolher
fornecedor
P2
Pedir
materiais
D1 Fornecedores
Lista_materiais
necessários
Pedido_preços
Preços_material
Nota_encomenta
Lista
Dados_fornecedor
Dados_fornecedor
Entidade
externa
Fluxo de dados
Depósito
De dados
Processo

62. Análise Estruturada
Diagrama de Contexto
1
2
1.1
1.2 2.1
2.2
Diagrama Zero
Diagrama 1 Diagrama 2
Especificação
da lógica dos
processos
Processo
1.1
Processo
1.2
Processo
2.1
Processo
2.2
Explosões

63. Análise Essencial
 É uma evolução da Análise Estruturada por adicionar a preocupação
com o controle.
 Usa uma lista de eventos externos como base para o particionamento
do sistema.
 O modelo essencial é construído sem considerar restrições de
implementação (assume uma tecnologia perfeita) – essência do sistema
 Bibliografia:
Yourdon, Edward, Análise Estruturada Moderna, Ed. Campus,
McMenamim, Sthephen M. e Palmer, John F., Análise Essencial de Sistemas,
Editora McGraw-Hill, Ltda., 1991.

64.  O modelo essencial é formado pelo:
 Modelo Ambiental – define a fronteira entre o sistema e o
ambiente.
 Modelo Comportamental – descreve o comportamento interno do
sistema.
 Modelo de Informação – modela os dados necessários às
atividades essenciais do sistema.
 Modelo de Implementação – extensão do modelo essencial
com restrições de implementação
Análise Essencial

65. Análise Essencial
 Modelo Ambiental
 Diagrama de Contexto - Define as interfaces entre o sistema e o
ambiente. São identificadas informações externas e as produzidas
como saída.
 Lista de Eventos - Identifica os eventos que ocorrem no ambiente
e como o sistema deve reagir.
• Modelo Comportamental
 Mostra o comportamento interno do sistema.
 Usa como ferramenta DFD com abordagem diferente.
 Constrói um DFD para cada evento (DFD de resposta a eventos). A
partir dele é feito o agrupamento para formar os diagramas
superiores e inferiores.
 Dicionário de Dados e Especificação de processos

66. Análise Essencial
 Modelo de Informação
 Representa os dados necessários ao sistema.
 Ferramentas utilizadas são:
 Diagrama de entidade e relacionamento
 Deriva da lista de eventos
 Representa a estrutura estática dos dados
 Dicionário de Dados
Empregado Dependente
1 n

67.  Modelo de implementação
 Insere restrições de implementação aos modelos
comportamental e de dados

Fronteiras de automação, tempo de execução, capacidade
de armazenamento, comunicação, etc.
Análise Essencial

68. Análise Orientada a Objetos
 Cenário
 Mudança do enfoque das funções para os dados
 Preocupação em modelar de forma mais detalhada o sistema
 Análise mais próxima da realidade
 Facilidade na comunicação com o usuário
 Objetos como entidades do mundo real
 Objetos com estrutura e comportamento e que se comunicam
 Dificuldades em fazer alterações nas estruturas de dados nas
abordagens tradicionais
 “Se eu alterar a definição desse dado, quais programas serão
afetados?”

69. Análise Orientada a Objetos
 Cenário
 Trabalha com conceitos já conhecidos - Modularidade, Abstração,
Encapsulamento, Mascarar informações, etc
 Orientação a objetos apesar de antiga não era utilizada por falta
de pessoas treinadas, interesse em manter a cultura adquirida,
ferramentas imaturas. Isso começa a se resolver.
O mundo real é composto por objetos. Cada objeto tem propriedades
e comportamentos. Então, porquê não desenvolver programas que
simulem no computador os objetos do mundo real com suas
propriedades e comportamentos?

70. Análise Orientada a Objetos
 Nos métodos tradicionais de análise, o comportamento do sistema e
seus dados eram considerados separadamente. Com orientação a
objetos, comportamento e dados são integrados, assim encapsulando
detalhes internos de um objeto dos demais.
Análise
Estruturada
e Essencial
Orientada a
Objetos
Enfoque
Conjunto de programas que executam processos
Sobre dados
Conjunto de “entidades” que têm características e
Comportamentos próprios
Foco
Sistema
Objeto

71. Paradigma orientado a objetos
 Sua principal característica é
 basear-se no objeto como fundamento para a
modelagem do sistema.
 Por objeto entenda-se
 “uma entidade independente, assíncrona e concorrente
que sabe coisas (armazena dados), realiza trabalho
(encapsula processos) e colabora com outros objetos
(troca mensagens)”,
 ou seja, semelhantemente ao objetivo do paradigma
estruturado, também o paradigma orientado a objetos
(OO) advoga a modelagem de processos e dados,
porém representados por uma única entidade, que é o
objeto.

72.  Para que isto seja viável, também uma série de
princípios têm de ser utilizados:
 identidade,
 classificação,
 herança,
 polimorfismo,
 abstração,
 encapsulamento,
 mensagens e
 concorrência.
Paradigma orientado a objetos

73.  A utilização destes princípios permite que
a modelagem do sistema seja mais
eficiente, visto que o objeto permite
a construção de um modelo mais
próximo e equivalente ao mundo
real, simplificando seu entendimento.
Esta característica é essencial, pois
viabiliza a modelagem de sistemas cada
vez mais complexos.
Paradigma orientado a objetos

74.  Inúmeras são as metodologias que se
baseiam no paradigma orientado a objetos,
porém a grande maioria delas propõe
atividades semelhantes a serem realizadas
para o desenvolvimento de sistemas
orientados a objetos:
 Análise de requisitos OO,
 Análise e Projeto OO,
 Programação OO e
 Teste OO.
Paradigma orientado a objetos

75.  Também são inúmeras as ferramentas para a
representação dos sistemas OO, sendo que
atualmente, a UML (Unified Modeling Language)
é a mais aceita entre os desenvolvedores de
sistemas.
 Já em relação às metodologias, nenhuma se
destaca atualmente, pois cada organização tende
a utilizar-se de uma metodologia proprietária para
o desenvolvimento de sistemas OO. Em um
futuro próximo, espera-se que o RUP (Rational
Unified Process) venha a ser adotado pela
maioria dos desenvolvedores.
Paradigma orientado a objetos

76. Cronologia resumida do paradigma
orientado a objetos
 final da década de 70 e início da década de
80: programação orientada a objetos
 meados da década de 80: projeto orientado
a objetos
 final da década de 80 e início da década de
90: análise orientada a objetos
 fins da década de 90: metodologias de
desenvolvimento OO de 1a e 2a gerações

77.  Como os métodos Booch e o OMT estavam sendo largamente
utilizados, seus autores juntaram forças para fazer um método
unificado, com uma linguagem padrão. Posteriormente Jacobson
juntou-se a equipe.
 Linguagem de modelagem proposta por Booch, Rumbaugh e Jacobson
 UML (Unified Modeling Language)
 Padronizada pela OMG (Object Management Group)
 Conta atualmente com o apoio de vários autores e várias empresas
 O RUP (Rational Unified Process) foi proposto como uma metodologia
para desenvolvimento de sistemas, orientada a objetos, utilizando
UML

78. Por que usar Orientação a
Objetos?
 Atualmente temos ferramentas completas para sua utilização
(integrando especificação e implementação)
 Praticamente todas as ferramentas novas de programação permitem
suporte a sua utilização
 Qualidade melhor do software (se usada corretamente)
 Produtividade em função do reuso (não é imediata)
 Produção de códigos mais fáceis de serem entendido (se for bom)
 Adequada para a construção de sistemas distribuídos e para
aplicações voltadas a Internet
 Permite acesso controlado às informações

79.  Dificuldade:
 Usuário não pensam seus problemas de forma orientada a
objetos
 Requisitos não são orientados a objetos
Requisitos de usuários são funcionais

80.  Todos os projetos são desenvolvidos
no prazo e custos estabelecidos?
 E a qualidade?

81. Porque os
projetos falham?

82. Falhas de desenvolvimento
 Uma breve estatística (fonte Chaos Report-Standish
Group - 1995)
 O “Relatório do Caos” - The Chaos Report – do Standish
Group, um marco na história de estudos de falhas de projetos
de tecnologia da informação, de 1995 identificou:
1. O escopo das falhas de projetos de software
2. Os principais fatores que causam as falhas de projetos de
software
3. Os ingredientes – chave que pode reduzir as falhas de projetos
de software

83. Os principais resultados alcançados pelo estudo foram:
 31.1% dos projetos seriam cancelados antes de estarem
completados/terminados
 52.7% dos projetos custariam 189% de suas estimativas
originais
 16.2% de todos os projetos de software são completados on-
time and on-budget.
 Nas grandes empresas, somente 9% de todos os projetos de
software são completados on-time and on-budget.
 Nas grandes empresas, apenas 42% dos produtos de software
contêm as funcionalidades e funções originalmente propostas.

84.  O mais importante aspecto desta pesquisa foi descobrir porque
os projetos falham.
 Para isto, o Standish Group entrevistou gerentes executivos de
TI sobre suas opiniões sobre porque os projetos obtêm
sucesso.
 As três maiores razões para o sucesso de um projetos são:
 o envolvimento do usuário,
 o suporte dos executivos e gestores e
 uma declaração/definição clara de requisitos.
 Há outros fatores de sucesso, mas com estes três elementos
juntos, a chance de sucesso aumenta muito.
 Sem eles, a chande de falhar aumenta dramaticamente.

85. Fatores de sucesso de um projeto

86. Porque isto
acontece?

87.  Ainda segundo o Chaos Report, a
maioria dos projetos falham não por
falta de recursos financeiros ou acesso
à tecnologia, mas sim por falta de
conhecimento em gestão de projetos.

88. Para viabilizar o atendimento a estas necessidades em relação ao
desenvolvimento e manutenção de sistemas de informação, surgem
as metodologias de desenvolvimento de sistemas (análise e projeto).
Boas práticas de desenvolvimento
Engenharia de Software

89. Vantagens da aplicação de uma metodologia de Análise e Projeto de
Sistemas
Padronização de técnicas, ferramentas e métodos para que toda a
organização "fale a mesma língua".
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.
Como conseqüê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.

90. O que é um projeto?

91. O que é um projeto?
Quais são os pilares que garantem um projeto executado com
sucesso?
Objetivo
Metodologia
Controle
Mas, o que é um PROJETO?
A palavra projeto tem origem no latim “projectu” que signfica “lançado
para diante”. É uma tarefa ou conjunto de ações com objetivo comum.
Diversos tipos de projetos:
Projeto de lei, projetos de engenharia, paisagístico, etc.

92. O que é um projeto?
O trabalho em equipe é a essência do projeto.
O gerente tem como meta controlar e garantir que a idéia principal seja
cumprida e evitar distorções.
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.

93. Ciclo de Vida de um Projeto
Três grandes fases:
O início
A maturidade
A conclusão
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.
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.

94. Pode-se considerar um projeto bem sucedido
aquele que foi desenvolvido/realizado:
• No prazo e orçamento previstos;
• Dentro das especificações técnicas e
qualidade previstas;
• Cliente/usuário satisfeito com o
produto/serviço recebido;
• Produto/serviço obtido é usado em sua
totalidade.

95.  O que é análise

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

97. Análise
 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.

98. Análise
 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.

99. O que é Análise?
 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.

100. Projeto
 A fase de projeto enfatiza a proposta de
uma solução que atenda os requisitos
da análise.
 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.

101. 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?

102. Por que fazer
Análise?
 Gerenciamento da complexidade.
 Comunicação entre as pessoas
envolvidas.
 Redução dos custos no
desenvolvimento.
 Predição do comportamento futuro do
sistema.

103. Por que fazer Análise?
 Entender o que o usuário realmente
quer ou necessita para resolver um
problema.

104. Diferenças entre análise
e projeto
Tem mais do que uma definição
empregada.
 Primeira Alternativa:
 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.
 O projeto modela a solução e consiste das
atividades de criação (como pode ser
feito)

105.  Segunda Alternativa
 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.
 O projeto inclui as atividades que resultam
em informação que interessa apenas ao
programador.
 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

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

107.  Além disso, projetos deste tipo possuem
as seguintes características:
 Não são sujeitos a freqüentes 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.

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

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

110.  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,
freqüentemente subestimam os
problemas que são causados para a
equipe e também para os custos do
projeto o congelamento prematuro dos
requisitos.

111. Projetos
 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

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

113. Desenvolver Sistemas é uma Arte ou Processo de Engenharia?
A quase totalidade do software produzido é
criada como objeto de arte
o construtor é um artista ou artesão
criatividade é a grande ferramenta.
O ideal seria que o software estivesse sendo
desenvolvido como artefato de manufatura
o construtor é um técnico
e o rigor científico - as bases de seu desenvolvimento
- sua principal ferramenta.

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

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

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

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

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

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

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

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

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

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

124. Os mandamentos para ser um bom
Analista de Sistemas
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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

145. Ciclo de Vida do Sistema
 Incremental e Interativo:

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

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

148. Ciclo de Vida do Modelo
Espiral
Planejamento Análise de riscos
EngenhariaAvaliaçã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