UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO SISTEMA DE GESTÃO COMERCIAL

Transcrição

1 UNIVERSIDADE FEDERAL DO RIO DE JANEIRO ESCOLA DE ENGENHARIA DEPARTAMENTO DE ELETRÔNICA E DE COMPUTAÇÃO SISTEMA DE GESTÃO COMERCIAL Autor: Ana Paula Campos Pinheiro Orientador: Prof. Antônio Cláudio Gómez de Sousa Examinador: Prof. Aloysio de Castro Pinto Pedroza Examinador: Prof. Flávio Luis de Mello

2 DEL Dezembro de 2007 ii

3 Agradecimento Tenho muito a agradecer a todos que contribuíram direta ou indiretamente com minha formação. Dentre estes posso citar todos os meus professores que sempre estiveram preocupados em passar o conhecimento necessário, que com certeza fizeram de mim e de todos os demais alunos deste curso engenheiros mais humanos e cada vez mais preocupados com o desenvolvimento de país, e em especial ao meu orientador deste projeto, o Professor Antônio Cláudio, a quem pude contar em cada dificuldade ocorrida. Agradeço muito também aos meus pais que sempre estiveram presentes em todos os momentos de minha vida, buscando sempre que eu tivesse um futuro de sucesso. Neles eu me espelho e sempre me espelharei, pois são meus eternos modelos de dignidade, honestidade e persistência. i

4 Resumo O desenvolvimento da tecnologia nos proporciona uma forma diferente de ver o mundo. Através dela, é possível que vários processos que antes eram realizados por seres humanos e, por isso, com imprecisão e com uma demanda de tempo maior, sejam automatizados e facilitados, o que torna a vida humana mais fácil. A utilização dos recursos tecnológicos vem sendo cada vez mais empregada no mercado atual. Várias empresas que antes realizavam suas atividades através de registro em papel ou contabilidade manual, hoje são capazes de realizar os mesmos através de computadores, registro em banco de dados etc. O presente trabalho visa à implementação de um software desenvolvido especificamente para atender às demandas comerciais de uma empresa de luminárias, a partir de técnicas de desenvolvimento de software, que detalhará as seguintes fases: planejamento, especificação de requisitos, descrição do projeto e implementação; os funcionários envolvidos nas atividades gerenciais da empresa terão suas vidas facilitadas através de funcionalidades que o sistema realiza. Com a implantação do sistema, espera-se uma melhora no desempenho dos funcionários, a partir de uma melhora nas condições de trabalho dos mesmos. Além disso, será possível para o cliente se mostrar no mercado como uma instituição automatizada, o que poderá ser uma forma de realização de marketing empresarial. ii

5 Palavras-chave Automatização Análise Informação Desenvolvimento Implementação iii

6 Índice 1 Introdução Planejamento do Projeto Introdução Finalidade Escopo Principais Funções Itens de Desempenho Gerenciamento e Restrições Técnicas Estimativas Dados históricos usados nas estimativas Técnicas de Estimativas Estimativa do Esforço, Custo e Duração Estratégia para o gerenciamento de riscos Tabela de Riscos Discussão de Riscos a serem Gerenciados Plano de RMMM Cronograma Estrutura do Projeto Rede de Tarefas Recursos do Projeto Pessoal Hardware e Software Recursos Especiais Organização Mecanismos de Controle e Acompanhamento Controle e garantia de qualidade Controle de Gerenciamento de Mudanças Especificação de Requisitos de Software Introdução...15 iv

7 Finalidade Escopo Definições, Acronismos e Abreviaturas Referências Resumo Descrição Geral Perspectiva do Produto Funções do Produto Características do Usuário Restrições Pressupostos e Dependências Requisitos Específicos Requisitos Funcionais Interface dos Usuários Requisitos de Desempenho Restrições de Projeto Atributos Outros Requisitos Descrição do Projeto Introdução Finalidade Escopo Definições, Acronismos e Abreviaturas Referências Decomposição Decomposição em Módulos Decomposição em Processos Concorrentes Decomposição de Dados Descrição das Dependências Dependências entre Módulos Dependências entre Processos Dependências entre Dados Projeto Detalhado das Entidades de Dados...52 v

8 5 Conclusão...57 Bibliografia...58 Apêndice...59 A. Manual do Usuário...59 vi

9 1 - Introdução A Lumitex Rio é uma empresa que há quase 20 anos inova na área de iluminação, oferecendo fabricação, montagem e instalação de luminárias para sistemas eficientes, com garantia de pleno conforto visual, alto rendimento e baixo consumo de energia, atendendo a edifícios residenciais, comerciais, esportivos, religiosos, hotéis, aeroportos, hospitais, shopping centers, universidades, jardins etc. Os sócios fundadores, Acrizio Freitas e Erlon Campos, são os atuais responsáveis pela empresa, que conta com um quadro de cinco funcionários e está localizada na Rua Aurora, 17 - Penha - Rio de Janeiro - RJ. Foi feito ao longo de duas semanas um trabalho de entrevista com os sócios da empresa, visando atender suas necessidades. O SGC - Sistema de Gestão Comercial tem como objetivo solucionar o problema do excesso de paperwork considerado crítico atualmente pelos dirigentes da empresa. Para isso foi feito todo o processo de análise de sistema, seguindo as normas ANSI/IEEE 830 e 1016 em alguns casos, que provocam uma certa repetição nos capítulos deste projeto, e em seguida a implementação do mesmo. Abaixo segue os objetivos funcionais do projeto: Integrar soluções de TI aos processos de negócio; Reduzir tempo de resposta e resolução dos serviços; Reduzir custos com a dinamização dos processos; Fortalecer o foco dos serviços no cliente; Aumentar a satisfação dos clientes; O sistema foi desenvolvido utilizando o Visual Basic 6.0 e para armazenamento de dados, foi utilizado o sistema gerenciador de banco de dados Access 2003, a licença para utilização dessas ferramentas somente quem precisa é o desenvolvedor do sistema. A estrutura e modelagem dos dados serão abordadas posteriormente, com a metodologia análise essencial estruturada. O documento está dividido da seguinte forma: no capítulo 2 será apresentado todo o planejamento do projeto com estimativas, cronograma, recursos e mecanismos utilizados para desenvolvimento, no capítulo 3 a especificação de requisitos do sistema,

10 no capítulo 4 a descrição do projeto, no capítulo 5 a conclusão tirada com a realização do projeto, bibliografia e o apêndice que contém o manual do usuário. 2

11 2 - Planejamento do Projeto 2.1. Introdução Finalidade Objetivos do planejamento da construção do sistema: Prover uma descrição geral do software; Identificar atividades e cronograma do projeto; Identificar os recursos necessários; Estabelecer uma fonte comum de informação; Estabelecer uma base para gerenciamento e controle O processo de um software é um projeto de engenharia envolvendo as fases de definições gerais, planejamento, especificação de requisitos, modelagem (ou projeto) e implementação. Nota-se que essa construção do sistema é precedida por diversas etapas anteriores, assim como de uma construção de uma casa Escopo O Sistema de Gestão Comercial solucionará o problema do excesso de paperwork como dito anteriormente. O projeto será a primeira versão do software, até porque os dirigentes nunca tiveram nenhum contato com qualquer tipo de sistema de gerenciamento e terão que passar por uma fase de adaptação. Versões posteriores do software poderão ser implementadas no futuro Principais Funções

12 Para facilitar o entendimento do escopo do projeto, dividimos as abordagens do software em 4 áreas: Clientes; Propostas; Produtos; Fornecedores; Suas principais funções são descritas abaixo: Clientes: Cadastrar cliente; Consultar por nome; Consultar por CNPJ ou CPF; Editar dados do cliente; Remover cliente; Fornecedores: Cadastrar fornecedor; Consultar fornecedor por nome; Editar dados do fornecedor; Remover fornecedor; Propostas: Adicionar proposta; Consultar proposta por cliente; Consultar proposta por data; Editar dados da proposta; Remover proposta; Produtos: Cadastrar produto; Consultar produto por nome; Consultar produto por referência; Editar dados do produto; 3

13 Remover produto; Novas versões posteriores do software se basearão na arquitetura da primeira versão, o que reforça a importância do desenho do software Itens de Desempenho Os usuários do Sistema de Gestão Comercial têm pouca experiência com informática. Além disso, o software operará em um único local e com mínimo consumo de hardware, portanto não há exigências maiores como tempo de resposta Gerenciamento e Restrições Técnicas Os processos de acompanhamento, revisão e avaliação serão realizados em todas as etapas do projeto, pela autora e seu orientador, e em marcos pré-determinados de acordo com o cronograma (próximo item). Para mais detalhes ver item 2.7 (página 14) Estimativas Dados Históricos Usados nas Estimativas As estimativas para o projeto de software (medidas de esforço, tamanho, etc) foram obtidas através da ferramenta COCOMO II a partir da entrada de dados sobre a configuração do software (linguagem, número de interfaces, etc), experiência da equipe, entre outros Técnicas de Estimativas A técnica de estimativa escolhida foi a Análise por Pontos de Função (APF), pois ela torna a medição independente da tecnologia utilizada para a construção do software. Além de ajudar no planejamento do projeto, os dados fornecidos pela ferramenta serão utilizados no controle e acompanhamento de projeto evitando transtornos como crescimento descontrolado de escopo (scope creep), atrasos nas atividades, etc. 4

