SlideShare uma empresa Scribd logo
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
 Plano de Ensino
 Cronograma
 Trabalhos
Aula1 e aula2 - Analise e Projeto de Sistemas
 Antes vamos ver/rever alguns conceitos
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.
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
Sistemas
Conjunto de elementos inter-relacionados
e inter-conectados desenvolvendo uma
atividade ou função para atingir objetivos
ou propósitos.
 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
PROCESSOS
(transformação)
Entradas
input
Saídas
output
Realimentação
(feedback)
Realimentação pode ser um sub-sistema
Componentes de um Sistema
Componentes básicos de um
SI
PROCESSOS
(transformação)
Entradas
input
Saídas
output
Realimentação
(feedback)
DADOS
INFORMAÇÕES
DADOS
INFORMAÇÕES
ARMAZENAMENTO
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.
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.
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.
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.
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.
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".
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
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
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.
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
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.
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;
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.
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.
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)
 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
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
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!
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
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
 Então ... O que devemos fazer?
 Estudar novas metodologias de
desenvolvimento de software!
 Quais são elas e quais são as melhores?
 Tendências (ou já realidades)...
 Fábrica de Software
 Extreme Programming
 CMM
 RUP
 Frameworks
 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
 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.
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
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...
A Evolução do Software
 50 - 64
 Base: Hardware
 Orientação Batch
 Software customizado (sob medida)
 Distribuição Limitada
 Ausência de Documentação
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
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
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?
“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
•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)
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
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?
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.
Afinal,
O que é software?
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”
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
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
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.
Quesitos de Qualidade do
Software
 Manutenibilidade
 Confiabilidade
 Eficiência
 Testabilidade
 Compreensibilidade
 Interface apropriada
 Adaptabilidade
 Modelagem de Sistemas de
Informação
 Revendo....
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.
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.
 O modelo também serve de guia
para a construção do produto final.
 Que modelos vocês já estudaram?
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.
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”.
 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
 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
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
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
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
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.
 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
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
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
 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
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?”
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?
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
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.
 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
 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
 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
 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
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
 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
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
 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
 Todos os projetos são desenvolvidos
no prazo e custos estabelecidos?
 E a qualidade?
Porque os
projetos falham?
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
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.
 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.
Fatores de sucesso de um projeto
Porque isto
acontece?
 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.
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
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.
O que é um projeto?
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.
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.
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.
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.
 O que é análise
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.
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.
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.
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.
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.
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?
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.
Por que fazer Análise?
 Entender o que o usuário realmente
quer ou necessita para resolver um
problema.
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)
 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
 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.
 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.
 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.
 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.
 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.
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
Então:
Desenvolver Sistemas é
uma Arte ou Processo de
Engenharia?
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.
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”
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
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
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
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
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
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.
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 consistência entre muitos
projetos;
•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:
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
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 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

Mais conteúdo relacionado

Mais procurados

Introdução a analise de sistemas i
Introdução a analise de sistemas iIntrodução a analise de sistemas i
Introdução a analise de sistemas i
Ray Fran Pires
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
Marcelo Yamaguti
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
elliando dias
 
Introdução à Análise de Sistemas - Parte II
Introdução à Análise de Sistemas - Parte IIIntrodução à Análise de Sistemas - Parte II
Introdução à Análise de Sistemas - Parte II
Nécio de Lima Veras
 
As aula 1 - introdução a análise de sistemas
As   aula 1 - introdução a análise de sistemasAs   aula 1 - introdução a análise de sistemas
As aula 1 - introdução a análise de sistemas
tontotsilva
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
Cloves da Rocha
 
Sistemas Computacionais - Aula 01 - Apresentação
Sistemas Computacionais - Aula 01 - ApresentaçãoSistemas Computacionais - Aula 01 - Apresentação
Sistemas Computacionais - Aula 01 - Apresentação
Leinylson Fontinele
 
1.Introdução Banco de Dados
1.Introdução Banco de Dados1.Introdução Banco de Dados
1.Introdução Banco de Dados
vini_campos
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
Rudson Kiyoshi Souza Carvalho
 
Informatica aplicada à administração - aula2
Informatica aplicada à administração - aula2Informatica aplicada à administração - aula2
Informatica aplicada à administração - aula2
José Alberto
 
Aula 10 Software - sistema operacional e aplicativos
Aula 10 Software - sistema operacional e aplicativosAula 10 Software - sistema operacional e aplicativos
Aula 10 Software - sistema operacional e aplicativos
CEULJI/ULBRA Centro Universitário Luterano de Ji-Paraná
 
