ANLISE E PROJETO DE SISTEMAS II

CURSO DE ANLISE E PROJETO DE SISTEMAS II

Nelson Barbosa Jr.

Nelson Barbosa Jr.

Pgina: 1

ANLISE E PROJETO DE SISTEMAS II

Ementa: Desenvolver a especificao de sistemas, atravs de estudos de casos, propiciar uma viso geral sobre as etapas que devem ser seguidas para o efetivo desenvolvimento de um projeto e seus aspectos gerenciais.

Nelson Barbosa Jr.

Pgina: 2

ANLISE E PROJETO DE SISTEMAS II

NDICE
1. Caminho do desenvolvimento..................................................................... 1.1. A Anlise Essencial.............................................................................. 1.1.1. Modelo Ambiental..................................................................... 1.1.2. Modelo Comportamental........................................................... 1.1.3. Um estudo de caso..................................................................... 1.1.3.1. Declarao de Objetivos do Sistema.......................... 1.1.3.2. Diagrama de Contexto................................................ 1.1.3.3. Lista de Eventos.......................................................... 1.1.3.4. DFD Particionado por Evento..................................... 1.1.3.5. A Especificao dos Processos.................................... 1.1.3.6. Modelagem de Dados.................................................. 1.1.3.7. Diagrama Hierrquico de Macro Atividades............... 1.1.3.8. Dicionrio de Dados.................................................... 1.1.3.9. CASE........................................................................... 2. Projeto (Design)............................................................................................ 2.1. Critrio de qualidade de projeto............................................................ 2.2. Modelo de Alocao de Processadores.................................................. 2.3. Consideraes sobre segurana e controle de sistemas......................... 2.4. Diagrama Hierrquico do Sistema......................................................... 2.5. Lay-Out de Telas/Relatrios.................................................................. 3. Gerncia de Projeto....................................................................................... 3.1. Problemas em Planejamento de Sistemas.............................................. 3.1.1. Relacionado com a rpida evoluo tecnolgica........................ 3.1.2. Relacionado com pessoas........................................................... 3.1.3. Outros problemas gerenciais....................................................... 3.1.4. Dificuldade de aferir progresso................................................... 3.1.5. A crise do software...................................................................... 4. Processo de gerncia de projeto.................................................................... 4.1. Definio de objetivos............................................................................ 4.2. Planejamento.......................................................................................... 4.3. Organizao / Coordenao.................................................................... 4.4. Avaliao do Progresso.......................................................................... 4.5. Reviso e Registro Histrico.................................................................. 5. Bibliografia.................................................................................................... 04 04 05 06 08 10 10 11 12 13 25 27 28 30 31 33 33 36 38 39 41 41 41 42 42 43 43 45 46 47 53 55 58 59

Nelson Barbosa Jr.

Pgina: 3

ANLISE E PROJETO DE SISTEMAS II

1. O Caminho do Desenvolvimento de Sistemas

Antes de se enfatizar qualquer aspecto relativo a Projeto de Sistema, especialmente em nossa etapa atual de formao profissional, fundamental resgatar, atravs de uma sntese (visto que foi objeto de estudo do semestre anterior), o caminho que um Analista de Sistemas dever seguir, ao utilizar o mtodo da anlise essencial.

1.1. A Anlise Essencial

Declarao Dos Objetivos

Modelo Ambiental

Diagrama De Contexto

Lista de Eventos Anlise Essencial DFD Particion por Eventos

D i c i o n a r i o D e d a d o s

Modelo Comportamental

Diagr. Entidade Relacionamento

Normalizao

A premissa bsica para o mtodo de anlise essencial descrever o sistema de maneira independente de restries tecnolgicas. Isto implica dizer que devemos considerar na confeco do modelo essencial a existncia de uma tecnologia perfeita. Devemos entender este aspecto como uma abstrao em que se supe uma tecnologia ideal, sem limitaes, onde:

Nelson Barbosa Jr.

Pgina: 4

ANLISE E PROJETO DE SISTEMAS II a) b) c) d) e) Os custos, consumo e desgaste dos equipamentos so zero A capacidade de armazenamento de dados do sistema infinita A velocidade dos processadores infinita O tempo de acesso a dados instantneo Zero Erro (no ocorrem falhas)

Atravs deste mtodo faz-se um exame do domnio do problema (levantamento de dados acerca do sistema que ser feito) inicialmente enfocando os aspectos mais essenciais pertinentes ao problema. A anlise essencial, constituda basicamente por duas fases ou modelos: Ambiental e o Comportamental. Modelo Ambiental No modelo ambiental tem-se a especificao macro do sistema (como se fosse uma caixa preta) inserido em um meio ambiente, busca-se representar a relao do sistema com o meio onde ele est, atravs de estmulos provenientes do meio e respostas a estes estmulos, que podero ser internas ao sistema ou ainda serem devolvidas para o meio ambiente. Trs grandes atividades so elaboradas neste modelo: Declarao dos Objetivos do Sistema, a elaborao do Diagrama de Contexto e a especificao da lista de eventos. Declarao de Objetivos Trata-se da especificao daquilo que o sistema dever fazer, frente aos problemas existentes na organizao para o qual ele ser feito. Deve tambm, tanto quanto possvel, refletir os desejos do usurio no que diz respeito as solicitaes que ele tenha apresentado como alternativas de soluo dos problemas. Naturalmente antes da elaborao dos objetivos do sistema, o Analista dever ter efetuado um minucioso levantamento de dados (checando inclusive requisitos do sistema), conhecendo profundamente o chamado domnio 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 excees. Diagrama de Contexto Aps a especificao formal dos objetivos do sistema, o Analista j estar em condies mais apropriadas para elaborar o diagrama de contexto. Ele reflete graficamente a relao do sistema com o meio ambiente onde est inserido. Esta relao d-se atravs do recebimento de estmulos 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. Lista de Eventos Trata-se da especificao das atividades (processos) essenciais que o sistema ter . Elas so ativadas por estmulos (fluxo de dados, fluxo temporal ou de controle), fazem algum processamento e geram respostas. No h uma precedncia estabelecida para a elaborao

Nelson Barbosa Jr.

Pgina: 5

ANLISE E PROJETO DE SISTEMAS II da lista de eventos e o diagrama de contexto, so 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). Tambm far um modelo de dados sobre o qual o sistema atuar, observando critrios para conseguir boa performance na sua utilizao (atravs da normalizao de dados). Acompanhando mais efetivamente este modelo (muito embora j possa existir antes dele) cria-se o dicionrio de dados. Tambm nesta fase elabora-se o D.F.D. Hierrquico, que nada mais do que o agrupamento de atividades essenciais afins (sncronas), 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 grfica, 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.

Nelson Barbosa Jr.

Pgina: 6

