fabrício costa santana professorfabricio.net [email protected]

126
ANÁLISE E MODELAGEM DE SISTEMAS I Fabrício Costa Santana professorfabricio.net [email protected]

Upload: internet

Post on 18-Apr-2015

117 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

ANÁLISE E MODELAGEM DE

SISTEMAS IFabrício Costa Santana

[email protected]

Page 2: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Ementa:◦ Visão geral de um sistema. Conceito de sistemas.

Sistemas de informação. Análise de sistemas. Estudo do ciclo de vida de um sistema. Metodologias de desenvolvimento de sistemas. Técnicas de Entrevistas e de Coleta de Dados. Análise estruturada de sistemas. Ferramentas da Análise Estruturada.

Apresentação da Disciplina

Page 3: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

OBJETIVO GERAL◦ Capacitar o aluno a utilizar adequadamente as

ferramentas da análise estruturada e projeto estruturado nas fases de desenvolvimento de modelos corretos de sistemas. Apresentar ao aluno as etapas seguidas pelo analista de sistemas na construção de um modelo do sistema até a sua implementação, usando essas técnicas. Deverá também saber como e quando utilizar as ferramentas de análise e projeto estruturados.

Apresentação da Disciplina

Page 4: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

OBJETIVOS ESPECÍFICOS◦ Compreender, de forma integrada, a natureza dos sistemas

de informação, sua importância para as organizações para uma melhor compreensão do papel dos profissionais que atuam nessa área;

◦ Utilizar o pensamento sistêmico na solução de problemas, dando condições para que este apresente propostas de pesquisa e desenvolvimento na área de sistemas de informação;

◦ Ter uma visão clara de um sistema, com suas etapas de desenvolvimento e a complexidade implícita em cada uma delas;

◦ Entender e saber aplicar as ferramentas de análise estruturada de sistemas;

◦ Dominar as técnicas da análise essencial.

Apresentação da Disciplina

Page 5: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

YOURDON, Edward. Análise estruturada moderna. Rio de Janeiro: Campus, 1990. 836p.

GANE, Chris; SARSON, Trish. Análise estruturada de sistemas. Rio de Janeiro: LTC, 1995. 257p.

MARTIN, James; McCLURE, Carma. Técnicas estruturadas e CASE. São Paulo: Makron Books, 1991. 854p.

DeMARCO, Tom. Análise estruturada e especificação de sistemas. Rio de Janeiro: Campus, 1989.

HEUSER, Carlos. Projeto de Banco de Dados. 1998

Referências

Page 6: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

SISTEMA

Page 7: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 8: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 9: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 10: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 11: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 12: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Conjunto de elementos interdependentes (entidades relacionadas), ou um todo organizado, ou partes que interagem formando um todo unitário e complexo desenvolvendo atividades ou funções para atingir um ou mais objetivos.

Significado de Sistema

Page 13: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Componentes Básicos de um Sistema

Page 14: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

O objetivo é a própria razão de existência do sistema

Objetivo

Page 15: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

É tudo aquilo que o sistema necessita como material de operação e é obtido no meio ambiente com o qual interage. É a energia que entra no sistema.

Entradas

Page 16: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Transformação de um insumo (entrada) em um produto, serviço, ou resultado (saída). Este processo é a maneira pela qual os elementos componentes de um sistema interagem no sentido de produzir as saídas desejadas.

Processamento

Page 17: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

São os resultados do processo de transformação das entradas;

É o produto final do processamento que será colocado no meio ambiente em que o sistema se insere;

É a forma de o sistema influenciar o meio.

Saídas

Page 18: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

A retroalimentação pode ser considerada como a reintrodução de uma saída sob a forma de informação.

Essa realimentação é um instrumento de regulação retroativa, ou de controle, em que as informações realimentadas são resultados das divergências verificadas entre as respostas de um sistema e os parâmetros previamente estabelecidos.

Realimentação

Page 19: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 20: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Padaria Construção Consultório Médico

Exercício

Page 21: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistemas Naturais Sistemas Feitos Pelos Homens