Aula 3 Sistemas de Informação - Tipos de SI
Aula 3 Sistemas de Informação - Tipos de SIAula 3 Sistemas de Informação - Tipos de SI
Aula 3 Sistemas de Informação - Tipos de SI
Daniel Brandão
 
Algoritmos e Estrutura de Dados - Aula 01
Algoritmos e Estrutura de Dados - Aula 01Algoritmos e Estrutura de Dados - Aula 01
Algoritmos e Estrutura de Dados - Aula 01
thomasdacosta
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de Informação
Daniel Brandão
 
Aula 1 - Introdução ao Conteúdo de Banco de Dados
Aula 1 - Introdução ao Conteúdo de Banco de DadosAula 1 - Introdução ao Conteúdo de Banco de Dados
Aula 1 - Introdução ao Conteúdo de Banco de Dados
Henrique Nunweiler
 
Gestão da Tecnologia da Informação - Aula 1
Gestão da Tecnologia da Informação - Aula 1Gestão da Tecnologia da Informação - Aula 1
Gestão da Tecnologia da Informação - Aula 1
Alessandro Almeida
 
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Leinylson Fontinele
 
Sistemas de Informação
Sistemas de InformaçãoSistemas de Informação
Sistemas de Informação
Mauricio Uriona Maldonado PhD
 
Aula 6 - Design e Processo de Design de Interfaces de Usuário
Aula 6 - Design e Processo de Design de Interfaces de UsuárioAula 6 - Design e Processo de Design de Interfaces de Usuário
Aula 6 - Design e Processo de Design de Interfaces de Usuário
André Constantino da Silva
 
Informática Básica - Aula 05 - Sistema Operacional Windows
Informática Básica - Aula 05 - Sistema Operacional WindowsInformática Básica - Aula 05 - Sistema Operacional Windows
Informática Básica - Aula 05 - Sistema Operacional Windows
Joeldson Costa Damasceno
 

Mais procurados (20)

Introdução a analise de sistemas i
Introdução a analise de sistemas iIntrodução a analise de sistemas i
Introdução a analise de sistemas i
 
Arquitetura de Software
Arquitetura de SoftwareArquitetura de Software
Arquitetura de Software
 
Analise de Requisitos
Analise de RequisitosAnalise de Requisitos
Analise de Requisitos
 
Introdução à Análise de Sistemas - Parte II
Introdução à Análise de Sistemas - Parte IIIntrodução à Análise de Sistemas - Parte II
Introdução à Análise de Sistemas - Parte II
 
As aula 1 - introdução a análise de sistemas
As   aula 1 - introdução a análise de sistemasAs   aula 1 - introdução a análise de sistemas
As aula 1 - introdução a análise de sistemas
 
Aula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de SoftwareAula - Introdução a Engenharia de Software
Aula - Introdução a Engenharia de Software
 
Sistemas Computacionais - Aula 01 - Apresentação
Sistemas Computacionais - Aula 01 - ApresentaçãoSistemas Computacionais - Aula 01 - Apresentação
Sistemas Computacionais - Aula 01 - Apresentação
 
1.Introdução Banco de Dados
1.Introdução Banco de Dados1.Introdução Banco de Dados
1.Introdução Banco de Dados
 
Aula 2 - Processos de Software
Aula 2 - Processos de SoftwareAula 2 - Processos de Software
Aula 2 - Processos de Software
 
Informatica aplicada à administração - aula2
Informatica aplicada à administração - aula2Informatica aplicada à administração - aula2
Informatica aplicada à administração - aula2
 
Aula 10 Software - sistema operacional e aplicativos
Aula 10 Software - sistema operacional e aplicativosAula 10 Software - sistema operacional e aplicativos
Aula 10 Software - sistema operacional e aplicativos
 
Aula 3 Sistemas de Informação - Tipos de SI
Aula 3 Sistemas de Informação - Tipos de SIAula 3 Sistemas de Informação - Tipos de SI
Aula 3 Sistemas de Informação - Tipos de SI
 
Algoritmos e Estrutura de Dados - Aula 01
Algoritmos e Estrutura de Dados - Aula 01Algoritmos e Estrutura de Dados - Aula 01
Algoritmos e Estrutura de Dados - Aula 01
 
Aula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de InformaçãoAula 01 - Introdução ao Sistema de Informação
Aula 01 - Introdução ao Sistema de Informação
 
Aula 1 - Introdução ao Conteúdo de Banco de Dados
Aula 1 - Introdução ao Conteúdo de Banco de DadosAula 1 - Introdução ao Conteúdo de Banco de Dados
Aula 1 - Introdução ao Conteúdo de Banco de Dados
 
