ANALISE E PROJETO DE SISTEMAS

ESUCRI ESCOLA SUPERIOR DE CRICIÚMA CURSO SISTEMA DE INFORMAÇÃO ANALISE E PROJETO DE SISTEMAS Profº Edson Thizon MARÇO/2004

METODOLOGIA DE DESENVOLVIMENTO E MANUTENÇÃO DE SISTEMAS (M.D.M.S. - VERSÃO 2.0) SUMÁRIO 1. INTRODUÇÃO... 2. FASES... 3. ESTUDO PRELIMINAR... 3.1 OBJETIVOS DA FASE... 3.2 PRODUTOS DA FASE... 3.3 ATIVIDADES DA FASE... 3.3.1 DEFINIÇÃO DO PROBLEMA... 3.3.2 DEFINIÇÃO DO ANDAMENTO DOS TRABALHOS... 3.3.3 DEFINIÇÃO DOS OBJETIVOS DO SISTEMA... 3.3.4 DEFINIÇÃO DA ABRANGÊNCIA DO SISTEMA... 3.3.5 ANÁLISE DAS RESTRIÇÕES FINANCEIRAS, OPERACIONAIS E DE DESENVOLVIMENTO... 3.3.6 DEFINIR ESTRATÉGIAS PARA O DESENVOLVIMENTO... 3.3.7 ESTIMATIVA DE RECURSOS DE HARDWARE E SOFTWARE DE APOIO... 3.3.8 ESTIMATIVA DE RECURSOS HUMANOS E PRAZOS ( CRONOGRAMA)... 3.3.9 VIABILIDADE... 3.3.10 APROVAÇÃO DO DOCUMENTO... 4. ANÁLISE DE REQUISITOS... 4.1 OBJETIVOS DA FASE... 4.2 PRODUTOS DA FASE... 4.3 ATIVIDADES DA FASE... 4.3.1 CONFIGURAÇÃO DAS REUNIÕES... 4.3.3 LEVANTAMENTO DOS EVENTOS E FUNÇÕES CORRESPONDENTES... 4.3.4 LEVANTAMENTO DE ENTIDADES E SEUS ATRIBUTOS... 4.3.5 APROVAÇÃO DO DOCUMENTO... 5. PROJETO LÓGICO... 5.1 OBJETIVOS DA FASE... 5.2 PRODUTOS DA FASE... 5.3 ATIVIDADES... 5.3.1 CONSTRUÇÃO DO MODELO ENTIDADE RELACIONAMENTO... 5.3.2 DIAGRAMA HIERÁRQUICO DE FUNÇÕES... 5.3.3 MATRIZ DE USO: ENTIDADES X FUNÇÕES... 5.3.4 DIAGRAMA DE FLUXO DE DADOS(OPCIONAL)... 6. PROJETO FíSICO... 6.1 OBJETIVOS DA FASE... 6.2 PRODUTOS DA FASE... 6.3 ATIVIDADES PREVISTAS... 6.3.1 PROJETO DO BANCO DE DADOS... 6.3.2 PROJETO DOS MÓDULOS DO SISTEMA ( ESTRUTURA DO SOFTWARE )... 6.3.3 APROVAÇÃO DO DOCUMENTO... 7. IMPLEMENTAÇÃO... 2

7.1 OBJETIVOS DA FASE... 7.2 PRODUTO DA FASE... 7.3 ATIVIDADES... 8. IMPLANTAÇÃO... 8.1 OBJETIVOS DA FASE... 8.2 PRODUTOS DA FASE... 8.3 ATIVIDADES... 8.3.1 MONTAGEM DO MANUAL DO USUÁRIO OU HELP ON LINE... 8.3.2 DESENVOLVER ROTINA DE INSTALAÇÃO DO SISTEMA... 8.3.3 TREINAMENTO... 8.3.4 CONVERSÃO DE ARQUIVOS... 8.3.5 ENCERRAMENTO DO DESENVOLVIMENTO... 9. DOCUMENTAÇÃO... 10. REFERÊNCIA BIBLIOGRÁFICA... 3

