2010 - TCC - Rubia Valiati Cardoso

(1)

RUBIA VALIATI CARDOSO

SISTEMA WEB DE GERENCIAMENTO, GERAÇÃO DE ORÇAMENTO

E PEDIDO PARA UMA AGÊNCIA DE DESIGN

VILA VELHA 2010

(2)

SISTEMA WEB DE GERENCIAMENTO, GERAÇÃO DE ORÇAMENTO

E PEDIDO PARA UMA AGÊNCIA DE DESIGN

Trabalho apresentado ao Curso de Sistemas de Informação, do Centro Universitário de Vila Velha – UVV, como requisito parcial para a obtenção do título de Bacharel em Sistemas de informação. Orientador: Prof. Msc. Cristiano Biancardi

VILA VELHA 2010

(3)

SISTEMA WEB DE GERENCIAMENTO, GERAÇÃO DE ORÇAMENTO

E PEDIDO PARA UMA AGÊNCIA DE DESIGN

Trabalho de Conclusão de Curso apresentado ao curso de Sistemas de Informação, do Centro Universitário Vila Velha – UVV, como requisito parcial para obtenção do título de Bacharel em Sistemas de Informação.

Aprovado em 28 de Junho de 2010.

COMISSÃO EXAMINADORA

Profº. Cristiano Biancardi Mestre em Informática Orientador

Profº. Heráclito A. Pereira Junior Mestre em Informática

Profª. Susiléa Abreu dos Santos Lima Mestre em Informática

(4)

Agradeço primeiramente a Deus pela oportunidade de realizar uma faculdade, pela força, coragem e bençãos.

Agradeço a minha família pelo apoio e auto estima, me incentivando sempre a não desistir diante as dificuldades encontradas.

Ao meu namorado Urlan Maciel Dipré por ser compreensivo, paciente e incentivador. As amizades feitas nesse período de curso que lutaram junto comigo, em especial Marineis de Souza Rigo por todo apoio e ajuda que foram de suma importância para a finalização deste trabalho e Aline Witelma Viana.

Ao apoio, paciência e atenção de Marcelo Littig, Manuel Hinojosa e Sandro Tonini. Ao orientador Prof. Msc. Cristiano Biancardi pelo direcionamento para que esse projeto se concretizasse.

A todos os professores pelo conhecimento a mim fornecido.

Por fim, e não menos importante, a Fusion Design pela colaboração no desenvolvimento deste projeto.

(5)

"Deus não nos exige que tenhamos sucesso; ele só exige que você tente."

(6)

Analisando o setor de design no mercado de trabalho, pode-se encontrar uma série de fatores que poderiam ser aprimorados e desenvolvidos, como gerenciamento da agência, geração de orçamentos e pedidos. No mercado de software, não há um sistema que contemple tudo isso voltado para o ramo de design. As agências necessitam de um software customizado que atendam as suas necessidades acelerando o fluxo das informações, a otimização de seus serviços e aproximação com o cliente.

Este trabalho propõe o desenvolvimento de um sistema web que contempla tudo o que uma agência de design precisa. O objetivo principal é automatizar o gerenciamento interno da agência, a realização de orçamentos resultando em pedidos online. Visando a facilidade de uso para todos os usuários, além de maior controle e confiabilidade dos dados da agência e padrão nos orçamentos e pedidos. Desta forma, o sistema foi construído utilizando conhecimentos de tecnologia da informação como Orientação a Objetos, modelado em linguagem UML e desenvolvido nas linguagens de programação Java e Flex, fazendo o uso do Postgres SQL para persistência do banco de dados.

(7)

Tabela 1 – Problemas, Causas e Possíveis Soluções Informatizadas...40

Tabela 2 – Fontes de Informações e Técnicas Utilizadas ...41

Tabela 3 – Oportunidade de Melhoria x Possíveis Aplicações...41

Tabela 4 – Tabela de Complexidade (VAZQUEZ, SIMÕES, ALBERT, 2010)...73

Tabela 5 – Contagem de Pontos por Função...74

Tabela 6 – Equipe de Desenvolvimento...76

Tabela 7 – Tabela Salário Profissionais de TI (INFO, 2009 / CATHO, 2009)...76

Tabela 8 – Investimento em Mão de Obra ...77

Tabela 9 – Especificação Servidor Primeira Proposta (DELL, 2009) ...77

Tabela 10 – Especificação de Hardware Primeira Proposta (DELL, 2009) ...78

Tabela 11 – Custos Operacionais Primeira Proposta...79

Tabela 12 – Benefícios Intangíveis Primeira Proposta...80

Tabela 13 – Especificação do Servidor Segunda Proposta (LOCAWEB, 2010) ...81

Tabela 14 – Especificação de Hardware Segunda Proposta (DELL, 2009) ...82

Tabela 15 – Custo Operacional Segunda Proposta ...82

Tabela 16 – Benefícios Intangíveis Segunda Proposta...84

Tabela 17 - Dicionário de Dados da classe Cliente...87

Tabela 18 – Dicionário de Dados da classe Pessoa Física...87

Tabela 19 - Dicionário de Dados da classe Pessoa Jurídica...88

Tabela 20 - Dicionário de Dados da classe Funcionário ...88

Tabela 21 - Dicionário de Dados da classe Empresa Terceirizada ...88

Tabela 22 – Dicionário de Dados da classe Serviço ...88

Tabela 23 – Dicionário de Dados da classe Orçamento ...88

Tabela 24 - Dicionário de Dados da classe Itens Orçamento...89

(8)

Tabela 28 – Dicionário de Dados da classe Agenda...90

Tabela 29 – Dicionário de Dados da Classe Conta Pagar ...90

Tabela 30 – Dicionário de Dados da Classe Conta Receber ...91

Tabela 31 – Dicionário de Dados da Classe Cheque...91

Tabela 32 – Referência Diagrama de Seqüência Manter Funcionário ...96

Tabela 33 – Referência Diagrama de Sequencia Manter Empresa Terceirizada...96

Tabela 34 – Referência Diagrama de Sequencia Manter Agenda ...96

Tabela 35 – Referência Diagrama de Sequencia Efetuar Conta Pagar ...100

Tabela 36 – Referência Diagrama de Sequencia Efetuar Conta Receber ...100

Tabela 37 – Referência Diagrama de Sequencia Manter Cheque ...101

Tabela 38 – Referência Diagrama de Sequencia Emitir Relatório Orçamento...108

Tabela 39 – Referência Diagrama de Sequencia Emitir Relatório Pedido ...109

Tabela 40 – Dicionário de Dados Gerência de Dados...127

Tabela 41 – Tabela Ícones...131

Tabela 42 – Tabela Campos dos Formulários...132

Tabela 43 – Tabela Menu...133

Tabela 44 – Tabela Logotipo...134

(9)

Figura 1 – Sistema de Solicitação de Orçamento (S2FT, 2010) ...22

Figura 2 – Sistema de Pedido (POWERCARD, 2010) ...22

Figura 3 – Modelo de Ciclo de Vida Cascata (BEZERRA, 2007) ...30

Figura 4 – Arquitetura MVC (MACORATTI, 2009) ...20

Figura 5 – Fluxograma Solicitação de Orçamento ...39

Figura 6 – Diagrama de Casos de Uso ...20

Figura 7 – Diagrama de Classes ...20

Figura 8 – Diagrama de Seqüência Efetuar Login...92

Figura 9 – Diagrama de Seqüência Incluir Cliente. ...93

Figura 10 – Diagrama de Seqüência Alterar Dados Pessoais...94

Figura 11 – Diagrama de Seqüência Consultar Cliente...94

Figura 12 – Diagrama de Seqüência Alterar Cliente ...95

Figura 13 – Diagrama de Sequência Excluir Cliente ...96

Figura 14 – Diagrama de Seqüência Incluir Serviço ...97