14 Estimativa do Esforço, Custo e Duração Opções escolhidas no COCOMO: Module Size: - Sizing Method: Function Points (seguindo a metodologia adotada Pontos por Função) - Module Size in Function Points: Language: Fourth Generation (esta opção engloba todos os Visuals) Inputs (telas de cadastro): 4 de complexidade baixa Outputs (relatórios): 3 Files (entidades do BD): 4 (tabelas) Queries (telas de consulta): 8 de complexidade baixa (visualização das telas de cadastro). Interfaces (integração com outros sistemas): Estimativa do Tamanho: Nenhuma 1540 SLOC (Source Lines of Code) Estimativa do Esforço: 4,0 Pessoa-Mês EAF (Effort Adjustment Factor): Fator de Esforço Adicional - Sobre o Produto: RELY (Required Software Reliability): VLO (Esforço adicional para o aumento da confiabilidade do sistema se falhar as conseqüências não são catastróficas); DATA (Data Base Size): NO (Tamanho da base de dados); DOCU (Documentation match to life-cycle needs): VHI (Documentação exigida sobre o ciclo de vida inclui grande esforço adicional); CPLX (Product Complexity): LO (Complexidade baixa); 5

15 - Sobre a Plataforma: TIME (Execution Time Constraint): NOM (Expectativa do percentual de tempo de execução consumido sobre o tempo disponibilizado pelo Sistema Operacional); STOR (Main Storage Constraint): NOM (Volume de dados a ser processado e armazenado); PVOL (Platform Volatility): LO (Mudanças a cada 12 meses na plataforma são consideradas como LO. Plataforma para um sistema de informação é o sistema operacional mais o hardware); - Sobre a Equipe: ACAP (Capacidade dos Analistas): HI (Habilidade, eficiência, minunciosidade, ser comunicativo e ser cooperativo); PCAP (Capacidade dos Programadores): HI (Mesmas características anteriores) - AEXP (Experiência dos Analistas): LO; PEXP (Experiência dos Programadores): HI; LTEX (Language Tool Experience): HI; PCON (Personnel Continuity): HI; Sobre o Projeto: TOOL: YES (Uso de ferramentas); SITE: YES (Situação do local de trabalho Banda larga); Estimativa de Esforço Adicional: EAF: 0,48 (fator calculado reduzirá o primeiro esforço estimado) Estimativa do Esforço (considerando EAF): 3,8 Pessoa-Mês Custo Pessoal: 0 Custo Estimado: 0 Prazo Estimado: 3,3 meses Risco Estimado: 0% Com o encurtamento do prazo (ajustando Schedule para LO 1,1), temos as seguintes modificações nas estimativas: 6

16 Estimativa de Esforço: 3,8 P-M EAF: 0,53 Estimativa de Esforço (considerando EAF): 3,8 P-M Estimativa de Custo: 0 Estimativa de Prazo: 3,3 meses Estimativa do Risco: 1,3 2.3 Estratégia para o Gerenciamento de Riscos Tabela de Riscos A seguir temos os riscos que podem vir a comprometer o bom andamento do processo de desenvolvimento do sistema em todas as suas fases: Tabela 1: Riscos do Sistema Risco Não cumprimento Categoria Impacto no Probabilidade Impacto 60% Catastrófico RMMM RMMM do prazo de entrega negócio Complexidade do Tecnologia para a 30% Catastrófico RMMM sistema Perda de arquivos construção Ambiente de 10% Catastrófico RMMM Falta de experiência desenvolvimento Tamanho e 50% Crítico RMMM inicial com a experiência da ferramenta de equipe desenvolvimento Doença, viagem ou Impacto no outro tipo de ausência negócio % Crítico RMMM 5 periódica das atividades do projeto Atividades paralelas Impacto no 60% negócio Crítico RMMM Discussão de Riscos a Serem Gerenciados 7

17 Os riscos acima listados já se encontram em ordem decrescente de impacto que eles causarão se transformados em realidade durante o projeto. Analisemos cada risco identificado: Não cumprimento do prazo de entrega Pode-se considerar esse risco o mais impactante para a equipe no final do projeto. A não entrega do produto final dentro prazo determinado implicará a reprovação do mesmo como projeto final do curso de graduação. Complexidade do Sistema Uma possível sub-estimação da complexidade do sistema durante o planejamento do escopo do projeto, tal como, planejar funcionalidades pequenas na teoria, porém de difícil implementação pode acarretar falta de tempo para a implementação das mesmas, além de comprometer todo o cronograma planejado. Perda de arquivos Um fator de risco altíssimo também, é a possibilidade de perda dos arquivos fonte gerados, bem como alguma documentação existente, proveniente de alguma falha de software ou hardware, o que faria com que o trabalho até aquele ponto fosse todo jogado fora. Falta de experiência inicial com a ferramenta de desenvolvimento Apesar da equipe já ter experiência de outros trabalhos utilizando a linguagem que será adotada, a ferramenta que a implementará, a fim de desenvolver o sistema, ainda não é de total domínio. Doença, viagem ou outro tipo de ausência periódica das atividades do projeto 8

18 Apesar de não haver nada planejado com relação à viagens ou outro tipo de afastamento, imprevistos desta natureza ou doença, podem fazer com que o desenvolvimento do projeto fique improdutivo durante algum intervalo de tempo. Atividades paralelas A equipe realiza atividades paralelas, tanto dentro da faculdade (outras matérias), como fora (estágio e outras atividades). Eventualmente, um tempo adicional ( invadindo o tempo planejado no cronograma) poderá ser gasto nessas atividades, comprometendo a média diária de produção de componentes da equipe Plano de RMMM Para cada risco identificado foram desenvolvidos mecanismos formais de mitigação, monitoramento e gerenciamento (RMMM). Vejamos, para cada caso, os procedimentos adotados: Não cumprimento do prazo de entrega (RMMM 1) Como mitigar os riscos? A probabilidade de entrega do trabalho fora do prazo pode ser prevenida a partir do instante em que a equipe alinha um comprometimento com o cronograma planejado previamente, bem como com as suas responsabilidades, também definidas no mesmo. Como monitorar os riscos? Através de uma análise semanal para a avaliação do andamento das atividades, e o controle do cronograma planejado. Como gerenciar os riscos? 9

19 Uma vez o risco de a entrega do produto fora do prazo se tornar evidente, a equipe se mobilizará em hora extra com as atividades para compensar o real atraso. Complexidade do Sistema (RMMM 2) Como mitigar os riscos? A política de mitigação consiste em planejar as funcionalidades do sistema de modo que a estimativa de esforço calculada esteja dentro de um valor compatível com a realidade e a possibilidade de execução pela equipe. Como monitorar os riscos? Observando se o cronograma está sendo cumprido como planejado. Se as tarefas estiverem exigindo mais tempo de desenvolvimento do que o previsto, há uma grande possibilidade de determinadas funcionalidades do sistema terem sido sub-estimadas, com relação à complexidade, durante o planejamento. Como gerenciar os riscos? Uma vez o risco se tornando evidente, e levando-se em conta que uma funcionalidade já comprometida com o cliente não pode ser alterada, a política a ser adotada será a utilização de horas extra para cumprir a tarefa problemática no tempo estipulado pelo cronograma. Perda de arquivos (RMMM 3) Como mitigar os riscos? A fim de evitar o risco de que alguma falha de software ou hardware possa comprometer a integridade dos arquivos, a equipe faz backup em um pen drive, no qual todos os arquivos gerados (tanto de código, como de documentação) serão armazenados. Um backup em CD dos mesmos também está planejado para ser feito a cada etapa concluída. Outra política é executar antivírus periodicamente a fim de constatar que nenhum arquivo seja infectado. Como monitorar os riscos? 10