1. INTRODUÇÃO No desenvolvimento de um sistema de informações computadorizado geralmente o gerente do projeto faz frente a alguns problemas técnicos que, se não forem previstos quando do início do projeto e bem gerenciados, fatalmente levarão ao insucesso do projeto. Problemas mais comuns: Evolução tecnológica; Especificação incorreta do sistema; Metodologias inadequadas; Restrições de pessoal, hardware e software. Outro conjunto de problemas na implantação de sistemas que diz respeito aos aspectos gerenciais do projeto, destacam-se: Comunicação falha da equipe de trabalho. Riscos não avaliados adequadamente. Dificuldade de estimar prazos e recursos. Conflito de objetivos. Fraca compatibilidade entre as políticas da empresa com a área de informática. Cultura da organização. Muitos dos problemas citados acima podem ser minimizados com a implantação de uma metodologia de desenvolvimento e manutenção de sistemas. Em todo processo de desenvolvimento de software existe um ciclo de vida que indica as principais fases que o mesmo percorre desde a sua concepção até sua morte. Cada fase do ciclo de vida do software, independentemente da abordagem utilizada, possui um conjunto de atividades, técnicas e ferramentas que a compõe, estabelecendo um roteiro de trabalho para o desenvolvimento e manutenção. A metodologia de desenvolvimento de sistemas é, em suma, um roteiro de trabalho sobre o qual o gerente visualiza todas as etapas de construção de um software, suas interdependências, bem como o progresso do mesmo. Alguns autores colocam que uma metodologia é um detalhamento de um ciclo de vida de sistema. Existem alguns pontos que justificam plenamente a necessidade de uma metodologia de desenvolvimento de sistemas em uma organização: Grande rotatividade do pessoal de informática é comum o surgimento de novas oportunidades para os profissionais de informática. Talvez essa característica esteja relacionada com a crescente evolução tecnológica que faz com que o mercado exija profissionais com perfis diferentes em pouco espaço de tempo. É fundamental que os projetos em desenvolvimento sejam independentes dos membros da equipe que o conduz. Isso pode ser obtido por uma metodologia que documente e padronize todo processo de desenvolvimento de sistemas. Organização da equipe quanto maior a equipe envolvida num determinado projeto mais difícil fica conduzir e controlar o papel de cada componente dessa equipe. Uma metodologia cria uma linguagem comum a todos, evitando que exista uma perda de seqüência e organização nas rotinas de trabalho. 4

Geração de sistemas de alta qualidade, dentro do orçamento e prazos previstos. Melhoria no relacionamento entre a área de sistemas e seus usuários. Melhor controle de tarefas e recursos em todos os níveis. Aumento de produtividade. Documentação adequada gerada ao longo do desenvolvimento. Conforme observado acima, são várias as contribuições trazidas por uma metodologia num ambiente de desenvolvimento e manutenção de sistemas. Existe, praticamente, três maneiras de adquirir uma metodologia: Desenvolver uma metodologia própria com pessoal técnico e com ajuda de consultores; Adaptar uma metodologia existente no mercado às suas particularidades; Adquirir uma metodologia de empresas especializadas. Certamente, a melhor metodologia é aquela concebida considerando-se as características do ambiente onde ela será implantada. Dessa forma, a melhor alternativa talvez seja desenvolver uma metodologia própria. A metodologia ora proposta contempla todas as fases do desenvolvimento de um sistema de informação: estudo preliminar, análise de requisitos, projeto lógico, projeto físico, implementação, testes, implantação e manutenção. Ela traz influências da Análise Essencial, considerando o tratamento por eventos, e da Análise Estruturada devido a maneira como trata a modelagem de funções. Para automatizar o processo de desenvolvimento dos sistemas pode-se fazer uso de uma ferramenta CASE (Computer Aided Software Engineering) que procura facilitar o trabalho dos analistas no sentido de dar maior produtividade durante o desenvolvimento de um projeto. A ferramenta CASE recomendada é o Oracle Designer 2000 que contempla tanto a modelagem funcional quanto a modelagem de dados, indo desde a parte conceitual da especificação do sistema até sua implementação de fato. Esta ferramenta também permite, a partir da definição conceitual, a prototipação para validar requisitos dos usuários. A metodologia é composta de duas partes: conceitos e atividades relacionados com as etapas de cada fase e documento gerado a partir delas. A Metodologia apresentada não é fixa e também não é camisa de força, no sentido que pretendemos atualiza-la constantemente, incluindo novas abordagens e ferramentas, contando com a colaboração de alunos e professores que tem interesse na área de desenvolvimento de sistemas. 5