Figura 15 – Diagrama de Seqüência Consultar Serviço...98

Figura 16 – Diagrama de Seqüência Alterar Serviço ...99

Figura 17 – Diagrama de Seqüência Excluir Serviço ...100

Figura 18 – Diagrama de Seqüência Solicitar Orçamento...20

Figura 19 – Diagrama de Seqüência Avaliar Orçamento ...103

Figura 20 – Diagrama de Seqüência Verificar Solicitações Orçamento ...104

Figura 21 – Diagrama de Seqüência Realizar Pedido...104

Figura 22 – Diagrama de Seqüência Gerar Orçamento ...20

Figura 23 – Diagrama de Seqüência Acompanhar Pedido...106

Figura 24 – Diagrama de Seqüência Emitir Relatório Administrativo Situação Cliente ...107

(10)

Figura 27 – Diagrama de Estados Pedido...110

Figura 28 – Arquitetura de Desenvolvimento ...118

Figura 29 – Diagrama de Pacotes do Sistema Web de Gerenciamento, Geração de Orçamento e Pedido ...120

Figura 30 – Modelo MVCE do Módulo Orçamento...121

Figura 31 – Diagrama da Camada Domínio do Problema (DP) ...123

Figura 32 – Diagrama Gerência de Tarefas (GT)...20

Figura 33 – Diagrama Gerência de Dados (GD) ...127

Figura 34 – Diagrama Relacional ...20

Figura 35 – Diagrama de Interface com Usuário (IU)...131

Figura 36 – Tela Login...134

Figura 37 – Tela Solicitar orçamento...20

Figura 38 – Tela Avaliar Orçamento...136

Figura 39 – Tela Detalhe Avaliar Orçamento ...136

Figura 40 – Tela Verificar Solicitações ...137

Figura 41 – Tela Detalhe Verificar Solicitações...138

Figura 42 – Tela Gerar Orçamento ...139

Figura 43 – Diagrama de Navegação Módulo Orçamento ...140

Figura 44 – Diagrama de Sequência Revisado Solicitar Orçamento...20

Figura 45 – Diagrama de Sequencia Revisado Avaliar Orçamento ...143

Figura 46 – Diagrama de Sequência Revisado Verificar Solicitações – Aceitar...144

Figura 47 – Diagrama de Sequência Revisado Verificar Solicitações - Rejeitar ...145

Figura 48 - Diagrama de Sequência Revisado Realizar Pedido...146

Figura 49 - - Diagrama de Sequência Revisado Gerar Orçamento – Aceitar...147

(11)

Figura 53 – Diagrama de Implantação UML...151

Figura 54 – Cadastro de Usuário ...153

Figura 55 – Cadastro de Perfil...153

Figura 56 – Permissão de Acesso...154

Figura 57 – Autenticação - Login...154

Figura 58 – Implementação MD5 usando Hash ...155

Figura 59 – Armazenamento de senha no BD usando MD5 – Hash...155

Figura 60 – Implementação Campos Obrigatórios ...155

Figura 61 – Campos Obrigatórios Tela Solicitar Orçamento ...156

Figura 62 – Campo Obrigatório Mensagem Tela Solicitar Orçamento ...156

Figura 63 – Campos da tabela Auditoria no Banco de Dados...157

Figura 64 – Tabela Orçamento com campos para Auditoria ...157

Figura 65 – Tela Principal Site ...164

Figura 66 - Login ...165

Figura 67 – Menu Perfil Cliente ...165

Figura 68 – Menu Arquivo ...165

Figura 69 – Alterar Senha ...166

Figura 70 – Menu Orçamento - Cliente ...166

Figura 71 – Campos Obrigatórios Solicitar Orçamento ...167

Figura 72 – Solicitar Orçamento...168

Figura 73 – Solicitar Orçamento - Calcular...169

Figura 74 – Solicitar Orçamento - Excluir...170

Figura 75 – Solicitar Orçamento – Mensagem Sucesso ...170

Figura 76 - Menu Perfil Gerente ...171

(12)

Figura 80 – Avaliar Orçamento – Mensagem Sucesso ...173

Figura 81 – Verificar Solicitações ...174

Figura 82 – Detalhe Verificar Solicitações...175

Figura 83 – Realizar Pedido...176

Figura 84 – Realizar Pedido – Depósito Bancário...176

Figura 85 – Realizar Pedido - Mensagem ...177

Figura 86 – Verificar Solicitações – Mensagem Rejeitar ...177

Figura 87 – Campos Obrigatórios Gerar Orçamento...177

Figura 88 – Gerar Orçamento – Consultar Cliente ...178

Figura 89 – Tabela Financeira...180

(13)

DAO - Data Access Objects DP – Domínio do Problema GD – Gerência de Dados GT – Gerência de Tarefas IU – Interface com Usuário

MD5 - Message-Digest algorithm 5 MVC – Model, View, Controller SLA - Service Level Agreement UML – Unified Modeling Language WSDL - Description Language XML - eXtensible Markup Language

(14)

1. INTRODUÇÃO...20

1.1. Motivação...21

1.2. Justificativa...23

1.3. Objetivo...23

1.4. Descrição dos Capítulos ...24

2. CONCEITOS ...26

2.1. Específicos...26

2.1.1. Design... ...26

2.1.2. Orçamento e Pedido ...27

2.2. Processo de Desenvolvimento de Software...28

2.2.1. Modelo de Ciclo de Vida ...29

2.2.1.1. Ciclo de Vida em Cascata...29

2.2.2. Orientação a Objetos ...30

2.2.3. UML (Unified Modeling Language) ...32

2.2.4. Padrões de Projeto ...33

2.2.4.1. Padrão MVCE ...34

3. LEVANTAMENTO DE REQUISITOS...37

3.1. Descrição do Ambiente ...37

3.2. Mini Mundo...38

3.3. Problemas, Causas, Possíveis Soluções Informatizadas ...40

3.4. Fontes de Informação e Técnicas Utilizadas ...41

3.5. Oportunidade de Melhoria x Possíveis Aplicações ...41

3.6. Diagrama de Casos De Uso...42

3.7. Descrição dos Atores ...43

(15)

3.8.2. Cadastros...45

3.8.2.1. Incluir Cliente ...45

3.8.2.2. Alterar Dados Pessoais...46

3.8.2.3. Manter Cliente...48

3.8.2.4. Manter Funcionário ...50

3.8.2.5. Manter Empresa Terceirizada...51

3.8.2.6. Manter Agenda ...51

3.8.2.7. Manter Serviço...52

3.8.3. Financeiro ...54

3.8.3.1. Efetuar Conta Pagar ...54

3.8.3.2. Efetuar Conta Receber ...55

3.8.3.3. Manter Cheque ...55

3.8.4. Orçamento e Pedido ...56

3.8.4.1. Solicitar Orçamento ...56

3.8.4.2. Avaliar Orçamento ...58

3.8.4.3. Verificar Solicitações de Orçamento ...59

3.8.4.4. Realizar Pedido...61

3.8.4.5. Gerar Orçamento ...62

3.8.4.6. Acompanhar Pedido ...64

3.8.5. Relatórios...65

3.8.5.1. Emitir Relatório Administrativo...65

3.8.5.2. Emitir Relatório Financeiro...67

3.8.5.3. Emitir Relatório Orçamento...68

3.8.5.4. Emitir Relatório Pedido ...68

(16)

4.1.2. Contagem de Pontos de Função ...72

4.1.3. Composição da Equipe de Desenvolvimento...75

4.1.4. Mão de obra para o Desenvolvimento do Sistema ...76

4.2. Primeira Proposta Tecnológica ...77

4.2.1. Especificação do Servidor...77

4.2.2. Especificação de Hardware ...78

4.2.3. Custo Operacional (CO)...79

4.2.4. Custo de Investimento (CI) ...79

4.2.5. Custo Total (CT) ...79