ANLISE E PROJETO DE SISTEMAS II

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 esto organizados e como eles se relacionam. Em cima deste modelo, pode ser aplicado a teoria da Normalizao, que permitir extrair melhor performance quando da utilizao da estrutura dos dados. Diagrama Hierrquico de Macro Atividades Trata-se de um D.F.D. onde se propiciar uma viso de Macro Atividades. Pega-se os diagramas de fluxo de dados particionados por eventos e verifica-se quais so aquelas atividades afins (sncronas que tratam determinado assunto). Estes processos so aglutinados em um nico, de tal forma que se obter uma viso mais sinttica da representao do sistema, cuja finalidade , alm da documentacional a possibilidade de examinar e definir interfaces e locais de processamento. A fim de facilitar a construo do DFD Hierrquico (atravs de uma viso 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 (viso nica de um DFD com todos os processos existentes). Dicionrio de Dados Todos os dados referenciados na construo do sistema, deve ter sua definio no dicionrio de dados. Para a construo do dicionrio existem alguns padres, dos quais, vamos adotar o segue: Smbolo = + ( ) { } [ ] * * @ | ou / Significado composto de E Opcional (pode estar presente ou ausente) Iterao (Repetio) Escolha uma das opes Comentrio Indica campo chave Separa Alternativas na construo [ ]

Nelson Barbosa Jr.

Pgina: 7

ANLISE E PROJETO DE SISTEMAS II

1.1.3. Um Estudo de Caso

Domnio do Problema A primeira grande misso do Analista de Sistema, ao ser chamado a desenvolver um sistema, o de delimitar a rea fronteiria deste sistema a ser desenvolvido. Exatamente o que se deseja e at onde dever ser feito tal coisa. Para iniciar este processo de identificao uma boa dica comear pela pergunta fundamental: Por que tal sistema deveria existir ? naturalmente quem contratou seu servio est apto a responder este questionamento com uma riqueza de detalhes muito grande. Em nosso estudo de caso, tem-se um sistema hoteleiro. Nesta fase de exame do domnio do problema, estabeleceu-se que o objetivo apenas o controle da disponibilidade de quartos do hotel (no envolve qualquer outro aspecto, tais como: controle financeiro, contbil, etc...). Uma vez claramente estabelecido o domnio do problema depois de um intenso levantamento de dados (que comeou pela pergunta acima: por que este sistema deveria existir ?), o Analista de Sistema deve se concentrar unicamente no domnio do problema, eventuais interfaces e nos requisitos necessrios ao desenvolvimento do sistema, passando para a etapa seguinte. Rigoroso Levantamento de Dados Aps um rigoroso levantamento de dados, que pode envolver, exame e cpia de documentos originais, acompanhamento do fluxo de trabalho, entrevistas com usurios e at mesmo estgio no local objeto do levantamento de dados. O Analista de Sistemas deve sair desta fase conhecendo todos os detalhes do negcio, suas regras, excees, linguagem empregada e eventuais particularidades da organizao sobre o negcio. Se o Analista ignorar esta fase ou desenvolve-la superficialmente, assumindo que j possui conhecimentos suficientes sobre o assunto, provavelmente, estabelecer requisitos confusos ou invlidos, fracassando j no incio de seu sistema.

Nelson Barbosa Jr.

Pgina: 8

ANLISE E PROJETO DE SISTEMAS II

Em nosso estudo de caso, aps estes procedimentos iniciais, chegou-se a um conhecimento acerca do que deveria ser feito. As informaes colhidas encontram-se no enunciado que segue: Estudo de Caso - Sistema Hoteleiro - Controle de Disponibilidades de Quartos Deseja-se desenvolver um sistema para um pequeno hotel que atenda aos seguintes requisitos: Quando o cliente telefona ou vem at o hotel e pede para reservar um quarto, o funcionrio verifica se existe quarto disponvel no perodo solicitado. Caso afirmativo, feita a reserva do quarto. Caso negativo, informado ao cliente a no disponibilidade do quarto. Quando o cliente no mais desejar o quarto reservado o funcionrio providencia o cancelamento da reserva, disponibilizando novamente o quarto. Quando o cliente no comparecer ao hotel para hospedar-se at s 12:00 horas do dia da reserva, deve ser cancelado a sua reserva. Quando o cliente ocupar um quarto, reservado previamente, o funcionrio faz o registro do cliente. Caso o quarto no esteja reservado uma mensagem de rejeio ser emitida. Caso contrrio, um pacote com informaes teis e a confirmao sero fornecidos ao cliente. Quando o cliente deixar o hotel, notificando sua sada, ser fornecido a conta, e o quarto ser disponibilizado para limpeza. O cliente pode pagar a conta vista, ou usando carto de crdito. Caso use carto de crdito, verificado sua situao para aceitar ou no o carto. Quando o quarto estiver limpo, aps uma ocupao, o gerente torna-o disponvel para nova locao.

De posse destas informaes, em nosso estudo de caso, segue um descritivo da anlise do problema e a descrio da soluo escolhida pelo Analista de Sistemas, diante, claro, alm das informaes, os desejos manifestados pelo usurio (e possveis de serem desenvolvidos).

Nelson Barbosa Jr.

Pgina: 9

ANLISE E PROJETO DE SISTEMAS II Descritivo da Soluo Escolhida Depois de estudar o volume de dados processado pelo sistema atual e considerando o tempo de resposta requerido, chego a concluso que o sistema novo precisar de quatro pessoas e um pequeno computador comercial. Dever ser atribudo tanto trabalho quanto for possvel ao computador de modo a poder minimizar os custos de processamento. Porm, no ser correr o risco de perder clientes por fora-lo a um contato direto com o computador (considerando a situao atual da interface homem/mquina); 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 no comparecimento, no requer nenhum contato direto com o cliente e, portanto, pode ser desempenhado diretamente pelo computador. O que vem a seguir a especificao tcnica do projeto do sistema, comeando inicialmente pelo modelo ambiental. 1.1.3.1. Declarao do Objetivo do Sistema Controlar o servio de reservas, registros e cobrana de quartos de um sistema hoteleiro. 1.1.3.2. Diagrama de Contexto Cli_Pac_Entr Cli_Rejeit Cli_Ent Cliente Cli_Reserva Cli_Cancel Ger_Lib Gerncia Ger_Can Cli_Paga Sistema Hoteleiro Cli_Sai Cli_Conta Cliente

1.1.3.3. Lista de Eventos do Estudo de Caso

Nelson Barbosa Jr.

Pgina: 10

ANLISE E PROJETO DE SISTEMAS II

N Evento 01 Cliente Reserva Quarto 02 03 Descrio do Evento Estmulo Cli_Reserva Tipo Ao Estmulo F Efetuar Reserva Resposta Cli_Reservado ou Cli_Indisp Ger_Cancel Cli_Pac_Ent ou Cli_Rej

04

05

06

07

08

Quando o cliente telefona ou vem at o hotel e pede para reservar um quarto, o funcionrio executa um procedimento padro hora de Quando o cliente no comparecer cancelar ao hotel para hospedar-se at as reserva 12:00 horas do dia da reserva Cliente Cliente faz o registro para a registra- ocupao do quarto, reservado se no previamente. Caso no reservado hotel uma mensagem de rejeio ser emitido, caso contrrio um pacote com informaes ser fornecido Cliente Quando o cliente deixar o hotel solicita este solicita que providencie o sada do fechamento de sua conta, havendo hotel a disponibilidade do quarto para limpeza Cliente Cliente paga a quantia paga a correspondente ao aluguel do conta quarto e s despesas efetuadas durante sua estadia Cliente Quando o cliente no mais desejar cancela a o quarto reservado e comunicar o reserva fato, ser cancelado a reserva, disponibilizando o quarto novamente Gerncia Quando o quarto estiver limpo o disponi- gerente torna-o disponvel biliza quarto Gerncia Gerncia inclui, exclui ou modifica cadastra dados do quarto quarto

Cli_Ent

T F

Cancelar Reserva Automaticamente Registrar Cliente

Cli_Sai

Fechar Quarto

Cli_Conta

Cli_Paga

Registrar Pagamento

Cli_Recibo

Cli_Cancel

Cancelar Reserva por Solicitao

Cli_Canc

Ger_Lib

Liberar Quarto

Msg_01

Ger_Cad

Manipular cadastro de quarto

Msg_02

Como voc sabe, deve haver entre a lista de eventos e o diagrama de contexto uma consistncia. importante lembrar tambm que a Lista de Eventos ou Diagrama de Contexto podem ser desenvolvidos paralelamente. Exerccio: Cheque ambos (Lista de Eventos X Diagrama de Contexto) e acerte as possveis inconsistncias encontradas. (eventuais alteraes faa sobre o prprio manual, no local adequado, a fim de que voc tenha o material completo para estudo)

Nelson Barbosa Jr.

Pgina: 11

ANLISE E PROJETO DE SISTEMAS II 1.1.3.4. DFD Particionado por Evento Depois que a lista de eventos estiver concluda ( claro que as vezes voc esquecer um ou outro evento, que depois podem ser acrescentados, mas, com certeza os eventos essenciais estaro l), voc dever fazer o Diagrama de Fluxo de Dados particionados por Eventos, tambm 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 CadReserva CadClien

Cli_Reserva

Efetuar Reserva CadQuarto

Cliente Cli_Reservado ou Cli_Indisp

Exerccio: Faa o D.F.D. particionado por eventos para os demais itens da lista de eventos. (antes porm, a seguir, d uma olhada no modelo de dados completo que utilizado neste estudo de caso pg. 21)

Nelson Barbosa Jr.

Pgina: 12

ANLISE E PROJETO DE SISTEMAS II

1.1.3.5. A Especificao dos Processos Como voc observou no diagrama da pgina anterior (DFD particionado por evento referente ao evento 01 da lista de eventos ), tudo que se enxerga que existe um processo que vai tratar determinado evento (Cliente reserva quarto), o qual mexe com determinados arquivos. Tem-se portanto, claramente, o que acontece, porm, precisa-se saber, como tal coisa acontece. Veja que o diagrama no expressa, por exemplo, nenhuma regra do negcio, a qual, se no for documentada, o desenvolvedor far um programa de reserva de quarto invlido. Veja, neste hotel do nosso estudo de caso, um cliente s pode reservar um quarto se o mesmo estiver liberado, aps ter passado por uma faxina (QuaSit = 0). Isto pode parecer bvio, mas como expressar essa regra do negcio, a fim de que o programador, ao desenvolver o mdulo que vai tratar da reserva, possa saber que isto deve ser checado ? Outro exemplo de regra do negcio : O cliente que efetuar nova reserva no mximo 15 dias aps sua ltima hospedagem, ter um desconto de 10 %. Isto de alguma forma tem que ser documentado e o programador, ao fazer o processo de fechamento da conta deve aplicar a regra, caso contrrio o sistema no ser vlido. Portanto tem-se que fazer a especificao funcional do mdulo (como ele deve funcionar), permitindo que exista uma documentao formal das regras do negcio, bem como algum possa implementar isto no sistema. H apenas alguns anos, esta especificao era extremamente formal, cuidando de mnimos detalhes, basicamente, um programa era escrito para que depois um programador apenas codificasse. Como por exemplo, o pedao de especificao mostrada abaixo: Limpe a Tela Abra o arquivo CadCli MostreMensagem Digite o C.G.C.: Aguarde a digitao Consistir o C.G.C. conforme rotina CONF_CGC . . .

Nelson Barbosa Jr.

Pgina: 13

ANLISE E PROJETO DE SISTEMAS II

Miniespecificaes

Atualmente o enfoque para que haja apenas uma miniespecificao. Uma miniespecificao vai tratar apenas das linhas genricas do processo enfatizando os aspectos essenciais e aqueles que referem-se as regras do negcio. De tal maneira que se no houver esta especificao um programador no far satisfatoriamente o programa, ou seja, ele no ser um programa vlido, de acordo com a realidade que deve atender. Portanto ningum sair ditando como fazer um programa para incluir, alterar, excluir ou consultar cadastros, salvo se houver detalhes de implementao proveniente das regras do negcio. E, neste caso, haver um miniespecificao acerca daquele aspecto.

O homem observa a montanha, atrs da esposa, com binculo. Quem estava com o binculo ? Quem estava atrs da esposa ? Observe que em uma narrativa comum, pode haver uma srie de ambigidades. Para tentar eliminar interpretaes diferenciadas de um texto, atravs do qual ser expresso regras de um negcio, criou-se algumas ferramentas.

Ferramentas para Miniespecificaes

Portugus Estruturado um texto em portugus, desenvolvido dentro de uma hierarquia. Pode-se empregar palavras chaves para delimitar esta hierarquia, bem como simultaneamente, indentar (margens diferenciadas) o texto. Admite uma certa liberdade de expresso, com relao a tamanho e contedo do texto, no h critrios rigorosamente estabelecidos. desejvel, porm, que se possa transmitir algo sem ambigidade de uma maneira bem sinttica. Exemplo de portugus estruturado:

Nelson Barbosa Jr.

Pgina: 14

ANLISE E PROJETO DE SISTEMAS II

DFD Particionado Por Evento - Evento 01 Cliente Reserva Quarto

CadReserva CadClien

Cli_Reserva

Reservar Quarto CadQuarto

Cliente Cli_Reservado ou Cli_Indisp

Miniespecificao PEGAR dados Cli_Reserva SE cliente inexistente, faa seu cadastro (para campo Cli_Sit jogar 0 ) PARA reservar quarto, faa: MOSTRAR lista de quartos livres para reserva ( todos que tiverem Qua_Sit = 0 ) SE no existir pelo menos um quarto livre, faa: Mensagem Desculpe, Hotel totalmente ocupado. Encerrar FIM SE QUANDO escolhido um quarto livre, faa: MARCAR quarto como reservado (jogar 1 para campo Qua_Sit) MARCAR cliente como solicitado reserva (jogar 1 para Cli_Sit) FIM QUANDO FIM PARA

Nelson Barbosa Jr.

Pgina: 15

ANLISE E PROJETO DE SISTEMAS II Pseudocdigo Basicamente, pseudocdigo e portugus estruturado no trazem grande diferena, contudo possvel distinguir entre ambos (algumas vezes os termos so usados indistintamente como sinnimos). O pseudocdigo usa notao mais formal, mais orientada ao profissional de processamento de dados, empregando as palavras chaves e tentando seguir uma sintaxe bem mais prxima de uma linguagem de programao. Usa-se palavras-chaves para realar o que seriam comandos utilizadas nas linguagens de programao; por exemplo: SE, SENO, ENTO, FIMSE, REPETIR, ENQUANTO, REPETIRAT, FIMREPETIR, ENCERRAR. Com relao as expresses lgicas, emprega-se a mesma gama de signos: >, <, =, <=, >=, E, OU. A grande desvantagem em se utilizar pseudocdigo, no lugar do portugus estruturado, que neste, se possibilita no prprio texto uma explicao mais detalhada acerca do processo que est sendo especificado. No pseudocdigo, tambm possvel agregar explicao, porm deve seguir como se fosse um comentrio em uma linguagem de programao, devendo ficar entre /* */. /* um comentrio qualquer em pseudocdigo */ Vamos examinar a seguir, como fica o exemplo feito em portugus estruturado referente ao evento essencial 01, agora refeito em pseudocdigo

Nelson Barbosa Jr.

Pgina: 16

ANLISE E PROJETO DE SISTEMAS II

CadReserva CadClien

Cli_Reserva

Efetuar Reserva CadQuarto

Cliente Cli_Reservado ou Cli_Indisp

Miniespecificao PEGAR Cli_Reserva SE cliente = inexistente ENTO EXECUTAR Cadastro_Cliente SE reservar = VERDADEIRO ENTO: EXECUTAR Lista_Quartos_Livres SE quarto = inexistente ENTO: Mensagem Desculpe, Hotel totalmente ocupado. ENCERRAR FIM SE SE quarto = escolhido ENTO: Qua_Sit = 1. Cli_Sit = 1. FIM SE FIM SE

Nelson Barbosa Jr.

Pgina: 17

ANLISE E PROJETO DE SISTEMAS II Ferramentas Auxiliares de Miniespecificaes Duas outras tcnicas de especificao podem ser utilizadas para expressar situaes de lgica complexa ou no. rvores e Tabelas de Deciso Uma rvore de deciso um modelo de uma funo na qual determinado o valor de uma varivel, com base neste valor, alguma ao executada. A ao pode ser para a escolha de outra varivel a ter seu valor calculado ou a sada da funo. Ento, cada ao executada depende do valor atual da varivel que est sendo testada e de todas as aes anteriores que foram executadas. Em uma rvore de deciso definida formalmente, uma varivel s testada uma vez em qualquer caminho atravs da rvore. Esta restrio feita para evitar testes redundantes. Exemplo de rvore de deciso. Ultima Compra Pessoa Fsica Clientes Pessoa Jurdica
Raiz Tronco

< 15 dias < 30 dias < 45 dias < 90 dias +90 dias

Emitir Congratulaes Emitir uma pesquisa Enviar catlogos Enviar Convite Enviar telegrama Enviar Catlogos

n Saldo Devedor ? s Enviar Carta Cobrana

Tronco Tronco Folhas

Exerccio Desenvolva uma rvore de deciso para o enunciado que segue. Se cliente for maior de 18 anos, pode fazer assinatura da revista. Os menores de 18, apenas com uma declarao dos pais. A assinatura pode ser feita para 6 meses, 9 meses, 12 meses ou 24 meses. Caso seja paga com carto, ter um desconto de 2% (6 meses), 3% (9meses), 5%(12 meses) e 10% (para 24 meses). rvores de deciso no so indicadas para expressar lgica complexa, neste caso, prefervel as tabelas de decises. Uma rvore comea sempre em uma raiz, a partir da qual, sempre ter no mnimo dois troncos, que daro origem a outros troncos ou folhas. Em cada tronco, pode surgir no mnimo dois e no mximo n outro troncos. Um tronco de um galho no pode ligar-se a outro tronco em outro galho. Uma rvore sempre terminar em suas folhas.

Nelson Barbosa Jr.

Pgina: 18

ANLISE E PROJETO DE SISTEMAS II Tabelas de Deciso Tem a mesma finalidade das rvores de deciso, porm abrem mo do aspecto grfico e proporcionam uma forma tabular. Pode-se por elas construir lgicas complexas. As tabelas de deciso possuem os seguintes componentes:
Condies /Aes Condio 1 Regras

01 S N S X -

02 S N X X

03

04

05

06

07

...

Condio 2 Condio n Ao 1 Ao n

Tem-se trs elementos distintos na tabela de deciso: As condies, as regras de deciso e as aes. A leitura da tabela de deciso deve ocorrer a partir da regra de deciso n 1. Deve-se ler no sentido vertical. No exemplo acima, l-se a condio 1. Se a resposta for S, passar para a condio seguinte. Se a resposta no for S, pula-se para a regra de deciso n 2 (e inicia-se da mesma forma). A cada condio existente, verifica-se se a resposta obtida aquela assinalada, se afirmativo, seguir para a condio seguinte. Se esta regra for totalmente satisfeita, ou seja, as respostas dadas as condies sejam de acordo com o que foi assinalado (s, n), checa-se os cursos de ao. Cada ao que estiver assinalada com X, ser executada. Uma vez satisfeita totalmente uma regra de deciso, a aplicao da tabela se encerra. Se pelo menos uma condio da regra no for satisfeita, pula-se para a prxima regra de deciso e assim sucessivamente. Veja na prxima pgina um exemplo de tabela de deciso.

Condies
Nelson Barbosa Jr.

Regras de Deciso
Pgina: 19

ANLISE E PROJETO DE SISTEMAS II e aes

Cliente Pessoa Fsica ? Ultima Compra foi feita menos que 15 dias ? Ultima Compra foi feita menos que 30 dias ? Ultima Compra foi feita menos que 45 dias ? Ultima Compra foi feita menos que 90 dias ? Ultima Compra foi feita mais de 90 dias ? Saldo Devedor ? Emitir Congratulaes Emitir uma pesquisa Enviar Catlogo Enviar Convite Enviar Telegrama Enviar carta cobrana a a a a a

01 S S X

02 S N S X

03 S N N S -

04 S N N N S -

05 S N N N N S -

06 N N

07 N S

08

09

10

11

12

X X X

X X

Exerccio Para o mesmo enunciado do exerccio existente na pgina 17, construa uma tabela de deciso.

Nelson Barbosa Jr.

Pgina: 20

ANLISE E PROJETO DE SISTEMAS II Miniespecificao de Processos Orientao e Padronizao para aplicao no T.C.C.

Uma miniespecificao vai tratar apenas das linhas genricas do processo, enfatizando os aspectos essenciais e aqueles que referem-se as regras do negcio, de tal maneira que, se no houver esta especificao, um programador no far satisfatoriamente o programa, ou seja, ele no ser um programa vlido, de acordo com a realidade que deve atender.

Portanto ningum sair ditando detalhadamente como fazer um programa para incluir, alterar, excluir ou consultar cadastros, dever ser apresentado apenas a sntese do objetivo global do processo, salvo se houver detalhes de implementao proveniente das regras do negcio, neste caso, haver um miniespecificao um pouco mais ampla.

Para qualquer miniespecificao sugere-se a utilizao de uma ferramenta que tente evitar ao mximo ambigidades de interpretao, com relao as idias que esto sendo expressas. Neste sentido emprega-se: Portugus Estruturado, Pseudocdigo, Tabelas de Deciso ou rvores de Deciso.

O mtodo da anlise essencial indica estas ferramentas para a miniespecificao, porm, deixa em aberto o formato de apresentao da miniespecificao. Muitos autores, influenciados pela fase estruturalista da anlise, normalmente exemplificam uma miniespecificao de forma estruturada, conforme exemplo a seguir:

Nelson Barbosa Jr.

Pgina: 21

ANLISE E PROJETO DE SISTEMAS II

CadReserva CadClien

Cli_Reserva

Efetuar Reserva CadQuarto

Cliente Qua_Reservado ou Qua_Indisp

PEGAR Cli_Reserva SE cliente = inexistente ENTO EXECUTAR Cadastro_Cliente SE reservar = VERDADEIRO ENTO: MOSTRAR Lista_Quartos para escolha de um SE quartos escolhidos = ocupados ENTO: Mensagem Desculpe, Hotel totalmente ocupado. (Qua_Indisp) ENCERRAR FIM SE SE quarto = livre ENTO: Qua_Sit = 1. /* marcar quarto como ocupado */ Cli_Sit = 1. /* marcar cliente com reserva feita */ Mensagem Reserva Concluda. (Qua_Reservado) FIM SE FIM SE

Verifica-se contudo, que perfeitamente livre a criao de uma miniespecificao em outros formatos, propiciando formas mais abstratas, sem a idia de uma estruturao. Este fator de fundamental importncia, j que, com um formato mais abstrato, tem-se uma anlise imparcial com relao a linguagem de implementao. Um modelo mais abstrato de miniespecificao, possibilita sem qualquer tipo de influncia, que o Analista se decida por implementar utilizando uma linguagem estruturada, linguagem de quarta gerao, ou orientao a objetos. Dentro desta perspectiva, com intuito de estabelecer um nico formato para as miniespecificaes dos TCCs, ser adotado o formato mais abstrato. Segue exemplo e algumas observaes a serem consideradas, com relao ao formato proposto. O exemplo a seguir o mesmo mostrado anteriormente, porm, utilizando a forma que dever ser empregada nos TCCs.

Nelson Barbosa Jr.

Pgina: 22

ANLISE E PROJETO DE SISTEMAS II

CadReserva CadClien

Cli_Reserva

Efetuar Reserva CadQuarto

Cliente Qua_Reservado ou Qua_Indisp

PEGAR Cli_Reserva EFETUAR cadastro do Cliente RESERVAR quarto SE houver disponibilidade RETORNAR mensagem ao cliente de acordo com resultado da operao

Acima um exemplo com o mesmo contedo mostrado anteriormente, porm, utilizando a forma que dever ser empregada nos TCCs. Esta forma no induz a uma lgica especfica para implementao que poder vir a ser de forma estruturada, orientada a eventos, orientada a objetos ou ainda um mix destes paradigmas. Consideraes Gerais sobre o exemplo O fluxo de dados Cli_Reserva, Qua_Reservado e Qua_Indisp, e os depsitos CadClien, CadReserva, CadQuarto devem estar descritos no dicionrio de dados. Com estas descries, mais a modelagem de dados, a miniespecificao acima de fcil implementao em qualquer linguagem.

Nelson Barbosa Jr.

Pgina: 23

ANLISE E PROJETO DE SISTEMAS II Observaes para a construo do modelo proposto. 1. No deve aparecer na miniespecificao qualquer descrio que j exista na lista de eventos. 2. Se uma regra de negcio j foi estabelecida e descrita a nvel de dicionrio de dados, no deve ser objeto de descrio na miniespecificao. Exemplo: No aceitar cadastro de clientes menores que 18 anos. Se no campo cliente.idade, no dicionrio de dados, j foi mencionado que o contedo do mesmo deve ser >= 18; ento, no h motivos para especificar isto novamente na miniespecificao (evitar qualquer redundncia). Detalhes com relao ao contedo de campos e seu significado devem necessariamente estar no dicionrio de dados. 3. Iniciar as sentenas com um verbo sempre no infinitivo. O verbo deve dar a idia da operao que se deseja realizar. Uma vez utilizado um verbo para determinada operao, ele sempre deve ser empregado quando se tratar daquela operao (padronizao especfica). 4. O complemento da sentena possui contedo livre, desde que: seja claro, sem ambigidades e o mais sinttico possvel. Pode ser empregado outros verbos no complemento da sentena para facilitar a expresso da idia.

Nelson Barbosa Jr.

Pgina: 24

ANLISE E PROJETO DE SISTEMAS II 1.1.3.6. Modelagem de Dados do Estudo de Caso O Analista verificou que havia uma relao entre Clientes e Quartos (Reserva), sobre a qual deveria armazenar informaes. Desta forma, o Analista de Sistemas gerou o Diagrama de Entidade Relacionamento, fazendo uma modelagem lgica de dados, conforme segue:

Cli_cpf Cli_nome Cli_End Res_DataIn Res_DataFi

Qua_Nr Qua_Descr Qua_Sit Qua_Val

CadClien

Reserv a

CadQuarto

Cli_Sit Cli_Ult_Data

claro que antes de se chegar a este modelo de dados (D.E.R.), para cada depsito 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 normalizao (1, 2 e 3 formas normais). O passo seguinte a partir da modelagem lgica dos dados, gerar sua modelagem fsica, ou seja, criar um modelo de dados com uma forma a partir da qual os dados sero 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 sero transformados em uma Entidade (depsito de dados), conforme visto a seguir.

Nelson Barbosa Jr.

Pgina: 25

ANLISE E PROJETO DE SISTEMAS II

Cli_cpf Cli_nome Cli_End Res_DataIn Res_DataFi

Qua_Nr Qua_Descr Qua_Sit Qua_Val

CadClien

CadReser

CadQuarto

Cli_Sit Cli_Ult_Data

Portanto, para modelo fsico, 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.

Nelson Barbosa Jr.

Pgina: 26

ANLISE E PROJETO DE SISTEMAS II 1.1.3.7. Diagrama Hierrquico de Macro Atividades Uma vez concludo 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 viso simplificada do sistema. Cli_Reserva Cli_Reservado ou Cli_Indisp Clientes Cli_Canc 1, 2, 6 Tratar Reserva Ger_Cancel

Cli_Cancel

CadClien

CadReser

CadQuarto Msg_01 Msg_02 Gerncia

Cli_Ent Cli_Cancel Clientes Cli_Sai Cli_Paga 3,4 Tratar Cliente

7,8 Tratar Quarto

Ger_Lib Ger_Cad

Cli_Conta

Cli_Reserva

Clientes

Nelson Barbosa Jr.

Pgina: 27

ANLISE E PROJETO DE SISTEMAS II 1.1.3.8 Dicionrio de Dados (parcial) do Estudo de Caso Caracter_Valido = * Conjunto de caracteres que podero ser utilizados * Tipo: Alfanumrico Tamanho: 01 [A-Z | 0 9 | @ | & | / | a z | , | . | - | * ] Cli_Cpf Cli_Nom = * Conter o Cdigo do Cadastro de Pessoa Fsica (CIC) * Formato: 999.999.999-99 = * Nome do Cliente * Tipo: Alfanumrico Tamanho: 40 Contedo: {Caracter_Valido} = * Rua, Avenida, Praa, e n. onde reside o Cliente * Tipo: Alfanumrico Tamanho: 40 Contedo: {Caracter_Valido} = * Nome do Bairro onde reside o cliente * Tipo: Alfanumrico Tamanho: 20 Contedo: {Caracter_Valido} = * Nome da Cidade onde reside o Cliente * Tipo: Alfanumrico Tamanho: 20 Contedo: {Caracter_Valido} = * Sigla do Estado onde se encontra a cidade do cliente * Tipo: Alfanumrico Tamanho: 02 = * Cdigo do endereamento postal de onde reside o cliente * Formato: 99999-999 = * Endereo completo de residncia do cliente * Cli_Rua + Cli_Bairro + Cli_Cid + Cli_UF + Cli_Cep

Cli_Rua

Cli_Bairro

Cli_Cidade

Cli_UF

Cli_Cep Cli_End

Nelson Barbosa Jr.

Pgina: 28

ANLISE E PROJETO DE SISTEMAS II Cli_Sit = * Indicar se o cliente encontra-se hospedado ou no * Tipo: Inteiro Tamanho: 01 Contedo: 0 * No est Hospedado * 1 * Encontra-se com Reserva Feita * 2 * Encontra-se Hospedado * = * Dever Ter a ltima data em que o cliente hospedou-se * Formato: 99/99/9999 = * Tupla do Cliente * @Cli_cpf + Cli_Nom + Cli_End + Cli_Sit + Cli_Ult_Data = {Cli_Registro}

Cli_Ult_Data Cli_Registro CadCli

Observe que o exemplo deste pequeno dicionrio de dados acima, compatvel com a entidade CadCli do modelo de dados mostrado anteriormente. Lembre-se de que no dicionrio deve estar todos os dados tratados no modelo de dados, bem como os Fluxos de Dados e Mensagens especificadas na lista de eventos. Exerccio: Refaa o dicionrio de dados (parcial) mostrado como exemplo, tentando diminuir seu tamanho sem perder o seu contedo. (Otimize o jeito de escreve-lo utilizando os recursos de sintaxe disponveis)

No Esquea At este ponto (desde de o levantamento de Dados, modelo Ambiental e modelo Comportamental ) tem-se os processos e resultados da Anlise do Sistema. Na continuao do processo de desenvolvimento do sistema, dever ser elaborado o chamado design , a partir dos resultados obtidos at aqui.

Nelson Barbosa Jr.

Pgina: 29

ANLISE E PROJETO DE SISTEMAS II 1.1.3.9. CASE - (Computer Aided Software Engineering) Engenharia de Software Auxiliada por Computador Este termo foi criado no comeo dos anos 80, atribudo a qualquer software que busca auxiliar o Analista na construo de sistemas. Teoricamente, para uma ferramenta ser considerada um software CASE, ela deve incorporar e suportar toda a trajetria e tcnicas de especificao e construo de um sistema de acordo com determinado mtodo. Deve ainda gerar o cdigo fonte de acordo com uma linguagem escolhida, compativel com o mtodo empregado. No caso de Orientao a Objeto, dever gerar o cdigo fonte em uma linguagem OO, ou trabalhar integrado a um repositrio de metadados de um banco de objetos. Pelo fato de existir softwares de apoio ao desenvolvimento de sistemas, que no atendem na integra a definio terica 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 so tratados os aspectos lgicos (especificao/documentao) dito que ele um UPPER-CASE, porm, se o software auxilia na modelagem lgica e fsica, propiciando at a possibilidade criao da base de dados, pode-se classific-lo como um LOW-CASE.

Nelson Barbosa Jr.

Pgina: 30

ANLISE E PROJETO DE SISTEMAS II

2. Projeto (design)
Observa-se de antemo, com algum rigor, que a traduo da palavra Project do Ingls para o portugus, com relao a sua aplicao na informtica, adquire um contexto muito maior do que aquele representado pela nossa palavra projeto. Project leva em considerao fases anteriores ao nosso projeto, abordando tarefas de planejamento, superviso e gerncia e no somente o projeto propriamente dito. O projeto, de que vamos tratar a partir deste ponto, portanto, o projeto propriamente dito (no ingls encontramos mais adequadamente a palavra design). O Projeto Estruturado Moderno de Sistemas a atividade de transformao das necessidades do usurio, provenientes da fase da Anlise, em um plano de implementao atravs da automao eletrnica. O objetivo modelar o sistema determinando como implementar, num ambiente em que deixa-se de ter a tecnologia perfeita, passando a levar em considerao o hardware e software com todas as suas limitaes. As restries de implementao, da tecnologia no ideal e imperfeita sero incorporadas atravs de atividades de infra-estrutura e administrativas.

2.1 Critrio de Qualidade do Projeto Completeza O projeto no deve perder nada do que foi identificado na fase de anlise como requisito essencial. Manutenibilidade Deve-se projetar um sistema de forma a permitir facilidades de alteraes, provenientes de: Erros do Sistema Novas necessidades do usurio Alteraes do Ambiente (observa-se que os sistemas mais fceis de alterar so aqueles construdos de forma modular, com cada mdulo desempenhando funes bem definidas e coesas) Performance Ela est diretamente relacionada ao uso otimizado dos recursos de hardware, software e pessoal disponveis.

Nelson Barbosa Jr.

Pgina: 31

ANLISE E PROJETO DE SISTEMAS II Com relao aos fatores que afetam o desempenho, temos: Deficincia do Projeto de Interface Vrios cuidados devem ser tomados quando se projeta uma interface (superfcie entre duas faces), mecanismos pelo qual ocorre a comunicao atual homem-mquina. A interface deve permitir que a comunicao se estabelea no sentido homem-mquina e vice-versa, devendo ser um mecanismo de mo dupla, permitindo ao homem no 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 informaes esto sendo transcritas, a ordem dos campos na tela (quando for o caso de um vdeo) deve obedecer a mesmo ordem dos campos existentes no documento, principalmente quando se tratar de um grande volume de transao. 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 perifricos Observe que para este tpico, deve-se conhecer muito bem o ambiento topolgico do hardware em que se est trabalhando e sua periferia (de perifricos), alm claro do hardware que est sobre esta estrutura. Devido ao tempo gasto em acesso a discos (que atualmente muito maior do que as operaes na CPU), deve-se prover o sistema de mecanismos que minimizem este tempo, empregando-se organizaes de arquivos adequadas, ou ajustando o parque de hardware. Falta de Reorganizao de Arquivos Em arquivos grandes de muita utilizao, deve-se verificar a possibilidade de limpezas peridicas, ou particionamento do arquivo, gerando um atual e um outro histrico. Processos longos em horrio de pique Evite ao mximo a execuo de processos batch de longa durao (transferncias de grandes arquivos, atualizao de grande volume de dados) durante o horrio de pique.

Nelson Barbosa Jr.

Pgina: 32

ANLISE E PROJETO DE SISTEMAS II Segurana Criar mecanismos que evitem acessos indevidos (ou no desejados) ao sistema. -Infiltrao intencional (roubo, sabotagem, grampeamento) -Infiltrao no intencional (linhas cruzadas, irradiaes) -Acidentes erro do usurio, falha de hardware, falha de software Confiabilidade Est relacionada a reduo do risco de interrupo no fluxo normal de processamento das informaes, que pode ser causada por: - indisponibilidade de acesso o sistema no oferece o servio no tempo estipulado - perda da integridade da informao Custo Balanceado (Economia) Deve haver uma admissvel distribuio de custos entre os aspectos que seguem: - custo da tecnologia - custo operacional - custo de construo e manuteno

2.2 Modelo de alocao de processadores Este modelo visa definir claramente as fronteiras da automao do sistema. Processador define quem executar algo. Por quem, entende-se computador ou pessoas (processadores humanos). Em relao aos modos de processamento de um sistema, h um espectro razoavelmente grande de possibilidades, que vai desde um processamento inteiramente manual at um processamento totalmente automatizado. Pode-se ir desde a total centralizao em um nico processador at uma soluo que utilize uma complexa rede de processamento distribudo. Na verdade, todo sistema possui vrias partes, as quais podem ter modos de processamento diferentes. Tem-se aqui o objetivo de alocar as atividades essenciais (segundo a lista de eventos) aos processadores que as executaro. Deve-se tambm alocar atividades adicionais necessrias devido a limitao da tecnologia (Backup, Restore, Reorganizaes)

Nelson Barbosa Jr.

Pgina: 33

ANLISE E PROJETO DE SISTEMAS II Portanto, necessrio responder a estas questes: -Quais os processos manuais e quais os automticos ? -Qual o processador de cada processo essencial (segundo a lista de eventos) ? -Qual o processador de cada processo adicional (visto a limitao de tecnologia) ? -Qual o modo de processamento de cada processo ? -Qual a freqncia de execuo de cada processo ? Um maneira de mostrar essas caractersticas do sistema atravs de um quadro de referncia como a seguir: FREQUNCIA
Minuto Hora Dirio Semanal Mensal

Batch Processador A On-Line Batch Processador B On-Line Sistema . . . Batch Processador n On-Line P1/P2 PT01

Nelson Barbosa Jr.

Pgina: 34

ANLISE E PROJETO DE SISTEMAS II H vrias formas que podem ser apresentadas para satisfazer visualmente a alocao de processadores, abaixo segue outro exemplo:
Processador PC-01 Pentium 100 Processo Evento Tipo Processamento Frequncia

P01 P02 PT01

Cliente Reserva Quarto hora de cancelar reserva Executar Antivrus

On-Line Batch Batch On-Line Batch Batch Batch

Diria Dirio Semanal Dirio Semanal Dirio Anual

PC-02 Pentium 133

P07

Quando Quarto estiver limpo gerente disponibiliza-o PT01 Executar Antivrus PT02 PT03 Backup dos Dados Reorganizao de Arquivos

. . . Pnn PTn = Atividade Essencial da lista de eventos = Processo de restrio Tecnolgica

O exemplo acima leva vantagens sobre o anterior, notadamente pelo fato de que pode ser aplicado a pequenas ou grandes quantidades da relao processador X processo. No modelo anterior, fica muito difcil a representao de vrios processos a serem executados em um mesmo processador num mesmo perodo.

Nelson Barbosa Jr.

Pgina: 35

ANLISE E PROJETO DE SISTEMAS II

2.3 Consideraes sobre segurana e controle do sistema 2.3.1 Verificao e Validao Em 22 de Julho de 1962, o foguete espacial Mariner I foi lanado em um primeiro esforo da humanidade de explorar os planetas, uma misso para Vnus. O foguete desviou de sua rota e o controle terrestre deu a ordem para explodi-lo. Posteriormente, uma investigao revelou que o software apresentava erros. A omisso de um simples hfen em um programa de computador tinha passado despercebida e tinha provocado um fracasso de toda a misso. O custo para o contribuinte fiscal foi de 18,5 milhes de dlares (MARTIN & MCCLURE, 1991:737). Certamente, talvez iremos ter que trabalhar com projetos, cujo custo seja mais modesto, comparado ao Mariner I, contudo, poder se enquadrar nas mesmas propores catastrficas, quanto aos possveis erros que venha a apresentar. H uma certa freqncia de erros graves exibidos pelos softwares atualmente desenvolvidos, apesar dos esforos especiais que se tem empregado para se atingir a perfeio. A preocupao com tais fatos, se deve ao prejuzo econmico que eles podem causar, no tanto pela situao de embarao que os mesmos costumam trazer. Certamente que a proeza de se conseguir um software 100% correto no momento de sua elaborao, nem sempre uma tarefa possvel, mas isto seria o ideal. Desta forma, o recurso atual para se eliminar tais erros, se encontra nas atividades de verificao e validao, fazendo uso de tcnicas dirigidas. Um questionamento sempre levantado sobre tais atividades, refere-se ao momento ideal em que devam ser realizadas: na fase final do ciclo de desenvolvimento do sistema ou durante o mesmo ? Constata-se que a correo deve ser aplicada por todo o ciclo de desenvolvimento, atravs do uso de vrias ferramentas e tcnicas. Verificao a demonstrao da consistncia, completeza e correo do software medida que ele evolui... Validao a demonstrao de que o sistema de software concludo satisfaz corretamente s necessidades e aos requisitos do usurio (MARTIN & MCCLURE, 1991:734). Nota-se ento, que a verificao busca corrigir o software etapa por etapa, durante o ciclo de seu desenvolvimento, enquanto que a validao cuida da correo do produto j finalizado.

Nelson Barbosa Jr.

Pgina: 36

ANLISE E PROJETO DE SISTEMAS II Alm do software final livre de erros, a economia monetria e de tempo que se pode obter quando se utiliza as atividades de verificao e validao, so considerveis. A trajetria bsica e mnima que se espera que o Analista deva seguir sugerido abaixo: Com relao a Verificao Efetuar testes de unidade a cada mdulo do software desenvolvido, verificando se este atinge seus objetos sem apresentar qualquer anomalia na execuo e no desempenho lgico. Lembre-se de que teste deve ser a incansvel busca de erros, e a depurao, a eficiente eliminao dos erros encontrados. Com relao a Validao Primeiro efetuar um teste funcional do sistema, onde, aps todos os mdulos 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 usurio, a fim de que se manifeste sobre a validade do produto. Segurana de Dados Por incrvel que parea, muitos daqueles diretamente ligados a tecnologia da informao, tais como tecnolgos, analistas, programadores, raramente, ao editar um texto, por exemplo, tem a preocupao de efetuar um backup. O que pensar ento de um usurio mais leigo ? fundamental, em qualquer sistema de informao, sob qualquer aspecto, que haja mecanismos para salvaguardar os dados manipulados no sistema. Tais mecanismos podem ser desde meras rotinas dirias de backup, at sofisticados hardwares com o meio de armazenamento espelhado e componentes redundantes, ou ainda tcnicas de replicagens da informao. Para a transao da informao tambm h absoluta necessidade de segurana. Sob este aspecto podemos considerar dois fatos: 1) Duas ou mais operaes acionadas em um processo que, para manter a integridade da informao, todas as operaes devem ser corretamente concludas. Havendo falha de uma, todo o processo deve ser revertido (Roll-Back). 2) Casos em que uma informao em trnsito poder exigir sua mais absoluta inviolabilidade deve passar pelo processo de criptografia.