Tipos de Sistemas

Page 22: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Conceito:◦ “Sistemas feitos pelo homem, que interagem com

ou são controlados por um ou mais computadores” (YOURDON, Edward)

Sistemas Automatizados

Page 23: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistemas Batch Sistemas On-line Sistemas de Tempo Real Sistemas de Apoio à Decisão Sistemas Baseados no Conhecimento

Sistemas Automatizados

Page 24: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

1. Quanto mais especializado é um sistema, menos capaz ele é de se adaptar a circunstâncias diferentes.

2. Quanto maior for um sistema, maior o número de recursos que serão necessários à manutenção diária.

3. Os sistemas sempre fazem parte de sistemas maiores e sempre podem ser divididos em sistemas menores.

4. Os sistemas crescem

Princípios Gerais dos Sistemas

Page 25: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Um sistema de informação é um conjunto organizado de elementos, podendo ser pessoas, dados, atividades ou recursos materiais em geral. Estes elementos interagem entre si para processar informação e divulga-la de forma adequada em função dos objetivos de uma organização.

Sistemas de Informação

Page 26: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Hardware Software Dados Procedimentos Peopleware

Componentes dos Sistemas de Informação

Page 27: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Estratégico

Tático

Operacional

Classificação quanto ao nível organizacional

Page 28: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistema de Processamento de Transações◦ Dados reais e precisos.◦ Saída: relatórios analíticos◦ Frequência: periódica◦ Ex: faturamento, estoque, contabilidade

Operacional

Operacional

Page 29: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistema de Controle Operacional◦ Supervisão◦ Compara o realizado com o previsto

◦ Relatórios consolidados◦ Frequência: periódica◦ Ex: custos, planejamento e controle de produção

Tático

Tático

Page 30: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistema de Apoio à Decisão◦ Média Gerência◦ Análise matemática e estatística dos dados

◦ Saída: gráficos e tabelas◦ Frequência: a pedido◦ Ex: simulação de cenários, análise de

investimentos

Tático

Tático

Page 31: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Sistema de Planejamento Estratégico◦ Alta administração◦ Analisa os fatores críticos de sucesso◦ Trabalha com projeções a longo prazo e tendências

do mercado◦ Saídas: gráficos e tabelas sofisticados◦ Frequência: a pedido◦ Ex: sistemas de informações executivas, BI

Estratégico

Estratégico

Page 32: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Usuários Gerente de Projeto Auditores, Controle de Qualidade e

Padronizadores Analista Projetista Programador Operador

Participantes no Desenvolvimento de Sistemas

Page 33: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Para quem o sistema é construído; O analista deve manter contato constante

com eles; A frase “o cliente tem sempre razão” deve

ser respeitada; Devem ser chamados de Clientes ou

Proprietários.

Usuários

Page 34: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Operadores◦ Têm visão local, isto e, não conhecem o processo

de forma global◦ Responsáveis por executar as funções do sistema◦ Têm uma visão fisica do sistema, ou seja,

imaginam o funcionamento do sistema considerando a tecnologia de implementação

Classificação por Tipo de Função

Page 35: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Supervisores◦ Podem ou não ter uma visão local◦ Geralmente conhecem as operações pois muitos

já foram Utilizadores operadores. Além disso, têm que supervisionar os Utilizadores operadores

◦ Orientado por considerações orçamentais (reduzir o quadro de funcionários ou aproveitá-los melhor)

◦ Normalmente agem como intermediários em relação aos níveis mais elevados

Classificação por Tipo de Função

Page 36: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Executivos◦ Não têm experiência operativa◦ Têm a iniciativa do projeto◦ Possuem uma visão global◦ Têm preocupações estratégicas◦ Capazes de lidar com modelos abstratos

Classificação por Tipo de Função

Page 37: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Amador◦ Nunca trabalhou com um computador◦ Tem dificuldade para entender os modelos

produzidos pelos analistas◦ Receia ser substituído pelo sistema ou ter sua

importância minimizada

Classificação por Nível de Experiência