20 Observando o comportamento do sistema operacional e da estação de trabalho como um todo; se outros arquivos estão sendo corrompidos; se as varreduras de anti-vírus estão sendo realmente bem sucedidas. Como gerenciar os riscos? Uma vez o problema ocorrido, a solução é baixar o backup do(s) arquivo(s) afetado(s) ou através do pen drive ou através do CD de backup. Falta de experiência inicial com a ferramenta de desenvolvimento (RMMM 4) Como mitigar os riscos? Começar, mesmo durante a fase de planejamento, a se ambientar com a ferramenta, para chegar na fase de desenvolvimento com um bom conhecimento de operação da mesma. Tutoriais provenientes da internet também serão utilizados para o auxílio. Como monitorar os riscos? Verificar o desenvolvimento das tarefas normalmente, com o foco apenas voltado para a complexidade do sistema e não inserindo a ferramenta de desenvolvimento como um peso adicional. Como gerenciar os riscos? Uma vez o risco se tornando evidente, a política adotada será a de auxílio externo (professor ou mesmo um colega que já esteja mais ambientado com a ferramenta). Doença, viagem ou outro tipo de ausência periódica das atividades do projeto (RMMM 5) Como mitigar os riscos? No caso de viagem ou outro tipo de ausência temporária, o ideal seria se planejar para que o projeto não fique em atraso. No caso de doença, obviamente, não há como prever. 11

21 Como monitorar os riscos? Através da obrigatoriedade com o projeto. Como gerenciar os riscos? Uma vez o risco se tornando evidente, as tarefas correspondentes ao período de desligamento seriam realizadas em horário extra ou adiantadas. Atividades paralelas (RMMM 6) Como mitigar os riscos? Evitar esses tipos de atividade é impossível, pois o mesmo comprometimento que a equipe tem com o desenvolvimento deste software, tem com seus demais compromissos formais. A idéia é se comprometer a produzir o máximo possível dentro do seu cronograma (quando não estiver realizando tais atividades paralelas) para, eventualmente, compensar atrasos que estas atividades possam causar no próprio cronograma em um momento posterior. Como monitorar os riscos? Observando se o volume de trabalho na empresa onde o membro da equipe estagia e das tarefas exigidas pelas disciplinas que estão sendo cursadas, estão aumentando. Como gerenciar os riscos? Uma vez o risco se tornando evidente, a política a ser adotada é de alocar horas extras do tempo livre para compensar tais desfalques no cronograma Cronograma Estrutura do Projeto A estrutura geral do projeto pode ser dividida em quatro fases principais: Planejamento, Especificação de Requisitos, Descrição de Projeto e Implementação. 12

22 Rede de Tarefas Tabela 2: Rede de Tarefas Etapa Planejamento Requerimento Desenho do Produto Program. Codificação e Início 15/08/ /09/ /09/ /09/2007 Fim 06/09/ /09/ /10/ /10/2007 Duração 22 dias 20 dias 10 dias 30 dias Teste Unitário Integração e Teste Defesa do Projeto Produtos Plano de Projeto ERS Descrição do Projeto Projeto de Soft., Pl. de Testes e Manual 1/11/ /12/ /11/ dias 04/12/ dia do Usuário Versão Alfa Apresentação do Sistema 2.5. Recursos do Projeto Pessoal A equipe é individual, composta por Ana Paula Campos Pinheiro Hardware e Software Para o desenvolvimento do projeto, usaremos um computador Athlon XP 2000+, 1.25GHz, com 768Mb de RAM e os softwares: MS Project 2000, COCOMO II, Visual Basic 6.0, Access 2003, Erwin e Visio Para documentação será usado o Word Recursos Especiais Não será necessária a utilização de recursos especiais devido à natureza do projeto. Todos os recursos necessários já estão disponíveis Organização 13

23 Como apenas uma pessoa é responsável pelo desenvolvimento do projeto, todas as etapas e o cumprimento de prazos serão de total responsabilidade da mesma Mecanismos de Controle e Acompanhamento Controle e Garantia de Qualidade Serão seguidas normas internacionais na confecção dos seguintes itens de configuração de software: Plano de Projeto para Software, Especificação de Requisitos de Software e Descrição de Projeto de Software. As normas estão disponíveis no endereço: Ao fim de cada fase do projeto, está prevista uma revisão técnica formal (RTF) a ser realizada pelo Orientador do Projeto Prof. Antonio Cláudio Controle de Gerenciamento de Mudanças Cada mudança num Item de Configuração de Software já submetido à revisão técnica formal será documentada. A decisão sobre a pertinência de uma mudança será decidida entre a empresa e o a equipe de desenvolvimento. 14

24 3 - Especificação de Requisitos de Software O processo de desenvolvimento de um software, no ciclo em cascata, engloba as seguintes fases: planejamento, especificação de requisitos, descrição do projeto e implementação. A segunda dessas fases é apresentada aqui Introdução Finalidade Este capítulo é um dos resultados da fase de análise e sua finalidade principal é detalhar o projeto desenvolvido. No planejamento obtivemos uma visão geral do software a ser desenvolvido. Na fase de análise, é definido o que o sistema deve fazer. São representados as informações, funções e o comportamento do sistema diante de eventos externos. Sendo assim, realiza uma descrição geral do software e aborda seus requisitos específicos. A redação do presente documento é baseada na norma ANSI/IEEE 830 simplificada e será apresentada aos sócios da empresa Lumitex Rio, clientes para os quais o software está sendo projetado Escopo O software desenvolvido foi designado como Sistema de Gestão Comercial (SGC). O objetivo principal do produto é informatizar a empresa, eliminando o excesso de papéis usados para administrá-la. Para isso, serão oferecidas algumas funcionalidades básicas de gerenciamento comercial, visto que os dirigentes da empresa nunca tiveram nenhum contato com qualquer tipo de sistema e terão que passar por uma fase de adaptação. O produto deverá trazer uma série de benefícios para a empresa. A parte administrativa será automatizada, facilitando, portanto, o controle das atividades da empresa. Além disso, informações sobre os produtos, clientes e fornecedores serão

25 armazenadas em banco de dados. Isso permitirá a geração de relatórios e facilitará o acompanhamento dos negócios da empresa por parte dos sócios Definições, Acronismos e Abreviaturas Nesta seção, serão indicadas as definições de termos e siglas utilizados na documentação do software projetado. DD Dicionário de Dados DFD Diagrama de Fluxos de Dados DER Diagrama de Estados e Relacionamentos DTE Diagrama de Transição de Estados ERS Especificação de Requisitos de Software MU Manual do Usuário PF Ponto por Função SGC Sistema de Gestão Comercial Referências Esta seção é reservada para a identificação dos documentos referenciados na ERS. As referências utilizadas são o Planejamento de Projeto do software projetado, capítulo 1, e a norma ANSI/IEEE 830 simplificada Resumo Nas próximas seções da ERS, realizaremos uma descrição geral do sistema a ser desenvolvido, abordando sobre a perspectiva do produto, suas principais 16

26 funcionalidades, as características do usuário, bem como as restrições e as dependências impostas ao projeto. Também discutiremos os requisitos específicos do projeto, falando dos requisitos funcionais, interfaces externas, requisitos de desempenho, restrições de projeto e atributos. Os requisitos funcionais do projeto são detalhados com mais clareza após a realização de uma análise do problema em questão. O tipo de análise escolhida foi a análise essencial estruturada. O primeiro passo da análise é definir o que o sistema deve fazer. Em seguida, deve-se definir as funcionalidades do sistema e realizar um levantamento de eventos e dados iniciais. Com isso, é possível construir um modelo ambiental, que nos fornecerá uma descrição do sistema do ponto de vista externo e é constituído dos seguintes itens: declaração dos objetivos do sistema, elaboração de DFD de Contexto e criação de lista de eventos. Também deve ser construído um modelo comportamental, definido do ponto de vista interno. A partir do modelo comportamental teremos os DFD s particionados e o DER. Para cada evento listado, teremos um DFD associado. Nesses DFD s, serão especificados os terminadores, fluxos e depósitos de dados necessários para cada processo. Partindo desses DFD s particionados, os processos são agrupados, gerando o DFD de Contexto. No DER, para cada processo primitivo deveremos ter uma especificação para esse processo. Nos requisitos de desempenho, abordaremos fatores de desempenho, tais como tempo de resposta exigido pelo software. Nas restrições de projeto discutiremos limitações impostas ao sistema por normas, escolhas de software ou hardware, entre outras. Nos atributos, falaremos de todos os atributos de qualidade que são aplicáveis ao software a ser desenvolvido, como, por exemplo, amigabilidade e confiabilidade. Com isso se encerra a especificação de requisitos do sistema projetado, cujo conteúdo constitui o documento gerado após a fase de análise, que compõe o processo de desenvolvimento de um software. 17

27 3.2. Descrição Geral Perspectiva do Produto O software projetado se trata de um sistema único, que será instalado na empresa. A interface com o usuário se baseia em telas desenvolvidas em Visual Basic e as informações manipuladas pelo sistema serão armazenadas em um banco de dados Funções do Produto Nesta seção, apresentaremos um sumário das principais funções do software, listadas a seguir: Cadastramento, edição e exclusão de clientes e fornecedores. Consulta de clientes por nome e CNPJ ou CPF. Consulta de fornecedores por nome. Cadastramento, edição e exclusão de propostas. Consulta de propostas por clientes e data. Faturar propostas. Cadastramento, edição e exclusão de produtos. Consulta de produtos por nome e referência. Relatório de produtos com referência e preço. Relatório de propostas de um determinado período. Relatório de movimentação do cliente Características do Usuário Os principais e únicos usuários do software serão os sócios da empresa Lumitex Rio (na presente documentação eles também serão considerados como funcionários da empresa), responsáveis pelo gerenciamento dos dados armazenados. Tais pessoas possuem uma faixa etária em torno dos 50 anos e serão vistos pelo sistema como usuários permanentes. 18