Nelson Barbosa Jr.

Pgina: 37

ANLISE E PROJETO DE SISTEMAS II Outra caracterstica de segurana de dados a ser tratada o acesso aos mesmos. Tanto quanto necessrio, checar identificao e senhas de acesso conforme o caso exigir. Segurana de Hardware Sabe-se que para um hardware funcionar perfeitamente, existe algumas especificaes a serem observadas. Via de regra, ignora-se tal fato, visto que existem muitos lugares onde, por exemplo, o pino terra da alimentao eltrica no utilizado. Outros fatores importantes como a estabilidade da tenso eltrica e a temperatura ambiental so fatores encarados como totalmente secundrios. As instalaes para utilizao do hardware deve atender as suas especificaes. Caso contrrio, o seu sistema j comea com alto risco de erro.

2.4 Diagrama hierrquico do sistema Mais como um mecanismo de estabelecimento da organizao hierrquica do sistema, o diagrama tambm um documento de interface, j que um esboo do que vir a ser o menu do sistema. Desta forma ele tambm parte integrante da documentao do sistema, uma vez que se pode recorrer a ele para identificar posies ou seqncia de caminho at se chegar a uma determinada opo.
Menu Principal

Cadastros

Movimentao

Consultas

Segurana

Quartos Clientes

Reserva Quarto Registro Cliente Cancela Reserva Fecha Conta Libera Quarto a