2. FASES O desenvolvimento de sistemas, numa visão convencional, pode ser dividido em 6 fases: Estudo Preliminar Análise de requisitos Projeto Lógico Projeto Físico Construção (implementação) implantação As fases são compostas de atividades, cada uma gerando seus produtos. A documentação gerada ao longo do projeto deve compor uma pasta própria, onde serão armazenados os documentos técnicos, atas, correspondências etc. 6

3. ESTUDO PRELIMINAR 3.1 OBJETIVOS DA FASE Fazer um estudo inicial do projeto a fim de avaliar a necessidade e viabilidade do sistema a ser desenvolvido bem como identificar as pessoas envolvidas e responsabilidades. O Estudo Preliminar pode determinar a inviabilidade do desenvolvimento do sistema, tendo como base as dificuldades para o seu desenvolvimento ou mesmo o nível de prioridades da organização. Em muitos casos também é considerado mais interessante a aquisição de um sistema já pronto que atenda os requisitos definidos. 3.2 PRODUTOS DA FASE O produto gerado é o documento denominado ESTUDO PRELIMINAR, conforme modelo Anexo I, contendo o resultado das atividades desenvolvidas nesta fase. 3.3 ATIVIDADES DA FASE Participantes comprometidos com o Estudo Preliminar: Participantes Nível de Importância Gerentes dos Setores Envolvidos Máxima Analistas Responsáveis Máxima Para melhor identificar os participantes do projeto, pode-se fazer uso, do organograma da Organização. 3.3.1 DEFINIÇÃO DO PROBLEMA Nesta fase é identificado e analisado o problema que se defronta no tema escolhido. Procura-se justificar a necessidade do desenvolvimento do sistema de informação. Questões Pertinentes: Qual a importância para a organização do desenvolvimento desse sistema? Qual o retorno que o sistema trará para a Organização? Qual a situação atual de informatização no setor? Quais as deficiências de informatização existentes no setor? Qual o nível de integração desejado com demais sistemas de informação? Existem soluções prontas para resolver o problema? 3.3.2 DEFINIÇÃO DO ANDAMENTO DOS TRABALHOS Entrar em acordo junto aos usuários no modo em que os trabalhos serão conduzidos com relação aos seguintes pontos: Comprometimento dos usuários durante todo projeto. Facilidade de acesso as informações. Breve descrição e aceitação da metodologia pelos usuários. 7

3.3.3 DEFINIÇÃO DOS OBJETIVOS DO SISTEMA Nesta etapa serão definidos os objetivos gerais e específicos que se pretende alcançar com o desenvolvimento do sistema, os setores que serão atendidos e as funções macro que serão contempladas. Questões Pertinentes: Quais os objetivos dos setores usuários do sistema? Que atividades o setor desempenha para atender a todos seu clientes/usuários? Quais os fatores críticos de sucesso para atingir os objetivos de cada setor usuário? Quais informações são necessárias para apoio a cada fator crítico de sucesso? Que funções o sistema irá contemplar a fim de para apoiar os fatores críticos de sucesso? Qual a urgência da automatização das funções que o sistema irá contemplar? Que funções serão suportadas pelo sistema para automatizar as atividades desenvolvidas pelo setor atendendo seus clientes? 3.3.4 DEFINIÇÃO DA ABRANGÊNCIA DO SISTEMA A partir da fase anterior a abrangência do sistema pode ser facilmente identificada: Identificar e descrever sucintamente as macro funções necessárias, órgãos envolvidos e pessoas responsáveis. Definir o fluxo de informações entre o sistema e as entidades externas (DFD de contexto). Questões Pertinentes: Quem serão os grupos de clientes/usuários do sistema? Quais as informações fornecidas/recebidas por esses usuários referentes ao sistema? 3.3.5 ANÁLISE DAS RESTRIÇÕES FINANCEIRAS, OPERACIONAIS E DE DESENVOLVIMENTO Esta etapa serve para identificar as restrições que devem ser considerados durante o desenvolvimento do sistema. Deve-se analisar alguns pontos críticos: Identificar se existe algumas restrições com relação ao ambiente (infraestrutura tecnológica, física e administrativa); Verificar restrições com relação a prazos e disponibilidade do setores usuários; Identificar equipe de trabalho (usuários e analistas), nível de participação e responsabilidades. 3.3.6 DEFINIR ESTRATÉGIAS PARA O DESENVOLVIMENTO Apresentar as estratégias em relação a: ferramentas a serem utilizadas para o desenvolvimento ; 8