28 Como o sistema será utilizado por usuários que nunca tiveram contato com sistemas de informatização, o mesmo deve apresentar um nível considerável de amigabilidade Restrições Esta seção se destina a descrever as limitações e restrições impostas aos recursos de hardware e software do projeto. Como recursos de hardware o computador utilizado para desenvolvimento do projeto será um Athlon XP 2000+, 1.25GHz, com 768Mb de RAM, HD de 120GB, capacidade suficiente para executar os recursos de software a serem utilizados. Já para operação será um Athlon XP 3000+, 2.15Ghz, com 512Mb de RAM e HD de 80GB. Os recursos de software a serem utilizados se compõem dos seguintes elementos: editor de texto para a documentação do projeto, ferramenta de desenvolvimento ou compilador para Visual Basic e sistema gerenciador de banco de dados. Esses aplicativos devem estar atualizados, a fim de se evitar ao máximo que ocorram problemas durante o desenvolvimento do projeto Pressupostos e Dependências Nesta seção deveremos descrever as dependências e os pressupostos necessários para o projeto. Esse item já foi discutido no Plano de Projeto, quando discutimos sobre os riscos aos quais o projeto está exposto. Devemos ressaltar que, para a realização do projeto, devemos ter disponíveis ambientes adequados para trabalho e, além disso, tempo suficiente para a execução do mesmo. Caso contrário há a possibilidade do projeto não ser desenvolvido no prazo determinado, o que representa uma conseqüência impactante ao desenvolvimento do sistema Requisitos Específicos Requisitos Funcionais Nesta seção, cada requisito funcional do software é detalhadamente especificado. Essa especificação foi realizada por meio do Modelo Essencial de análise de requisitos. 19

29 Modelo Ambiental Este sistema está sendo concebido para apoiar algumas tarefas realizadas em uma firma de produtos de iluminação. O sistema apoiará na informatização de atividades referentes à administração da empresa, tais como, cadastro de clientes, fornecedores, produtos e controle de orçamentos efetuados. Todas as funcionalidades do sistema serão realizadas por um único tipo de funcionário (usuário), que são os próprios sócios da empresa. Sendo assim, não há necessidade de limitar qualquer tipo de operação por usuário. Diagrama de Contexto Figura 1: Diagrama de Contexto Lista de Eventos Operações com cliente: Funcionário realiza o cadastro de um novo cliente. Funcionário consulta dados de clientes. Funcionário edita o cadastro de um cliente. Funcionário exclui o cadastro de um cliente. Funcionário solicita relatório de movimentação do cliente. 20

30 Operações com fornecedores: Funcionário realiza o cadastro de um novo fornecedor. Funcionário consulta dados de fornecedores. Funcionário edita o cadastro de um fornecedor. Funcionário exclui o cadastro de um fornecedor. Operações com propostas: Funcionário realiza o cadastro de uma nova proposta. Funcionário consulta propostas por cliente ou data. Funcionário edita o cadastro de uma proposta. Funcionário exclui uma proposta cadastrada. Funcionário fatura uma proposta cadastrada aceita. Funcionário solicita relatório de propostas de cliente por período. Operações com produtos: Funcionário realiza cadastro de produtos. Funcionário consulta produtos por nome e refrência. Funcionário edita um produto cadastrado. Funcionário exclui produto cadastrado. Funcionário solicita relatório de preço dos produtos. 21

31 Modelo Comportamental DFD s particionados por eventos Operações com cliente: Funcionário realiza o cadastro de um novo cliente. Figura 2: DFD Cadastrar Cliente Funcionário consulta dados de clientes. Figura 3: DFD Consultar Cliente 22

32 Funcionário edita o cadastro de um cliente. Figura 4: DFD Editar Cliente Funcionário exclui o cadastro de um cliente. Figura 5: DFD Excluirr Cliente 23

33 Funcionário solicita relatório de movimentação do cliente. Figura 6: DFD Relatório de Movimentação do Cliente Operações com fornecedores: Funcionário realiza o cadastro de um novo fornecedor. Figura 7: DFD Cadastrar Fornecedor 24

34 Funcionário consulta dados de fornecedores. Figura 8: DFD Consultar Fornecedor Funcionário edita o cadastro de um fornecedor. Figura 9: DFD Editar Fornecedor 25

35 Funcionário exclui o cadastro de um fornecedor. Figura 10: DFD Excluir Fornecedor Operações com propostas: Funcionário realiza o cadastro de uma nova proposta. Figura 11: DFD Cadastrar Proposta Funcionário consulta propostas por cliente ou data. Figura 12: DFD Consultar Proposta 26

36 Funcionário edita o cadastro de uma proposta. Figura 13: DFD Editar Proposta Funcionário exclui uma proposta cadastrada. Figura 14: DFD Excluir Proposta Funcionário fatura uma proposta cadastrada aceita. Figura 15: DFD Vender Proposta 27

37 Funcionário solicita relatório de propostas de cliente por período. Figura 16: DFD Relatório de Propostas Operações com produtos: Funcionário realiza cadastro de produtos. Figura 17: DFD Cadastrar Produto Funcionário consulta produtos por referência ou nome. Figura 18: DFD Consultar Produto 28

38 Funcionário edita um produto cadastrado. Figura 19: DFD Editar Produto Funcionário exclui produto cadastrado. Figura 20: DFD Excluir Produto Funcionário solicita relatório de preço dos produtos. Figura 21: DFD Relatório de Preço de Produtos 29

39 Diagrama Entidade Relacionamento Figura 22: Diagrama Entidade Relacionamento No modelo conceitual de Diagrama Entidade Relacionamento acima, nota-se a indicação de chaves estrangeiras (FK) nas entidades de dados. Isto ocorre devido ao uso da ferramenta Erwin, utilizada para fazer o modelo. Dicionário de Dados Terminadores Funcionário: Único tipo de usuário do sistema, que possui um cargo de sócio na firma. Tem direito a executar todas as operações do sistema. 30

40 Depósitos de Dados Clientes: Depósito de dados sobre clientes da firma. Estrutura: (a) Código do Cliente: identificador do cliente; tipo: inteiro. (b) CNPJ/CPF: o número do cadastro nacional de pessoa jurídica da empresa ou pessoa física se for o caso; tipo: string, tamanho: 16. (c) Inscrição Estadual/RG: número do registro no cadastro do ICMS que as empresas possuem ou Registro geral se for o caso; tipo:string, tamanho:8. (d) Nome Cliente: nome empresa do cliente; tipo: string; tamanho: 100. (e) Telefone: um telefone fixo de contato com o cliente; tipo: string, tamanho: 12. (f) Fax: número do fax do cliente; tipo: string, tamanho: 12. (g) E mail: um e mail de contato com o cliente; tipo: string, tamanho: 20. (h) Endereço: endereço completo da empresa do cliente ou do escritório. Deve incluir logradouro, número e complemento; tipo: string, tamanho: 100. (i) CEP: código de endereçamento postal referente ao endereço acima; tipo: string, tamanho: 9. (j) Bairro: bairro do endereço especificado anteriormente; tipo: string, tamanho: 30. (k) Cidade: cidade onde se localiza a sede da empresa do cliente ou o escritório; tipo: string; tamanho: 50. (l) UF: unidade da federação onde se localiza a sede da empresa do cliente ou o escritório; tipo: string, tamanho: 2. Fornecedores: Depósito de dados sobre fornecedores de produtos pra firma. Estrutura: (a) Código do Fornecedor: identificador do fornecedor; tipo: inteiro. (b) Nome Fantasia: nome da empresa do fornecedor; tipo: string, tamanho: 100. (c) CNPJ: o número do cadastro nacional de pessoa jurídica da empresa; tipo: string, tamanho: 16 (d) Telefone: um telefone fixo de contato com o fornecedor; tipo: string, tamanho: 12. (e) Fax: número do fax do fornecedor; tipo: string, tamanho: 12. (f) E mail: um e mail de contato com o fornecedor; tipo: string, tamanho:

41 (g) Endereço: endereço completo da empresa do fornecedor ou do escritório. Deve incluir logradouro, número e complemento; tipo: string, tamanho: 100. (h) CEP: código de endereçamento postal referente ao endereço acima; tipo: string, tamanho: 9. (i) Bairro: bairro do endereço especificado anteriormente; tipo: string, tamanho: 30. (j) Cidade: cidade onde se localiza a sede da empresa do fornecedor ou o escritório; tipo: string, tamanho: 50. (k) UF: unidade da federação onde se localiza a sede da empresa do fornecedor ou o escritório com o qual a empresa se comunica; tipo: string, tamanho: 2. Produtos: Depósito de dados contendo informações referentes aos produtos que a firma vende. Estrutura: (a) Código do Protuto: identificador do produto; tipo: inteiro. (b) Nome do Produto: nome completo do produto; tipo: string, tamanho: 100. (c) Referência do Produto: Código interno da empresa usado para representar um determinado produto; tipo: string, tamanho: 10 (d) Valor do Produto: valor de venda de um determinado produto; tipo: real. Propostas: Depósito de dados de pedidos de propostas efetuadas por clientes. Estrutura: (a) Código da Proposta: identificador da proposta; tipo: inteiro. (b) Cógido do Cliente: identificador do cliente para a qual a proposta está sendo feita; tipo: inteiro. (c) Número da Proposta: número de identificação interna da proposta; tipo: string, tamanho:8. (d) Tipo: identifica se a proposta foi faturada ou se continua somente como orçamento; tipo:string. (e) Data de emissão: data na qual a proposta foi emitida; tipo: data. (f) Validade da Proposta: prazo de validade da proposta; tipo: data. (g) Prazo de Entrega: número de dias que o pedido poderá ser entregue; tipo: string, tamanho:10. (h) Local de Entrega: endereço do local de entrega, o campo deve incluir logradouro, número, complemento e bairro; tipo: string, tamanho 100. (i) Forma de Pagamento: forma na qual será efetuado o pagamento; tipo: string. 32

42 (j) Nome do Produto: descrição do produto na proposta; tipo: string, tamanho:200. (k) Valor Unitário do Produto: preço de cada item de produto; tipo: real. (l) Quantidade de Peças: quantidade de peças de cada produto; tipo: inteiro. (m) Valor Total: valor total de todos os itens da proposta; tipo: real. (n) Número da Duplicata: número da duplicata emitida para o cliente; tipo: string, tamanho: 10. (o) Número da Nota Fiscal: número da nota fiscal de venda para o cliente; tipo: string, tamanho: 10. Entidades As entidades do DER possuem as estruturas iguais às dos depósitos de dados. Seus nomes são os mesmos, porém as entidades possuem nomes no singular. Além das entidades correspondentes aos depósitos descritos acima, existem mais algumas entidades no sistema, explicitadas a seguir. Endereço: o atributo Endereço nas entidades cliente, proposta, fornecedor, nota fiscal, duplicata e item proposta, torna-se chave estrangeira para esta entidade. Atributos: (a) Cd Endereço: identificador de um ramo de atuação (chave primária); tipo: inteiro. (b) Endereço: local onde se encontra a empresa; tipo: string, tamanho 100. CEP: o atributo CEP nas entidades cliente, endereço, item proposta, duplicata, nota fiscal e fornecedor, torna-se chave estrangeira para esta entidade. Atributos: (a) Cd CEP: identificador do CEP (chave primária); tipo: inteiro. (b) CEP: código de endereçamento postal referente ao endereço; tipo: string, tamanho:9. Bairro: o atributo Bairro nas entidades cliente, nota fiscal, duplicata, proposta, item proposta, CEP, endereço e fornecedor, torna-se chave estrangeira para esta entidade. Atributos: (a) Cd Bairro: identificador de um Bairro (chave primária); tipo: inteiro. 33

43 (b) Bairro: nome do bairro onde se localiza a empresa; tipo: string, tamanho: 30. Cidade: o atributo Cidade nas entidades cliente, nota fiscal, duplicata, bairro, endereço, CEP, item proposta, proposta e fornecedor, torna-se chave estrangeira para esta entidade. Atributos: (a) Cd Cidade: identificador de uma cidade (chave primária); tipo: inteiro. (b) Cidade: nome da cidade onde se localiza a empresa; tipo: string, tamanho: 50. UF: uma Unidade da Federação do Brasil. O atributo Estado nas entidades cliente, proposta, nota fiscal, duplicata, endereço, cidade, bairro, CEP, item proposta e fornecedor, torna se chave estrangeira para esta entidade. Atributos: (a) Cd UF: identificador de um Estado (chave primária); tipo: inteiro. (b) UF: sigla do Estado; tipo: string; tamanho: 2. Fluxos de Dados Dados Cliente: Estrutura de dados referente a um cliente. (a) Nome da Empresa: nome da empresa do cliente; (b) Telefone: um telefone fixo de contato com o cliente; (c) Celular: um telefone móvel para contato com o cliente; (d) Fax: número do fax do cliente; (e) E mail: e mail de contato com o cliente; (f) Endereço: endereço completo da empresa do cliente ou do escritório com o qual a empresa de eventos se comunica para prestar seus serviços. Deve incluir logradouro, número, complemento e bairro; (g) CEP: código de endereçamento postal referente ao endereço acima; (h) Bairro: bairro do endereço acima; (i) Cidade: cidade onde se localiza a sede da empresa do cliente ou o escritório com o qual a empresa de eventos se comunica para prestar seus serviços; (j) Estado: unidade da federação onde se localiza a sede da empresa do cliente ou o escritório com o qual a empresa de eventos se comunica para prestar seus serviços; 34

44 (k) Inscrição Estadual: número do registro no cadastro do ICMS que as empresas possuem; (l) CNPJ: o número do cadastro nacional de pessoa jurídica da empresa; Cliente Cadastrado: aviso ao usuário que o cliente foi cadastrado com sucesso. CNPJ, Nome Cliente: campo de busca por dados de clientes. Pode conter o CNPJ ou parte do nome do cliente. Dados Cliente: resultado da consulta (por CNPJ ou Nome Cliente) feita pelo usuário, retorna todos os dados do cliente. Novos Dados: novas informações ou alterações sobre o cliente adicionadas no banco de dados. Dados Cliente: novos dados do cliente alterados ou adicionados com sucesso. CNPJ, Nome Cliente: busca de cliente por nome ou CNPJ para ser excluído do sistema. Excluir Dados: dados excluído do sistema. Cliente Removido: aviso ao usuário que o cliente foi removido com sucesso. CNPJ, Nome Cliente: busca de cliente por nome ou CNPJ para emissão de relatório de movimentação do cliente. Dados Cliente: resultado da consulta (por CNPJ ou Nome Cliente) feita pelo usuário, retorna toda a movimentação do cliente. Relatório Cliente: relatório de movimentação do cliente gerado e emitido para o usuário. Dados Fornecedor: Estrutura de dados referente a um fornecedor. (a) Nome da Empresa: nome da empresa do fornecedor; 35

45 (b) Telefone: um telefone fixo de contato com o fornecedor; (c) Celular: um telefone móvel para contato com o fornecedor; (d) Fax: número do fax do fornecedor; (e) E mail: um e mail de contato com o fornecedor; (f) Endereço: endereço completo da empresa do fornecedor. Deve incluir logradouro, número e complemento; (g) Bairro: bairro referente ao endereço; (h) CEP: código de endereçamento postal referente ao endereço acima; (i) Cidade: cidade onde se localiza a sede da empresa do fornecedor ou o escritório com o qual a empresa de eventos se comunica para realizar seus contratos; (j) Estado: unidade da federação onde se localiza a sede da empresa do fornecedor ou o escritório com o qual a empresa de eventos se comunica; (k) CNPJ: o número do cadastro nacional de pessoa jurídica da empresa do fornecedor. Fornecedor Cadastrado: aviso ao usuário que o fornecedor foi cadastrado com sucesso. Nome Fornecedor: campo de busca por dados de fornecedor. Pode conter o nome do fornecedor ou parte dele. Dados Fornecedor: resultado da consulta (por Nome Fornecedor) feita pelo usuário, retorna todos os dados do fornecedor. Novos Dados Fornecedor: novas informações ou alterações sobre o fornecedor adicionadas no banco de dados. Dados Fornecedor: novos dados do fornecedor alterados ou adicionados com sucesso. Nome Fornecedor: busca de fornecedor por nome para ser excluído do sistema. Excluir Dados: dados excluído do sistema. 36

46 Fornecedor Removido: aviso ao usuário que o fornecedor foi removido com sucesso. Dados Proposta: Estrutura de dados referente a uma proposta: (a) Número da Proposta: número de identificação interna da proposta; (b) Data da proposta: data na qual a proposta foi emitida; (c) Data de Validade da Proposta: validade da proposta; tipo: data. (d) Prazo de Entrega: número de dias que o pedido poderá ser entregue; (e) Local de Entrega: endereço do local de entrega, o campo deve incluir logradouro, número, complemento e bairro; (f) Forma de Pagamento: forma na qual será efetuado o pagamento; (g) Nome do Produto: descrição do produto na proposta; (h) Valor Unitário do Produto: preço de cada item de produto; (i) Quantidade de Peças: quantidade de peças de cada produto; (j) Valor Total: valor total de todos os itens da proposta; (k) Nu NF: número referente à nota fiscal da venda. (l) Nu Duplicata: número referente à duplicata emitida. Dados Cliente: Estrutura de dados referente a um cliente, idêntica a citada anteriormente. Dados Produto: Estrutura de dados referente a um produto: (a) Nome do Produto: nome completo do produto; (b) Referência do Produto: Código interno da empresa usado para representar um determinado produto; (c) Valor do Produto: valor de venda de um determinado produto; Proposta Cadastrada: aviso ao usuário que a proposta foi cadastrada com sucesso. Nome_Cliente, Data_Proposta: campo de busca de propostas. Pode ser efetuada através do nome do cliente ou da data de emissão da proposta. Dados Proposta: resultado da busca por propostas feita pelo usuário. 37