Gestão da Tecnologia da Informação - Aula 1
Gestão da Tecnologia da Informação - Aula 1Gestão da Tecnologia da Informação - Aula 1
Gestão da Tecnologia da Informação - Aula 1
 
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
Sistemas Operacionais - Aula 02 (Visão geral de sistemas operacionais)
 
Sistemas de Informação
Sistemas de InformaçãoSistemas de Informação
Sistemas de Informação
 
Aula 6 - Design e Processo de Design de Interfaces de Usuário
Aula 6 - Design e Processo de Design de Interfaces de UsuárioAula 6 - Design e Processo de Design de Interfaces de Usuário
Aula 6 - Design e Processo de Design de Interfaces de Usuário
 
Informática Básica - Aula 05 - Sistema Operacional Windows
Informática Básica - Aula 05 - Sistema Operacional WindowsInformática Básica - Aula 05 - Sistema Operacional Windows
Informática Básica - Aula 05 - Sistema Operacional Windows
 

Destaque

Analise e Projeto de Sistemas
Analise e Projeto de SistemasAnalise e Projeto de Sistemas
Analise e Projeto de Sistemas
Victor Mateus Espindula
 
Análise de sistemas aula 2
Análise de sistemas   aula 2Análise de sistemas   aula 2
Análise de sistemas aula 2
Mário Gomes
 
Metodologias de análise e desenvolvimento de sistemas
Metodologias de análise e desenvolvimento de sistemasMetodologias de análise e desenvolvimento de sistemas
Metodologias de análise e desenvolvimento de sistemas
Susana Oliveira
 
Analise sistemas 02
Analise sistemas 02Analise sistemas 02
Analise sistemas 02
Caroline Raquel Rodrigues
 
Analise sistemas 06
Analise sistemas 06Analise sistemas 06
Analise sistemas 06
Caroline Raquel Rodrigues
 
Análise essencial e análise estruturada
Análise essencial e análise estruturadaAnálise essencial e análise estruturada
Análise essencial e análise estruturada
Wagner Bonfim
 
Análise estruturada de sistemas - Modelo de contexto
Análise estruturada de sistemas - Modelo de contextoAnálise estruturada de sistemas - Modelo de contexto
Análise estruturada de sistemas - Modelo de contexto
Luciano Almeida
 
Modelos de ciclo de vida de software
Modelos de ciclo de vida de softwareModelos de ciclo de vida de software
Modelos de ciclo de vida de software
Yuri Garcia
 
Desenvolvimento Ágil e XP
Desenvolvimento Ágil e XPDesenvolvimento Ágil e XP
Desenvolvimento Ágil e XP
Elomar Souza
 
Projeto de Sistemas - Parte001
Projeto de Sistemas - Parte001Projeto de Sistemas - Parte001
Projeto de Sistemas - Parte001
Cláudio Amaral
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
Leandro Rezende
 
Perfil profissional tecnólogo em análise e desenvolvimento de sistemas
Perfil profissional tecnólogo em análise e desenvolvimento de sistemasPerfil profissional tecnólogo em análise e desenvolvimento de sistemas
Perfil profissional tecnólogo em análise e desenvolvimento de sistemas
Carlos Melo
 
Tecnologias Web com foco na criação de Landing Pages
Tecnologias Web com foco na criação de Landing PagesTecnologias Web com foco na criação de Landing Pages
Tecnologias Web com foco na criação de Landing Pages
Rangel Javier
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
Adriano Tavares
 
Linguagem de Programação II - Plano de Ensino
Linguagem de Programação II - Plano de EnsinoLinguagem de Programação II - Plano de Ensino
Linguagem de Programação II - Plano de Ensino
Daniel Arndt Alves
 
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURAHELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
Helber Choo
 
Uma experiência de formação de professores no uso
Uma experiência de formação de professores no usoUma experiência de formação de professores no uso
Uma experiência de formação de professores no uso
Caroline Raquel Rodrigues
 
Estatistica de cana
Estatistica de canaEstatistica de cana
Estatistica de cana
Federal University of Paraná
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
Kéllyson Gonçalves da Silva
 
Palestra viabilidade nas construções análise dos sistemas construtivos em con...
Palestra viabilidade nas construções análise dos sistemas construtivos em con...Palestra viabilidade nas construções análise dos sistemas construtivos em con...
Palestra viabilidade nas construções análise dos sistemas construtivos em con...
Edson Fernando Leite Filho
 

Destaque (20)

Analise e Projeto de Sistemas
Analise e Projeto de SistemasAnalise e Projeto de Sistemas
Analise e Projeto de Sistemas
 
Análise de sistemas aula 2
Análise de sistemas   aula 2Análise de sistemas   aula 2
Análise de sistemas aula 2
 