etapas da metodologia que precisam ser atacadas; prioridade de implantação dos módulos ( se houver algum módulo prioritário em função de necessidades da organização); prototipação - será utilizado este recurso para validar especificações?? Quais ferramentas?? 3.3.7 ESTIMATIVA DE RECURSOS DE HARDWARE E SOFTWARE DE APOIO Avaliar alternativas de configurações de hardware e software de apoio tanto para o desenvolvimento como para a operação do sistema. Em cada uma delas deverá ser feita uma análise dos benefícios em conjunto com o usuário, escolhendo a solução mais adequada. 3.3.8 ESTIMATIVA DE RECURSOS HUMANOS E PRAZOS ( CRONOGRAMA) Avaliar a necessidade de recursos humanos e respectivos prazos para o desenvolvimento e implantação do sistema proposto, contemplando as atividades previstas na metodologia, incluindo atividades de conversão, treinamento, documentação e outros. Normalmente neste item é estabelecido um cronograma físico contemplando as atividades previstas, incluindo o numero estimado de horas homem em cada fase (horas homem por categoria de profissional) 3.3.9 VIABILIDADE A partir das informações coletadas até então, verificar a viabilidade do desenvolvimento do projeto tendo como base os seguintes pontos: - Os riscos associados ao desenvolvimento do sistema. Muitos dos riscos podem ser detectados a partir das restrições financeiras, operacionais e de desenvolvimento. - Os impactos na Organização - Os benefícios esperados associados ao projeto. Observação : neste ponto do projeto sempre que possível é recomendável uma análise de custo/benefício, envolvendo aspectos diversos, utilizando metodologia específica. Em termos acadêmicos nem sempre é possível realiza-la. Portanto fica restrita aos itens acima mencionados. 3.3.10 APROVAÇÃO DO DOCUMENTO O documento gerado na fase é submetido à aprovação do usuário, formalizando-se a autorização para a continuidade do projeto. 9

4. ANÁLISE DE REQUISITOS Mediante aprovação da continuidade do projeto, dentro da fase de estudo preliminar, a próxima etapa é coletar todas as informações necessárias considerando a abrangência do sistema. A fase de análise de requisitos tem uma importância crítica no desenvolvimento de sistemas de informações. Todas as atividades e produtos derivados desta fase constituem a base para as demais. Por isso, os erros cometidos nessa fase podem comprometer todas as fases subsequentes. Além da participação ativa dos usuários durante a análise de requisitos é fundamental que todos estejam engajados durante todas as fases do desenvolvimento do sistema. 4.1 OBJETIVOS DA FASE Definir as características funcionais do negócio mediante levantamento das informações junto aos usuários. 4.2 PRODUTOS DA FASE O produto gerado nesta fase é o documento denominado ANÁLISE DE REQUISITOS, conforme modelo do Anexo II. 4.3 ATIVIDADES DA FASE Os participantes abaixo precisam estar comprometidos durante a análise de requisitos: - Participantes Nível de importância - Gerentes dos setores envolvidos Máxima - Analistas responsáveis Máxima - Administradores de dados Média - Usuários Máxima 4.3.1 CONFIGURAÇÃO DAS REUNIÕES As reuniões para a coleta de informações devem ser marcadas pelos responsáveis pelo desenvolvimento do sistema tanto da parte técnica quanto da parte dos usuários. Os participantes deverão ser comunicados formalmente através de uma carta onde constará a pauta da reunião, os participantes, nível de importância da participação, início e término previsto. Não se deve fazer uso das reuniões para resolver problemas de pouca relevância. Para estes casos, um contato sem formalidades se faz necessário dentro do relacionamento usuário/analista. Para cada reunião formal deve ser elaborada uma ata que servirá para registrar as principais decisões tomadas junto aos usuários, garantindo o comprometimento do mesmo no desenvolvimento do sistema. A ata deve conter 10