4.2.6. Benefícios Tangíveis...79

4.2.7. Benefícios Intangíveis...80

4.2.8. Prazo de Retorno...80

4.3. Segunda Proposta Tecnológica ...81

4.3.1. Especificação do Servidor...81

4.3.2. Especificação de Hardware ...81

4.3.3. Custo Operacional (CO)...82

4.3.4. Custo Investimento ...82 4.3.5. Custo Total (CT) ...83 4.3.6. Benefícios Tangíveis...83 4.3.7. Benefícios Intangíveis...84 4.3.8. Prazo de Retorno...84 4.4. Proposta Escolhida ...84 5. ESPECIFICAÇÃO DE ANÁLISE...85 5.1. Diagrama de Classes...85 5.2. Dicionário de Dados...87

(17)

5.3.1.1. Efetuar Login...92

5.3.2. Cadastros...93

5.3.2.1. Incluir Cliente ...93

5.3.2.2. Alterar Dados Pessoais...93

5.3.2.3. Manter Cliente...94 5.3.2.3.1. Consultar Cliente...94 5.3.2.3.2. Alterar Cliente ...95 5.3.2.3.3. Excluir Cliente ...95 5.3.2.4. Manter Serviço...97 5.3.2.4.1. Incluir Serviço ...97 5.3.2.4.2. Consultar Serviço...97 5.3.2.4.3. Alterar Serviço ...98 5.3.2.4.4. Excluir Serviço ...99 5.3.3. Financeiro ...100 5.3.4. Orçamento e Pedido ...101 5.3.4.1. Solicitar Orçamento ...101 5.3.4.2. Avaliar Orçamento ...103

5.3.4.3. Verificar Solicitações de Orçamento ...103

5.3.4.4. Realizar Pedido...104

5.3.4.5. Gerar Orçamento ...105

5.3.4.6. Acompanhar Pedido ...106

5.3.5. Relatórios...106

5.3.5.1. Emitir Relatório Administrativo...106

5.3.5.2. Emitir Relatório Financeiro...107

(18)

6. ESPECIFICAÇÃO DE PROJETO ...111

6.1. Escolha da Tecnologia...112

6.2. Arquitetura do Sistema...119

6.1.1. Diagrama de Pacotes ...119

6.2. Divisão em Camadas ...120

6.2.1. Camada Domínio do Problema (DP) ...122

6.2.2. Camada Gerência de Tarefas (GT) ...124

6.2.3.1. Dicionário de Dados do Diagrama Gerência de Dados ...127

6.2.3.2. Diagrama Relacional...128

6.2.3.3. Dicionário de Dados do Diagrama Relacional...130

6.2.4. Camada Interface com Usuário (IU) ...130

6.2.4.1. Padrões de Interface...131 6.2.4.1.1. Ícones e Botões ...131 6.2.4.1.2. Formulários ...132 6.2.4.1.3. Menu...133 6.2.4.1.4. Logotipo ...134 6.2.4.1.5. Telas ...134 6.2.4.2. Diagrama de Navegação ...139

6.2.4.3. Componentes do Flex Utilizados para a Construção das Interfaces..140

6.3. Diagrama de Seqüência Revisado...141

6.3.1. Solicitar Orçamento ...141

6.3.2. Avaliar Orçamento ...143

6.3.3. Verificar Solicitações Orçamento ...144

6.3.4. Realizar Pedido...146

(19)

7. PROJETO DE SEGURANÇA ...152

7.1. Mecanismos para Controle de Segurança ...152

7.1.1. Controle de Usuários ...152

7.1.2. Controle de Perfil ...153

7.1.3. Controle de Permissão de Acesso...153

7.1.4. Autenticação ...154

7.1.5. Integridade dos dados ...155

7.1.6. Política de Backup ...156

7.2. Auditoria...156

8. CONCLUSÃO ...158

9. REFERÊNCIAS BIBLIOGRÁFICAS...159

10. ANEXO A: Manual do Usuário ...162

(20)

1. INTRODUÇÃO

Diante o mercado de trabalho atual observa-se a necessidade das empresas em buscar o crescimento e destaque entre as outras. Um grande fator auxiliador para tal crescimento é a utilização da TI (Tecnologia da Informação). Mas, ainda hoje existem pequenas e médias empresas que possuem uma relação de medo e dúvida com a tecnologia. Esse medo pode ser devido à falta de conhecimento e iniciativa de tais empresas.

Visto isso, a agência Fusion Design, visando seus negócios junto ao cliente, buscou soluções em meio a TI para gerenciar suas informações. A agência está no mercado a aproximadamente 2 (dois) anos desenvolvendo soluções em identidades visuais e web. Todo serviço de design é realizado utilizando tecnologias com alta definição visual, softwares de criação de imagens como Photoshop, Corel Draw e Rhinoceros para imagens 3D, e codificação de sites como DreamWeaver. Seus clientes fazem o primeiro contato com a agência através de solicitações de orçamento, orçamentos estes que requerem tempo e padronização da empresa no processo de realizá-lo. Mas tal atividade é realizada através de e-mails, não possuindo um controle das solicitações que já foram atendidas ou não, podendo assim, perder clientes. Sendo também dessa forma a realização de pedidos. Além do seu gerenciamento ser feito através de planilhas Excel, não possuindo controle sobre suas contas e assim prejudicando o gerenciamento da agência.

Diante tal cenário, fez-se o uso da TI na automatização dos processos da agência através de um sistema que gerencia suas informações, agiliza e padroniza seus orçamentos e pedidos.

Mas afinal, o que é TI?

Segundo WIKIPEDIA (2010), Tecnologia da Informação é o conjunto de todas as atividades e soluções providas por recursos de computação. Seu uso permite uma relação mais estreita entre empresa e cliente.

Sendo uma importante ferramenta para vantagens competitivas de mercado, sucesso nos negócios, redução de custos, automatização dos processos,

(21)

gerenciamento contínuo, flexibilidade diante as transformações e aperfeiçoamento nas tomadas de decisão.

Com a evolução da tecnologia da informação, surge então o e-Commerce.

“E-Commerce ou comércio eletrônico, é a combinação entre o negócio tradicional e a automatização trazida pela Internet que permite às empresas, trocar informações ou dados sobre vendas, realizar transações financeiras, entrega e faturação de bens e serviços, de uma forma automatizada e sobre um protocolo de comunicação seguro e inovador, onde potencialmente estão presentes todos os potenciais compradores a nível mundial.” (DALERA, 2010)

Através do comércio eletrônico o cliente pode suprir suas necessidades 24 horas por dia através de um meio seguro e confiável. E as empresas potenciam suas vendas, realizam seu Marketing e agilizam seus processos de venda.

Assim, esse projeto viabiliza um sistema web que contempla todas as necessidades da agência de design, utilizando todos os processos de desenvolvimento de software desde seu planejamento, análise, projeto, implementação e testes.

1.1. Motivação

Observando o mercado de software foi encontrando uma carência no que diz respeito a sistemas que englobam gerenciamento, geração de orçamento e pedidos de serviços de design.

Através de uma pesquisa, foram encontrados alguns softwares que realizam tais tarefas, porém isoladamente.

A figura 1 mostra um sistema de solicitação de orçamento online da empresa S2FT – Design e Sistemas. Este sistema não permite que o cliente tenha uma visualização dos valores dos serviços, e as especificações dos mesmos.

(22)

Figura 1 – Sistema de Solicitação de Orçamento (S2FT, 2010) A figura 2 mostra um sistema de pedido online da empresa PowerCard.

Figura 2 – Sistema de Pedido (POWERCARD, 2010)

Todos esses sistemas são proprietários das empresas que os utilizam.

Além da falta de softwares no mercado, o processo de solicitação de orçamento é o primeiro contato entre cliente e empresa. Este é um dos processos que requer maior agilidade e precisão, pois o cliente espera um retorno quase que imediato. Em