Quartos Livres

Backup

Clientes Hospedados

Nelson Barbosa Jr.

Pgina: 38

ANLISE E PROJETO DE SISTEMAS II Observa-se que podem haver outros programas no sistema, porm, sua execuo d-se em funo de outros fatos, que no sejam da escolha de um usurio. Como exemplo pode-se citar: programa de converso de valor para extenso, programas cujo estmulo seja um fluxo temporal (rodar todo dias as 12h). Estas chamadas de programas estaro documentadas nas miniespecificaes dos programas chamadores. Por exemplo, em um programa que emita um recibo, cujo valor deve ser convertido para extenso, dever conter em sua miniespecificao a chamada a esta subrotina ou programa.

2.5 Lay-Out de telas / relatrios Qualquer sistema de informao utiliza interfaces e cuida do meio pelo qual este mecanismo opera. Na construo dos sistemas de informao, necessrio um cuidado especial com relao aos requisitos exigidos por cada uma das partes (homem-mquina) que se ligam pela interface. Para a mquina basta que o meio fsico esteja em perfeita condio de funcionamento, pois assim, os dados do input estando corretos, o resultado certamente estar (sob ponto de vista do hardware). O homem por sua vez, ao receber uma informao proveniente da mquina, deve visualizla de uma forma amigvel e de fcil entendimento. Este aspecto pode ter muita influncia na negociao poltica de venda do produto para o usurio. Em certos momentos a forma mais amigvel e de fcil entendimento, ser aquela que o usurio deseja ver, independente do que voc tenha estudado sobre interfaces e ergonometria (no se esquea disto). O fato que uma vez definido um relatrio ou uma tela, tente seguir aquele modelo como padro para os demais. Por que padronizar ? Ora, voc estar universalizando funes, bem como diminuindo o tempo de aprendizado e uso de seu sistema. No reinvente a roda. Se j existe um certo padro de mercado, emprega-o . Veja por exemplo, se voc fizer hoje um software para utilizao em um microcomputador IBM-PC, qual a tecla mais indicada para ser utilizada como help do seu sistema ? Por qu ? Alguns detalhes valem ser lembrados com relao a telas/relatrios, sempre que possvel mencione:

Nelson Barbosa Jr.

Pgina: 39

ANLISE E PROJETO DE SISTEMAS II Nome da tela/Relatrio Ttulo do Processo Data / Hora Pgina Porm, se j existe um padro dentro de seu desenvolvimento, siga-o . Veja por exemplo no caso de um desenvolvimento para o ambiente WINDOWS, voc deve respeitar todas as caractersticas de interface j definidas. Acompanhar Evoluo Atualmente existe um leque muito grande de recursos para tornar amigvel a interface homem-mquina. Especialmente, a interface grfica, aquela que para os sistemas de informao atualmente melhor esto sendo empregadas, j que uma forma bastante amigvel de enviar e receber informaes. A esta interface grfica, pode ser incorporado outros elementos que a completam, tais como sons, imagens estticas, animadas ou filmadas e outros elementos de multimdia. Multimdia a combinao de texto, som e vdeo para apresentar informaes por maneiras que voc apenas imaginava. A multimdia d vida s pginas de informao... muda a maneira como as pessoas usam os computadores... (JAMSA, 1993:XIII). Por exemplo, em um sistema de controle de biblioteca, poderia-se ter alm da opo de busca de um livro, a possibilidade de ouvir um trecho do livro narrado pelo computador na lngua previamente escolhida, e tambm, a seu critrio, poderia ver as imagens relativas a estria que estaria sendo narrada. A multimdia caminha para um evoluo que agregar outros fatores, tais como a possibilidade futura da inexistncia de um vdeo como hoje o concebemos, mas a projeo de imagens hologrficas, propiciando a interao atravs de uma realidade virtual, o que permitir uma vivncia e avaliaes que seriam impossveis em circunstncias normais ( como por exemplo, caminhar dentro de um vulco ou tapar sua chamin e verificar o resultado, segundo as leis da fsica ).