data e duração da reunião, participantes, objetivos, observações e decisões tomadas. 4.3.2 COLETA DE INFORMAÇÕES Existem algumas técnicas de coleta das informações que eventualmente podem ser utilizadas durante a análise de requisitos: Entrevista A técnica de entrevista talvez seja a mais usada, porém ela requer do analista uma certa habilidade para se alcançar bons resultados. O analista deve saber fazer perguntas certas, no momento certo e às pessoas certas. Deve também saber conduzir a entrevista para seus objetivos, evitando desvios indesejáveis. Em outras palavras, entrevistar tem a ver com relações humanas e aí entra em jogo uma série de fatores como a capacidade de extrair informações que o usuário, a priori, é incapaz de dizer. Observação do Ambiente Para a observação do ambiente o analista deve passar algum tempo no setor, observando as funções desempenhadas e até mesmo desempenhando algumas. A atenção deverá concentrar-se nas funções que existem na organização, como são desempenhadas, que informações e materiais utilizam. Esta técnica é boa no sentido que coleta diretamente as informações sem que alguém as forneça ao analista, porém falha quando as pessoas sendo observadas se inibem ou se superam, modificando o comportamento habitual no desempenho das funções. Para assegurar o sucesso deste tipo de coleta de informações é importante adotar uma postura informal no momento de analisar o ambiente desejado. O analista precisa se portar como um membro da equipe de trabalho que compõe o setor em análise. Análise de Documentos Nesta técnica é necessário abstrair as funções a partir das informações contidas nos formulários ou documentos que tramitam na organização que se pretende informatizar. É uma técnica de coleta parcial e serve mais como complemento de outras técnicas. 4.3.3 LEVANTAMENTO DOS EVENTOS E FUNÇÕES CORRESPONDENTES Eventos são estímulos que ocorrem no mundo externo, e aos quais nosso sistema deve responder. Nesta etapa são identificados os eventos onde a partir desses são derivadas funções (procedimentos) que podem tratá-los. Existem dois tipos de eventos: Evento Externo/Fluxo geralmente é formado por uma entidade externa seguido de um verbo e complemento. Ex.: Aluno solicita empréstimo. Evento Temporal/Controle geralmente é formado por verbo seguido de complemento ou por substantivo que indica noção de tempo seguido de complemento. Ex.: É hora de emitir lista de livros comprados. Semanalmente fazse compra de periódicos. A partir do levantamento dos eventos, serão identificadas e descritas as funções que os tratam. 11

Cabe nesta parte do desenvolvimento, no caso de sistemas de informações aplicados no mundo dos negócios, discutir as principais práticas de negócios relacionadas com o sistema. Desta maneira aproveita-se experiências já consolidadas no mundo dos negócios e define-se mais corretamente as funções a serem informatizadas 4.3.4 LEVANTAMENTO DE ENTIDADES E SEUS ATRIBUTOS Entidades são objetos sobre os quais existe o interesse em guardar informações. Nesta etapa deverão ser identificadas todas as entidades de interesse do negócio e seus respectivos atributos, descrevendo sucintamente cada componente. 4.3.5 APROVAÇÃO DO DOCUMENTO O documento gerado na fase é submetido à aprovação do usuário, formalizando-se a autorização para a continuidade do projeto. 12