(23)

situações de inúmeras solicitações, depende de rapidez para que se possa fornecer este feedback1 ao solicitante.

Esses processos são realizados através de planilhas eletrônicas, papéis ou via e-mail, não possuindo registros de solicitações e pedidos, controle sobre o financeiro e acompanhamento gerencial da empresa.

1.2. Justificativa

Diante esta carência do mercado de software, este projeto visa relacionar as principais necessidades do gerenciamento interno da agência, obtendo maior controle, agilidade, facilidade e confiabilidade em seus dados através de relatórios gerenciais. Auxiliando também, na geração de orçamentos e pedidos, tendo padrão, agilidade e controle das solicitações, sendo de fácil utilização para com seus usuários.

1.3. Objetivo

O principal objetivo do sistema é automatizar o gerenciamento da agência, a realização de um orçamento resultando em um pedido online.

Os objetivos específicos do trabalho são:

• Desenvolvimento de um software de fácil utilização para os profissionais da área e clientes dentro das dependências de cada um, tornando mais eficaz assim, o processo de solicitação de orçamentos e realização de pedidos; • Agilidade nos retornos das solicitações de orçamentos dos clientes; • Relatórios gerenciais;

1

Feedback: Dicionário Informal (2006) Palavra em inglês que no português significa retorno, resposta, análise crítica.

(24)

• Gráficos de acompanhamento de pedidos;

Para obter tais objetivos se faz necessário desenvolver o software em uma arquitetura web e multiplataforma para atender às necessidades de diversos clientes que utilizam ambientes diferentes. Utilizar técnicas e metodologias de Engenharia de Software para se obter qualidade no mesmo. Gerar documentação do projeto apresentando todos os elementos técnicos e funcionalidades do mesmo.

1.4. Descrição dos Capítulos

Os capítulos estão organizados da seguinte forma:

O capítulo 2, conceitos, apresenta os conceitos específicos da área de Design Gráfico, Web e Produto, orçamento e pedidos. Apresenta também conceitos de SI (Sistemas de Informação) que orientarão no processo de desenvolvimento do projeto.

O capítulo 3, levantamento de requisitos, apresenta a descrição do ambiente identificando os problemas, causas e possíveis soluções para o mesmo. Apresenta também, as fontes de informações, as técnicas utilizadas no levantamento e propostas de melhoria. Abordando os casos de uso indicando como serão realizadas as ações no sistema.

O capítulo 4, propostas tecnológicas, apresenta duas propostas tecnológicas, abordando investimentos, benefícios, prazos e estimativas do tamanho do projeto. O capítulo 5, especificação de análise, apresenta o diagrama de classes, o diagrama de seqüência que demonstra as ações realizadas no sistema e o diagrama de estados.

O capítulo 6, especificação de projeto, apresenta o sistema de forma mais detalhada, sendo mais específico, mostrando a arquitetura do sistema, a divisão em camadas, o diagrama de componentes e de implantação.

O capítulo 7, projeto de segurança, será abordado soluções para prevenir riscos e diminuí-los, evitando que ocorra falhas, erros e perdas no sistema.

(25)

O capítulo 8, apresenta a conclusão do projeto, definindo as futuras propostas para a evolução do projeto e todas as dificuldades encontradas no desenvolvimento do mesmo.

O capítulo 9 apresenta as referências bibliográficas utilizadas para o desenvolvimento do projeto.

Por fim, são apresentados os anexos, contendo o manual do usuário e outras documentações.

(26)

2. CONCEITOS

Este capítulo apresentará os conceitos utilizados neste projeto, sendo eles, conceitos específicos que envolvem o cenário para o desenvolvimento do projeto, quanto, conceitos de engenharia de software, tornando mais claro o entendimento relacionado aos aspectos abordados no mesmo.

2.1. Específicos

Para entender melhor a respeito do ramo de atividade no qual o sistema será projetado e desenvolvido, este tópico apresentará conceitos específicos da área de Design gráfico, web e produto como conceitos sobre orçamento e pedido.

2.1.1. Design

Segundo o site WIKIPEDIA (2010), denomina-se Design qualquer processo técnico e criativo relacionado à configuração, concepção, elaboração e especificação de um artefato. Esse processo normalmente é orientado por uma intenção ou objetivo, ou para a solução de um problema.

O Design é uma atividade envolvendo uma ampla faixa de profissões, das quais produtos, serviços, comunicações gráficas, decoração e arquitetura fazem parte. Composto por planejar, desenvolver, projetar, tendo como resultado desses processos instruções, desenhos, modelos e protótipos ou como solução produto, serviço ou benefícios gerados.

Neste projeto serão abordadas três especialidades de Design, sendo elas:

• Design gráfico: É o processo de comunicar visualmente utilizando textos e imagens para apresentar informações. A prática de design gráfico envolve um aspecto de habilidades cognitivas, estéticas e habilidades em artes visuais e diagramação de páginas. Geralmente se refere aos processos pelas quais a comunicação é criada e produtos que são gerados. Refere-se

(27)

à área de conhecimento e à prática profissional específica e relativa ao ordenamento estético-formal de elementos textuais e não-textuais que compõem peças gráficas destinadas à produção com objetivo expressamente comunicacional.

• Webdesign: É uma extensão da prática do Design, onde o foco do projeto é a criação de web sites e documentos disponíveis no ambiente da web. Tende à multidisciplinaridade, uma vez que a construção de páginas web requer subsídios de diversas áreas técnicas, além do design propriamente dito. Áreas como a arquitetura da informação, programação, usabilidade, acessibilidade entre outros.

• Design de Produto: Também chamado de projeto de produto ou desenho industrial, design de produto trabalha com a produção de objetos e produtos tridimensionais para usufruto humano. Um designer (profissional de design) de produto lidará essencialmente com o projeto e produção de bens de consumo ligados à vida quotidiana (como mobiliário doméstico e urbano, eletrodomésticos, automóveis e outros tipos de veículos, etc) assim com a produção de bens capital, como máquinas e motores.

2.1.2. Orçamento e Pedido

Orçamento é uma estimativa de quanto custará o serviço e produto solicitados por algum cliente e quanto tempo estes levarão para serem desenvolvidos e produzidos. Neste é apresentado uma listagem de produtos e serviços selecionados por cada cliente, com seus respectivos preços, quantidade, valor total e data prevista de entrega.

“Orçamento – Ato ou efeito de orçar (calcular, computar, avaliar); Cálculo de gastos a fazer com algo projetado; (Dicionário Brasileiro GLOBO)”

Pedido é a realização de uma solicitação aprovada. Este acontece após o orçamento (neste contexto), é a aprovação do cliente para que comece o

(28)

desenvolvimento e produção dos serviços e produtos antes solicitados no orçamento. É nesta fase que é realizado o pagamento das solicitações.

2.2. Processo de Desenvolvimento de Software

Um processo de desenvolvimento de software envolve todas as atividades necessárias para definir, desenvolver, testar e manter um software. Alguns objetivos de um processo de desenvolvimento são: definir quais as atividades a serem executadas ao longo do projeto; quando, como e por quem tais atividades serão executadas; prover pontos de controle para verificar o andamento do desenvolvimento; padronizar a forma de desenvolver software (BEZERRA, 2003) Segundo PRESSMAN (2007), o processo de desenvolvimento de software pode ser compreendido como um conjunto de atividades relacionadas que têm como finalidade definir, desenvolver, testar e manter um produto de software.

As atividades típicas utilizadas no processo de desenvolvimento são:

• Levantamento de Requisitos: O levantamento de requisitos possibilita que o engenheiro de sistema especifique a função e o desempenho do software, indique a interface do software com outros elementos do sistema e estabeleça quais são as restrições de projeto que o software deve enfrentar. Os modelos de processos são construídos nesta etapa

