• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Aula1 e aula2 - Analise e Projeto de Sistemas
 

Aula1 e aula2 - Analise e Projeto de Sistemas

on

  • 995 views

 

Statistics

Views

Total Views
995
Views on SlideShare
776
Embed Views
219

Actions

Likes
0
Downloads
36
Comments
0

1 Embed 219

http://www.gustavo.pro.br 219

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.
  • 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.

Aula1 e aula2 - Analise e Projeto de Sistemas Aula1 e aula2 - Analise e Projeto de Sistemas Presentation Transcript

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