Page 38: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Novato arrogante◦ Participou de alguns projetos◦ Possui ou trabalha com computadores◦ Por conhecer algumas ferramentas, gosta de

opinar sobre as tecnologias a serem usadas para implementar o sistema

Classificação por Nível de Experiência

Page 39: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Experiente◦ Conhecem a análise de sistemas◦ Têm experiência de outros projetos◦ Discutem sobre as técnicas de modelação sendo

utilizadas

Classificação por Nível de Experiência

Page 40: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Principais funções:◦ Gerenciar e alocar recursos de toda a equipe

técnica ◦ Prestar contas junto à administração superior ◦ Encaminhar problemas identificados no decorrer

do projeto

Gerente do Projeto

Page 41: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Responsáveis por garantir que o sistema será desenvolvido de acordo com os vários padrões internos e externos da organização, especialmente aqueles voltados à segurança e ao controle de qualidade do produto final.

Auditores, Controle de Qualidade e Padronizadores

Page 42: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

O analista de sistemas precisa ter aptidões interpessoais (além do conhecimento da tecnologia), ou seja, deve falar com outras pessoas usando a “linguagem” que elas usam, para não ser considerado amedrontador ou alienígena.

Analista de Sistemas

Page 43: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Desempenha vários papéis:◦ Arqueólogo e escriba◦ Mediador◦ Inovador◦ Líder de projeto

Analista de Sistemas

Page 44: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Características de um bom analista:◦ Possui habilidade com pessoas.◦ Possui conhecimento de aplicações (ajuda a

compreender a empresa do usuário).◦ Possui habilidade em tecnologia.◦ Mente lógica e organizada (visualizar o sistema

sob diferentes perspectivas).

Analista de Sistemas

Page 45: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Tem a função de transformar os requisitos dos usuários, modelados pelo analista de sistemas, em um projeto implementável em um computador.

Normalmente o analista e o projetista são a mesma pessoa, ou membros do mesmo grupo de pessoas.

Projetista de Sistemas

Page 46: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

O analista de sistemas deve fornecer informações suficientemente detalhadas para que o projetista elabore um projeto tecnologicamente bom.

O projetista deve fornecer informações suficientes para que o analista possa dizer se os requisitos dos usuários podem ser completamente atendidos ou devem ser modificados.

Projetista de Sistemas

Page 47: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Responsável por codificar e testar (usando uma linguagem de programação) os módulos do sistema modelados pelos projetistas.

Em um cenário ideal, o programador não deveria ter contato com o analista já que se baseia apenas no trabalho feito pelo projetista.

Programador

Page 48: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Pessoa encarregada de operar os computadores, da rede, da segurança do hardware e das bases de dados, da execução dos programas e da saída das impressoras.

Operador

Page 49: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Conceito: Estudo de um problema, que antecede à tomada de uma

decisão/ação (antes de passar à sua resolução).

Em Sistemas de Informação: Estudo de alguma área de trabalho ou de uma aplicação,

descrição das suas características e funcionalidades, levando geralmente à especificação de um novo sistema.

Análise Estruturada: É a utilização de ferramentas que permitem a

especificação formal dos requisitos do sistema a ser desenvolvido.

Análise

Page 50: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Etapa onde ocorre uma análise detalhada dos requisitos levantados;

São construídos modelos para representar o sistema a ser desenvolvido;

Uma especificação formal dos requisitos é produzida, representando todos os requisitos analisados;

Uma revisão da especificação é realizada, de forma a garantir que a mesma esteja completa, consistente e precisa quanto às informações nela apresentadas.

Análise Estruturada

Page 51: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

O Domínio da Informação de um problema precisa ser representado e entendido;

As funções a serem desenvolvidas pelo sistema devem ser definidas (modelos devem ser desenvolvidos descrevendo a informação, a função e o comportamento do sistema);

Os modelos devem ser particionados de modo que revelem detalhes em forma de camadas;

O processo de análise deve ir da informação essencial até os detalhes de implementação.

Princípios da Análise Estruturada

Page 52: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

É uma representação em pequena escala de um objeto que se pretende executar ou reproduzir em tamanho natural.