• Análise de Requisitos: O processo de coleta dos requisitos é intensificado e concentrado especificamente no software. Para entender a natureza do(s) software(s) a ser(em) construído(s), o engenheiro de software deve compreender o domínio da informação para o software, bem como a função, desempenho e interface exigidos. Os requisitos, tanto para o sistema como para o software, são documentados e revistos com o cliente. • Projeto: É um processo de múltiplos passos que se concentra em quatro atributos distintos do programa: estrutura de dados, arquitetura de software, detalhes procedimentais e caracterização de interface.

(29)

• Implementação: Executa a tarefa de traduzir o projeto em linguagem de máquina.

• Teste: Concentra-se nos aspectos lógicos internos do software, garantindo que todas as instruções tenham sido testadas, e concentra-se também nos aspectos funcionais externos, ou seja, realizando testes para descobrir erros e garantir que a entrada definida produza resultados reais que concordem com os resultados exigidos.

• Manutenção: Indubitavelmente, o software sofrerá mudanças depois que for entregue ao cliente. Ocorrerão mudanças porque erros foram encontrados, porque o software deve ser adaptado a fim de acomodar mudanças em seu ambiente externo ou porque o cliente exige acréscimos funcionais ou de desempenho. A manutenção de software reaplica cada uma das etapas precedentes do ciclo de vida a um programa existente, e não a um novo.

2.2.1. Modelo de Ciclo de Vida

O modelo de ciclo de vida é utilizado para descrever um grupo de atividades e a forma como elas se relacionam. A definição das etapas do processo de desenvolvimento do sistema possibilitam prover marcos e pontos de controle para avaliação de qualidade da gerência de projeto.

2.2.1.1. Ciclo de Vida em Cascata

Caracteriza-se por possuir uma tendência na progressão seqüencial entre uma fase e a seguinte. Eventualmente, pode haver uma retroalimentação de uma fase para a fase anterior, mas, de um ponto de vista macro, as fases seguem seqüencialmente. (BEZERRA. 2007)

Este modelo tem a vantagem que só avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente

(30)

participa ativamente no projeto e que sabe muito bem o que quer. Este modelo minimiza o impacto da compreensão adquirida no decurso de um projeto, uma vez que se um processo não pode voltar atrás de modo a alterar os modelos e as conclusões das tarefas anteriores, é normal que as novas idéias sobre o sistema não sejam aproveitadas.

A figura 3 mostra como ocorre o ciclo de vida em cascata.

Figura 3 – Modelo de Ciclo de Vida Cascata (BEZERRA, 2007)

O modelo de ciclo de vida cascata foi adotado devido às suas boas práticas para que o projeto seja bem sucedido. Este modelo é importante para o desenvolvimento do sistema, pois todo o trabalho será desenvolvido usando como base as fase nele contida.

2.2.2. Orientação a Objetos

A Orientação a Objetos é um paradigma de programação. Um sistema de software orientado a objetos consiste em vários objetos trabalhando junto com o objetivo de realizar as funcionalidades desse sistema. Cada objeto é responsável por tarefas específicas. É através da cooperação entre objetos que a computação do sistema se desenvolve (BEZERRA, 2003).

(31)

Este paradigma não é adotado por completo, podendo ser visto nas empresas, que possuem diversidade na programação de suas aplicações.

Uma abordagem completa implica em toda uma visão orientada a objetos, e não apenas o mero emprego de uma programação orientado a objetos (PRESSMAN, 2007).

“Os benefícios da tecnologia orientado a objetos são ampliados se ela é adotada no início e ao longo de todo processo de engenharia de software.” Pode-se concluir que a orientação a objetos como técnica para a modelagem de sistemas diminui a diferença semântica entre a realidade sendo modelada e os modelos construídos, por isso, tem sido provado o seu valor para a construção de sistemas em todos os tipos de domínios de problemas, abrangendo todos os graus de tamanho e de complexidade. Além disso muitas linguagens, sistemas operacionais e ferramentas contemporâneas são, de alguma forma, orientados a objeto, fortalecendo a visão do mundo em termos de objetos (BOOCH, 2006).

Com a orientação a objetos são definidos diversos conceitos como:

• Abstração: É a habilidade de selecionar aspectos essenciais de um contexto qualquer, ignorando características de menor importância.

• Classes: É a abstração de características relevantes do mundo real. Uma classe define o comportamento dos objetos, através de métodos, e quais estados ele é capaz de manter, através de atributos.

• Atributos: São as características que um objeto pode assumir. • Métodos: São as ações que um objeto pode realizar.

• Objeto: É a instância de uma classe, é o elemento criado a partir da classe seguindo os moldes já definida na classe.

• Mensagens: São estímulos enviados a um objeto para invocar os seus métodos, ativando um comportamento descrito n sua classe.

• Herança: É o mecanismo que uma classe pode derivar de uma outra classe aproveitando os seus métodos e atributos.

(32)

• Polimorfismo: É a capacidade de abstrair várias aplicações diferentes em uma mesma interface.

• Encapsulamento: É ocultar o funcionamento interno e as estruturas de dados de um objeto, de forma que se utilizar os serviços de um objeto não é necessário saber o seu funcionamento.

• Interface: É um contrato entre a classe e o mundo externo. Quando uma classe implementa uma interface, ela está comprometida a fornecer o comportamento publicado pela interface.

2.2.3. UML (Unified Modeling Language)

A UML é uma linguagem visual para modelar sistemas orientados a objetos. Isso quer dizer que a UML é uma linguagem que define elementos gráficos (visuais) que podem ser utilizados na modelagem de sistemas. Esses elementos permitem representar os conceitos de paradigma da orientação a objetos. Através dos elementos gráficos definidos nesta linguagem pode-se construir diagramas que representam diversas perspectivas de um sistema (BEZERRA, 2007).

Durante uma década, Grady Booch, James Rmbaugh e Ivar Jacobson colaboraram para combinar as melhores características de seus métodos individuais de análise e projeto orientados a objetos num método unificado. O resultado chamado de linguagem de modelagem unificada (Unified Modeling Language, UML), tornou-se amplamente usado pela indústria (BOOCH, 1999).

A UML permite ao engenheiro de software expressar em modelo de análise usando uma notação de modelagem, que é regulada por um conjunto de regras sintáticas, semânticas e pragmáticas. Em UML, um sistema é representado usando visões diferentes, que descrevem o sistema a partir de perspectivas distintas e diferentes. Cada visão é definida por um conjunto de diagramas. As visões propostas são as seguintes:

• Visão de Casos de Uso: Descreve o sistema de um ponto de vista externo como um conjunto de interações entre o sistema e os agentes externos ao

(33)

sistema. Esta visão é criada inicialmente e direciona o desenvolvimento das outras visões do sistema.

• Visão de Projeto: Enfatiza as características do sistema que dão suporte, tanto estrutural quanto comportamental, às funcionalidades externamente visíveis do sistema.

• Visão de Implementação: Abrange o gerenciamento de versões do sistema, construídas pelo agrupamento de módulos (componentes) e subsistemas. • Visão de Implantação: Corresponde à distribuição física do sistema sem

seus subsistemas e à conexão entre essas partes.

• Visão de Processo: Esta visão enfatiza as características de concorrência (paralelismo), sincronização e desempenho do sistema.

Os artefatos gerados em cada visão estão continuamente sendo refinados conforme a necessidade ou alterados caso haja a licitação de novos requisitos.

2.2.4. Padrões de Projeto

Os padrões de software ou padrões de desenho de software, também muito conhecido pelo termo original em inglês Design Patterns, descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.

De acordo com os autores da Gang Of Four (principal catálogo de padrões de projeto), uma definição para Design Patterns seria:

“Descrição de objetos de comunicação e classes que são customizados para resolver um problema geral de design em um contexto particular.”

