aula1 e aula2 - analise e projeto de sistemas

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)

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

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

FINAN.

JURID. ADM

- PESSOAS

- EQUIPAMENTOS

- INSUMOS

PROCESSOS

ECONOMIA

TECNOLOGIA

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

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!

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

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

Dados_fornecedor

Entidade externa

Fluxo de dadosDepósitoDe dados

Processo

Análise Estruturada

Diagrama de Contexto

1.2 2.1

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

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

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?

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

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.

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.

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.

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.

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

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?

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

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.

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.

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

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á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á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

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

aula1 e aula2 - analise e projeto de sistemas

Technology

inov aula2

hardware aula2

pe - aula2

aula2 ligacaoquim

aula2 timkt

mac2166–introduçãoàcomputação aula1...

aula2 glicolise 2014

exercício aula2

analise de dados longitudinais´ introduc¸ao˜ a...

aula2 - biossegurança_fisiot.ppt

digestivo aula2

slide aula2

aula2 25.08.08

aula1 bio 08 - pgcsiamspe.org · incerteza baseados em um...

módulo1 aula2

analise aula2

aula2 joao

aula2 mesopotamia

lorena aula2

oscilações prof. romulo aula1-07/05 aula2-14/05 revisão:...