Nelson Barbosa Jr.

Pgina: 40

ANLISE E PROJETO DE SISTEMAS II

3. Gerncia 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 execuo das atividades de desenvolvimento propriamente dito, que envolvem metodologias, tcnicas e ferramentas de desenvolvimento, tudo mais em um projeto de sistemas ao de gerncia. Assim deve-se ter em mente o que segue, como definio 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 rpida evoluo da tecnologia Proliferao desordenada de microcomputadores Vida til do Hardware Grande quantidade de software no integrado Aumento dos nveis de expectativa devido divulgao instantnea das inovaes Ferramentas de desenvolvimento muito recentes, ainda no consolidadas

Nelson Barbosa Jr.

Pgina: 41

ANLISE E PROJETO DE SISTEMAS II

3.1.2 Relacionados com pessoas As pessoas freqentemente no sabem o que realmente querem ou necessitam desenvolvimento de sistemas exige muita comunicao: - No. De interaes dois a dois = N(N 1) / 2 - Muitas pessoas falam bem, pouqussimas ouvem bem - Palavras tem diferentes significados muito comum desenvolvedores no ouvirem os usurios e raramente constrem o que necessrio Desenvolvedores no aceitam mudana no seu prprio domnio (paradigma de comportamento) Conflitos sempre existiro. Cabe ao gerente administrar adequadamente