5. PROJETO LÓGICO Esta fase se caracteriza pela especificação conceitual do sistema, ou seja, é o projeto segundo visão do usuário. Aqui são utilizadas ferramentas que garantem uma formalidade para especificação do projeto evitando ambigüidades. A partir dessa fase, recomenda-se a utilização da ferramenta CASE Oracle Designer 2000 mais especificamente o Entity Relationship, o Dataflow e o Function Hierarchy. As informações coletadas na análise de requisitos são utilizadas nessa fase para desenvolver os modelos de dados e funcional. 5.1 OBJETIVOS DA FASE Especificar detalhadamente, segundo visão do usuário, os elementos que compõe o sistema no que se refere às funções e aos dados, abstraindo detalhes de implementação. 5.2 PRODUTOS DA FASE O produto da fase é um documento denominado PROJETO LÓGICO conforme modelo do Anexo III. 5.3 ATIVIDADES Os participantes abaixo precisam estar comprometidos durante o projeto lógico: Participantes Nível de participação -Gerentes dos setores envolvidos Máxima -Analistas responsáveis Máxima -Administrado de dados Máxima -Analistas desenvolvedores Máxima 5.3.1 CONSTRUÇÃO DO MODELO ENTIDADE RELACIONAMENTO A construção do modelo de dados conceitual, pode ser feita através do model entidade relacionamento que adota o padrão estabelecido pela ferramenta CASE Oracle Designer 2000 módulo Entity Relationship. É importante considerar que o modelo de dados esteja normalizado até a terceira forma normal. 5.3.2 DIAGRAMA HIERÁRQUICO DE FUNÇÕES A partir da lista de funções que responderão aos eventos é modelado o diagrama hierárquico funcional, cabendo a utilização da ferramenta CASE Oracle Designer 2000 módulo Function Hierarchy. Além do diagrama hierárquico funcional é necessário que se especifique as funções para que o usuário compreenda e aprove a funcionalidade do projeto. Dentre as informações contidas na especificação das funções destacam-se o objetivo da função, as estradas, as saídas e o processamento. 13

5.3.3 MATRIZ DE USO: ENTIDADES X FUNÇÕES A matriz de uso do projeto lógico é uma extensão daquela montada na análise de requisitos sendo que, agora é necessário indicar quais operações cada função executa sobre as entidades. 5.3.4 DIAGRAMA DE FLUXO DE DADOS(OPCIONAL) O diagrama de fluxo de dados pode ser utilizado como uma ferramenta alternativa para modelar dinamicamente o fluxo de informações e processos existentes no sistema. Esse diagrama é derivado do diagrama de contexto desenvolvido na fase de estudo preliminar que agora é refinado até um nível considerado elementar. A notação para o desenvolvimento do diagrama de fluxo de dados é estabelecida na ferramenta CASE Oracle Designer 2000 módulo Dataflow. 14

6. PROJETO FíSICO 6.1 OBJETIVOS DA FASE Tendo como base o Projeto Lógico, o objetivo desta fase é o de detalhar os elementos de projeto do sistema a nível físico. 6.2 PRODUTOS DA FASE O produto da fase é um documento denominado PROJETO FÍSICO, Anexo IV, que conterá a especificação técnica completa do sistema, visando a sua implementação, envolvendo o projeto do banco de dados, a especificação dos módulos, e o projeto de comunicação. 6.3 ATIVIDADES PREVISTAS Os participantes abaixo precisam estar comprometidos, nesta fase, da seguinte forma: Participantes Nível de participação -Gerentes dos setores envolvidos Mínima -Analistas responsáveis Máxima -Administrado de dados Máxima -Usuários Mínima 6.3.1 PROJETO DO BANCO DE DADOS Tendo como base o diagrama ER desenvolvido na fase anterior, projetar a estrutura física da base de dados, via mapeamento do modelo conceitual para o modelo físico. Feito o projeto, partir para a geração das tabelas com seus atributos, considerando todas as restrições de integridade projetadas, facilidades de acesso ( índices para chaves estrangeiras, visões), procedimentos para possibilitar o processamento distribuído.( se necessário) e níveis de autorização para garantir privacidade. Elaborar também o diagrama físico de dados ( chamado também de diagrama esquema de dados) a partir do modelo conceitual. No caso de utilização de ferramenta CASE ORACLE DESIGNER 2000, a obtenção do modelo físico é facilitada, com geração automática a partir do modelo conceitual. Obtido o diagrama Esquema de dados, poderão ser realizados ajustes no modelo, envolvendo os seguintes itens : ajustes no diagrama ( visão gráfica); refinamento das tabelas, conforme necessidades especificas, utilizando os recursos da Case, com ênfase em : definição de atributos, definição de seqüências, ordem das chaves primárias, eliminação de índices desnecessários, marcação de identificadores únicos ( se necessário); inclusão de índices secundários; inclusão de visões ; inclusão de snapshots para processamento distribuído; inclusão de check-constraints; 15

