Análise e Projeto de Sistemasde Informação
2o. Semestre de 2013
Material criado por Prof. EdinelsonRevisão e atualização: Prof. Gustavo Gonzalez
Faculdade Salesiana Dom Bosco de PiracicabaCurso Sistemas de Informação
Plano de Ensino
Cronograma
Trabalhos
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)
Entradasinput
Saídasoutput
Realimentação(feedback)
Realimentação pode ser um sub-sistema
Componentes de um Sistema
Componentes básicos de um SI
PROCESSOS(transformação)
Entradasinput
Saídasoutput
Realimentação(feedback)
DA
DO
SIN
FO
RM
AÇ
ÕE
S
DA
DO
SIN
FO
RM
AÇ
ÕE
SARMAZENAMENTO
Ambiente de um sistemaSistema 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?
A Importância do Software naHistó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 desempenhodesejados”
“Estruturas de dados que possibilitam que os
programas manipulem adequadamente ainformaçã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 doSoftware
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.
ModelagemModelar 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
E1Departamentode produção
E2Fornecedores
P1Escolher
fornecedor
P2Pedir
materiais
D1 Fornecedores
Lista_materiaisnecessários
Pedido_preços
Preços_material
Nota_encomenta
Lista
Dados_fornecedor
Dados_fornecedor
Entidade externa
Fluxo de dadosDepósitoDe dados
Processo
Análise Estruturada
Diagrama de Contexto
12
1.1
1.2 2.1
2.2
Diagrama Zero
Diagrama 1 Diagrama 2
Especificaçãoda lógica dosprocessos
Processo1.1
Processo1.2
Processo2.1
Processo2.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 Dependente1 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
Estruturadae Essencial
Orientada aObjetos
Enfoque
Conjunto de programas que executam processosSobre 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?ObjetivoMetodologiaControle
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 livroMetodologia: 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 definidosNo 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 egerê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ícioFim
Coleta erefinamento
dos requisitos
Projetorápido
Construçãodo protótipo
Avaliação doprotótipo
pelo cliente
Refinamentodo protótipo
Engenhariado 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 baseadanos requisitos iniciais
Decisão de prosseguirou não prosseguir
Protótipo de softwareinicial
Protótipo no nível seguinte
Sistema construído pela engenharia
Avaliação pelo cliente
Coleta inicial dosrequisitos e
planejamento do projeto
Planejamento baseado noscomentários do cliente
Análise de riscos baseadana reação do cliente