3.1.3. Outros problemas Gerenciais Imprevisibilidade previsvel Frias de elementos da equipe Baixa disponibilidade de recursos de hardware Alocao temporria de pessoal para outro sistema Mudana de prioridades da organizao Seleo de pessoal Quantidade X Qualidade Nvel do profissional (conhecimento X experincia X dinamismo ) A somatria destes dois fatores trs como conseqncia um terceiro: Dificuldade de estimar prazos e recursos

Nelson Barbosa Jr.

Pgina: 42

ANLISE E PROJETO DE SISTEMAS II

3.1.4. Dificuldade de aferir progresso 100 % 99 % Tempo

SINDROME DOS 99 %

Completude do sistema No h frmulas mgicas para evitar atrasos em projetos de sistemas (No silver bullet no tem bala de prata) A nica maneira de monitorar o progresso de um projeto, atravs do estabelecimento de marcos ou pontos de controle, ao longo das fases e atividades que o compem, que se constituem em etapas sobre as quais podemos afirmar com certeza: est 100% concluda. 3.1.5. A Crise do Software Em 1993 foi feito uma estimativa sobre das metodologias, tcnicas e ferramentas de desenvolvimento de sistemas existentes na poca (que foram uma somatria evolutiva dos 25 anos anteriores), e pode-se concluir que: Se todos os sistemas necessrios tivessem que ser implementados nos prximos dez anos com a tecnologia de software disponvel, mais da metade da populao do mundo teria que ser de programadores . O recente advento dos gerenciadores de bancos de dados, das ferramentas CASE (Computer Aided Software Engineering ) , das linguagens de programao visuais e da orientao a objeto tem contribudo para melhorar a produtividade no desenvolvimento de sistemas. Porm, apenas uma gerncia adequada do uso dessas ferramentas tornar possvel a superao da crise do software ainda existente. Muitas pessoas acreditam que desenvolver um sistema simplesmente programar.

Nelson Barbosa Jr.

Pgina: 43

ANLISE E PROJETO DE SISTEMAS II

Como se fosse possvel aplicar a sistemas complexos do mundo real, as mesmas decises de projeto, utilizadas na resoluo de problemas que esto ao alcance da compreenso de um nico programador.

Nelson Barbosa Jr.

Pgina: 44

ANLISE E PROJETO DE SISTEMAS II

4. Processo de Gerncia de Projeto

1 Objetivos 2 Planejamento Organizao / Coordenao Avaliao do Progresso 5 Reviso e registro histrico 3

1. Defina os objetivos do projeto Repetir 2. 3. 4. 5. Planejar as tarefas para alcanar os objetivos Organizar / Coordenar os recursos colocar as tarefas em execuo Avaliar o progresso em relao ao plano at alcanar os objetivos Revisar o planejamento, a organizao dos objetivos, conforme necessrio. Registrar o histrico do projeto

FimRepetir

Nelson Barbosa Jr.

Pgina: 45

ANLISE E PROJETO DE SISTEMAS II

4.1. Definio dos Objetivos

O primeiro princpio de gerncia de projetos estabelecer um conjunto claro de objetivos e requisitos do projeto, bem como obter informaes que permitam decidir sobre a convenincia de realizar o desenvolvimento do projeto. Objetivos tcnicos ou meta do projeto Especificaes do produto, lista de padres aplicveis, restries assumidas (ambiente operacional, outros sistemas) Prazos: sempre um fator limitante Oramento: Quase sem um fator limitante Recursos: nem sempre limitante quanto os anteriores Muitas vezes, estas informaes para serem uma base segura sobre a qual seja possvel estabelecer um contrato de desenvolvimento, devem estar reunidas em um documento, conhecido como Proposta de Desenvolvimento de Sistema. Organizao da Proposta de Desenvolvimento de Sistema Objetivo: antecipar respostas a perguntas que surgiro durante o desenvolvimento. Contedo: Descrio em linhas gerais do sistema atual e suas deficincias; Descrio do sistema a ser desenvolvido, definindo seus objetivos, requisitos, as necessidades e expectativas dos usurios bem como as vantagens do sistema proposto; Dados que permitam avaliar a viabilidade do desenvolvimento e da operao do sistema proposto

Nelson Barbosa Jr.

Pgina: 46

ANLISE E PROJETO DE SISTEMAS II

Para que a proposta cumpra seu papel, ela deve ser: Macroscpica, de forma a exigir um mnimo de detalhe; Fidedigna, sem omitir ou exagerar fatos; Imparcial; Realista e vivel;