47 Dados Cliente: resultado da busca por propostas feita pelo usuário. Quando a busca por proposta é realizada, o sistema retorna simultaneamente os dados do cliente. Dados Produto: resultado da busca por proposta feita pelo usuário. O sistema retorna dados dos produtos contidos na proposta. Novos Dados: novas informações ou alterações de uma proposta adicionadas no banco de dados. Dados Proposta: novos dados da proposta alterados ou adicionados com sucesso. Nome_Cliente, Data_Proposta: busca de proposta por nome do cliente, data que a proposta foi emitida ou número da proposta para ser excluída do sistema. Excluir Proposta: proposta excluída do sistema. Proposta Removida: aviso ao usuário que a proposta foi removida com sucesso. Nome_Cliente, Data_Proposta: busca de proposta por período ou nome para emissão de relatório de propostas dos clientes. Dados Proposta: resultado da consulta (Nome_Cliente ou Data_Proposta) feita pelo usuário, retorna os dados das propostas consultadas. Relatório Propostas: relatório das propostas feitas pelos clientes por período é gerado com sucesso. Dados Produtos: Estrutura de dados referente a um produto: (a) Nome do Produto: nome completo do produto; (b) Referência do Produto: Código interno da empresa usado para representar um determinado produto; 38

48 (c) Valor do Produto: valor de venda de um determinado produto; Produto Cadastrado: aviso ao usuário que o produto foi cadastrado com sucesso. Nome Produto, Referência Produto: campo de busca por dados de um produto. Pode conter o nome do produto ou referência. Dados Produto: resultado da consulta (por Nome ou Referência do Produto) feita pelo usuário, retorna os dados do produto pedido. Novos Dados Produto: novas informações ou alterações sobre o produto adicionadas no banco de dados. Dados Produto: novos dados do produto alterados ou adicionados com sucesso. Nome Produto, Referência Produto: busca de produto por nome ou referência para ser excluído do sistema. Excluir Produto: produto excluído do sistema. Produto Removido: aviso ao usuário que o produto foi removido com sucesso. Nome Produto, Referência Produto: busca de produtos através de nome ou referência para que seja gerado um relatório de preço dos produtos. Uma lista com todos os produtos também poderá ser gerada. Dados Produto: retorno dos preços dos produtos. Relatório Preços: resultado da solicitação feita pelo usuário, o relatório é gerado e emitido com sucesso. 39

49 Especificação de Processos Operações com clientes Funcionário realiza o cadastro de um novo cliente Funcionário digita os dados de um novo cliente; Procurar em Clientes um CNPJ/CPF igual ao digitado; Se CNPJ/CPF existe então dar mensagem de que já existe um cliente cadastrado com o CNPJ/CPF; senão armazenar os dados do novo cliente em Clientes. Funcionário consulta dados de clientes Usuário estabelece um critério de busca que pode ser composto de: CNPJ/CPF ou Nome Cliente (dois nomes, ou partes de nomes, filtrados pelos operadores menor que, maior que, igual ou contém ) Agrupar critérios com o operador lógico E ; Ler em Clientes os clientes que atendem ao critério de busca estabelecido; Se nenhum cliente atende então não aparecerá na lista clientes; senão retornar ao usuário os dados dos clientes encontrados. Funcionário edita o cadastro de um cliente Usuário procura o cliente a ser alterado na lista de consulta; Se o cliente não existe então não aparecerá na lista clientes; senão os dados são gravados em Clientes no registro. 40

50 Funcionário remove o cadastro de um cliente Usuário informa o CNPJ/CPF ou nome do cliente que quer remover; Se o cliente não existe então não aparecerá na lista clientes; senão pedir confirmação do usuário e, caso seja confirmado, remover o cliente. OBS.: No caso de um cliente ser removido, as propostas relacionadas a ele não serão excluídas automaticamente, porém acusará cliente não existente. O usuário neste caso ou altera o cliente ou cancela a proposta. Funcionário solicita relatório de movimentação do cliente Usuário procura o cliente na lista de consulta; Se o cliente não existe então não aparecerá na lista clientes; senão seleciona o cliente e clique no botão histórico e depois em imprimir. Operações com fornecedores Funcionário realiza o cadastro de um novo fornecedor Funcionário digita os dados de um novo fornecedor; Procurar em Fornecedores um CNPJ igual ao digitado; Se CNPJ existe então dar mensagem de que já existe um fornecedor cadastrado com o CNPJ; senão armazenar os dados do novo fornecedor em Fornecedor. 41

51 Funcionário consulta dados de fornecedores Funcionário estabelece um critério de busca que pode ser composto de: Nome do Fornecedor (dois nomes, ou partes de nomes, filtrados pelos operadores menor que, maior que, igual ou contém ); Agrupar critérios com o operador lógico E ; Ler em Fornecedores aqueles que atendem ao critério de busca estabelecido; Se nenhum fornecedor atende então não aparecerá na lista fornecedores; senão retornar ao usuário os dados dos fornecedores encontrados. Funcionário edita o cadastro de um fornecedor Usuário procura o fornecedor a ser alterado na lista de consulta; Se o fornecedor não existe então não aparecerá na lista fornecedores; senão os dados são gravados em Fornecedores no registro. Funcionário remove o cadastro de um fornecedor Usuário informa o nome do fornecedor que quer remover; Se o fornecedor não existe então não aparecerá na lista fornecedores; senão pedir confirmação do usuário e, caso seja confirmado, remover o fornecedor. OBS.: A exclusão de fornecedor não altera e nem exclui nenhuma outra informação atribuída, pois como pode ser visto no DER (pág. 30) o único relacionamento existente com fornecedor é o endereço do mesmo. 42

52 Operações com propostas Funcionário realiza o cadastro de uma nova proposta Funcionário digita os dados de uma nova proposta; Armazenar os dados da nova proposta em Propostas. Funcionário consulta propostas por cliente ou data Usuário informa o nome do cliente ou a data de emissão da proposta para o qual quer recuperar os dados; Ler em Propostas as propostas procuradas; Se não há propostas então não aparecerá na lista propostas; senão retornar ao usuário as propostas encontradas. Funcionário edita o cadastro de uma proposta Usuário procura a proposta a ser alterada na lista de consulta; Se a proposta não existe então não aparecerá na lista de propostas; senão os dados são gravados em Propostas no registro correspondente. Funcionário remove o cadastro de uma Proposta Usuário informa o número da proposta que quer remover; Se a proposta não existe então não aparecerá na lista de propostas; - senão - Se a proposta for do tipo venda - então não é possível excluir esta proposta; - senão pedir confirmação do usuário e, caso seja confirmado, cancelar a proposta; 43

53 Funcionário solicita relatório de propostas de cliente por período Usuário informa o nome do cliente ou data da proposta na tela de consulta; Se o cliente não existe então não aparecerá na lista de propostas; senão Se a data da proposta não existe então não aparecerá na lista de propostas; senão buscar propostas cadastradas do cliente ou do período correspondente e imprimir relatório; Operações com Produtos Funcionário realiza o cadastro de um novo produto Funcionário digita os dados de um novo produto; Armazenar dados do novo produto em Produtos; Funcionário consulta dados de produtos Usuário informa o nome do produto ou referência para o qual quer recuperar os dados; Ler em Produtos o produto procurado; Se não há produto então não aparecerá na lista de produtos; senão Apresentar ao usuário os dados do produto encontrado. Funcionário edita o cadastro de um produto Usuário procura o produto a ser alterado na lista de consulta; Se o produto não existe 44

54 então não aparecerá na lista de produtos; senão os dados são gravados em produtos no registro correspondente. Funcionário remove o cadastro de um produto Usuário informa o nome do produto ou referência que quer remover; Se o produto não existe então não aparecerá na lista de produtos; senão pedir confirmação do usuário e, caso seja confirmado, cancelar o produto. OBS.: No caso da exclusão de algum produto, a integridade dos dados relacionados a este produto estará garantida, ou seja, existindo propostas contendo algum produto excluído, este produto não será excluído da proposta em questão. Funcionário solicita relatório de preço dos produtos Usuário acessa a tela de consulta; Imprime relatório de preços; Limites de Automação Todos os eventos especificados e analisados serão implementados em uma única iteração. O sistema será inteiramente desenvolvido pela aluna Ana Paula Pinheiro, em Visual Basic Interfaces dos Usuários As interfaces com os usuários se tratam de formulários criados no Visual Basic. Para ter acesso ao sistema, o usuário deve digitar seu login e sua senha na tela inicial do 45