Modelo

Page 53: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Mapas: modelos bidimensionais do mundo em que vivemos;

Globos: modelos tridimensionais do mundo em que vivemos;

Pautas musicais: representações gráficas / textuais das notas musicais;

Desenhos arquitetônicos: planta de uma casa, ou edifício, ou ponte...;

Fluxograma: representações esquemáticas de decisões e seqüência de atividades para execução de algum procedimento.

Modelos

Page 54: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

“... podemos construir modelos de maneira a realçar ou enfatizar certos recursos decisivos do sistema, enquanto, simultaneamente, podemos ignorar outros aspectos do sistema. Isto permite que nos comuniquemos com o usuário de uma maneira clara...”

Edward Yourdon

Por que Construir Modelos

Page 55: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Entidade Relacionamento Diagrama de Fluxo de Dados Especificação de Processos Dicionário de Dados

Tipos de Modelos da Análise Estruturada

Page 56: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Percepção de que o mundo real é formado por um conjunto de objetos chamados entidades e pelo conjunto dos relacionamentos entre estes objetos.

Diagrama de Entidade-Relacionamento

Page 57: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Diagrama de Entidade-Relacionamento

Page 58: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Mostram as funções e sub-funções que transformam o fluxo de dados.

Diagrama de Fluxo de Dados

Page 59: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Diagrama de Fluxo de Dados

Page 60: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fornecem uma indicação de como os dados são transformados.

Especificação de Processos

Page 61: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Especificação de Processos

Page 62: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

É uma listagem organizada, com descrições de todos os elementos de dados pertinentes ao sistema.

Dicionário de Dados

Page 63: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Dicionário de Dados

Page 64: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fazer uso de ferramentas, facilitando a comunicação com o usuário e a organização das informações;

Retirar a redundância do documento gerado (especificação estruturada);

Substituir o excesso de texto do documento gerado, por gráficos;

Tornar mais fácil o processo de manutenção, após a codificação.

Vantagens do Uso de Modelos

Page 65: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Possibilidade de focalizar a atenção nas características importantes do sistema, deixando um pouco de lado as menos importantes;

Discutir modificações e correções nos requisitos do usuário com baixo custo e mínimo risco;

Mostrar ao usuário o sistema que será implementado de forma mais clara e objetiva.

Vantagens do Uso de Modelos

Page 66: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Descrever o que o cliente deseja; Estabelecer uma base para a criação de um

projeto do sistema; Definir um conjunto de requisitos que possa

ser validado quando o sistema for construído.

Objetivos do Uso de Modelos

Page 67: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Para desenvolver sistemas úteis, de alta qualidade e que realmente satisfaçam as necessidades dos utilizadores, é necessário considerar os seguintes aspectos:◦ Produtividade;◦ Confiabilidade;◦ Manutenibilidade;◦ Qualidade;◦ Portabilidade;◦ Segurança.

Principais Problemas no Desenvolvimento de Sistemas

Page 68: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Produtividade

Page 69: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Os dois aspectos mais importantes deste problema são:◦ A demanda reprimida (backlog) por novos

sistemas;◦ O tempo necessário para construir um novo

sistema.

Problemas Relacionados à Produtividade

Page 70: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Visível:◦ Solicitados oficialmente pelos utilizadores e que foram

aceites e tiveram suas verbas aproveitadas pela gestão.◦ Ainda não foram iniciados por falta de recursos humanos

(analistas, programadores, etc.) Invisível:

◦ Sistemas que os utilizadores sabem que precisam, mas não se dão ao trabalho de solicitar oficialmente porque ainda estão a aguardar outros projectos

Desconhecido:◦ Sistemas que os utilizadores ainda não sabem que

precisam mas que emergirão logo que sejam concluídos outros sistemas dos backlogs visível e invisível.

Demanda reprimida

Page 71: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Preocupação com a perda de oportunidades de negócios.

Quando o sistema ficar pronto, as condições terão se modificado.

Muitos projetos nem são terminados.

Tempo de desenvolvimento