Em uma estrutura organizacional mais simples, a proposta de desenvolvimento acaba se resumindo num documento interno do tipo Ordem de Servio, em outras organizaes menores ainda, simples reunies 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 tcnicas (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 prtica, o planejamento no to cartesiano como aparenta. O grau de complexidade e preciso depende do estgio em que se est planejando. Nos estgios iniciais, ele mais simples e impreciso, nos estgios mais avanados mais complexo e detalhado. Ao longo do desenvolvimento, o objetivo do planejamento um alvo mvel. Portanto, segundo dizem, a nica certeza sobre um plano que as coisas no ocorrero conforme planejado; ainda assim, tenha um plano, ruim com ele, muito pior ainda sem.

Nelson Barbosa Jr.

Pgina: 47

ANLISE E PROJETO DE SISTEMAS II Exemplo de Tabela de Planejamento

O qu ? Atividades

Por Que ?

Quem Far

Quando

Onde

Como ferramentas e Quanto mtodos Custa ?

Quanto Tempo ?

Outra forma de efetuar um planejamento a utilizao e um organograma, conforme exemplo abaixo:

Publicar Jornal 1 Obter Verba Comprar Material 4 Encomendar Des.Artstico 5 Fazer Fotos

Produzir Jornal

2 Comprar Papel

3 Comprar Mat.Foto Produzir Texto Produzir Verso Final

6 Editar Texto

7 Revisar Texto

8 Integrar Des./Foto

9 Imprimir

Nelson Barbosa Jr.

Pgina: 48

ANLISE E PROJETO DE SISTEMAS II Exemplo de planejamento, utilizando aplicao de chaves

Obter Verba Comprar Papel Comprar Material Comprar Mat. Fotogrfico Encomendar Des. Artstico Publicar Jornal Fazer Fotos Editar Texto Produzir Texto Revisar Texto Produzir Jornal Produzir Verso Final Integrar Desenho Foto Imprimir

Outro exemplo de planejamento, utilizando classificao codificada

Nelson Barbosa Jr. Pgina: 49

ANLISE E PROJETO DE SISTEMAS II

Publicar Jornal 1. Obter Verba 2. Comprar Material 2.1 Comprar Papel 2.2. Comprar Mat. Fotogrfico 3. Encomendar Des. Artstico 4. Fazer Fotos 5. Produzir Jornal 5.1 Produzir Texto 5.1.1 Editar Texto 5.1.2 Revisar Texto 5.2 Produzir Verso Final 5.2.1 Integrar Desenho/Foto 5.2.2 Imprimir

Exerccio: Fazer um DFD para expressar o planejamento de acordo com os exemplos vistos.

Nelson Barbosa Jr.

Pgina: 50

ANLISE E PROJETO DE SISTEMAS II Exemplo do planejamento com lista de atividades, incluindo durao e seqncia Atividades (a) Obter Verba (b) Comprar Papel (c) Comprar Material Fotogrfico (d) Encomendar Desenho Artstico (e) Fazer Fotos Anterior (a) (a) (a) (c) (f) (e) (d) (g) (b) (h) Atividade (a) (b) (c) (d) (e) (f) (g) (h) (i) (f) Editar Texto (g) Revisar Texto (h) Integrar Foto/Desenho (i) Imprimir Posterior (b) (c) (d) (i) (e) (h) (h) (g) (h) (i) Durao 3 2 1 7 3 5 5 1 1

Planejamento utilizando o diagrama de GANTT ATIVIDADES 01 (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 02 03 04 05 06 07 08 09 10 11 12

Nelson Barbosa Jr.

Pgina: 51

ANLISE E PROJETO DE SISTEMAS II

Exemplo do planejamento empregando diagrama de GANTT com alocao de recursos Atividades (a) Obter Verba (b) Comprar Papel (c) Comprar Material Fotogrfico (d) Encomendar Desenho Artstico (e) Fazer Fotos RECURSOS HUMANOS EDITOR (b) COMPRADOR (c) (d) DESENHISTA (e) (f) REDATOR (G) REVISOR 01 (a) 02 03 (f) Editar Texto (g) Revisar Texto (h) Integrar Foto/Desenho (i) Imprimir

04

05

06

07

08 09

10 11 12 (h) (i)

Lembre-se que onde existe a numerao, pode-se trocar por Datas.

Nelson Barbosa Jr.

Pgina: 52

ANLISE E PROJETO DE SISTEMAS II

4.3. Organizao / Coordenao

A tarefa de organizar pode ser vista como montar um time: dado um grupo de pessoas e uma meta comum, qual o melhor papel para cada indivduo, e como as responsabilidades devem ser divididas ? Como motivar estas pessoas ? Como gerar uma sinergia ? Veja como no existe a priore, respostas para estas questes, dissociadas de um contexto onde aplica-las (pessoas com seus interesses, viso de mundo, qualificao, experincias diferenciadas). Portanto, a tarefa de coordenao no fcil (para um tcnico, pior ainda, se no tiver um mnimo de formao voltada para cincias humanas/administrativas). Objetivos da Organizao / Coordenao Combinar conhecimentos tcnicos de cada pessoa com as tarefas que ela vai realizar Reduzir ao mnimo as horas ociosas das pessoas Designar cada pessoa para apenas uma tarefa de cada vez Obtenha no apenas o envolvimento, mas o comprometimento das pessoas

Nelson Barbosa Jr.

Pgina: 53

ANLISE E PROJETO DE SISTEMAS II Diferena entre envolvimento e comprometimento. Na floresta, numa linha manh ensolarada, a coruja, a galinha e o porco se encontram: CORUJA: Vamos fazer um omelete ? TODOS: Vamos !!! CORUJA: Bom, eu posso entrar com a frigideira . A galinha pensou, pensou, pensou... GALINHA: Eu posso entrar com os ovos. CORUJA: Legal ! Por alguns segundos a coruja e a galinha entreolharam-se e simultaneamente, voltaram-se ao porco... GALINHA e CORUJA: Voc entra com o bacon... Moral da estria: A galinha estava envolvida o porco comprometido. Fatores Humanos Tenha sempre em mente que as Pessoas so o mais importante recurso em projetos de sistemas (s vezes o nico alm do tempo). Sero tambm as pessoas que iro julgar a utilidade dos softwares desenvolvidos, portanto, fundamental que se entenda um pouco de fatores humanos (psicologia da personalidade, motivao, comunicao) Aspectos chaves: Trabalho em grupos pequenos Liderana tcnica por competncia Local de trabalho adequado Benefcios: Reduo de problemas de comunicao Padro de qualidade Aprendizado mtuo Sociabilizao do trabalho

Nelson Barbosa Jr.

Pgina: 54

ANLISE E PROJETO DE SISTEMAS II

4.4 Avaliao do Progresso

a atividade gerencial que serve para obter uma medio do andamento do projeto, de acordo com pontos de controles especificados (Milestones). Dois nveis de controle: Informal No dia a dia do gerente, atravs de interao casual (intencional) com os membros da equipe; no gera relatrios. Um controle informal efetivo, minimiza a freqncia e as sobrecarga (overhead) de reunies e relatrios. Formal Requer relatrios peridicos gerados por revises sobre andamento do projeto. Normalmente, so de dois tipos: Revises Gerenciais reunies realizadas em cada ponto de controle com todo o grupo de desenvolvimento; gerando um relatrio de progresso (com a narrativa do ponto atual e justificativa) Revises Tcnicas voltadas para aspectos especficos dentro das etapas existentes, envolvendo apenas os profissionais diretamente ligados com aqueles aspectos, tendo por objetivo eliminar problemas de transcurso, mantendo um registro sobre isto relatrio tcnico.

Nelson Barbosa Jr.

Pgina: 55

ANLISE E PROJETO DE SISTEMAS II

Exemplo de um projeto com pontos de controle FASE 100 110 120 199 300 310 320 330 340 350 399 500 510 520 530 540 700 710 720 730 740 ATIVIDADE DEFINIO DO PROJETO Avaliao Preliminar Estudo do Projeto Ponto de Reviso DEFINIO DOS REQUISITOS BSICOS Esboo das Funes do Sistema Avaliao de Recursos Tecnolgicos Planejamento do Desenvolvimento Anlise de Viabilidades Reviso e Aprovao Ponto de Reviso DESENVOLVIMENTO Levantamento detalhado de dados Projeto Lgico (Mod.Ambiental/Comportamtal) Projeto Fsico (Implementao) Ponto de Reviso IMPLANTAO Planejamento da Implantao Teste Piloto Instalo / Treinamento Instalao e Treinamento Acompanhamento e Auditoria PONTOS DE CONTROLE

Fase 100 Concluda

Fase 300 concluda

Atividade 520 concluda Fase 500 concluda

Fase 700 concluda (encerramento do projeto)

Um exemplo de pauta para reunies referente as revises gerenciais

Nelson Barbosa Jr.

Pgina: 56

ANLISE E PROJETO DE SISTEMAS II Que pode ser aplicada em qualquer momento dentro da evoluo do projeto: 1 2 3 4 5 6 7 8 9 Atividades Desenvolvidas Fases e Atividades em curso Problemas Encontrados Solues Propostas Atividades a serem desenvolvidas Ocorrncia de Contingncias Consideraes sobre os prazos Providncias Concluso da Reunio

Revises Tcnicas Com relao as Revises Tcnicas, se prope: 1 Reviso de Requisitos Motivao principal: Assegurar que, se os desenvolvedores construrem um sistema que satisfaa os requisitos, ele satisfar as necessidades dos usurios. Avaliao dos aspectos: Incorreo: requisitos que demandam algo que os usurios no querem. Imcompleteza: a especificao falha em dizer algo que algum usurio necessita. Ambigidade: requisitos que so imprecisos a ponto de admitir muitas possveis interpretaes. Inconsistncia: requisitos que se contradizem um ao outro 2 Reviso de design O design satisfaz os requisitos ? O design consistente ? O design completo ?

Nelson Barbosa Jr.

Pgina: 57

ANLISE E PROJETO DE SISTEMAS II Fazendo parte deste elenco, aplicar walkthrough (inspees para validao e verificao) As revises tcnicas podem ser realizadas em diferentes fases do ciclo de desenvolvimento. Na fase de anlise de requisitos, o objetivo a validao do sistema, em geral envolvendo usurios. VALIDAO Estamos construindo o sistema certo ? Nas fases subsequentes, o objetivo a verificao do desenvolvimento, como pressuposto de que os requisitos esto vlidos. VERIFICAO Estamos construindo certo o sistema ?

4.5 Reviso e Registro Histrico

Revisar um projeto o processo de fazer mudanas a fim de resolver os desvios do planejamento. A reviso do projeto permite ao gerente manter suas armas gerenciais apontadas para o alvo mvel do projeto. So cinco as boas razes usuais para se fazer reviso: Perda de prazo para o trmino de tarefas Tarefas mal feitas Tarefas no realizadas Mudanas imprevistas de pessoal Corte de recursos inicialmente previstos

Sem registro, a histria continuar a ser repetida sem aperfeioamento da experincia.

Nelson Barbosa Jr.

Pgina: 58

ANLISE E PROJETO DE SISTEMAS II

5. BIBLIOGRAFIA
Kugler, Aguinaldo Aragon Fernandes & Kugler, Jos Luiz Carlos. Gerncia de Projeto de Sistemas. Rio de Janeiro, LTC, 1990. Martin, James & McClur, Carma. Tcnicas Estruturadas e Case. So Paulo. Makron, 1991. McMenamin, Stephen M. & Palmer, John F. Anlise Essencial de Sistemas. So Paulo, McGraw-Hill, 1991. Pompilho, S. Anlise Essencial. Rio de Janeiro. Infobook, 1994.

Nelson Barbosa Jr.

Pgina: 59

ANLISE E PROJETO DE SISTEMAS II

Nelson Barbosa Jr.

Pgina: 60