Metodologias de análise e desenvolvimento de sistemas
Metodologias de análise e desenvolvimento de sistemasMetodologias de análise e desenvolvimento de sistemas
Metodologias de análise e desenvolvimento de sistemas
 
Analise sistemas 02
Analise sistemas 02Analise sistemas 02
Analise sistemas 02
 
Analise sistemas 06
Analise sistemas 06Analise sistemas 06
Analise sistemas 06
 
Análise essencial e análise estruturada
Análise essencial e análise estruturadaAnálise essencial e análise estruturada
Análise essencial e análise estruturada
 
Análise estruturada de sistemas - Modelo de contexto
Análise estruturada de sistemas - Modelo de contextoAnálise estruturada de sistemas - Modelo de contexto
Análise estruturada de sistemas - Modelo de contexto
 
Modelos de ciclo de vida de software
Modelos de ciclo de vida de softwareModelos de ciclo de vida de software
Modelos de ciclo de vida de software
 
Desenvolvimento Ágil e XP
Desenvolvimento Ágil e XPDesenvolvimento Ágil e XP
Desenvolvimento Ágil e XP
 
Projeto de Sistemas - Parte001
Projeto de Sistemas - Parte001Projeto de Sistemas - Parte001
Projeto de Sistemas - Parte001
 
Aula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a ObjetosAula2 - Modelagem de Sistemas Orientada a Objetos
Aula2 - Modelagem de Sistemas Orientada a Objetos
 
Perfil profissional tecnólogo em análise e desenvolvimento de sistemas
Perfil profissional tecnólogo em análise e desenvolvimento de sistemasPerfil profissional tecnólogo em análise e desenvolvimento de sistemas
Perfil profissional tecnólogo em análise e desenvolvimento de sistemas
 
Tecnologias Web com foco na criação de Landing Pages
Tecnologias Web com foco na criação de Landing PagesTecnologias Web com foco na criação de Landing Pages
Tecnologias Web com foco na criação de Landing Pages
 
A importância da arquitetura de software
A importância da arquitetura de softwareA importância da arquitetura de software
A importância da arquitetura de software
 
Linguagem de Programação II - Plano de Ensino
Linguagem de Programação II - Plano de EnsinoLinguagem de Programação II - Plano de Ensino
Linguagem de Programação II - Plano de Ensino
 
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURAHELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
HELBER_CHOO_-_TRABALHO_DE_LICENCIATURA
 
Uma experiência de formação de professores no uso
Uma experiência de formação de professores no usoUma experiência de formação de professores no uso
Uma experiência de formação de professores no uso
 
Estatistica de cana
Estatistica de canaEstatistica de cana
Estatistica de cana
 
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWAREANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
ANÁLISE DO PARADIGMA HÍBRIDO NA INDÚSTRIA DE SOFTWARE
 
Palestra viabilidade nas construções análise dos sistemas construtivos em con...
Palestra viabilidade nas construções análise dos sistemas construtivos em con...Palestra viabilidade nas construções análise dos sistemas construtivos em con...
Palestra viabilidade nas construções análise dos sistemas construtivos em con...
 

Semelhante a Aula1 e aula2 - Analise e Projeto de Sistemas

Aula 01 – aps
Aula 01 – apsAula 01 – aps
Aula 01 – aps
Mariana Oliveira Santos
 
Computação Autonoma no Ambiente das Tecnologias da Informação
Computação Autonoma no Ambiente das Tecnologias da InformaçãoComputação Autonoma no Ambiente das Tecnologias da Informação
Computação Autonoma no Ambiente das Tecnologias da Informação
Leonardo Sepulcri
 
Sistemas de informação 1
Sistemas de informação 1Sistemas de informação 1
Sistemas de informação 1
celsocarriel
 
Sibb i
Sibb iSibb i
Sibb i
plgrodrigues
 
O Sistema de informação
O Sistema de informaçãoO Sistema de informação
O Sistema de informação
Filipe Simão Kembo
 
Teoria geral-de-sistemas
Teoria geral-de-sistemasTeoria geral-de-sistemas
Teoria geral-de-sistemas
Itália Camolesi
 
Capitulo2 eb
Capitulo2 ebCapitulo2 eb
Fundamentos da informação
Fundamentos da informaçãoFundamentos da informação
Fundamentos da informação
Dudu18Machado
 
Sld 1
Sld 1Sld 1
Sld 1
spawally
 
Analise - Aula 1
Analise - Aula 1Analise - Aula 1
Analise - Aula 1
Kelvin Wesley
 