Page 72: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Problemas técnicos Problemas gerenciais Inexperiência da equipe Falta de tempo para análise e projeto Escasso envolvimento por parte da gerência

ou usuários

Motivos do Fracasso em Alguns Projetos de Software

Page 73: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Contratação de mais profissionais Contratação de profissionais mais

talentosos, com melhores condições de trabalho

Deixar que usuários desenvolvam seus pequenos sistemas (Ex: planilhas de cálculos)

Melhores linguagens de programação Atacar o problema da manutenção Controles de Engenharia de Software Ferramentas automatizadas (Ferramentas

CASE)

Soluções Para Diminuição do Tempo de Desenvolvimento

Page 74: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

A produtividade e a qualidade do trabalho dos programadores está diretamente ligada ao serviço feito pelo analista

Algumas das técnicas de aumento de produtividade têm importância direta para os analistas

A produtividade da análise é um problema politicamente sensível◦ Utilizadores e gestor têm ansiedade pelo início da

programação◦ Utilizadores não entendem a importância da

especificação

Razões Para a Conscientização dos Analistas Quanto à Produtividade

Page 75: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

“Para que servem todas essas figuras e palavras? Nós já explicamos o que queremos. Para que escreveram tudo isso?”

“Quando vocês vão começar a escrever os programas?”

Problemas Que o Analista Enfrenta Com os Usuários

Page 76: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Confiabilidade

Page 77: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

É difícil descobrir como solucionar o erro; Deve-se encontrar todos os pontos de

correção; Alta probabilidade de introduzir novos erros

(efeitos colaterais); Nem sempre são reportados pelos

utilizadores; Dificuldade de reproduzir o erro.

Dificuldades na Detecção de Erros de Sistemas

Page 78: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Em 1979, o sistema SAC / NORAD (que significa Strategic Air Command / Defesa Aérea Norte-Americana) registrou 50 alarmes falsos, incluindo um ataque simulado, os resultados ou saídas ocasionaram acidentalmente um combate ao vivo.

Um erro de programa em um simulador de vôo de avião F16 o levava a ficar de cabeça para baixo, toda vez que cruzava a linha do Equador.

Um míssil de um F18 iniciou sua propulsão quando ainda ligado ao avião e fez a aeronave perder 6000 metros de altitude.

As portas do sistema de trem BART, controlado por computador, em São Francisco, às vezes aberto no tempo entre as estações.

Exemplos de Erros de Software e Suas Implicações

Page 79: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Um sinal de alerta do NORAD, do Sistema de Aviso Rápido de Mísseis Balísticos (BMNEWS), detectou a lua, como um míssil que se aproximava;

O índice da bolsa de valores de Vancouver, no Canadá, perdeu 574 pontos no período de 22 meses, devido a um erro de arredondamento de decimais (por exemplo, arredondar 3,14159 para 3,1416);

Em 28 de novembro de 1979, um avião da Air New Zealand caiu em uma montanha. As investigações posteriores mostraram que haviam sido detectados e corrigidos um erro nos dados do curso do computador, mas nunca foram reportados para o piloto.

Exemplos de Erros de Software e Suas Implicações

Page 80: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Inicialmente o nº de erros encontrados é pequeno (utilizadores sem segurança para apontar erros), como indica T1.

À medida que os utilizadores se familiarizam com sistema os erros são percebidos e reportados (entre T1 e T2).

Após um tempo (após T2) o nº de erros encontrados começa a diminuir (sistema começa a tornar-se mais estável).

O número de erros volta a crescer devido a correções ou modificações que introduzem novos erros (após T3).

A curva nunca atinge zero.

Erros Descobertos em Função do Tempo

Page 81: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Manutenibilidade

Page 82: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Modificações no hardware Novos dispositivos Necessidade de melhorar o desempenho Garantir maior confiabilidade Alterações dos requisitos

Principal dificuldade: documentação desatualizada

Manutenibilidade

Page 83: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Qualidade

Page 84: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

A qualidade de um sistema pode ser mensurada considerando a eficácia e a eficiência obtidas:

Eficácia = Resultados Obtidos / Resultados Pretendidos

Eficiência = Resultados Obtidos / Recurso Consumido

Qualidade

Page 85: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Não contribuem para os objectivos da empresa;

Não atendem às necessidades dos utilizadores;

Não são confiáveis; São ineficientes; Têm manutenção constante, difícil e

onerosa.

Problemas Relacionados à Falta de Qualidade do Sistema

Page 86: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Portabilidade

Page 87: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Consiste em escrever sistemas que podem ser transferidos para outras plataformas.

Apesar de não ser um problema da alçada do analista, ele deve especificar que há essa

necessidade. A portabilidade geralmente provoca

ineficiência já que recursos disponíveis de determinada

plataforma não são aproveitados.

Portabilidade

Page 88: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Segurança

Page 89: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

A segurança de sistemas de informação consiste basicamente em:◦ Impedir o acesso de pessoas não autorizadas;◦ Conceder acesso a certas funcionalidades apenas

a algumas pessoas.

Segurança

Page 90: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Ausência de Planeamento de Sistemas; Ausência de Administração de Dados; Não utilização de Métodos e Técnicas Formais de

Desenvolvimento; Não utilização de Técnicas e Ferramentas; Adopção de Metodologias não ambientadas à realidade da

empresa; Falta de definição precisa dos objetivos e requisitos do

sistema; Dificuldade de comunicação e/ou falta de entrosamento entre

as pessoas envolvidas no processo;◦ Dificuldade de comunicação entre Utilizadores e Desenvolvedores

(linguagem);◦ Rivalidade entre utilizadores;

Falta de precisão e clareza na especificação dos sistemas.

Principais Causas dos Problemas Relacionados à Segurança

Page 91: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Ciclo de Vida do Projeto de Sistemas

Page 92: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Um ciclo de vida de projeto bem definido oferece mecanismos para planejar e acompanhar atividades de forma mais precisa, possibilitando a detecção de problemas de forma mais rápida.

Também conhecido como: Metodologia de Desenvolvimento de Sistemas ou

Plano de Projeto.

Ciclo de Vida do Projeto

Page 93: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

São relativamente informais; São iniciados após um entendimento verbal

entre os usuários e a equipe de projeto; O trabalho de desenvolvimento é feito sem

muito alvoroço.

Pequenas Organizações

Page 94: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Tudo é feito de maneira mais formal; As comunicações entre os usuários, a

gerência e a equipe de projeto são documentadas;

Todos estão cientes da existência de várias fases;

Normalmente o gerente é responsável por definir as fases e atividades do projeto.

Grandes Organizações

Page 95: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Definir as atividades a serem executadas no projeto;◦ Participantes têm uma visão do que estão

fazendo no projeto. Manter consistência entre projetos de uma

mesma organização; Introduzir pontos de verificação para o

controle gerencial de decisões;◦ Permite identificar se o projeto está atrasado e

como corrigir o problema.

Objetivos Para o Ciclo de Vida dos Projetos

Page 96: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Ciclo de Vida Clássico

Page 97: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com
Page 98: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Implementação Bottom-Up (de baixo para cima):◦ Nada está terminado até que esteja totalmente

pronto. ◦ Os erros triviais são encontrados no início do

período de teste e os erros mais sérios são encontrados no final.

◦ A depuração tende a ser extremamente difícil durante os estágios finais dos testes do sistema.

◦ A necessidade de tempo para testes normalmente aumenta exponencialmente durante os estágios finais do projeto.

Desvantagens do Ciclo de Vida Clássico

Page 99: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Progressão Sequencial:◦ As fases são seguidas de forma sequencial.◦ As especificações produzidas em cada fase são

"congeladas". ◦ Os requisitos mudam e é necessário voltar à fase

inicial.◦ Erros são encontrados na especificação e devem

ser corrigidos.

Desvantagens do Ciclo de Vida Clássico

Page 100: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Ciclo de Vida Estruturado

Page 101: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Também conhecida como estudo de viabilidade ou estudo inicial das atividades.