Os padrões de projeto tornam mais fácil reutilizar projetos e arquiteturas bem sucedidas. Expressar técnicas testadas e aprovadas as torna mais acessíveis para os desenvolvedores de novos sistemas. Ajudam a escolher alternativas de projeto que tornam um sistema reutilizável e a evitar alternativas que comprometam a

(34)

reutilização. Podem melhorar a documentação e a manutenção de sistemas ao fornecer uma explicação explícita de interações de classes e objetos e o seu objetivo subjacentes. Em suma, ajudam um projetista a obter um projeto “certo” mais rápido (GAMMA, 2002).

Contudo, a idéia central dos padrões é seguir maneiras que levem ao desenvolvimento baseado em abstração de soluções e isso acarreta diretamente em melhores práticas no desenvolvimento, adotando modelos que deram certo.

Abaixo será dada uma explicação sobre o padrão de projeto utilizado no desenvolvimento deste trabalho.

2.2.4.1. Padrão MVCE

Segundo BASHAM (2005), o MVC, como o nome sugere, possibilita a separação de um projeto em múltiplas camadas, das quais fazem parte: Modelo (Model), Visão (View) e Controlador (Controller). Surgiu como uma forma melhorada para construção de interfaces gráficas, mas tomou grande amplitude e passou a ser utilizado, de uma forma geral, na arquitetura de sistemas complexos.

O MVC que separa a lógica de negócios no model, a apresentação na view e a interação entre eles no controller, também se apresenta como uma boa escolha para a construção de aplicações web interativas. Isto devido ao fato de neste tipo de aplicação haverem grandes quantidades de interações de diversos tipos de usuários e buscas e exibições de dados.

A aplicação do padrão MVC possibilita o desacoplamento das partes do programa deixando-o modularizado. O sistema é decomposto em componentes com funções específicas e independentes uns dos outros, aumentando assim, a coesão dos mesmos.

Todas essas características tornam o projeto mais reutilizável devido ao fraco acoplamento, ou seja, não há interdependências entre componentes e os mesmos podem ser empregados com pequenas adaptações em projetos futuros. Acrescentando ainda que, reutilizando projetos que foram baseados em padrões, é

(35)

aceitável que foram abordadas as melhores práticas de pessoas experientes que trabalharam soluções neste domínio.

No MVC, os componentes se comunicam através da definição de interfaces e

troca de mensagens. Desta forma, qualquer um dos componentes pode ser modificado ou substituído sem interferir em nada no funcionamento dos demais, basta que o novo componente siga a implementação das interfaces definidas. Com isso se obtém a desejada flexibilidade que os sistemas atuais exigem.

O padrão MVCE é uma evolução do modelo MVC onde junto a camada de Modelo foi melhorada, devido a separação da camada de persistência chamada normalmente de DAO (Data Access Objects – Objetos de Acesso a Dados) da camada de modelo. Tanto o modelo MVC quanto o modelo MVCE (Modelo, Visão, Controle, Estendido) tem como objetivo fornecer uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos dados de uma aplicação, separando a sua apresentação visual da lógica do negócio.

O MVCE divide os componentes de um sistema em quatro camadas deixando-o mais modularizado e fracamente acoplado, sendo elas:

• Camada Lógica da Aplicação (Modelo): É a camada onde são definidos os Modelos, classes de modelo de dados, que possuem métodos e os atributos do sistema. É nesta camada que fica contida toda a lógica de negócio. No desenvolvimento os modelos são agrupados no pacote chamado DP (Domínio do Problema).

• Camada de Persistência (Estendido/DAO): É a camada que contém as classes responsáveis por se comunicar com outro sistema para a recuperação, inserção ou deleção de dados, normalmente através de um SGBD (Sistema Gerenciador de Banco de Dados). No desenvolvimento as classes de persistências são agrupadas no pacote chamado de GD (Gerenciados de Dados).

• Camada de Visualização do Sistema (Visão): Constitui a interface do sistema de interação com o usuário, é o que o usuário irá visualizar ao iniciar o sistema. A camada da visão tem a função de capturar as ações do usuário e passar para os níveis abaixo do sistema e de receber a resposta

(36)

do sistema e transmiti-la para o usuário. No desenvolvimento as classes de visualização são agrupadas nos pacotes de IU (Interface com Usuário) • Camada de Controle (Controle): É onde serão processadas todas as

requisições feitas através da interface (Visão). O controle também acessa a Camada Lógica a fim de obter determinadas informações sobre aos Modelos. Toda lógica da aplicação (validações, atribuições, etc.) é feita no Controle (CAVALCANTI, 2007).

A figura 4 mostra o fluxo de eventos e informações em uma arquitetura MVC.

(37)

3. LEVANTAMENTO DE REQUISITOS

Neste capítulo será abordado o levantamento de requisitos das funcionalidades do sistema.

O levantamento de requisitos é fundamental para o desenvolvimento de sistemas, por tratar justamente de descobrir o que se deseja do sistema, entender aquilo que o cliente deseja ou o que o cliente acredita que precisa e as regras do negócio ou processos do negócio. Está associado ao processo de descobrir quais são as operações que o sistema deve realizar e quais são as restrições que existem sobre elas (WAZLAWICK, 2004).

Nesta fase inicial, é muito importante que as informações sejam colhidas de forma correta através de estudos em documentos, reuniões, Braimstorming (tempestade de idéias), questionários ou a observação para evitar futuros problemas.

Os requisitos podem ser classificados em duas grandes categorias:

• Requisitos Funcionais: Correspondem à listagem de tudo que o sistema deve fazer.

• Requisitos Não-Funcionais: São restrições colocadas sobre como o sistema deve realizar seus requisitos funcionais.

3.1. Descrição do Ambiente

A empresa onde a aplicação proposta irá operar trata-se de uma agência de Design no ramo gráfico, web e produtos.

A Fusion Design foi fundada em 2008 por quatro estudantes de Design de Produtos formados pela UVV (Centro Universitário Vila Velha).

Atualmente, administrada por apenas dois dos fundadores, a agência desenvolve identidade visual corporativa para seus clientes através da criação de logotipos, folhetos, sites e diversas outras manifestações visuais. Atendem empresas que

(38)

estão iniciando e necessitam de uma nova identidade, até empresas de médio e grande porte que estão aprimorando e reestruturando sua comunicação.

Seu diferencial está na qualidade dos serviços prestados, no atendimento e no prazo. Estão sempre adicionando novas técnicas e tecnologias do mercado de comunicação visual em seus trabalhos.

3.2. Mini Mundo

A figura 5 refere-se a um Diagrama de Atividades2 _{representando o processo de}

solicitação de orçamento e realização de um pedido.

2

(39)

(40)

O processo de solicitação de orçamento inicia com a requisição de algum(s) produto(s) ou serviço(s) de à agência. Esta por sua vez, busca valores referentes à solicitação realizada pelo cliente em planilhas, para assim, gerar um retorno ao solicitante referente ao orçamento.

Ao receber o retorno, o cliente analisa e decide se realiza um pedido ou cancela esta solicitação. Caso opte pela primeira escolha, o cliente volta a entrar em contato com a agência para especificar seu pedido, ou seja, dá maiores detalhes sobre o mesmo. A produção só começa com o pagamento de parte do valor do pedido.

Após o desenvolvimento, é necessária a validação do cliente para saber se tudo foi feito como solicitado. Caso haja alguma alteração, a agência a realiza e o cliente a valida novamente, para assim, caso necessite de terceiros para a finalização do mesmo, ser encaminhado para empresa terceirizada responsável pela confecção do produto.

Por fim, o produto é entregue ao cliente e o restante do pagamento é efetuado. Caso o cliente solicite um serviço, não há a intervenção de uma empresa terceirizada, a própria agência finaliza o processo de desenvolvimento do mesmo.

3.3. Problemas, Causas, Possíveis Soluções Informatizadas

A tabela 1 representa os principais problemas levantados, suas causas e possíveis soluções, referente a todo contexto apresentado anteriormente.