Sociedade, Dados e Informação
Sociedade, Dados e InformaçãoSociedade, Dados e Informação
Sociedade, Dados e Informação
Claudio Barbosa
 
Sistemas de Informação (1).ppt
Sistemas de Informação (1).pptSistemas de Informação (1).ppt
Sistemas de Informação (1).ppt
Agrupamento de escolas de Pombal
 
Fundamentos de sistemas de informação
Fundamentos de sistemas de informaçãoFundamentos de sistemas de informação
Fundamentos de sistemas de informação
Leonardo Melo Santos
 
Capitulo2 eb extra
Capitulo2 eb extraCapitulo2 eb extra
Capitulo2 eb extra
producaoaudiovisualunip
 
Material Sistema integrados.pptx
Material Sistema integrados.pptxMaterial Sistema integrados.pptx
Material Sistema integrados.pptx
JulianoCarvalho34
 
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃOLIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
Os Fantasmas !
 
Dayana222
Dayana222Dayana222
Dayana222
Dayana Gomes
 
Modelagem de dados
Modelagem de dadosModelagem de dados
Modelagem de dados
Manuella Veroni
 
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
DosmitoJoaoDesma
 
2 sistemas
2 sistemas2 sistemas
2 sistemas
Felipe Pereira
 

Semelhante a Aula1 e aula2 - Analise e Projeto de Sistemas (20)

Aula 01 – aps
Aula 01 – apsAula 01 – aps
Aula 01 – aps
 
Computação Autonoma no Ambiente das Tecnologias da Informação
Computação Autonoma no Ambiente das Tecnologias da InformaçãoComputação Autonoma no Ambiente das Tecnologias da Informação
Computação Autonoma no Ambiente das Tecnologias da Informação
 
Sistemas de informação 1
Sistemas de informação 1Sistemas de informação 1
Sistemas de informação 1
 
Sibb i
Sibb iSibb i
Sibb i
 
O Sistema de informação
O Sistema de informaçãoO Sistema de informação
O Sistema de informação
 
Teoria geral-de-sistemas
Teoria geral-de-sistemasTeoria geral-de-sistemas
Teoria geral-de-sistemas
 
Capitulo2 eb
Capitulo2 ebCapitulo2 eb
Capitulo2 eb
 
Fundamentos da informação
Fundamentos da informaçãoFundamentos da informação
Fundamentos da informação
 
Sld 1
Sld 1Sld 1
Sld 1
 
Analise - Aula 1
Analise - Aula 1Analise - Aula 1
Analise - Aula 1
 
Sociedade, Dados e Informação
Sociedade, Dados e InformaçãoSociedade, Dados e Informação
Sociedade, Dados e Informação
 
Sistemas de Informação (1).ppt
Sistemas de Informação (1).pptSistemas de Informação (1).ppt
Sistemas de Informação (1).ppt
 
Fundamentos de sistemas de informação
Fundamentos de sistemas de informaçãoFundamentos de sistemas de informação
Fundamentos de sistemas de informação
 
Capitulo2 eb extra
Capitulo2 eb extraCapitulo2 eb extra
Capitulo2 eb extra
 
Material Sistema integrados.pptx
Material Sistema integrados.pptxMaterial Sistema integrados.pptx
Material Sistema integrados.pptx
 
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃOLIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
LIVRO PROPRIETÁRIO - CENÁRIOS DE TECNOLOGIA DA INFORMAÇÃO
 
Dayana222
Dayana222Dayana222
Dayana222
 
Modelagem de dados
Modelagem de dadosModelagem de dados
Modelagem de dados
 
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
1.01_Sistema de Informacao na Organizacao_Trabalho III.pptx
 
2 sistemas
2 sistemas2 sistemas
2 sistemas
 

Aula1 e aula2 - Analise e Projeto de Sistemas

  • 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
  • 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?
  • 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
  • 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

Notas do Editor

  1. Ao trabalhar em um sistema de folha de pagamento o Analista deve conhecer como é o funcionamento do sistema de Recursos Humanos, uma vez que o sistema de pagamento faz parte deste. Sistemas automatizados: são sistemas feitos pelo homem, que interagem com ou são controlados por um ou mais computadores.
  2. O ser humano têm limitações de entendimento de um problema dependendo de sua complexidade, imagine um projeto de um avião. Os projetitas de um avião precisam abstrair certas informações para entender seu funcionamento, portanto eles devem entender parte por parte. Redução de custo: na construção civil é mais fácil e barato corrigir uma maquete do que depois quebrar e refazer uma parede, o mesmo seria no desenvolvimento de um sistema. Prever um comportamento futuro do sistema irá permitir ao análise dar diferentes soluções para um problema.