Normalmente é iniciado quando o usuário solicita que algo seja automatizado.

É importante peça para tomada de decisão e no planejamento do sistema.

Fase 1 - Levantamento

Page 102: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Principais objetivos: ◦ Identificar os usuários responsáveis e desenvolver

um "escopo" inicial do sistema: Entrevistas Diagrama de Contexto Diagrama(s) de Fluxo de Dados

◦ Identificar as atuais deficiências no ambiente do usuário.

◦ Estabelecer metas e objetivos para um novo sistema.

Fase 1 - Levantamento

Page 103: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Problema que pode ocorrer:◦ Dificuldade em entender o problema a ser

resolvido.

Fase 1 - Levantamento

Page 104: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fase 1 - Levantamento

Requisitos do Sistema

1.Levantamento

Usuários

Direção

Relatório experimentalde custo/ benefícios

Restrições

Charter

Page 105: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Gerar uma especificação estruturada do projeto do sistema a partir do critério do usuário e da previsão do projeto.

Isso envolve a modelagem do ambiente do usuário usando as seguintes ferramentas:◦ Diagramas de Fluxo de Dados◦ Diagramas de Entidades-Relacionamentos◦ Diagramas de Transições de Estado

Envolve o desenvolvimento de um modelo ambiental e um comportamental.

Fase 2 - Análise

Page 106: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fase 2 - Análise

Requisitos do Sistema

1. Levantamento

Usuários

Direção

Relatório experimentalde custo/ benefícios

Restrições

Charter 2. Análise

Políticas do Usuário

Operações

Restrições

Relatório de custo/ benefícios

Especificação Estruturada

Page 107: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Alocação de partes da especificação (modelo essencial) aos processadores apropriados (pessoas ou máquinas).

Desenvolvimento de uma hierarquia de módulos de programas e interfaces entre esses módulos.

Transformação do modelo de dados em um projeto de banco de dados (dependente da tecnologia adotada).

Deve ser desenvolvido o modelo de implementação do usuário (fronteira homem-máquina e interface homem-máquina).

Fase 3 - Projeto

Page 108: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fase 3 - Projeto

Requisitos do Sistema

1. Levantamento

Usuários

Direção

Relatório experimentalde custo/ benefícios

Restrições

Charter 2. Análise

Políticas do Usuário

Operações

Restrições

Relatório de custo/ benefícios

Especificação Estruturada

3. Projeto

Especificação de projeto

Page 109: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Codificação e integração dos módulos. Programação Estruturada e Implementação

Top-Down. O sistema vai ficando completo

progressivamente.

Fase 4 - Implementação

Page 110: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Criar os testes de aceitação a partir da especificação estruturada.

Pode ser feita paralelamente ao projeto e à implementação.

Fase 5 - Geração de testes de Aceitação

Page 111: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fases 4 e 5

2. Análise

Especificação Estruturada

3. Projeto

Especificação de projeto

5. Geração do Teste de Aceitação 4.Implementação

Sistema integrado

Conjunto de teste de controle de qualidade

Page 112: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Também chamada de teste final ou teste de aceitação.

Exige como entrada os testes de aceitação e um sistema integrado.

Fase 6 - Controle de Qualidade

Page 113: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Descrição formal das partes do novo sistema: manuais

Descrição de como será a interação com o usuário (parte automatizada).

Fase 7 - Descrição dos Procedimentos

Page 114: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fases 6 e 7

5. Geração do Teste de Aceitação

4.Implementação

Sistema integrado

Conjunto de teste de controle de qualidade

6. Controle de Qualidade

Sistema aceito

2.Análise

Especificação Estruturada

7. Descrição de Procedimentos

Manual do Usuário

Page 115: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Desenvolver programas para converter os dados existentes para o novo banco de dados.

Fase 8 - Conversão do Banco de Dados

Page 116: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Passagem imediata x gradual. Treinamento dos usuários.

Fase 9 - Instalação

Page 117: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Fases 8 e 9

9. Instalação6.Controle de Qualidade

Sistema aceito

Sistema instalado