Tabela 1 – Problemas, Causas e Possíveis Soluções Informatizadas

Problemas Levantados Causas Possíveis Soluções

Geração de orçamento dependente da empresa.

Falta de uma ferramenta para que essa solicitação seja realizada em qualquer lugar.

Funcionalidade de solicitar orçamentos online.

Orçamentos fora do padrão. Orçamentos gerados em documentos Word e/ou assuntos de emails.

Funcionalidade de gerar orçamentos online.

Perdas de informações detalhadas para realizar um

Pedidos realizados não (nem sempre) baseados no

Funcionalidade de realizar pedidos online a partir da

(41)

pedido. orçamento. solicitação de um orçamento. Perda de tempo dos

funcionários

Localizar a situação que se encontra o pedido de um cliente.

Funcionalidade para o cliente acompanhar seus pedidos online.

Perda de dados. Controle financeiro realizado através de tabelas Excel.

Funcionalidade para controlar todos os gastos e contas a receber da empresa.

Falta de relatórios. Não há dados registrados para essa ação.

Funcionalidade para emissão de relatórios gerenciais.

3.4. Fontes de Informação e Técnicas Utilizadas

A tabela 2 descreve as fontes de informações e técnicas de levantamento de dados que foram utilizadas para coletar tais informações.

Tabela 2 – Fontes de Informações e Técnicas Utilizadas

Fonte de Informação Técnica Utilizada

Urlan Maciel Dipré - Sócio Gerente Agência Entrevista e Questionamentos Documentos (Orçamento, Boletos, Planilhas) Levantamento Documental Acompanhamento no ambiente de trabalho Observação

3.5. Oportunidade de Melhoria x Possíveis Aplicações

A tabela 3 descreve as oportunidades de melhoria e possíveis aplicações para isso. Tabela 3 – Oportunidade de Melhoria x Possíveis Aplicações

Oportunidades de Melhoria Possíveis Aplicações

Ambiente próprio do funcionário Área particular de cada funcionário para que o mesmo possa visualizar trabalhos já realizados e/ou que estão realizando. Geração de Contrato Funcionalidade de Gerar Contratos

possuindo assinatura digital tanto do cliente quanto da própria empresa.

Pagamento de pedidos via cartão de crédito Funcionalidade agregada ao sistema para a escolha de pagamento via cartão de

(42)

crédito na finalização de um pedido.

Geração de Nota Fiscal Funcionalidade de gerar nota fiscal do pedido dentro da aplicação.

Enviar mala-direta Funcionalidade de envio de propagandas da empresa aos seus clientes e terceiros como forma de marketing.

3.6. Diagrama de Casos De Uso

Modelo de caso de uso é uma representação das funcionalidades externamente observáveis do sistema e dos elementos externos ao sistema que interagem com ele.

Um diagrama de caso de uso representa graficamente os atores, casos de uso e relacionamentos entre esses elementos e tem o objetivo de ilustrar quais elementos externos interagem com que funcionalidades do sistema. (BEZERRA, 2007)

A forma de ilustrar um caso de uso é utilizando do artifício da diagramação como forma de ilustrar de maneira simples as funções principais do sistema e seus diferentes tipos de usuários, ou seja, atores que interagirão com eles (ALLAN DENNIS, BARBARA HALEY WIXON, 2005).

(43)

3.7. Descrição dos Atores

O sistema de geração de orçamento e pedido online possui os seguintes atores: • Cliente: Usuário que utiliza o sistema com intuito de solicitar um orçamento

de um produto e/ou serviço e realizar um pedido dos mesmos. Figura 6 – Diagrama de Casos de Uso

(44)

• Funcionário: Usuário responsável por registrar as transações financeiras, gerar um orçamento e realizar um pedido de um produto e/ou serviço para um cliente e realizar o cadastro dos mesmos.

• Gerente: Usuário com maiores privilégios, podendo manipular o sistema por inteiro. Possuindo acesso às informações financeiras, administrativas e de transações de solicitações.

3.8. Descrição dos Casos de Uso

A descrição do caso de uso pode descrever em uma seqüência razoavelmente completa de passos todas as atividades que ocorrem em reação a um evento acionador ao sistema e como o mesmo reagiria ao evento (ALLAN DENNIS, BARBARA HALEY WIXON, 2005).

A seguir são apresentadas as descrições dos casos de uso vistos no diagrama apresentado na figura 6.

3.8.1. Geral

3.8.1.1. Efetuar Login

UC001: Efetuar Login (UCEL)

Descrição: Este caso de uso é responsável por autenticar o usuário no sistema. Atores: Cliente, Funcionário e Gerente.

Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário conter login e senha. Fluxo Principal – Efetuar Login

(45)

1. O caso de uso se inicia quando o ator acessa a área restrita. 2. O sistema disponibiliza a tela de autenticação.

3. Ator insere login e senha.