55 sistema. A partir daí, ao clicar nas opções dos menus, serão acionados outros formulários para que possam ser executadas as operações e funcionalidades do sistema Requisitos de Desempenho O software não é exigido em nenhum requisito especial de desempenho. O seu tempo de resposta deve ser apenas curto o suficiente para não irritar os seus usuários Restrições de Projeto Nenhuma norma ou escolha por software ou hardware define algo que se imponha como uma limitação ao projeto deste software Atributos O software a ser implementado deve ter interface com o usuário bastante amigável. A sua confiabilidade deve ser de nível médio, visto que não realizará nenhuma operação crítica. E, por fim, deve ser, naturalmente, projetado e implementado de forma a tornar bastante fácil a sua manutenção Outros Requisitos Não existem requisitos adicionais a serem considerados no projeto deste software. 46

56 4 - Descrição de Projeto de Software 4.1. Introdução Finalidade Este capítulo compreende o projeto do sistema a ser implementado e tem como resultado uma descrição de projeto, que será apresentada nas próximas seções. A redação do presente documento é baseada na norma ANSI/IEEE 1016 simplificada e será apresentada aos sócios da empresa Lumitex Rio, clientes para os quais o software está sendo projetado Escopo No sistema serão oferecidas algumas funcionalidades básicas de gerenciamento comercial, visto que os dirigentes da empresa nunca tiveram nenhum contato com qualquer tipo de sistema e terão que passar por uma fase de adaptação. O produto deverá trazer uma série de benefícios para a empresa. A parte administrativa será automatizada, facilitando, portanto, o controle das atividades da empresa. Além disso, informações sobre os produtos, clientes e fornecedores serão armazenadas em banco de dados. Isso permitirá a geração de relatórios e facilitará o acompanhamento dos negócios da empresa por parte dos sócios Definições, Acronismos e Abreviaturas Nesta seção, estão indicadas as definições de termos e siglas utilizados na documentação do software projetado. SGC Sistema de Gerenciamento Comercial ERS Especificação de Requisitos de Software

57 Referências Esta seção é reservada para a identificação dos documentos referenciados na descrição de projeto. No nosso caso, as referências utilizadas são o Plano de Projeto do software, documento gerado na fase de planejamento do projeto em questão, o ERS, produto resultante da fase de análise de requisitos do software, e a norma ANSI/IEEE 1016 simplificada Decomposição Decomposição em Módulos Essa seção apresenta a decomposição do software em módulos, descrita na figura a seguir. Cada um desses módulos tem a sua arquitetura descrita e é, também, decomposto em módulos menores. Figura 23: Módulos do SGC Módulo SGC Esse módulo é responsável pela autenticação de usuário na tela do Menu Principal. Para acessar o sistema será preciso ter o nome de usuário e senha únicos, lembrando que 48

58 só quem acessará o sistema serão os sócios, não havendo necessidade de cadastro de usuário para cada funcionário. Figura 24: Módulo de acesso ao sistema. Gerenciamento de Clientes Esse módulo responde por todas as operações com cliente, tais como, cadastro, consulta, edição, exclusão de cliente e relatório de movimentação do cliente. Figura 25: Módulo de gerenciamento de clientes Gerenciamento de Fornecedores Esse módulo responde por todas as operações com fornecedores, cadastro, consulta, edição e exclusão. 49

59 Figura 26: Módulo de gerenciamento de fornecedores Gerenciamento de Propostas Esse módulo é basicamente igual aos anteriores, realizando operações similares para propostas. Figura 27: Módulo de gerenciamento de propostas Gerenciamento de Produtos Esse módulo é basicamente igual aos anteriores, realizando operações similares para produtos. 50

60 Figura 28: Módulo de gerenciamento de produtos Decomposição em Processos Correntes Praticamente não existem processos concorrentes no SGC. A maioria dos processos do sistema é executada de forma seqüencial. Os únicos processos concorrentes que podem ocorrer são os acessos ao banco de dados. O tratamento da ocorrência de acessos simultâneos à base de dados fica a cargo do sistema gerenciador de banco de dados Access. Normalmente, quando ocorrem acessos simultâneos, o Access coloca um dos processos em espera até que o outro termine. Desta forma o sistema não precisa tratar processos concorrentes, pois isto já é feito pelo sistema gerenciador de banco de dados Decomposição de Dados Neste item são descritas as entidades de dados do sistema SGC, seus atributos e características. Estas informações já foram mostradas na Especificação de Requisitos de Software na página Descrição das Dependências Dependências entre Módulos 51

61 Essa seção contém uma descrição dos acoplamentos existentes entre os módulos que compõem o sistema. Para o módulo SGC se realiza a autenticação de usuário e em seguida a tela principal é impresso na tela. No módulo de Gerenciamento de Clientes, ao executar a exclusão de clientes, deve ser consultado o módulo Gerenciamento de Propostas para saber quais propostas cadastradas no sistema estão relacionadas com o cliente a ser editado. Para o módulo de Gerenciamento de Produtos, ao executar uma edição de produtos, deve ser consultado o módulo Gerenciamento de Propostas, a fim de buscar informações de propostas associados ao produto em questão. A edição inclui operações de alterações no cadastro do produto e exclusão do registro correspondente. Na exclusão, é realizada uma exclusão lógica. O registro é apenas marcado como excluído no banco de dados e as propostas relacionadas ao produto são mantidas. O módulo de Gerenciamento de Fornecedores, não possui acoplamento com outros módulos Dependências entre Processos Esse item não se aplica, pois não existem dependências entre processos Dependências entre Dados Nesse item devem ser descritos os relacionamentos entre os dados. Pelo diagrama de entidade e relacionamento, mostrado no item 2.3 acima, podemos notar claramente as dependências existentes entre os dados das entidades Projeto Detalhado das Entidades de Dados Entidade de Dados Cliente CD CLIENTE NOME CLIENTE CNPJ/CPF INSC ESTADUAL/RG TEXTO(100) TEXTO(16) TEXTO(8) 52

62 TELEFONE TEXTO(12) FAX TEXTO(12) TEXTO(20) CD ENDEREÇO CD BAIRRO CD CEP CD CIDADE CD UF PRIMARY KEY (CD CLIENTE), FOREIGN KEY (CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) Entidade de Dados Fornecedor CD FORNECEDOR NOME FANTASIA TEXTO(100) CNPJ TEXTO(16) INSC ESTADUAL TEXTO(8) TELEFONE TEXTO(12) FAX TEXTO(12) TEXTO(20) CD ENDEREÇO CD CEP CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD FORNECEDOR), FOREIGN KEY (CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) Entidade de Dados Proposta CD PROPOSTA NU PROPOSTA TIPO TEXTO DATA DE EMISSAO DATA/HORA FORMA PAGAMENTO TEXTO VALOR TOTAL MONETARIO VALIDADE PROPOSTA DATA/HORA PRAZO ENTREGA TEXTO(10) LOCAL ENTREGA TEXTO(100) CD CLIENTE CD ENDEREÇO CD CEP CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD PROPOSTA), 53

63 FOREIGN KEY (CD CLIENTE, CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) Entidade de Dados Produto CD PRODUTO NOME PRODUTO TEXTO(100) REFERENCIA PRODUTO TEXTO(10) VALOR PRODUTO MONETARIO PRIMARY KEY (CD PRODUTO) Entidade de Dados Endereço CD ENDEREÇO ENDEREÇO TEXTO(100) CD BAIRRO CD CEP CD CIDADE CD UF PRIMARY KEY (CD ENDEREÇO), FOREIGN KEY (CD BAIRRO, CD CEP, CD CIDADE, CD UF) Entidade de Dados CEP CD CEP CEP TEXTO(9) CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD CEP), FOREIGN KEY (CD BAIRRO, CD CIDADE, CD UF) Entidade de Dados Bairro CD BAIRRO BAIRRO TEXTO(30) CD CIDADE CD UF PRIMARY KEY (CD BAIRRO), FOREIGN KEY (CD CIDADE, CD UF) Entidade de Dados Cidade 54

