Baixe Análise e Projeto de Sistemas II e outras Manuais, Projetos, Pesquisas em PDF para Informática, somente na Docsity! CURSO DE TECNÓLOGO EM PROCESSAMENTO DE DADOS Prof. Sérgio Luiz Tonsig 2000 Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 2 FACULDADE DE TECNOLOGIA DA ALTA NOROESTE Curso de Tecnólogo em Processamento de Dados Disciplina: Análise e Projeto de Sistemas II Prof.: Sérgio Luiz Tonsig* Ementa: Desenvolver a especificação de sistemas, através de estudos de casos, propiciar uma visão geral sobre as etapas que devem ser seguidas para o efetivo desenvolvimento de um projeto e seus aspectos gerenciais. • Docente da Faculdade de Tecnologia da Alta Noroeste. Especialista em Sistemas de Informação pela Universidade Federal de São Carlos. Mestrando em Gerência de Sistemas de Informação de PUC Campinas. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 5 a) Os custos, consumo e desgaste dos equipamentos são zero b) A capacidade de armazenamento de dados do sistema é infinita c) A velocidade dos processadores é infinita d) O tempo de acesso a dados é instantâneo e) Zero Erro (não ocorrem falhas) Através deste método faz-se um exame do domínio do problema (levantamento de dados acerca do sistema que será feito) inicialmente enfocando os aspectos mais essenciais pertinentes ao problema. A análise essencial, é constituída basicamente por duas fases ou modelos: Ambiental e o Comportamental. Modelo Ambiental No modelo ambiental tem-se a especificação macro do sistema (como se fosse uma caixa preta) inserido em um meio ambiente, busca-se representar a relação do sistema com o meio onde ele está, através de estímulos provenientes do meio e respostas a estes estímulos, que poderão ser internas ao sistema ou ainda serem devolvidas para o meio ambiente. Três grandes atividades são elaboradas neste modelo: Declaração dos Objetivos do Sistema, a elaboração do Diagrama de Contexto e a especificação da lista de eventos. Declaração de Objetivos Trata-se da especificação daquilo que o sistema deverá fazer, frente aos problemas existentes na organização para o qual ele será feito. Deve também, tanto quanto possível, refletir os desejos do usuário no que diz respeito as solicitações que ele tenha apresentado como alternativas de solução dos problemas. Naturalmente antes da elaboração dos objetivos do sistema, o Analista deverá ter efetuado um minucioso levantamento de dados (checando inclusive requisitos do sistema), conhecendo profundamente o chamado domínio do problema. Se o sistema for referente a controle de uma biblioteca, o Analista precisa saber tudo sobre bibliotecas, regras gerais, linguagem utilizada, detalhes e exceções. Diagrama de Contexto Após a especificação formal dos objetivos do sistema, o Analista já estará em condições mais apropriadas para elaborar o diagrama de contexto. Ele reflete graficamente a relação do sistema com o meio ambiente onde está inserido. Esta relação dá-se através do recebimento de estímulos do meio ambiente, os quais ativam processos, e estes, por sua vez geram respostas, que podem vir a ser respostas externas ao sistema, ou seja, resposta ao meio ambiente. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 6 Lista de Eventos Trata-se da especificação das atividades (processos) essenciais que o sistema terá . Elas são ativadas por estímulos (fluxo de dados, fluxo temporal ou de controle), fazem algum processamento e geram respostas. Não há uma precedência estabelecida para a elaboração da lista de eventos e o diagrama de contexto, são atividade que podem estar acontecendo paralelamente inclusive. Modelo Comportamental O modelo comportamental é a fase em que o Analista passa a olhar para dentro do sistema. Irá detalhar como cada atividade existente na lista de eventos se comporta (como ela deve funcionar). Também fará um modelo de dados sobre o qual o sistema atuará, observando critérios para conseguir boa performance na sua utilização (através da normalização de dados). Acompanhando mais efetivamente este modelo (muito embora já possa existir antes dele) cria-se o dicionário de dados. Também nesta fase elabora-se o D.F.D. Hierárquico, que nada mais é do que o agrupamento de atividades essenciais afins (síncronas), que enfocam determinado aspecto no sistema. Diagrama de Fluxo de Dados Particionado por Evento Para cada item da lista de eventos o Analista de Sistemas fará um Diagrama de Fluxo de Dados, representando de forma gráfica, individualmente, cada evento existente no sistema. Desta forma, haverá tantos diagramas de fluxo de dados particionado por eventos, quantos forem os itens existentes na lista de eventos. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 7 Diagrama Entidade Relacionamento Para modelagem de dados, o Analista de Sistemas fará inicialmente o D.E.R. Com este diagrama terá um poderoso instrumento para mapear como os dados estão organizados e como eles se relacionam. Em cima deste modelo, pode ser aplicado a teoria da Normalização, que permitirá extrair melhor performance quando da utilização da estrutura dos dados. Diagrama Hierárquico de Macro Atividades Trata-se de um D.F.D. onde se propiciará uma visão de Macro Atividades. Pega-se os diagramas de fluxo de dados particionados por eventos e verifica-se quais são aquelas atividades afins (síncronas – que tratam determinado assunto). Estes processos são aglutinados em um único, de tal forma que se obterá uma visão mais sintética da representação do sistema, cuja finalidade é, além da documentacional a possibilidade de examinar e definir interfaces e locais de processamento. A fim de facilitar a construção do DFD Hierárquico (através de uma visão mais global do sistema), pode-se antes elaborar o chamado Diagrama Preliminar, que consiste em pegar todos os DFDs particionados por evento e torná-lo um só (visão única de um DFD com todos os processos existentes). Dicionário de Dados Todos os dados referenciados na construção do sistema, deve ter sua definição no dicionário de dados. Para a construção do dicionário existem alguns padrões, dos quais, vamos adotar o segue: Símbolo Significado = É composto de + E ( ) Opcional (pode estar presente ou ausente) { } Iteração (Repetição) [ ] Escolha uma das opções * * Comentário @ Indica campo chave | ou / Separa Alternativas na construção [ ] Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 10 Descritivo da Solução Escolhida “Depois de estudar o volume de dados processado pelo sistema atual e considerando o tempo de resposta requerido, chego a conclusão que o sistema novo precisará de quatro pessoas e um pequeno computador comercial. Deverá ser atribuído tanto trabalho quanto for possível ao computador de modo a poder minimizar os custos de processamento. Porém, não ser correrá o risco de perder clientes por força-lo a um contato direto com o computador (considerando a situação atual da interface homem/máquina); consequentemente, optou-se por alocar tudo ao computador, exceto as partes das atividades essenciais que envolvem um contato direto com os clientes do hotel. Uma atividade essencial, Cancelar não comparecimento, não requer nenhum contato direto com o cliente e, portanto, pode ser desempenhado diretamente pelo computador.” O que vem a seguir é a especificação técnica do projeto do sistema, começando inicialmente pelo modelo ambiental. 1.1.3.1. Declaração do Objetivo do Sistema Controlar o serviço de reservas, registros e cobrança de quartos de um sistema hoteleiro. 1.1.3.2. Diagrama de Contexto Cliente Cliente Sistema Hoteleiro Cli_Reserva Cli_Cancel Cli_Rejeit Cli_Pac_Entr Cli_Ent Cli_Sai Gerência Cli_Conta Cli_Paga Ger_Lib Ger_Can Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 11 1.1.3.3. Lista de Eventos do Estudo de Caso Nº Evento Descrição do Evento Estímulo Tipo Estímulo Ação Resposta 01 Cliente Reserva Quarto Quando o cliente telefona ou vem até o hotel e pede para reservar um quarto, o funcionário executa um procedimento padrão Cli_Reserva F Efetuar Reserva Cli_Reservado ou Cli_Indisp 02 É hora de cancelar reserva Quando o cliente não comparecer ao hotel para hospedar-se até as 12:00 horas do dia da reserva - T Cancelar Reserva Automaticamente Ger_Cancel 03 Cliente registra- se no hotel Cliente faz o registro para a ocupação do quarto, reservado previamente. Caso não reservado uma mensagem de rejeição será emitido, caso contrário um pacote com informações será fornecido Cli_Ent F Registrar Cliente Cli_Pac_Ent ou Cli_Rej 04 Cliente solicita saída do hotel Quando o cliente deixar o hotel este solicita que providencie o fechamento de sua conta, havendo a disponibilidade do quarto para limpeza Cli_Sai F Fechar Quarto Cli_Conta 05 Cliente paga a conta Cliente paga a quantia correspondente ao aluguel do quarto e às despesas efetuadas durante sua estadia Cli_Paga F Registrar Pagamento Cli_Recibo 06 Cliente cancela a reserva Quando o cliente não mais desejar o quarto reservado e comunicar o fato, será cancelado a reserva, disponibilizando o quarto novamente Cli_Cancel F Cancelar Reserva por Solicitação Cli_Canc 07 Gerência disponi- biliza quarto Quando o quarto estiver limpo o gerente torna-o disponível Ger_Lib F Liberar Quarto Msg_01 08 Gerência cadastra quarto Gerência inclui, exclui ou modifica dados do quarto Ger_Cad F Manipular cadastro de quarto Msg_02 Como você sabe, deve haver entre a lista de eventos e o diagrama de contexto uma consistência. É importante lembrar também que a Lista de Eventos ou Diagrama de Contexto podem ser desenvolvidos paralelamente. Exercício: Cheque ambos (Lista de Eventos X Diagrama de Contexto) e acerte as possíveis inconsistências encontradas. (eventuais alterações faça sobre o próprio manual, no local adequado, a fim de que você tenha o material completo para estudo) Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 12 1.1.3.4. DFD Particionado por Evento Depois que a lista de eventos estiver concluída (é claro que as vezes você esquecerá um ou outro evento, que depois podem ser acrescentados, mas, com certeza os eventos essenciais estarão lá), você deverá fazer o Diagrama de Fluxo de Dados particionados por Eventos, também conhecido como Diagrama das Atividade Essenciais. Em nosso estudo de caso, conforme nossa lista de eventos, deverá haver oito DFDs particionados por evento. Abaixo, como exemplo, segue o Diagrama correspondente ao primeiro evento da lista. Evento 01 – Cliente Reserva Quarto Exercício: Faça o D.F.D. particionado por eventos para os demais itens da lista de eventos. (antes porém, a seguir, dê uma olhada no modelo de dados completo que é utilizado neste estudo de caso – pág. 21) Efetuar Reserva Cliente CadClien CadReser va CadQuarto Cli_Reserva Cli_Reservado ou Cli_Indisp Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 15 Exemplo de português estruturado: DFD Particionado Por Evento - Evento 01 – Cliente Reserva Quarto Reservar Quarto Cliente CadClien CadReser va CadQuarto Cli_Reserva Cli_Reservado ou Cli_Indisp Miniespecificação PEGAR dados Cli_Reserva SE cliente inexistente, faça seu cadastro (para campo Cli_Sit jogar 0 ) PARA reservar quarto, faça: MOSTRAR lista de quartos livres para reserva ( todos que tiverem Qua_Sit = 0 ) SE não existir pelo menos um quarto livre, faça: Mensagem “Desculpe, Hotel totalmente ocupado.” Encerrar FIM SE QUANDO escolhido um quarto livre, faça: MARCAR quarto como reservado (jogar 1 para campo Qua_Sit) MARCAR cliente como solicitado reserva (jogar 1 para Cli_Sit) FIM QUANDO FIM PARA Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 16 Pseudocódigo Basicamente, pseudocódigo e português estruturado não trazem grande diferença, contudo é possível distinguir entre ambos (algumas vezes os termos são usados indistintamente como sinônimos). O pseudocódigo usa notação mais formal, mais orientada ao profissional de processamento de dados, empregando as palavras chaves e tentando seguir uma sintaxe bem mais próxima de uma linguagem de programação. Usa-se palavras-chaves para realçar o que seriam comandos utilizadas nas linguagens de programação; por exemplo: SE, SENÃO, ENTÃO, FIMSE, REPETIR, ENQUANTO, REPETIRATÉ, FIMREPETIR, ENCERRAR. Com relação as expressões lógicas, emprega-se a mesma gama de signos: >, <, =, <=, >=, E, OU. A grande desvantagem em se utilizar pseudocódigo, no lugar do português estruturado, é que neste, se possibilita no próprio texto uma explicação mais detalhada acerca do processo que está sendo especificado. No pseudocódigo, também é possível agregar explicação, porém deve seguir como se fosse um comentário em uma linguagem de programação, devendo ficar entre /* */. /* um comentário qualquer em pseudocódigo */ Vamos examinar a seguir, como fica o exemplo feito em português estruturado referente ao evento essencial 01, agora refeito em pseudocódigo Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 17 Efetuar Reserva Cliente CadClien CadReser va CadQuarto Cli_Reserva Cli_Reservado ou Cli_Indisp Miniespecificação PEGAR Cli_Reserva SE cliente = “inexistente” ENTÃO EXECUTAR Cadastro_Cliente SE reservar = VERDADEIRO ENTÃO: EXECUTAR Lista_Quartos_Livres SE quarto = “inexistente” ENTÃO: Mensagem “Desculpe, Hotel totalmente ocupado.” ENCERRAR FIM SE SE quarto = “escolhido” ENTÃO: Qua_Sit = 1. Cli_Sit = 1. FIM SE FIM SE Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 20 Condições Regras de Decisão e ações 01 02 03 04 05 06 07 08 09 10 11 12 Cliente é Pessoa Física ? S S S S S N N Ultima Compra foi feita a menos que 15 dias ? S N N N N - - Ultima Compra foi feita a menos que 30 dias ? - S N N N - - Ultima Compra foi feita a menos que 45 dias ? - - S N N - - Ultima Compra foi feita a menos que 90 dias ? - - - S N - - Ultima Compra foi feita a mais de 90 dias ? - - - - S - - Saldo Devedor ? - - - - - N S Emitir Congratulações X Emitir uma pesquisa X Enviar Catálogo X X Enviar Convite X Enviar Telegrama X Enviar carta cobrança X Exercício Para o mesmo enunciado do exercício existente na página 17, construa uma tabela de decisão. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 21 Miniespecificação de Processos Orientação e Padronização para aplicação no T.C.C. Uma miniespecificação vai tratar apenas das linhas genéricas do processo, enfatizando os aspectos essenciais e aqueles que referem-se as regras do negócio, de tal maneira que, se não houver esta especificação, um programador não fará satisfatoriamente o programa, ou seja, ele não será um programa válido, de acordo com a realidade que deve atender. Portanto ninguém sairá ditando detalhadamente como fazer um programa para incluir, alterar, excluir ou consultar cadastros, deverá ser apresentado apenas a síntese do objetivo global do processo, salvo se houver detalhes de implementação proveniente das regras do negócio, neste caso, haverá um miniespecificação um pouco mais ampla. Para qualquer miniespecificação sugere-se a utilização de uma ferramenta que tente evitar ao máximo ambigüidades de interpretação, com relação as idéias que estão sendo expressas. Neste sentido emprega-se: Português Estruturado, Pseudocódigo, Tabelas de Decisão ou Árvores de Decisão. O método da análise essencial indica estas ferramentas para a miniespecificação, porém, deixa em aberto o formato de apresentação da miniespecificação. Muitos autores, influenciados pela fase estruturalista da análise, normalmente exemplificam uma miniespecificação de forma estruturada, conforme exemplo a seguir: Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 22 Verifica-se contudo, que é perfeitamente livre a criação de uma miniespecificação em outros formatos, propiciando formas mais abstratas, sem a idéia de uma estruturação. Este fator é de fundamental importância, já que, com um formato mais abstrato, tem-se uma análise imparcial com relação a linguagem de implementação. Um modelo mais abstrato de miniespecificação, possibilita sem qualquer tipo de influência, que o Analista se decida por implementar utilizando uma linguagem estruturada, linguagem de quarta geração, ou orientação a objetos. Dentro desta perspectiva, com intuito de estabelecer um único formato para as miniespecificações dos TCCs, será adotado o formato mais abstrato. Segue exemplo e algumas observações a serem consideradas, com relação ao formato proposto. O exemplo a seguir é o mesmo mostrado anteriormente, porém, utilizando a forma que deverá ser empregada nos TCCs. PEGAR Cli_Reserva SE cliente = “inexistente” ENTÃO EXECUTAR Cadastro_Cliente SE reservar = VERDADEIRO ENTÃO: MOSTRAR Lista_Quartos para escolha de um SE quartos escolhidos = “ocupados” ENTÃO: Mensagem “Desculpe, Hotel totalmente ocupado.” (Qua_Indisp) ENCERRAR FIM SE SE quarto = “livre” ENTÃO: Qua_Sit = 1. /* marcar quarto como ocupado */ Cli_Sit = 1. /* marcar cliente com reserva feita */ Mensagem “Reserva Concluída.” (Qua_Reservado) FIM SE FIM SE Efetuar Reserva Cliente CadClien CadReser va CadQuarto Cli_Reserva Qua_Reservado ou Qua_Indisp Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 25 1.1.3.6. Modelagem de Dados do Estudo de Caso O Analista verificou que havia uma relação entre Clientes e Quartos (Reserva), sobre a qual deveria armazenar informações. Desta forma, o Analista de Sistemas gerou o Diagrama de Entidade Relacionamento, fazendo uma modelagem lógica de dados, conforme segue: Cli_cpf Qua_Nr Cli_nome Qua_Descr Qua_Sit Cli_End Res_DataIn Res_DataFi Qua_Val Cli_Sit Cli_Ult_Data É claro que antes de se chegar a este modelo de dados (D.E.R.), para cada depósito de dados que existia nos DFDs particionados por evento, foi elaborado uma lista de atributos, e eleito a chave principal. Depois, ao modelo inicialmente obtido, foi aplicado a teoria da normalização (1ª, 2ª e 3ª formas normais). O passo seguinte é a partir da modelagem lógica dos dados, gerar sua modelagem física, ou seja, criar um modelo de dados com uma forma a partir da qual os dados serão implementados de fato. Para tanto, gera-se o Diagrama de Estrutura de Dados. Aqueles relacionamentos existentes do DER, para os quais foi verificado a necessidade do armazenamento de atributos, no DED serão transformados em uma Entidade (depósito de dados), conforme visto a seguir. Reserva CadRese CadClien CadQuarto Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 26 Cli_cpf Qua_Nr Cli_nome Qua_Descr Qua_Sit Cli_End Res_DataIn Res_DataFi Qua_Val Cli_Sit Cli_Ult_Data Portanto, para modelo físico, o analista designou o nome CadClien para o arquivo ou tabela onde iria ser armazenado os dados do cliente, de igual forma CadQuarto para os dados do quarto e CadReser para os dados da reserva. CadClien CadReser CadQuarto Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 27 1.1.3.7. Diagrama Hierárquico de Macro Atividades Uma vez concluído os DFDs particionados por evento, pode-se desenvolver este diagrama. Ele consiste em um DFD que agregará eventos relativos a um mesmo assunto, permitindo uma visão simplificada do sistema. Clientes 1, 2, 6 Tratar Reserva Cli_Reserva Cli_Reservado ou Cli_Indisp Cli_Cancel Cli_Canc CadClien CadReser CadQuarto 3,4 Tratar ClienteClientes Cli_Ent Cli_Cancel Cli_Sai Clientes Cli_Conta Cli_Paga Cli_Reserva Gerência Ger_Cancel 7,8 Tratar Quarto Msg_01 Msg_02 Ger_Lib Ger_Cad Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 30 1.1.3.9. CASE - (Computer Aided Software Engineering) Engenharia de Software Auxiliada por Computador Este termo foi criado no começo dos anos 80, atribuído a qualquer software que busca auxiliar o Analista na construção de sistemas. Teoricamente, para uma ferramenta ser considerada um software CASE, ela deve incorporar e suportar toda a trajetória e técnicas de especificação e construção de um sistema de acordo com determinado método. Deve ainda gerar o código fonte de acordo com uma linguagem escolhida, compativel com o método empregado. No caso de Orientação a Objeto, deverá gerar o código fonte em uma linguagem OO, ou trabalhar integrado a um repositório de metadados de um banco de objetos. Pelo fato de existir softwares de apoio ao desenvolvimento de sistemas, que não atendem na integra a definição teórica de CASE, foi criado termos para classifica-los, tais como UPPER-CASE, LOW-CASE. Se um software auxilia o analista apenas na parte inicial da metodologia, onde são tratados os aspectos lógicos (especificação/documentação) é dito que ele é um UPPER- CASE, porém, se o software auxilia na modelagem lógica e física, propiciando até a possibilidade criação da base de dados, pode-se classificá-lo como um LOW-CASE. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig 31 2. Projeto (“design”) Project do Inglês maior do que aquele representado pela nossa palavra projeto. Project leva em consideração fases anteriores ao nosso projeto, abordando tarefas de planejamento, O projeto, de que vamos tratar a partir deste ponto, portanto, é o projeto propriamente dito (no inglês encontramos mais adequadamente a palavra ). O Projeto Estruturado Moderno de Sistemas é a atividade de transformação das implementação através da automação eletrônica. O objetivo é modelar o sistema determinando implementar, num ambiente em que deixa-se de ter a tecnologia perfeita, passando a levar em consideração o hardware As restrições de implementação, da tecnologia não ideal e imperfeita serão incorporadas através de atividades de infra-estrutura e administrativas. Completeza O projeto não deve perder nada do que foi identificado na fase de análise como requisito Manutenibilidade Deve-se projetar um sistema de forma a permitir facilidades de alterações, provenientes Erros do Sistema Novas necessidades do usuário (observa-se que os sistemas mais fáceis de alterar são aqueles construídos de forma modular desempenhando funções bem definidas e coesas) Ela está diretamente relacionada ao uso otimizado dos recursos de hardware, software e pessoal disponíveis. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 32 Com relação aos fatores que afetam o desempenho, temos: Deficiência do Projeto de Interface Vários cuidados devem ser tomados quando se projeta uma interface (superfície entre duas faces), mecanismos pelo qual ocorre a comunicação atual homem-máquina. A interface deve permitir que a comunicação se estabeleça no sentido homem-máquina e vice-versa, devendo ser um mecanismo de mão dupla, permitindo ao homem não apenas ser o agente deflagrador de um processo comunicativo, mas contemplar o desenrolar do mesmo; intervindo, requerendo ou sendo requisitado. Quando houver entradas de dados referentes a um documento fonte original, a partir do qual as informações estão sendo transcritas, a ordem dos campos na tela (quando for o caso de um vídeo) deve obedecer a mesmo ordem dos campos existentes no documento, principalmente quando se tratar de um grande volume de transação. O analista de sistema deve estar atento e acompanhado o nascimento de novos meios para o input de dados nos computadores (voz, ondas cerebrais e outros), adequando sempre a interface segundo o novo contexto. Tempo de acesso a disco e periféricos Observe que para este tópico, deve-se conhecer muito bem o ambiento topológico do hardware em que se está trabalhando e sua periferia (de periféricos), além é claro do hardware que está sobre esta estrutura. Devido ao tempo gasto em acesso a discos (que atualmente é muito maior do que as operações na CPU), deve-se prover o sistema de mecanismos que minimizem este tempo, empregando-se organizações de arquivos adequadas, ou ajustando o parque de hardware. Falta de Reorganização de Arquivos Em arquivos grandes de muita utilização, deve-se verificar a possibilidade de limpezas periódicas, ou particionamento do arquivo, gerando um atual e um outro histórico. Processos longos em horário de pique Evite ao máximo a execução de processos batch de longa duração (transferências de grandes arquivos, atualização de grande volume de dados) durante o horário de pique. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig 35 Há várias formas que podem ser apresentadas para satisfazer visualmente a alocação de PC-01 P01 Cliente Reserva Quarto Diária P02 É hora de cancelar reserva Batch Diário PT01 Executar Antivírus Batch Semanal PC-02 Pentium 133 P07 Quando Quarto estiver limpo gerente disponibiliza-o On-Line Diário PT01 Executar Antivírus Batch Semanal PT02 Backup dos Dados Batch Diário PT03 Reorganização de Arquivos Batch Anual . . . Pnn = Atividade Essencial da lista de eventos PTn = Processo de restrição Tecnológica O exemplo acima leva vantagens sobre o anterior, notadamente pelo fato de que pode ser aplicado a pequenas ou grandes quantidades da relação processador X processo. No modelo anterior, fica muito difícil a representação de vários processos a serem executados em um mesmo processador num mesmo período. Processador Processo Evento Tipo Processamento Frequência Análise e Projeto de Sistemas II Página: 36 2.3.1 Verificação e Validação “Em 22 de Julho de 1962, o foguete espacial Mariner I foi lançado em um primeiro desviou de sua rota e o controle terrestre deu a ordem para explodi-lo. Posteriormente, uma investigação revelou que o software apresentava erros. A omissão de um simples fracasso de toda a missão. O custo para o contribuinte fiscal foi de 18,5 milhões de dólares” (MARTIN & MCCLURE, 1991:737). comparado ao Mariner I, contudo, poderá se enquadrar nas mesmas proporções catastróficas, quanto aos possíveis erros que venha a apresentar. desenvolvidos, apesar dos esforços especiais que se tem empregado para se atingir a perfeição. A preocupação com tais fatos, se deve ao prejuízo econômico que eles podem Certamente que a proeza de se conseguir um software 100% correto no momento de sua elaboração, nem sempre é uma tarefa possível, mas isto seria o ideal. verificação e validação, fazendo uso de técnicas dirigidas. Um questionamento sempre levantado sobre tais atividades, refere-se ao momento ideal durante o mesmo ? Constata-se que a correção deve ser aplicada por todo o ciclo de desenvolvimento, “Verificação é a demonstração da consistência, completeza e correção do software à medida que ele evolui... Validação é a demonstração de que o sistema de software & MCCLURE, 1991:734). Nota-se então, que a verificação busca corrigir o software etapa por etapa, durante o ciclo finalizado. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 37 Além do software final livre de erros, a economia monetária e de tempo que se pode obter quando se utiliza as atividades de verificação e validação, são consideráveis. A trajetória básica e mínima que se espera que o Analista deva seguir é sugerido abaixo: Com relação a Verificação Efetuar testes de unidade a cada módulo do software desenvolvido, verificando se este atinge seus objetos sem apresentar qualquer anomalia na execução e no desempenho lógico. Lembre-se de que teste deve ser a incansável busca de erros, e a depuração, a eficiente eliminação dos erros encontrados. Com relação a Validação Primeiro efetuar um teste funcional do sistema, onde, após todos os módulos terem passado pelo teste de unidade, verifica-se como se comportam quando executados em conjunto. Submeter, este processo de teste funcional, a um rigoroso exame pelo usuário, a fim de que se manifeste sobre a validade do produto. Segurança de Dados Por incrível que pareça, muitos daqueles diretamente ligados a tecnologia da informação, tais como tecnológos, analistas, programadores, raramente, ao editar um texto, por exemplo, tem a preocupação de efetuar um backup. O que pensar então de um usuário mais leigo ? É fundamental, em qualquer sistema de informação, sob qualquer aspecto, que haja mecanismos para salvaguardar os dados manipulados no sistema. Tais mecanismos podem ser desde meras rotinas diárias de backup, até sofisticados hardwares com o meio de armazenamento espelhado e componentes redundantes, ou ainda técnicas de replicagens da informação. Para a transação da informação também há absoluta necessidade de segurança. Sob este aspecto podemos considerar dois fatos: 1) Duas ou mais operações acionadas em um processo que, para manter a integridade da informação, todas as operações devem ser corretamente concluídas. Havendo falha de uma, todo o processo deve ser revertido (Roll-Back). 2) Casos em que uma informação em trânsito poderá exigir sua mais absoluta inviolabilidade deve passar pelo processo de criptografia. Análise e Projeto de Sistemas II Página: 40 mencione: Nome da tela/Relatório Data / Hora Página no caso de um desenvolvimento para o ambiente WINDOWS, você deve respeitar todas as características de interface já definidas. Atualmente existe um leque muito grande de recursos para tornar amigável a interface homem-máquina. atualmente melhor estão sendo empregadas, já que é uma forma bastante amigável de enviar e receber informações. como sons, imagens estáticas, animadas ou filmadas e outros elementos de multimídia. “Multimídia é a combinação de texto, som e vídeo para apresentar informações por muda a maneira como as pessoas usam os computadores...” (JAMSA, 1993:XIII). Por exemplo, em um sistema de controle de biblioteca, poderia-se ter além da opção de na língua previamente escolhida, e também, a seu critério, poderia “ver” as imagens relativas a estória que estaria sendo narrada. possibilidade futura da inexistência de um vídeo como hoje o concebemos, mas a projeção de imagens holográficas, propiciando a interação através de uma realidade circunstâncias normais ( como por exemplo, caminhar dentro de um vulcão ou tapar sua chaminé e verificar o resultado, segundo as leis da física ). Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 41 3. Gerência de Projetos A partir deste ponto vamos tratar de projeto (“Project”) no sentido do empreendimento global, diferente portanto de projeto (“design”) que é apenas uma fase dentro deste empreendimento. Exceto pela execução das atividades de desenvolvimento propriamente dito, que envolvem metodologias, técnicas e ferramentas de desenvolvimento, tudo mais em um projeto de sistemas é ação de gerência. Assim deve-se ter em mente o que segue, como definição do nosso empreendimento global: Projeto de Sistemas = estabelecimento de OBJETIVOS + Planejar e executar ATIVIDADES + Administrar PRAZOS + Gerenciar RECURSOS + Conviver com RISCOS/INCERTEZAS 3.1 Problemas em projetos de sistemas 3.1.1 Relacionados com a rápida evolução da tecnologia • Proliferação desordenada de microcomputadores • Vida útil do Hardware • Grande quantidade de software não integrado • Aumento dos níveis de expectativa devido à divulgação instantânea das inovações • Ferramentas de desenvolvimento muito recentes, ainda não consolidadas Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 42 3.1.2 Relacionados com pessoas • As pessoas freqüentemente não sabem o que realmente querem ou necessitam • desenvolvimento de sistemas exige muita comunicação: - No. De interações dois a dois = N(N – 1) / 2 - Muitas pessoas falam bem, pouquíssimas ouvem bem - Palavras tem diferentes significados • É muito comum desenvolvedores não ouvirem os usuários e raramente constróem o que é necessário • Desenvolvedores não aceitam mudança no seu próprio domínio (paradigma de comportamento) • Conflitos sempre existirão. Cabe ao gerente administrar adequadamente 3.1.3. Outros problemas Gerenciais “ Imprevisibilidade “ previsível Férias de elementos da equipe Baixa disponibilidade de recursos de hardware Alocação temporária de pessoal para outro sistema Mudança de prioridades da organização Seleção de pessoal Quantidade X Qualidade Nível do profissional (conhecimento X experiência X dinamismo ) A somatória destes dois fatores trás como conseqüência um terceiro: Dificuldade de estimar prazos e recursos Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 45 4. Processo de Gerência de Projeto 1. Defina os objetivos do projeto Repetir 2. Planejar as tarefas para alcançar os objetivos 3. Organizar / Coordenar os recursos – colocar as tarefas em execução 4. Avaliar o progresso em relação ao plano – até alcançar os objetivos 5. Revisar o planejamento, a organização dos objetivos, conforme necessário. Registrar o histórico do projeto FimRepetir Objetivos Planejamento Organização / Coordenação Avaliação do Progresso Revisão e registro histórico 1 2 3 4 5 Prof. Sérgio Luiz Tonsig Página: 4.1. O primeiro princípio de gerência de projetos é estabelecer um conjunto claro de objetivos e requisitos do projeto, bem como obter informações que permitam decidir sobre a Objetivos técnicos ou meta do projeto Especificações do produto, lista de padrões aplicáveis, restrições assumidas Prazos: sempre um fator limitante Orçamento: Quase sem um fator limitante Muitas vezes, estas informações para serem uma base segura sobre a qual seja possível estabelecer um “contrato de desenvolvimento”, devem estar reunidas em um documento, Proposta de Desenvolvimento de Sistema. Organização da Proposta de Desenvolvimento de Sistema antecipar respostas a perguntas que surgirão durante o desenvolvimento. Conteúdo: Descrição do sistema a ser desenvolvido, definindo seus objetivos, requisitos, as necessidades e expectativas dos usuários bem como as vantagens do sistema proposto; proposto Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 47 Para que a proposta cumpra seu papel, ela deve ser: • Macroscópica, de forma a exigir um mínimo de detalhe; • Fidedigna, sem omitir ou exagerar fatos; • Imparcial; • Realista e viável; Em uma estrutura organizacional mais simples, a proposta de desenvolvimento acaba se resumindo num documento interno do tipo Ordem de Serviço, em outras organizações menores ainda, simples reuniões com o desenvolvedor, de forma verbal, se elabora todo este contexto acima exposto referente a proposta de desenvolvimento. 4.2. Planejamento Um planejamento bem feito deve primeiro definir quais atividades devem ser realizadas (O QUE), devidamente justificadas (POR QUE), em que ordem (QUANDO) devem ser feitas, com que técnicas (COMO), empregando quais recursos humanos (QUEM), trabalhando em que lugar (ONDE). Esta matriz O QUE x ( POR QUE, QUANDO, COMO, QUEM, ONDE), permitirá estimar QUANTO será despendido em cada atividade, nas fases e no projeto como um todo, em termos de TEMPO e CUSTO. Na prática, o planejamento não é tão cartesiano como aparenta. O grau de complexidade e precisão depende do estágio em que se está planejando. Nos estágios iniciais, ele é mais simples e impreciso, nos estágios mais avançados mais complexo e detalhado. Ao longo do desenvolvimento, o objetivo do planejamento é um alvo móvel. Portanto, segundo dizem, “ a única certeza sobre um plano é que as coisas não ocorrerão conforme planejado”; ainda assim, tenha um plano, ruim com ele, muito pior ainda sem. Análise e Projeto de Sistemas II Página: 50 Publicar Jornal 1. Obter Verba 2. Comprar Material 2.2. Comprar Mat. Fotográfico 3. Encomendar Des. Artístico 5. Produzir Jornal 5.1 Produzir Texto 5.1.2 Revisar Texto 5.2 Produzir Versão Final 5.2.2 Imprimir Exercício: Fazer um DFD para expressar o planejamento de acordo com os exemplos Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 51 Exemplo do planejamento com lista de atividades, incluindo duração e seqüência Atividades (a) Obter Verba (f) Editar Texto (b) Comprar Papel (g) Revisar Texto (c) Comprar Material Fotográfico (h) Integrar Foto/Desenho (d) Encomendar Desenho Artístico (i) Imprimir (e) Fazer Fotos Anterior Atividade Posterior Duração - (a) (b) (c) (d) 3 (a) (b) (i) 2 (a) (c) (e) 1 (a) (d) (h) 7 (c) (e) (h) 3 - (f) (g) 5 (f) (g) (h) 5 (e) (d) (g) (h) (i) 1 (b) (h) (i) - 1 Planejamento utilizando o diagrama de GANTT ATIVIDADES 01 02 03 04 05 06 07 08 09 10 11 12 (a) Obter Verba (b) Comprar Papel (c) Comprar Mat.Fotog. (d) Encom.Des.Artist. (e) Fazer fotos (f) Editar Texto (g) Revisar Texto (h) Integrar Desc./Foto (i) Imprimir Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig 52 Atividades (a) Obter Verba (b) Comprar Papel (g) Revisar Texto (h) Integrar Foto/Desenho (d) Encomendar Desenho Artístico i) Imprimir (e) Fazer Fotos HUMANOS 01 03 04 06 07 09 10 12 EDITOR (h) (i) (b) (c) (d) (e) (f) REVISOR Lembre-se que onde existe a numeração, pode-se trocar por Datas. Análise e Projeto de Sistemas II Página: 55 Avaliação do Progresso acordo com pontos de controles especificados (Milestones Dois níveis de controle: Informal equipe; não gera relatórios. Um controle informal efetivo, minimiza a freqüência e as sobrecarga ( ) de reuniões e relatórios. Requer relatórios periódicos gerados por revisões sobre andamento do projeto. Normalmente, são de dois tipos: – reuniões realizadas em cada ponto de controle com todo o grupo de desenvolvimento; gerando um relatório de progresso (com a narrativa do ponto atual e Revisões Técnicas – voltadas para aspectos específicos dentro das etapas existentes, objetivo eliminar problemas de transcurso, mantendo um registro sobre isto – relatório técnico. Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 56 Exemplo de um projeto com pontos de controle FASE ATIVIDADE PONTOS DE CONTROLE 100 110 Avaliação Preliminar Estudo do Projeto 199 Fase 100 Concluída 300 310 Esboço das Funções do Sistema Avaliação de Recursos Tecnológicos 330 340 Análise de 350 Revisão e Aprovação Ponto de Revisão Fase 300 concluída DESENVOLVIMENTO 510 520 Projeto Lógico ( Comportamtal) Atividade 520 concluída Projeto Físico (Implementação) 540 Fase 500 concluída 700 710 Planejamento da Implantação Teste Piloto 730 Instalação e Treinamento 740 Fase 700 concluída (encerramento do projeto) Análise e Projeto de Sistemas II Prof. Sérgio Luiz Tonsig Página: 57 Um exemplo de pauta para reuniões referente as revisões gerenciais Que pode ser aplicada em qualquer momento dentro da evolução do projeto: 01 Atividades Desenvolvidas 02 Fases e Atividades em curso 03 Problemas Encontrados 04 Soluções Propostas 05 Atividades a serem desenvolvidas 06 Ocorrência de Contingências 07 Considerações sobre os prazos 08 Providências 09 Conclusão da Reunião Revisões Técnicas Com relação as Revisões Técnicas, se propõe: 01 Revisão de Requisitos Motivação principal: Assegurar que, se os desenvolvedores construírem um sistema que satisfaça os requisitos, ele satisfará as necessidades dos usuários. Avaliação dos aspectos: Incorreção: requisitos que demandam algo que os usuários não querem. Imcompleteza: a especificação falha em dizer algo que algum usuário necessita. Ambigüidade: requisitos que são imprecisos a ponto de admitir muitas possíveis interpretações. Inconsistência: requisitos que se contradizem um ao outro 02 Revisão de design O design satisfaz os requisitos ? O design é consistente ? O design é completo ?