4. Ator seleciona a opção Entrar. (#E1)

5. O sistema realiza autenticação e encerrando o caso de uso. Fluxo Exceção

(#E1): Login ou senha inválido

a. Ao selecionar opção Entrar o sistema verifica se o usuário e a senha informados pelo ator estão corretos.

b. Sistema exibe mensagem “Usuário ou senha inválida”. Pós-condição: Usuário autenticado no sistema.

3.8.2. Cadastros

3.8.2.1. Incluir Cliente

UC002: Incluir Cliente (UCIC)

Descrição: Este caso de uso é responsável por incluir os dados do cliente no sistema.

Atores: Cliente, Funcionário e Gerente. Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário autenticado no sistema. Fluxo Principal – Incluir Cliente

(46)

2. Sistema libera os campos para inserção dos dados.

3. Autor insere os dados (apresentado no dicionário de dados) do cliente. 4. Autor seleciona opção Salvar. (#A1)

5. O sistema verifica os dados informados encerrando o caso de uso. (#E1) (#E2) Fluxo Alternativo

(#A1): Cancelar

a. Ator seleciona opção de Cancelar.

b. Sistema limpa os campos da tela e cancela a inserção dos dados do cliente no sistema.

Fluxo de Exceção

(#E1): Campos obrigatórios não preenchidos

a. O sistema verifica se todos os dados foram informados de forma correta.

b. O sistema informa a obrigatoriedade do preenchimento e da correção dos campos.

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. (#E2): CPF/CNPJ existente

a. O sistema verifica se o CPF/CNPJ informado já existe. b. Sistema exibe mensagem “CPF/CNP já cadastrado”.

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. Pós-condição: Cliente incluído no sistema.

3.8.2.2. Alterar Dados Pessoais

(47)

Descrição: Este caso de uso é responsável por alterar os dados pessoais do cliente no sistema.

Atores: Cliente.

Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário autenticado no sistema. Fluxo Principal – Alterar Dados Pessoais

1. O caso de uso de inicia quando o ator solicita alterar seus dados pessoais no sistema.

2. O sistema libera os campos com seus dados preenchidos para devida alteração. 3. Ator realiza alteração desejada.

4. Ator seleciona opção Salvar. (#A1)

5. O sistema verifica os dados alterados encerrando o caso de uso. (#E1) (#E2) Fluxo Alternativo

(#A1): Cancelar

b. Sistema limpa os campos da tela e cancela a inserção dos dados do cliente no sistema encerrando o caso de uso.

(48)

(#E2): CPF/CNPJ existente

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. Pós-condição: Dados Pessoais do cliente alterados no sistema.

3.8.2.3. Manter Cliente

UC004: Manter Cliente (UCMC)

Descrição: Este caso de uso é responsável por consultar, alterar e excluir os dados do cliente no sistema.

Atores: Funcionário e Gerente.

Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário autenticado no sistema. Fluxo Principal – Consultar Cliente

1. O caso de uso se inicia quando o ator solicita consultar os dados de um cliente no sistema.

2. Sistema fornece tela para busca do cliente.

3. Ator escolhe opção de busca por Nome, CPF/CNPJ ou Razão Social. 4. Ator insere algum dado referente à escolha anterior.

5. Ator seleciona ícone de busca. (#E1) 6. Sistema retorna cliente desejado.

(49)

7. Ator seleciona cliente e escolhe opção de Transferir dados do cliente para a tela principal (tela anterior) encerrando o caso de uso.

Fluxo Alternativo (#A1): Alterar Cliente

a. Ator seleciona opção de Alterar algum dado do cliente.

b. O sistema libera os campos com seus dados preenchidos para devida alteração. c. Ator realiza alteração desejada.

d. Ator seleciona opção Salvar. (#A3)

e. O sistema verifica os dados alterados encerrando o caso de uso. (#E2) (#E3) (#A2): Excluir Cliente

a. Ator seleciona opção de excluir um cliente. b. Ator seleciona opção de Salvar. (#A3) (#A3): Cancelar

b. Sistema limpa os campos da tela e cancela a inserção dos dados do cliente no sistema encerrando o caso de uso.

(#E1): Dado para busca inexistente

a. Ator informa dado para busca inexistente.

b. Sistema exibe mensagem “Sem dados para seleção”.

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. (#E2): Campos obrigatórios não preenchidos

(50)

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. (#E3): CPF/CNPJ existente

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. Pós-condição: Cliente devidamente manutenido33 no sistema.

3.8.2.4. Manter Funcionário

UC005: Manter Funcionário (UCMF)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir os dados do funcionário no sistema.

Atores: Gerente.

Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário autenticado no sistema.

Este caso de uso segue o mesmo fluxo que os casos de uso Incluir Cliente (UC002 - UCIC) e Manter Cliente (UC004 - UCMC).

Pós-condição: Funcionário devidamente manutenido no sistema.

3

Manutenido: Habilidade de incluir, alterar e excluir dados através de processos elementares da aplicação (BRAGA, 1996).

(51)

3.8.2.5. Manter Empresa Terceirizada

UC006: Manter Empresa Terceirizada (UCMET)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir os dados da empresa terceirizada no sistema.

Pós-condição: Empresa Terceirizada devidamente manutenida no sistema.

3.8.2.6. Manter Agenda

UC007: Manter Agenda (UCMA)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir compromissos na agenda.

Atores: Funcionário, Gerente.

(52)

Aplica-se a verificação da data do compromisso ser uma data válida. Pós-condição: Agenda devidamente manutenida no sistema.

3.8.2.7. Manter Serviço

UC008: Manter Serviço (UCMS)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir serviços no sistema.

Casos de Uso Incluídos: UCMIS - Manter Itens Serviço. Casos de Uso Estendidos: Não se aplica.

Pré-condição: Usuário autenticado no sistema. Fluxo Principal – Incluir Serviço

1. O caso de uso se inicia quando o ator solicita incluir serviço no sistema. (#A1) 2. Sistema fornece tela com os campos para inserir os dados do serviço.

3. Ator insere dados (apresentado no dicionário de dados) do serviço. 4. Ator insere dados do item de serviço correspondente aquele serviço. 5. Ator solicita incluir item de serviço.

6. O sistema verifica os dados informados referente ao item. (#E1) 7. Ator seleciona opção de salvar. (#A2)

8. O sistema verifica os dados informados encerrando o caso de uso. (#E1) Fluxo Alternativo

(#A1): Consultar Serviço

(53)

b. Sistema fornece tela para busca do serviço. c. Ator escolhe opção busca por Descrição ou Tipo. d. Ator insere algum dado referente à escolha anterior. e. Ator seleciona ícone de busca. (#E2)

f. Sistema retorna serviço desejado.

g. Ator seleciona serviço e escolhe opção de transferir dados do serviço para a tela principal (tela anterior).

(#A2): Cancelar

b. Sistema limpa os campos da tela e cancela a inserção dos dados do serviço e dos itens de serviço no sistema.

(#A3): Alterar

a. Ator seleciona opção de Alterar algum dado do serviço e/ou item de serviço. b. O sistema libera os campos com seus dados preenchidos para devida alteração. c. Ator realiza alteração desejada. (#A4)

d. Ator seleciona opção Salvar. (#A2) (#A5) e. O sistema verifica os dados alterados. (#E1) (#A4): Excluir Item Serviço

a. Ator seleciona item a ser excluído na listagem. b. Ator seleciona opção de excluir.

c. Ator retorna ao passo D do fluxo alternativo #A3. (#A5): Excluir Serviço

(54)

b. Ator seleciona opção de Salvar. (#A2) Fluxo de Exceção

c. O ator volta ao(s) passo(s) assinalado(s) pelo sistema do fluxo principal. (#E2): Sem dados

a. Caso não haja dados para a busca desejada, sistema emite mensagem “Sem dados para a seleção!”

Pós-condição: Serviço e itens de serviço devidamente manutenidos no sistema.

3.8.3. Financeiro

3.8.3.1. Efetuar Conta Pagar

UC009: Efetuar Conta Pagar (UCECP)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir as contas a pagar da agência.

(55)

Aplica-se a verificação dos campos (dicionário de dados) data de vencimento e de pagamento serem datas válidas, e o número de parcelas deve maior do que 1 (um). Pós-condição: Conta Pagar efetuada no sistema.

3.8.3.2. Efetuar Conta Receber

UC010: Efetuar Conta Receber (UCECR)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir as contas a receber da agência.

Aplica-se a verificação dos campos (dicionário de dados) data de quitação e de recebimento serem datas válidas, e o número de parcelas deve maior do que 1 (um). Pós-condição: Conta Receber efetuada no sistema.

3.8.3.3. Manter Cheque

UC011: Manter Cheque (UCMCH)

Descrição: Este caso de uso é responsável por incluir, consultar, alterar e excluir os cheques no sistema.

(56)

Pós-condição: Cheque devidamente manutenido no sistema.

3.8.4. Orçamento e Pedido

3.8.4.1. Solicitar Orçamento

UC012: Solicitar Orçamento (UCSO)

Descrição: Este caso de uso é responsável por solicitar um orçamento no sistema. Atores: Cliente.

Casos de Uso Incluídos: Não se aplica. Casos de Uso Estendidos: Não se aplica. Pré-condição: Usuário autenticado no sistema. Fluxo Principal – Solicitar Orçamento

1. O caso de uso se inicia quando o ator solicita opção de solicitar um orçamento. 2. Ator seleciona tipo de serviço.

3. Ator seleciona o serviço.

4. Ator seleciona opção de Buscar. (#E1)

5. Sistema lista todos os serviços referentes à busca.

6. Ator seleciona opções desejadas e transfere para listagem ao lado. 7. Ator insere alguma observação.

(57)

8. Ator seleciona opção de Enviar. (#A1)(#A2)

9. Sistema emite mensagem “Orçamento enviado com sucesso!” encerrando o caso de uso.

Fluxo Alternativo (#A1): Calcular

a. Ator seleciona opção de Calcular.

b. Sistema bloqueia a tela para seleção de mais itens, inserção de alguma observação e/ou exclusão de algum item já selecionado.

c. Sistema realiza cálculo do total do valor dos itens e da data prevista. d. Ator retorna ao passo 8 do fluxo principal. (#A3)

(#A2): Excluir

a. Ator seleciona item a ser excluído na listagem de itens selecionados. b. Ator seleciona opção de excluir.

c. Sistema exclui item selecionado.

d. Ator retorna ao passo 8 do fluxo principal. (#A3): Voltar

a. Ator seleciona opção de voltar.

b. Sistema desbloqueia a tela para seleção de mais itens, inserção de alguma observação e/ou exclusão de algum item já selecionado.

a. O sistema verifica se todos os campos foram selecionados de forma correta. b. O sistema informa a obrigatoriedade da seleção dos campos.