8.Conversão de Banco de Dados

Banco de Dados convertido

3.Projeto Especificação de projeto

Operações Banco de Dados existente

Page 118: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Abordagem Radical do ciclo de vida:◦ As atividades do projeto são executadas em paralelo (a

codificação começa no primeiro dia). Abordagem Conservadora do ciclo de vida:

◦ Uma atividade só é iniciada quando a anterior foi concluída.

Ambas as abordagens são perigosas pois são os extremos.

Podem ser adotadas abordagens intermediárias:◦ Iniciar uma fase quando 75% ou 50% da anterior estiver

concluída.◦ Executar duas atividades em paralelo (levantamento e

análise).

Abordagem Radical X Conservadora do Ciclo de Vida

Page 119: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Para cada projeto, uma abordagem diferente pode ser usada, baseada nos seguintes fatores:

Quão inconstante é o usuário?◦ Usuários inconstantes ou inexperientes requerem

uma abordagem mais radical.◦ Usuários veteranos se adequam mais a uma

abordagem mais conservadora. Pressão para produzir resultados imediatos

e palpáveis.

Abordagem Radical X Conservadora do Ciclo de Vida

Page 120: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Para cada projeto, uma abordagem diferente pode ser usada, baseada nos seguintes fatores:◦ Pressão sobre o gerente do projeto para produzir

um cronograma, um orçamento e avaliação de pessoas e outros recursos: Radical (precoce) -> maior erro. Conservadora -> menor erro.

◦ Perigo em cometer um erro técnico (implementação inviável).

Abordagem Radical X Conservadora do Ciclo de Vida

Page 121: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Na prototipação cada necessidade levantada é simulada no protótipo, que é expandido e refinado gradualmente.

Também conhecido como desenvolvimento heurístico.

É uma alternativa atraente para lidar com a incerteza, a ambigüidade e a inconstância dos projetos.

No final da modelagem o protótipo será desprezado e substituído por um programa real pois ele é apenas um modelo.

Ciclo de Vida da Prototipação

Page 122: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Os prototipadores normalmente utilizam os seguintes tipos de ferramentas:◦ Dicionário de dados integrado.◦ Gerador de tela.◦ Gerador de relatórios não-procedural.◦ Linguagem de programação de quarta geração.◦ Linguagem de consultas não-procedural.◦ Recursos poderosos de gerenciamento de banco

de dados.

Ciclo de Vida da Prototipação

Page 123: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

Projetos que são bons candidatos para a abordagem de prototipação têm as seguintes características:◦ O usuário é incapaz ou não deseja examinar

modelos abstratos de papel como DFD's.◦ O usuário é incapaz de exprimir os seus

requisitos, podendo identificá-los através de tentativas e erros ("Eu não sei o que quero, mas eu saberei, se o vir").

◦ O sistema está previsto para ser on-line (a maioria das ferramentas de apoio são orientadas para a abordagem on-line).

Ciclo de Vida da Prototipação

Page 124: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

◦ Não exige a especificação de grandes quantidades de detalhamento algorítmico.

◦ O usuário está mais interessado no formato e na diagramação da entrada e da saída.

Ciclo de Vida da Prototipação

Page 125: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

A abordagem da prototipação pode ser combinada à análise estruturada como uma forma de auxiliar a descoberta/especificação dos requisitos.

A abordagem Top-Down pode funcionar como uma forma de prototipação, na qual cada versão contém mais funcionalidades e está mais próxima do desejo do usuário.

Ciclo de Vida da Prototipação

Page 126: Fabrício Costa Santana professorfabricio.net prof.fabricio@outlook.com

O risco em adotar o protótipo com um sistema de produção é grande e pode ser desastroso porque:◦ Não foi preparado para manipular eficientemente

grandes volumes de transações.◦ Carece de detalhes operativos como:

Recuperação de erros, documentação do usuário, procedimento de conversão.

◦ O projeto pode terminar sem que tenha sido produzida qualquer documentação formal, que deveria ser mantida ao longo da vida do sistema.

Ciclo de Vida da Prototipação