64 CD CIDADE CIDADE TEXTO(50) CD UF PRIMARY KEY (CD CIDADE), FOREIGN KEY (CD UF) Entidade de Dados UF CD UF PRIMARY KEY (CD UF) Entidade de Dados Nota Fiscal CD NOTA FISCAL NOTA FISCAL DATA EMISSAO DATA/HORA CD CLIENTE CD ENDEREÇO CD CEP CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD NOTA FISCAL), FOREIGN KEY (CD CLIENTE, CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) Entidade de Dados Duplicata CD DUPLICATA NU DUPLICATA VALOR VENCIMENTO MONETARIO VALOR PAGAMENTO MONETARIO DATA EMISSAO DATA/HORA DATA VENCIMENTO DATA/HORA DATA PAGAMENTO DATA/HORA CD NOTA FISCAL CD CLIENTE CD ENDEREÇO CD CEP CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD DUPLICATA), FOREIGN KEY (CD NOTA FISCAL, CD CLIENTE, CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) 55

65 Entidade de Dados Item Proposta CD ITEM QT ITEM PROPOSTA DESCRIÇAO TEXTO(200) CD PRODUTO CD PROPOSTA CD CLIENTE CD ENDEREÇO CD CEP CD BAIRRO CD CIDADE CD UF PRIMARY KEY (CD ITEM), FOREIGN KEY (CD PRODUTO, CD PROPOSTA, CD CLIENTE, CD ENDEREÇO, CD BAIRRO, CD CEP, CD CIDADE, CD UF) 56

66 5 Conclusão O desenvolvimento deste projeto proporcionou a utilização de padrões de desenvolvimento de software bastante utilizados. O produto desenvolvido é um sistema que atende bem as características da instituição referida como cliente, uma vez que automatizou os processos existentes na empresa, referente à administração. O produto foi desenvolvido com uma interface básica que pode ser devidamente melhorada no futuro conforme as intenções do cliente. O resultado obtido com o desenvolvimento deste projeto é satisfatório e foi assim considerado pelo cliente em final de testes. Os próximos passos consistem na implantação do sistema na empresa para que o mesmo possa começar a ser utilizado pelos seus usuários. Este processo deve acontecer ainda nesse mês. Existem funcionalidades que não fizeram parte do escopo desta versão inicial que podem ser geradas a partir de futuras solicitações pelo cliente ou propostas encaminhadas ao mesmo com aceitação, tais como, emissão de nota fiscal e duplicata e controle de estoque. Pode-se afirmar, enfim, que o trabalho desenvolvido forneceu possibilidade de contato com um cliente e o projeto de um ambiente que realmente será utilizado gerando, assim, uma elevada quantidade de experiência e conhecimentos novos a seu desenvolvedor e agregando valor ao cliente que, por sua vez, terá seu desempenho elevado no mercado em que atua.

67 Bibliografia Pressman, Roger S. (2006). Engenharia de Software, Mc Grw Hill, Sexta Edição. Bob Reselman, Jeff Webb, Michael Mckelly (1997). Usando o Visual Basic 5, Campus. Ovídio Pazello Júnior (2001). Visual Basic Desenvolvendo um Aplicativo, Erica. Tutorial: acessado em 16/07/2007 Apostila Access 2003, acessado em 20/04/2007

68 Apêndice A. Manual do Usuário 1. Objetivo O objetivo deste manual é permitir o esclarecimento de quaisquer dúvidas do usuário com relação ao uso do Sistema de Gerenciamento Comercial (SGC). É esperado que após a leitura desse documento, qualquer usuário seja capaz de dominar o funcionamento do mesmo sem problemas. 2. Introdução O sistema possui somente um tipo de usuário, os dirigentes da empresa, que terá acesso completo ao sistema. O programa não precisa ser instalado, basta que se rode o arquivo executável colocado na máquina. 3. Utilizando o Sistema 3.1. Tela de Acesso ao Sistema

69 Campo Nome do Operador: nome do usuário que está acessando o sistema, não existe restrição. Campo Senha de Acesso: dado cadastrado que permite o acesso ao sistema, após digitá-lo pressionar a tecla enter Tela Principal Botão Cadastros: ao clicar nesse botão aparecerá o menu com o tipo de cadastro que o usuário quer realizar: clientes, fornecedores ou produtos. Botão Propostas: ao clicar nesse botão aparecerá a tela de propostas, onde o usuário poderá realizar todas operações com propostas: cadastrar, consultar, editar e imprimir relatório. Botão Utilitários: ao clicar nesse botão aparecerá o menu com opções de utilitários do sistema: alterar senha, ajusta e corrige banco de dados, cópia de segurança do banco de dados, restaura cópia do banco de dados e backup de arquivos. Botão Calculadora: ao clicar nesse botão aparecerá uma calculadora Botão Calendário: ao clicar nesse botão aparecerá um calendário 60

70 Botão Internet: ao clicar nesse botão abrirá uma tela da web. Botão Encerra: ao clicar nesse botão o usuário sairá do sistema Tela de Clientes A tela de clientes aparece quando o usuário clica no botão cadastros clientes e já aparece na função consulta. Campo Digite a Pesquisa: o usuário digita o nome ou CNPJ/CPF do cliente, vai depender da opção escolhida no campo ao lado Ordem de Pesquisa Campo Ordem de Pesquisa: escolhe o tipo de consulta, se é por nome ou CNPJ/CPF. Botão Cadastrar Novo: ao clicar nesse botão vai pra tela de cadastrar novo cliente. Botão Excluir: exclui o cliente selecionado na lista que aparece na tela. Botão Editar: ao clicar nesse botão vai pra tela de alteração de algum dado do cliente. Botão Histórico: aparece a movimentação do cliente. Botão Finalizar: fecha a tela de clientes. 61

71 3.3. Tela de Cadastro de Cliente Campo Código do Cliente: esse campo é preenchido automaticamente pelo sistema. Todos os outros campos no formulário são informações sobre o cliente. Sendo que os campos que possuem o símbolo * são de preenchimento obrigatório. Botão Confirmar: confirma o cadastro com as informações preenchidas. Botão Retornar: cancela o cadastramento e retorna pra tela anterior. 62

72 3.4. Tela de Fornecedores A tela de fornecedores aparece quando o usuário clica no botão cadastros fornecedores e já aparece na função consulta. Campo Pesquisa: o usuário digita o nome do fornecedor para consulta-lo. Botão Cadastrar Novo: ao clicar nesse botão vai pra tela de cadastrar novo fornecedor. Botão Excluir: exclui o fornecedor selecionado na lista que aparece na tela. Botão Editar: ao clicar nesse botão vai pra tela de alteração de algum dado do fornecedor. Botão Finalizar: fecha a tela de fornecedores. 63

73 3.5. Tela de Cadastro de Fornecedores Campo Código: esse campo é preenchido automaticamente pelo sistema. Todos os outros campos no formulário são informações sobre o fornecedor. Botão Confirmar: confirma o cadastro com as informações preenchidas. Botão Retornar: cancela o cadastramento e retorna pra tela anterior. 64

74 3.6. Tela de Produtos A tela de produtos aparece quando o usuário clica no botão cadastros produtos e já aparece na função consulta. Campo Pesquisa: o usuário digita a referência ou descrição do produto, vai depender da opção escolhida no campo ao lado Ordem de Pesquisa Campo Ordem de Pesquisa: escolhe o tipo de consulta, se é por referência ou descrição do produto. Botão Cadastrar Novo: ao clicar nesse botão vai pra tela de cadastrar novo produto. Botão Excluir: exclui o produto selecionado na lista que aparece na tela. Botão Editar: ao clicar nesse botão vai pra tela de alteração de algum dado do produto. Botão Imprimir: Imprime o relatório de preços do produto. Botão Finalizar: fecha a tela de produtos. 65

75 3.7. Tela de Cadastro de Produtos 3.8. Tela de Propostas Todos os outros campos no formulário são informações sobre o produto e devem ser preenchidos pelo usuário, exceto os campos, data de cadastro e último reajuste de preço. Botão Confirmar: confirma o cadastro com as informações preenchidas. Botão Retornar: cancela o cadastramento e retorna pra tela anterior. 66

76 3.9. Tela de Propostas A tela de propostas aparece quando o usuário clica no botão propostas e já aparece na função consulta. Campo Pesquisa: o usuário digita o nome do cliente ou data, vai depender da opção escolhida no campo ao lado Ordem de Pesquisa. Campo Ordem de Pesquisa: escolhe o tipo de consulta, se é por nome do cliente ou data. Campo tipo: escolhe a opção de a proposta ser somente proposta ou se ela foi vendida. Campo Período: usuário escolhe o período que deseja consultar propostas. Botão Novo: ao clicar nesse botão vai pra tela de cadastrar nova proposta. Botão Editar: ao clicar nesse botão vai pra tela de alteração de algum dado da proposta. Botão Imprimir: imprime relatório de propostas de um determinado período. Botão Finalizar: fecha a tela de propostas. 67

77 3.9. Tela de Cadastro de Propostas Campo Proposta Nr.: esse campo é preenchido automaticamente pelo sistema. Todos os outros campos no formulário são informações sobre a proposta. Botão Cancelar: cancela o preechimento da proposta, retornando pra tela de propostas. Botão Fechar: confirma o cadastro com as informações preenchidas e retorna pra tela de propostas. 68