inclusão de autogen(geração automática de valores); triggers de base. 6.3.2 PROJETO DOS MÓDULOS DO SISTEMA ( ESTRUTURA DO SOFTWARE ) Tendo como base o diagrama hierárquico das funções obtido no PROJETO LÒGICO, bem como as relações Funções X Entidades, elaborar o diagrama hierárquico dos módulos e a especificação de cada um deles. Para cada módulo, especificar : Nome do módulo Objetivos Mapa de acesso especificando, quando for o caso, as tabelas acessadas para atualização e/ou consulta. Desejável representação gráfica. Descrição dos procedimentos básicos no caso de módulos com maior complexidade incluir maior nível de detalhamento. Interface quando for o caso de telas de manipulação de dados (screens), consultas, relatórios e menus. No caso de utilização da ferramenta CASE ORACLE DESIGNER 2000, a especificação dos módulos fica também facilitada. O software CASE oferece apoio na geração da estrutura e dos módulos, a partir de especificações no nível lógico/físico. Ajustes podem ser efetuados para a adaptação às necessidades. 6.3.3 APROVAÇÃO DO DOCUMENTO O documento gerado na fase é submetido à aprovação do usuário, formalizando-se a autorização para a continuidade do projeto. 16

7. IMPLEMENTAÇÃO 7.1 OBJETIVOS DA FASE A fase de implementação tem como objetivo a programação propriamente dita dos diversos módulos e a sua integração na estrutura definida. 7.2 PRODUTO DA FASE O produto da fase é o conjunto de programas codificados e devidamente testados. 7.3 ATIVIDADES Deverão ser feitos testes de validação dos módulos de forma individual e depois integrada ( inserido no contexto), escolhendo-se amostras representativas de dados. 17

8. IMPLANTAÇÃO 8.1 OBJETIVOS DA FASE Colocar o sistema em funcionamento nas instalações do usuário. 8.2 PRODUTOS DA FASE Nesta fase é elaborado e entregue o MANUAL DO USUÀRIO e o TERMO DE ENCERRAMENTO DO DESENVOLVIMENTO DO SISTEMA. 8.3 ATIVIDADES As atividades normalmente desenvolvidas nesta fase são: 8.3.1 MONTAGEM DO MANUAL DO USUÁRIO OU HELP ON LINE Montar um conjunto de instruções capaz de ser entendida pelos diversos tipos de usuários, de forma a possibilitar a operação do sistema de forma facilitada. 8.3.2 DESENVOLVER ROTINA DE INSTALAÇÃO DO SISTEMA Desenvolver programa para efetuar a instalação do sistema no ambiente do usuário. 8.3.3 TREINAMENTO Tem a finalidade de capacitar o usuário na utilização do sistema, com confiabilidade e segurança. 8.3.4 CONVERSÃO DE ARQUIVOS Converter os arquivos existentes para a nova estrutura projetada. Na maioria dos casos é uma tarefa bastante árdua. 8.3.5 ENCERRAMENTO DO DESENVOLVIMENTO Por ocasião do encerramento desta fase, deverá ser providenciado o TERMO DE ENCERRAMENTO DO DESENVOLVIMENTO DO SISTEMA, com a devida aceitação pelo usuário. 18

9. DOCUMENTAÇÃO A documentação do sistema surge em paralelo ao seu desenvolvimento. São gerados os seguintes documentos: Estudo preliminar Análise de requisitos Projeto lógico Projeto físico Manual do usuário Para efeito de utilização e manutenção do sistema serão utilizados: Projeto lógico Projeto físico Manual do usuário Em anexo, apresentamos os modelos de documentação. 19

10. REFERÊNCIA BIBLIOGRÁFICA GARCINDO, Luiz A. S., FARACO, Rafael, Metodologia de Desenvolvimento e Manutenção de Sistemas. Unisul. Versão 2, 2002. 20