Sistema Vendas e Estoque

7/30/2019 Sistema Vendas e Estoque

1/72

FACULDADE DE PINDAMONHANGABA

Raquel Aparecida Marcondes de Souza

SISTEMA PARA CONTROLE DE VENDAS E ESTOQUE

Pindamonhangaba - SP2009


2/72

Raquel Aparecida Marcondes de Souza


Monografia apresentada como parte dosrequisitos para obteno do Diploma deBacharel em Sistemas de Informao peloCurso de Bacharelado em Sistemas daInformao da Faculdade dePindamonhangaba.

Prof. MSc. Alindacir Maria Dalla Vecchia

GrassiProf. Brbara Alessandra GonalvesPinheiro Yamada

Pindamonhangaba - SP2009


3/72

RAQUEL APARECIDA MARCONDES DE SOUZA


Monografia apresentada como parte dosrequisitos para obteno do Diploma deBacharel em Sistemas de Informao peloCurso de Bacharelado em Sistemas daInformao da Faculdade dePindamonhangaba.

Data: ______________________

Resultado: __________________

BANCA EXAMINADORA

Prof. _______________________________ Faculdade de Pindamonhangaba

Assinatura __________________________

Prof. _______________________________ Faculdade de Pindamonhangaba

Assinatura __________________________

Prof. _______________________________ ___________________________

Assinatura __________________________


4/72

AGRADECIMENTOS

Agradeo primeiramente a Deus pela oportunidade de conseguir uma bolsa

para poder realizar meus estudos e por todas as dificuldades que Ele foi me

ajudando a superar nestes quatro anos.

Ao presidente Lus Incio Lula da Silva e sua equipe de governo pelo projeto

ProUni, que me permitiu a concesso de uma bolsa integral nesta faculdade.

s minhas professoras Alindacir Maria Dalla Vecchia Grassi e Brbara

Alessandra Gonalves Pinheiro Yamada que no s me orientaram com muita

dedicao, como tambm me deram foras para continuar nos momentos de maior

desnimo.

Ao meu professor Fabiano Sabha que, apesar do pouco tempo que nos deu

aula, demonstrou ser muito responsvel e ntegro, sempre prestativo e atencioso.

s minhas companheiras de estgio Juliete Gomes de Amorim e Mariana

Rosa Silva que muito colaboraram no desenvolvimento do prottipo do sistema aqui

apresentado, seja na modelagem ou na prpria linguagem de programao, bem

como nas dificuldades que foram surgindo ao longo do desenvolvimento.


5/72

RESUMO

Atualmente, a maior parte das empresas comerciais, desde as micro empresas atas grandes redes, possuem um sistema de softwarepara gerenciar todas as suasatividades. Neste sentido, este trabalho apresenta um prottipo para gerenciamentode vendas e estoque de uma pequena empresa comercial, sem fins lucrativos: oBazar do Sagrado Corao de Jesus. A inexistncia de um sistema informatizadopara esse gerenciamento pode gerar muitas inconsistncias e redundncia dedados, alm de atrasos para se obter informaes importantes para a tomada dedecises e at mesmo a falncia de empresas. O objetivo informatizar ogerenciamento das principais atividades de uma empresa comercial, provendo comas informaes armazenadas, condies para um controle financeiro e de estoque

mais gil, preciso e verdico. O sistema abrange funcionalidades como Gesto deAcesso, Gesto de Cadastro, Gesto de Movimentao Financeira e de Estoque eGesto de Relatrios, as quais foram modeladas nos diagramas de Fluxo de Dadose Entidade-Relacionamento, disponibilizados na ferramenta Case Studio. O sistemafoi implementado na linguagem Object Pascal por meio do IDE Delphi 7, comprogramao estruturada.

Palavras-chave: Agilidade. Estoque. Gerenciamento. Software. Vendas.


6/72

System to manage sales and stock

ABSTRACT

Nowadays, almost all commercial companies from small business to large ones,have a software system to manage all their tasks. In this sense, the present workaims in demonstrating a prototype to companies for managing their sales and stocksfor a non-profit company called The Bazar do Sagrado Corao de Jesus. The lackof a computerized system for management can generate many inconsistencies,redundance data, and delays for important information of making decisions and even

going out of business. The objective is to automate the management of the mainactivities in this company, providing it with the information stored, a financial controland faster, accurate and reliable stock. The system includes features such as AccessManagement, Management of Registration, Financial Transactions Management,Stock Reports Management. It was modeled in Data Flow and Entity-RelationshipDiagrams, available in Case Studio tool. The system has been implemented in ObjectPascal using the Delphi 7 IDE with structured programming.

Keywords: Agility. Stock. Management. Software. Sales.


7/72

LISTA DE TABELAS

Tabela 5.1 Cartes de histria resumidos.................................................................38Tabela 5.2 Cartes de histria com prioridades, estimativa e interaes........39Tabela 5.3 Requisitos Funcionais................................................................................41Tabela 5.4 Requisitos no Funcionais .......................................................................44


8/72

LISTA DE FIGURAS

Figura 3.1- Aplicao estruturada em Delphi ......................................................................17Figura 3.2 - Tela inicial do Delphi verso 7..........................................................................18Figura 3.3 - Tela inicial doMicrosoft Office Access 2003....................................................21Figura 3.4 - Tela inicial do BDEAdministrator....................................................................22Figura 3.5- Case Studio 2 com projeto visualizado em mdulos ........................................25Figura 4.1 Modelo de Carto de Histria no XP ..............................................................29Figura 4.2 Modelo de Carto de Tarefa no XP.................................................................30Figura 4.3 Ciclo de vida nos projetos XP ..........................................................................32Figura 5.1 Diagrama de Fluxo de Dados do Sistema SCVE-BSCJ.................................45Figura 5.2 Decomposio do Processo: Processar Vendas ..............................................46Figura 5.3 Decomposio do Processo: Gerenciar Usurios ...........................................46

Figura 5.4 Diagrama Entidade-Relacionamento do Sistema SCVE-BSCJ ....................47Figura 5.5 Esquema Relacional do Sistema SCVE-BSCJ ...............................................48Figura 6.1 Tela de Abertura do SCVE-BSCJ ...................................................................51Figura 6.2 Alterar Senha.....................................................................................................51Figura 6.3 Menu Principal ..................................................................................................52Figura 6.4 Cadastro de Artesos ........................................................................................53Figura 6.5 Cadastro de Produtos .......................................................................................53Figura 6.6 Cadastro de Usurios ........................................................................................54Figura 6.7 Lista de Artesos ...............................................................................................54Figura 6.8 Lista de Produtos ..............................................................................................55Figura 6.9 Lista de Usurios ...............................................................................................55

Figura 6.10 Formulrio de Despesas do Bazar .................................................................56Figura 6.11 Formulrio de Receitas do Bazar ..................................................................56Figura 6.12 Formulrio de Fechamento do Caixa Dirio ................................................57Figura 6.13 Formulrio de Pagamento ao Arteso ..........................................................57Figura 6.14 Recibo de Pagamento ao Arteso ..................................................................58Figura 6.15 Formulrio de Vendas ....................................................................................58Figura 6.16 Formulrio de Itens de Venda .......................................................................59Figura 6.17 Formulrio de Entrada de Produtos .............................................................59Figura 6.18 Recibo de Entrega de Produtos......................................................................60Figura 6.19 Formulrio de Devoluo de Produtos..........................................................60Figura 6.20 Recibo de Devoluo de Produtos..................................................................61Figura 6.21 Relatrio de Produtos com tempo de permanncia vencido .......................61Figura 6.22 Relatrio de Produtos em Estoque ................................................................62Figura 6.23 Relatrio de Caixa Dirio...............................................................................62Figura 6.24 Resumo Mensal de Fluxo de Caixa................................................................63Figura 6.25 Relatrio de Repasse ao Bazar.......................................................................63Figura 6.26 Formulrio deBackup ....................................................................................64Figura 6.27 Capa do Manual de Orientao ao Usurio .................................................64Figura 6.28 Formulrio de Informaes do Sistema ........................................................65


9/72

SUMRIO

1 INTRODUO .........................................................................................................91.1 Objetivo do Trabalho.....................................................................................101.2 Etapas desenvolvidas ...................................................................................111.3 Estrutura do Trabalho ...................................................................................11

2 CONTEXTUALIZAO DO SISTEMA ..................................................................13

2.1 Descrio do modelo atual ...........................................................................132.2 Proposta .........................................................................................................14

3 FERRAMENTAS UTILIZADAS..............................................................................16

3.1 Delphi..............................................................................................................163.2 Access............................................................................................................193.3 BDE Administrator.........................................................................................213.4 Case Studio....................................................................................................23

4 MODELO DE PROCESSO DE DESENVOLVIMENTO DE SOFTWARE

UTILIZADO ...............................................................................................................26

4.1 Definio de Modelo de Processo de Desenvolvimento de Software.......264.2 Extreme Programming(XP) ..........................................................................27

4.2.1 Mecanismo de Desenvolvimento no XP ...................................................325 MODELAGEM DO SISTEMA SCVE-BSCJ ...........................................................36

5.1 Viso do Sistema ...........................................................................................365.1.1 Composio e tarefas da equipe...............................................................375.1.2 Escopo do Produto.....................................................................................375.1.3 Histrias do usurio ...................................................................................375.1.4 Estimativa, priorizao e planejamento....................................................385.1.5 Funes do Produto...................................................................................405.1.6 Testes de Aceitao ...................................................................................485.1.7 Fim do projeto.............................................................................................49

6 PROTTIPO DO SISTEMA ...................................................................................50

6.1 Apresentao do Prottipo do Sistema.......................................................50

7 CONCLUSES E CONSIDERAES FINAIS .....................................................66

REFERNCIAS BIBLIOGRFICAS .........................................................................68

REFERNCIAS BIBLIOGRFICAS COMPLEMENTARES.....................................71


10/72

9

1 INTRODUO

Nas dcadas de 80 e 90, vrias manchetes de revistas e jornais, como por

exemplo: Software: A Nova Fora Propulsora, Armadilha do Software

Automatizar ou No? e Criar Software Novo: Era Uma Tarefa Agonizante...,

demonstravam a nova compreenso da importncia do softwarede computador

suas oportunidades e os perigos que apresentavam (PRESSMAN, 1995, p. 3). O

grande desafio da dcada de 90 melhorar a qualidade (e reduzir o custo) de

solues baseadas em computador solues que so implementadas com

software (PRESSMAN, 1995, p. 4). Essa preocupao com a qualidade e custo do

software ainda persiste nos dias atuais, surgindo cada vez mais tcnicas para

auxiliar o desenvolvimento do software, constituindo uma disciplina chamada

Engenharia de Software, que utiliza tcnicas de engenharia, como teorias, mtodos

e ferramentas, para produzir um software, desde os estgios iniciais de

especificao do sistema at a manuteno desse sistema, trabalhando sempre de

acordo com as restries organizacionais e financeiras (SOMMERVILLE, 2003).

Os sistemas de softwareso utilizados em todos os lugares e setores, desdeequipamentos eltricos, operaes da indstria manufatureira, escolas e

universidades, setor de assistncia sade, finanas e governo, ou at mesmo

como entretenimento.

Segundo Pressman (1995, p. 20), o processamento de informaes

comerciais a maior rea particular de aplicao de software. Sistemas distintos,

como por exemplo, folha de pagamento, contas a pagar e a receber, controle de

estoque, dentre outros, se integraram, formando softwarede sistema de informaesadministrativas, que acessam um ou mais banco de dados que contm informaes

comerciais, facilitando as operaes comerciais e as tomadas de decises

administrativas.

Portanto, torna-se evidente as vantagens de sistemas informatizados para o

controle de gerenciamento de qualquer atividade comercial, como por exemplo,

reduo de custos, acesso rpido s informaes, garantia de integridade e

veracidade da informao, alm de garantia de segurana de acesso informao eeliminao da redundncia de dados (SOMMERVILLE, 2003).


11/72

10

O descontrole do estoque gera muitos prejuzos para as empresas de

atividade comercial, visto que as mesmas podem perder oportunidades de venda por

no terem acesso rpido a dados do seu estoque. Alm disso, a falta de um rigoroso

controle financeiro pode levar a falncia da empresa.

A falta de gerncia das informaes no Bazar do Sagrado Corao de Jesus

gera vrios problemas, como: descontrole de estoque, dos usurios do sistema, dos

artesos e de caixa.

O controle de mercadorias em estoque demorado e impreciso, no havendo

controle de tempo de permanncia das mercadorias no bazar, culminando no

acmulo de estoque por mercadorias encalhadas e no h um controle financeiro

do bazar, gerando atraso no pagamento dos artesos, falta de informao de quemvendeu o qu e inexistncia de informaes financeiras para tomada de decises,

como por exemplo, compra de algum item necessrio ao bazar.

Um sistema informatizado proporcionar ao bazar maior agilidade e preciso

no controle de estoque, controle total de entrada e sada de dinheiro, de usurios do

sistema e das mercadorias vendidas pelos mesmos, dos artesos e das mercadorias

entregues por eles e um estoque mais selecionado (controle de tempo de

permanncia das mercadorias no bazar).Torna-se ento necessrio o desenvolvimento de um sistema que armazene

de forma confivel, informaes dos produtos, usurios e artesos do Bazar do

Sagrado Corao de Jesus, fornecendo, sempre que necessrio, relatrios

financeiros e de estoque.

1.1 Objetivo do Trabalho

Projetar e implementar um sistema para controle de vendas e estoque do

Bazar do Sagrado Corao de Jesus SCVE-BSCJ, o qual gerenciar todo o

funcionamento do bazar para obter informaes detalhadas, de forma rpida e

segura, sobre cada produto, usurio e arteso, alm de quantidade de produtos em

estoque, tempo de permanncia dos mesmos, valores devidos aos artesos e valorem caixa.


12/72

11

Os fatos apresentados neste trabalho so reais, porm os nomes so fictcios

para preservar a Entidade.

1.2 Etapas desenvolvidas

A primeira etapa desenvolvida foi o levantamento do sistema utilizado pelo

Bazar do Sagrado Corao de Jesus, dos problemas encontrados no mesmo e a

identificao das necessidades do cliente, obtidos por meio de informaes

coletadas em entrevista e reunies com o cliente.

Definiu-se ento, os objetivos e escopo do projeto, que permitiu a escolha do

modelo de processo de desenvolvimento de software que melhor se aplicasse ao

SCVE-BSCJ. Para isso foram estudados e analisados alguns modelos.

Em seguida, foi utilizada a Anlise Estruturada de Sistema para modelar os

requisitos do usurio, por meio do DFD - Diagrama de Fluxo de Dados e DER

Diagrama Entidade-Relacionamento.

Iniciou-se, ento, a programao do prottipo do Sistema SCVE-BSCJ, comaplicao de testes a cada nova funcionalidade implementada. Somente se passava

implementao de uma nova funcionalidade, aps todos os testes terem sido

efetuados com sucesso.

Em paralelo a todas estas atividades, foi redigida a presente monografia.

1.3 Estrutura do Trabalho

Este trabalho est dividido em 7 Captulos, a saber:

Captulo 1 - Introduo: Apresenta uma viso geral de todo o trabalho;

Captulo 2 - Contextualizao do Sistema: Expe o sistema atual de

gerenciamento do Bazar do Sagrado Corao de Jesus e a proposta deste

trabalho;


13/72

12

Captulo 3 - Ferramentas Utilizadas: Explica as ferramentas utilizadas no

desenvolvimento do trabalho;

Captulo 4 - Modelo de Processo de Desenvolvimento de Software:

Apresenta, detalhadamente, o ciclo de vida adotado no desenvolvimento

do Sistema SCVE-BSCJ;

Captulo 5 - Modelagem do Sistema SCVE-BSCJ: Descreve o estudo de

caso realizado;

Captulo 6 - Prottipo do Sistema: Apresenta o prottipo do Sistema

SCVE-BSCJ;

Captulo 7 - Concluses e Consideraes Finais: Concluso do

Trabalho.


14/72

13

2 CONTEXTUALIZAO DO SISTEMA

Para uma melhor compreenso da proposta deste trabalho, neste captulo

apresentado o modelo atual de controle de vendas e estoque, utilizado pelo Bazar

do Sagrado Corao de Jesus.

2.1 Descrio do modelo atual

O Bazar do Sagrado Corao de Jesus um comrcio sem fins lucrativos.

Seu principal objetivo a comercializao de peas confeccionadas por artesos e

integrantes de projetos sociais da cidade de Jesus de Nazar, com o intuito de

auxili-los na divulgao e venda de seus trabalhos. Os artesos cadastrados em

projetos sociais do municpio recebem integralmente o valor oriundo de suas vendas,

enquanto que os demais artesos revertem 10% do valor de suas vendas para a

manuteno do bazar.

Os funcionrios do bazar so voluntrios, ou seja, no recebem nenhuma

remunerao por seus servios e, geralmente, trabalham se revezando no horrio da

manh e da tarde.

H uma grande diversidade de produtos, com variados preos, porque cada

arteso define o valor de suas mercadorias, podendo haver o mesmo tipo de produto

oriundo do mesmo arteso, mas com preos diferentes. Para este controle so

confeccionadas etiquetas manualmente, com identificao da mercadoria e doarteso e o preo do produto.

Quando o arteso deixa seus produtos preenchido um recibo em uma

planilha do Excel, com a discriminao das mercadorias, quantidades e valores das

mesmas. O recibo emitido em duas vias, que so assinadas pelo arteso e pelo

funcionrio receptor. O arteso recebe uma via e a outra fica no bazar para controle

do mesmo.

Ao vender um produto, o funcionrio preenche uma outra planilha para acertofinanceiro do arteso. Esta planilha separada por arteso, sendo uma para cada


15/72

14

arteso. Ao encerrar o ms, feito o fechamento das planilhas de acerto financeiro,

para se obter o valor devido a cada arteso e o valor de repasse ao bazar. Estas

planilhas servem de recibo de pagamento de artesos e tambm so emitidas em

duas vias, as quais so assinadas e datadas pelos artesos no momento do acerto.

O bazar possui uma ficha de cadastro de cada arteso com seus dados

pessoais, bem como o registro no Departamento de Cultura do municpio,

denominado PAT.SUTACO. Esta ficha preenchida manualmente e arquivada em

uma gaveta, em ordem alfabtica.

Quando h necessidade de saber a quantidade exata de determinado

produto, realizada a contagem manual do mesmo e quando chega um cliente

perguntando se h determinado produto no bazar, o funcionrio precisa procurarpara descobrir.

No mantido nenhum cadastro de funcionrios do bazar. Somente h o

nmero do telefone dos mesmos anotados em um caderno.

2.2 Proposta

O Sistema para controle de vendas e estoque do Bazar do Sagrado Corao

de Jesus SCVE-BSCJ visa informatizar todas as rotinas do bazar que,

atualmente, so realizadas de forma manual, conforme exposto a seguir.

Ser implementado um cadastro de todos os funcionrios, denominados

usurios do sistema, dos artesos e das mercadorias deixadas pelos mesmos,

denominadas produtos.

Para acessar o sistema ser necessrio que o usurio se identifique por meio

de seu logine senha. Sem a validao do usurio no ser possvel o acesso ao

mesmo. Outra funcionalidade a ser permitida a alterao de senha, desde que

haja primeiro a validao do usurio.

A entrada de mercadorias ser feita atravs de um formulrio de entrada de

produtos, onde o usurio preencher todos os dados das mercadorias deixadas e,

para cada mercadoria, um cdigo ser gerado automaticamente pelo sistema. Este

cdigo servir para identificao da mesma. Outro requisito a identificao do


16/72

15

usurio que realizou a entrada do produto, pois em caso de dvida, haver como

esclarec-la.

Ao cadastrar a entrada do produto, o estoque ser automaticamente

atualizado. Ao final, ser possvel imprimir o recibo de entrega de mercadorias e as

etiquetas dos produtos.

As vendas sero cadastradas no sistema por meio de um formulrio de

vendas, dando baixa automaticamente no produto e buscando o arteso que o

forneceu para clculo de seu pagamento e do repasse ao bazar.

Por meio do menu principal, podero ser emitidos relatrios financeiros dirios

ou mensais.

O estoque tambm poder ser consultado a qualquer momento, assim comoo valor devido aos artesos e o valor de repasse ao bazar. Caso seja necessrio,

podero ser emitidos relatrios de acompanhamento, como por exemplo, relatrios

de valor de repasse ao bazar ou aos artesos, por perodos determinados pelo

usurio.

O sistema prover, ainda, um controle de tempo de permanncia de produtos

no estoque. No final de cada ms ser possvel imprimir a relao de produtos a

serem devolvidos; neste caso, o sistema calcular e imprimir a relao dosprodutos que esto, h mais de trs meses, no bazar.

O Captulo 5 apresenta o Documento de Requisitos e Modelagem propostos

para o sistema SCVE-BSCJ.


17/72

16

3 FERRAMENTAS UTILIZADAS

Neste Captulo sero apresentadas as ferramentas utilizadas para

desenvolver o Sistema SCVE-BSCJ.

3.1 Delphi

Delphi no uma linguagem de programao, mas um ambiente de

desenvolvimento integrado(MANZANO, 2006).

O ambiente de programao Delphi baseado na linguagem de

programao Object Pascal, oriunda da linguagem Pascal, a qual foi projetada pelo

Professor Niklaus Wirth (MANZANO, 2006, p. 19).

O Delphi um Integrated Development Environment (IDE) ou Ambiente de

Desenvolvimento Integrado (MANZANO, 2006), ou seja, um ambiente de suporte

que permite a programao visual: as telas podem ser montadas facilmente,

simplesmente com o clicar e arrastar de componentes aos formulrios, sendo

possvel compilar o projeto na linguagem Object Pascale gerar o prottipo desejado.

Segundo Silva; Paula (2007, p. 20), o IDE do Delphi possui uma estrutura de

fcil compreenso, possibilitando que at mesmo os programadores iniciantes

desenvolvam seus projetos sem muitas dificuldades.

Este IDE foi criado pela Borlandcomo uma ferramenta de programao Rapid

Application Development (RAD), isto , Desenvolvimento Rpido de Aplicaes. muito verstil, podendo ser aplicado para pequenas, mdias ou grandes

aplicaes, suportando criao de softwares multi-plataforma (Windows e Linux),

sistemas multicamadas, aplicaes para a Internet e para o ambiente cliente-

servidor e tem propsito geral, permitindo desenvolvimento de aplicaes tanto

cientficas como comerciais. Por todos esses motivos, muitas empresas em

diversos segmentos do mercado utilizam o Delphi como ferramenta de solues de

desenvolvimento de sistemas corporativos (SILVA; PAULA, 2007, p. 13).


18/72

17

De acordo com Silva; Paula (2007, p. 19), o Delphi 7 possui vrias edies

com caractersticas particulares, conforme segue:

Personal uma edio para programadores eventuais e no possui

suporte nem para banco de dados nem para outras caractersticasavanadas do Delphi.Professional Studio Esta edio para desenvolvedores profissionais epossui todas as ferramentas bsicas para trabalhar com banco de dados,programao para web e algumas das ferramentas externas, comoModelMaker e IntraWeb.Enterprise Studio uma edio para o desenvolvimento de aplicativoscorporativos. Para isso, conta com ferramentas para XML avanadastecnologias para Web, e muitas outras ferramentas.Architect Studio Esta edio amplia o suporte da edio Enterprise aoBold, um ambiente para construir aplicaes com modelo UML ecapacidade de mapear seus objetos tanto na base de dados quanto nainterface com o usurio.

Alm de possuir vrias edies, o ambiente do Delphi pode ser personalizado

de acordo com as necessidades do desenvolvedor.

A estrutura de uma aplicao Delphi muito simples. Conforme Garcia (2005,

p. 16), uma aplicao desenvolvida em Delphi consiste em um arquivo de projeto,

composto por um ou mais forms (formulrios) e units. Os forms so elementos

visuais para a criao de uma interface entre a aplicao e o usurio e as unitsso

arquivos de programa-fonte. Todo formulrio, obrigatoriamente, tem uma unit

correspondente, porm nem toda unit corresponde a um formulrio. Existem

aplicaes que possuem apenas units, denominadas console application. Um

exemplo da estrutura de uma aplicao Delphi apresentado na Figura 3.1.

Figura 3.1- Aplicao estruturada em DelphiGARCIA (2005, p. 19)

Project 1

(arquivo de projeto)

extenso .DPR

(Delphi Project)

Form 1

extenso .DFM

(Delphi Form)

Form 2

extenso .DFM

Unit 3

extenso .PAS

Unit 2

extenso .PASUnit 1

extenso .PAS

(PAScal)


19/72

18

O Delphi possui dois nveis de programao: nvel de designem que utiliza

recursos de programao visual e aproveita componentes prontos e o nvel de

component writer em que o desenvolvedor elabora os componentes a serem

utilizados pelos programadores que trabalham no nvel design(GARCIA, 2005).

Em 2002, a Borland lanou a verso 7 do IDE Delphi, com novos recursos

voltados para aplicaes para Internet como a Intraweb, e Rave Reports para a

criao de relatrios, entre outros (MANZANO, 2006). A Figura 3.2 apresenta a tela

inicial do Delphi verso 7.

Conforme os componentes vo sendo selecionados, o Delphi escreve o

cdigo fonte. Os componentes, em geral, incluem classes e propriedades muito

utilizadas, que se relacionam com outros objetos (GARCIA, 2005). Alm disso, oDelphi possui um amplo suporte para trabalho com banco de dados Paradox, dBase,

Access, MySQL, Oracle, Firebird, entre outros (SILVA; PAULA, 2007, p. 83).

Figura 3.2 - Tela inicial do Delphi verso 7BORLAND(2002)


20/72

19

3.2 Access

Nem todos os sistemas baseados em computador fazem uso de um banco

de dados, mas, para todos que o fazem, essa modalidade de armazenamento de

informaes freqentemente de grande importncia para a funo global

(PRESSMAN, 1995, p. 197). Por esse motivo, assim que o domnio da informao

definido, aplicada uma disciplina tcnica denominada engenharia de banco de

dados (database engineering), que abrange a anlise, projeto e criao de banco de

dados. O engenheiro de sistemas deve definir as informaes a serem contidas no

banco de dados, os tipos de queries a serem submetidos a processamento, a

maneira pela qual os dados sero acessados e a capacidade do banco de dados

(PRESSMAN, 1995, p. 197).

De acordo com Silva; Paula (2007, p. 83), a utilizao de banco de dados

essencial para o desenvolvimento de aplicativos comerciais. As principais

vantagens do banco de dados so reduo ou eliminao de redundncias,

eliminao de inconsistncias, rapidez e eficincia na recuperao e manipulao de

dados, compartilhamento de dados, restries de segurana, padronizao eindependncia dos dados e manuteno de integridade (DATE, 2004).

Por ser um projeto pequeno, que exige rapidez de desenvolvimento, a

implementao do Banco de Dados (DATE, 2004) ser feita no MSAccess -

Microsoft Office Access2003 (MICROSOFT, 2009), que permite o desenvolvimento

rpido de aplicaes que envolvem a modelagem e estrutura de dados. Apesar de

ser um banco de dados proprietrio, ou seja, pago, sua principal vantagem consiste

no fato do desenvolvimento da estrutura de dados ser de forma intuitiva, nonecessitando que o desenvolvedor tenha conhecimentos avanados em modelagem

de dados e lgica de programao.

O MSAccess um sistema relacional de administrao de banco de dados da

Microsoft, includo no pacote do Microsoft Office Professional, que disponibiliza a

linguagem de programao Microsoft VisualBasic for Application.

No MSAccess, os bancos de dados consistem em quatro objetos principais:


21/72

20

a) Tabelas: responsvel por armazenar dados em linhas e colunas. Cada

assunto principal deve constituir uma tabela individual, portanto os bancos de dados

podem conter uma ou mais tabelas;

b) Consultas: recuperam e processam dados, podendo combinar dados de

diferentes tabelas, atualizar dados e executar clculos com base nesses dados;

c) Formulrios: controlam a entrada e as exibies de dados, fornecendo uma

interface amigvel como se fosse um formulrio de papel, mas com utilizao de

mouse e teclado para entrada de dados. Conforme os dados so inseridos nos

formulrios, os mesmos so salvos na devida tabela;

d) Relatrios: fazem o resumo e a impresso de dados, transformando os

dados de tabelas e consultas em documentos destinados comunicao de idias.Os formatos dos relatrios podem ser salvos para que tenham sempre a mesma

aparncia, mesmo que os dados sejam alterados.

Para manipular as informaes armazenadas no MSAccesse tambm no IDE

Delphi utilizada a linguagem SQL (Structured Query Language) ou, Linguagem

de Consulta Estruturada, que se estabeleceu como linguagem padro de banco de

dados e utiliza vrios comandos para manipular estas informaes, como o comando

Createpara criao do banco de dados e das tabelas, o comando Open para abrir obanco de dados ou as tabelas antes do incio das atividades com os mesmos, o

comando Insertpara inserir novos registros na tabela, o comando Deletepara excluir

registro de uma tabela, o comando Updatepara alterar valores das colunas de uma

tabela e o comando Select que seleciona um grupo de registros de uma ou mais

tabelas, sendo um dos principais recursos desta linguagem (SILVA; PAULA, 2007).

Os bancos de dados criados pelo MSAccess so relacionais, ou seja, os

dados armazenados em vrias tabelas separadas de acordo com o assunto ou atarefa esto relacionados, podendo ser reunidos da maneira que for especificado

(MICROSOFT, 2009).

A Figura 3.3 ilustra a tela inicial do MSAccess2003.


22/72

21

Figura 3.3 - Tela inicial do Microsoft Office Access2003MICROSOFT(2003)

3.3 BDE Administrator

O BDE (Borland Database Engine) um mecanismo fornecido pelo Delphi

para acessar banco de dados locais por meio de driversODBC (CANTU, 2006). Foi

construdo com o objetivo de unificar a conectividade de banco de dados, atravs da

abstrao de toda a funcionalidade de um banco de dados dentro de um engine,

facilitando, por exemplo, a atualizao do acesso a banco de dados, pois no

necessria a atualizao de um pacote de software inteiro. Alm disso, economiza

espao em disco e garante que o cdigo de acesso ao banco de dados seja escrito

apenas uma vez (UNITRI, 2009).

Com o recurso do BDE no necessrio conhecimento prvio paradesenvolvimento de aplicativos de bancos de dados em Delphi e nem os usurios


23/72

22

destes aplicativos precisam ter esse conhecimento. A instalao e a execuo deste

recurso so de forma automtica no Delphi (SILVA; PAULA, 2007).

Os drivers padres do BDE Administrator so Paradox, dBASE, FoxPro e

ASCII text, alm de incluir tambm um driverpara o Microsoft Access. Outros drivers

so instalados separadamente. Para abrir ou criar tabelas do Microsoft Accessbasta

utilizar o driver MSAccessdo BDE Administrator(BDE, 1998).

Para facilitar o trabalho com banco de dados o BDE utiliza o conceito de alias

(apelido) (SILVA; PAULA, 2007, p. 103), que funciona como um apontador para o

caminho especificado, conectando os componentes do Delphi com as tabelas fsicas

do banco de dados e permitindo, inclusive, que as tabelas possam ser colocadas

em outro diretrio, sem que seja necessrio alterar o seu caminho em todos oscomponentes da aplicao (SILVA; PAULA, 2007, p. 103), bastando que o caminho

seja alterado no BDE Administrator . A Figura 3.4 apresenta a tela inicial do BDE

Administrator.

Figura 3.4 - Tela inicial do BDE AdministratorBDE (1998)


24/72

23

3.4 Case Studio

CASEsignifica computer-aided software engineering, ou seja, engenharia de

softwarecom o auxlio de computador (SOMMERVILLE, 2003). Ferramentas CASE

so vrios programas utilizados para apoiar as atividades de processo de software,

desde a fase inicial (quando pode ser chamada de ferramenta Upper-CASE), como

anlise de requisitos, at a fase final (quando pode ser chamada de ferramenta

Lower-CASE), como depurao e testes. So freqentemente utilizados para

proporcionar apoio aos mtodos. Podem tambm incluir um gerador de cdigos que,

automaticamente, origina cdigo-fonte a partir do modelo de sistema e alguma

orientao de processo, que fornece conselhos ao engenheiro de softwaresobre o

que fazer em seguida (SOMMERVILLE, 2003).

Pressman (1995) deixa claro que o verdadeiro poder do CASEs pode ser

obtido quando as vrias ferramentas so integradas. Entre os vrios benefcios

incluem-se transferncia harmoniosa de informaes de uma ferramenta para outra

e de uma etapa da engenharia de softwarepara a seguinte, aumento no controle do

projeto, obtido por meio de um melhor planejamento, monitorao e comunicao ecoordenao melhorada entre os membros de uma equipe que esteja trabalhando

num grande projeto de software(PRESSMAN, 1995). Para essa integrao, faz-se

uso do repositrio CASE, que um banco de dados que armazena todas as

informaes de engenharia de software. Alm das funes bvias de um sistema de

gerenciamento de banco de dados, o repositrio tambm realiza a integridade de

dados (valida entradas, garante consistncia entre objetos relacionados e executa

automaticamente modificaes em cascata), compartilhamento de informaes(entre mltiplos desenvolvedores e entre mltiplas ferramentas), integrao dados-

ferramenta, integrao dados-dados, imposio metodolgica (atravs de um

paradigma especfico para a engenharia de software) e padronizao de

documentos (criando definies para os objetos do banco de dados).

Existem diversas ferramentas CASE a disposio, cada uma abordando

aspectos diferentes de desenvolvimento de software, por exemplo, diagramas

propostos pela Anlise Estruturada ou Orientada a Objetos, Requisitos, ModeloEntidade Relacionamento, dentre outros. Algumas so comercializadas e outras no.


25/72

24

Exemplos de ferramentas so Case Studio, Case Design Studio, IBDataWorks,

argoUML, Visual-Paradigm, Dia, JudeCommunity, ErWin, dentre outros.

Neste trabalho ser utilizada a ferramenta Case Studio (CASE, 2006) por

possuir todos os diagramas necessrios ao desenvolvimento de softwareproposto

pela Anlise Estruturada de Sistemas, ser uma ferramenta leve, rpida, de fcil

utilizao e muito didtica.

Uma caracterstica muito importante desta ferramenta a engenharia reversa,

com gerao de scriptscom muitas opes de configurao, entre elas scriptspara

tabelas, chaves primrias, ndices, triggers e restries referenciais, o que facilita

muito quando no h documentao do sistema pronto.

O Case Studio 2 trabalha somente com Anlise Estruturada de Sistemas edisponibiliza os seguintes diagramas: Diagrama Entidade-Relacionamento (DER) e

Diagrama de Fluxo de Dados (DFD), que so elaborados de forma visual e

interativa. O projeto pode ser visualizado em mdulos ou de maneira global e

tambm podem ser visualizadas as entidades fsicas ou lgicas, todos os atributos

ou somente as chaves.

Case Studio uma ferramenta CASE compatvel com vrios bancos de

dados: Access2000, Access97, Advantage7, Clipper 5, DBIsam 3.23, DB2 UDBver. 8.1, DB2 UDB ver. 7, Firebird 1.5, Informix 9, Informix, Ingres, InterBase 7,

InterBase 6 SQL 3, InterBase 6 SQL 1, InterBase 5, InterBase 4, MaxDB, MS SQL

2000, MS SQL 7, MS SQL 6.5, MySQL 4.0, MySQL 3.23, Oracle 10g, Oracle 9i,

Oracle 8, Paradox, Pervasive V8, PostgreSQL 7.4, PostgreSQL 7.3, PostgreSQL 7,

Sybase Anywhere, Sybase ASE 12.5, Sybase ASE 12.5.1.

Os principais recursos da ferramenta Case Studio 2 so: implementao

automtica dos principais relacionamentos, bom controle de usurio e segurana,podendo ser feito controle, at mesmo, de qual operao determinado usurio pode

fazer em determinada entidade e, controle de versionamento, com comparativo entre

as diferentes verses.

Os documentos principais de anlise so gerados em dois formatos: html e rtf.

A Figura 3.5 mostra um projeto visualizado em mdulos no Case Studio2.


26/72

25

Figura 3.5- Case Studio2 com projeto visualizado em mdulosCASE(2006)


27/72

26

4 MODELO DE PROCESSO DE DESENVOLVIMENTO DE

SOFTWAREUTILIZADO

O objetivo deste captulo definir Modelo de Processo de Desenvolvimento

de Software e apresentar o modelo Extreme Programming (XP) adotado para o

desenvolvimento do Sistema SCVE-BSCJ.

4.1 Definio de Modelo de Processo de Desenvolvimento de

Software

Para que possa ser entendido o que Modelo de Processo de

Desenvolvimento de Software necessrio, primeiramente, ter uma viso bem

definida do conceito de Software. Segundo Sommerville (2003), software no

apenas o programa, mas tambm toda a documentao associada, que descreve a

estrutura do sistema de software e documentao do usurio, que explica como

utilizar o sistema e os dados de configurao necessrios para fazer com que esses

programas operem corretamente.

Engenharia de Software a disciplina que se ocupa de todos os aspectos da

produo de software, desde os estgios iniciais de especificao do sistema at a

manuteno desse sistema, depois que ele entrou em operao (SOMMERVILLE,

2003). A Engenharia de Software no se limita aos processos tcnicos de

desenvolvimento de software, mas envolve todo o gerenciamento de projetos de

softwaree o desenvolvimento de ferramentas, mtodos e teorias que dem apoio

produo de software, com a finalidade de produzir softwarede alta qualidade, com

uma boa relao custo-benefcio.

De acordo com Sommerville (2003), Processo de Desenvolvimento de

Software um conjunto de atividades e resultados associados que geram um

produto de software. conhecido tambm como Ciclo de Vida de um Software.

Portanto, Modelo de Processo de Desenvolvimento de Software pode ser

definido como uma sugesto de seqncia de atividades a ser seguida, como uma


28/72

27

receita, para a obteno do sistema de software; fruto de estudos e experincias no

desenvolvimento de software. Sua principal importncia auxiliar e conduzir o

desenvolvedor nas etapas a serem seguidas para produzir um sistema de software

de alta qualidade.

H uma diversidade muito grande de Modelos de Processo de

Desenvolvimento de Software. Na literatura so encontrados vrios modelos como

Madaw(NOGUEIRA; FERRETI, 2005), Rational Unified Process(RUP) (RATIONAL,

2009), Baseado em Usabilidade (MARTINEZ, 2003), Prototipao (PRESSMAN,

1995; SOMMERVILLE, 2003), Extreme Programming (XP) (BECK, 1999), dentre

outros. A escolha de um ou de outro depende do domnio da aplicao, ou ainda, a

empresa tambm pode optar por desenvolver um modelo prprio, de acordo comsua realidade.

Para o desenvolvimento do Sistema SCVE-BSCJ foi adotado o modelo de

processo de desenvolvimento XP por ser um processo leve, centrado no

desenvolvimento iterativo (entre desenvolvedor e cliente) e com a entrega constante

de pequenas verses (releases) do software, atendendo perfeitamente s

perspectivas do cliente (BECK, 1999). Na seo 4.2 apresentado esse modelo em

detalhes.

4.2 Extreme Programming(XP)

Introduzido por Kent Beck e Ward Cunningham por volta de 1996, ideal para

desenvolvimento rpido de projetos com requisitos vagos e freqentes mudanas deescopo (BECK, 1999; CANTU, 2006).

Faz parte de uma famlia de processos de desenvolvimento de software

denominada Metodologia Agile, que visa desenvolver softwares de qualidade, no

menor tempo possvel, atendendo as necessidades do cliente e respondendo com

rapidez s mudanas nas especificaes dos projetos (KUHN; PAMPLONA, 2009).

Prega a idia de releases curtos, ou seja, o cliente recebe, assim que

possvel, pequenas verses para anlise.


29/72

28

As verses devem ser incrementadas com a melhoria constante do cdigo,

denominada re-trabalho, mesmo que o cdigo esteja funcionando perfeitamente.

Estas mudanas no cdigo devem ser encaradas com naturalidade, visto que

o XP assume que os requisitos do sistema mudam constantemente, sem que isso

seja culpa do cliente.

Tem por base a presena do cliente junto aos desenvolvedores. Ele acaba

por se tornar um membro da equipe de desenvolvimento, reavaliando a verso

recebida e realimentando a equipe com suas principais necessidades e prioridades e

recebendo da equipe informaes como riscos, estimativas e alternativas de design.

Com isso, criado um elo de parceria e confiana mtua, dispensando muitos

documentos formais e dando liberdade de negociao de atrasos ou outrasnecessidades, quando necessrio.

O XP norteado por quatro dimenses (BECK, 1999):

Simplicidade: a equipe deve modelar e documentar apenas quando

extremamente necessrio e deve implementar da forma mais simples

possvel as necessidades do cliente para que ele possa aprender durante

o projeto e consiga dar o feedback necessrio. O desenvolvedor deve

implementar apenas o necessrio para atender o pedido do cliente,agilizando o processo e satisfazendo o cliente.

Comunicao: os desenvolvedores e o cliente devem estar em constante

comunicao.

Coragem: preciso ter coragem para admitir problemas, pedir auxlio

quando necessrio, alterar algo j pronto, dizer ao cliente que haver

atraso no prazo, enfim, fazer o que correto, independente das reaes

(BONA, 2002). Feedback: quanto mais cedo se descobrir o problema, mais cedo ser

corrigido.

Ao invs de ser organizado de forma rigorosa, em processos burocrticos, o

desenvolvimento baseado em 12 prticas simples, a saber (BONA, 2002;

EXTREME, 2009):

Histrias do Usurio (user stories): as funcionalidades do sistema so

descritas em histrias pelo prprio cliente com suas palavras e da formamais simples possvel. Estas histrias substituem os longos documentos


30/72

29

de requisitos nos mtodos tradicionais e cada histria deve ser descrita

em aproximadamente trs sentenas.

Plano de Entregas (Release Planning): aps a definio das histrias

necessrio estimar o tempo de implementao das mesmas para que o

cliente priorize o que deve ser implementado. realizada uma reunio

para o planejamento de entregas (cronograma de cada histria). A idia

que um projeto possa ser quantificado em quatro variveis: escopo,

recursos, tempo e qualidade, sendo as regras do negcio (escopo,

prioridade, composio das verses e datas das verses) estimadas pelo

cliente e as consideraes tcnicas (tempo, riscos tcnicos e processo)

estimadas pelos tcnicos. A Figura 4.1 ilustra um modelo de Carto deHistria.

Figura 4.1 Modelo de Carto de Histria no XP

BONA (2002, p. 42)

Pequenas Verses (Small Releases): nas reunies de planejamento so

definidas as funcionalidades do sistema que sero implementadas a cada

iterao de desenvolvimento para que o cliente possa se beneficiar do

sistema. A entrega de cada releaseno deve ultrapassar o prazo de dois

meses. Quanto mais rpido se introduzir uma funcionalidade no sistema,

maior ser o tempo para consert-la, caso seja necessrio.

Iteraes (Iterations): a diviso dos releasesem espaos menores parareduzir o tempo para o feedback com o cliente, pois dois meses um


31/72

30

tempo longo demais para este feedback. Cada iterao contm um

conjunto de histrias a serem implementadas, podendo durar de uma a

trs semanas, tendo ao final a avaliao do cliente. A equipe recebe

orientaes atravs de cartes de tarefas, cujo modelo ilustrado na

Figura 4.2.

Figura 4.2 Modelo de Carto de Tarefa no XPBONA (2002, p. 43)

Plano de Iterao (Iteration Planning): no incio de cada iterao feita

uma reunio para que o cliente possa definir quais histrias sero

implementadas, priorizando as que possuem maior valor para o mesmo.

Reunies Rpidas (Stand-Up Meetings): cada dia de trabalho da equipe

iniciada com uma rpida reunio (aproximadamente 20 minutos) para

comunicar problemas, solues e decidir as histrias que sero

implementadas no dia e, em conjunto, definir os responsveis por cadauma delas. Estas reunies devem ser feitas, preferencialmente, com todos

os integrantes em p para evitar conversas paralelas e fazer os

integrantes irem direto ao assunto, agilizando e simplificando a reunio.

Conserte o XP (FixXP): quando o processo falhar, o mesmo deve ser

corrigido. As regras do XP devem ser seguidas, mas no se deve hesitar

em alterar o que no funcionar.

Solues Rpidas (Spike Solutions): para resolver problemas difceis

devem ser criadas solues rpidas. Programas simples devem ser


32/72

31

criados para explorar solues em potencial, reduzindo o risco de um

problema.

Reestruturao (Refactor): mesmo que o cdigo esteja funcionando

perfeitamente, deve-se reestrutur-lo sempre, removendo redundncias,

eliminando funcionalidades no utilizadas e modificando arquiteturas

obsoletas. Todo desenvolvedor deve promover esta reestruturao,

deixando o cdigo mais legvel e simples sem, no entanto, alterar o

comportamento do mesmo.

Programao em Pares (Pair Programming): a implementao de

qualquer cdigo deve ser feita em dupla, denominada de programao em

par. Dois desenvolvedores trabalham no mesmo problema, ao mesmotempo e no mesmo computador. Um deles o responsvel pela

codificao (condutor), geralmente o novato. O outro, mais experiente,

acompanha o trabalho do parceiro (navegador), revisando o cdigo

digitado, ajudando o outro a desenvolver suas habilidades, percebendo

erros de programao que poderiam levar horas para serem depurados e

cobrando padres de desenvolvimento da equipe. Alm disso, h uma

troca de experincias e idias entre os dois, facilitando na busca desolues para possveis problemas. Os papis e os pares so trocados

freqentemente, permitindo que toda equipe conhea e possa alterar o

cdigo. Esta rotatividade do cdigo representa sua propriedade coletiva,

encorajando toda a equipe a colaborar com novas idias. Qualquer

membro da equipe pode adicionar funcionalidades, corrigir erros ou

reestruturar o cdigo. Todos so responsveis pelo cdigo inteiro. As

codificaes devem seguir padres pr-estabelecidos pela equipe paraque todos possam entend-las.

Semana de trabalho de 40 horas: o XP prega o ritmo sustentvel da

equipe, proibindo que os desenvolvedores trabalhem at mais tarde,

respeitando suas condies fsicas e psicolgicas e garantindo a

concentrao da equipe, para reduzir pequenas falhas na implementao.

Testes: o XP utiliza dois tipos de testes: o Teste Unitrio e o Teste de

Aceitao. Teste Unitrio (Unit Test): Todo cdigo testado atravs de scripts

de teste automatizado que so desenvolvidos pelos prprios


33/72

32

desenvolvedores antes da codificao e servem para a validao do

cdigo. Estes testes devem ser automatizados para que possam ser

executados rapidamente e rodem constantemente, garantindo que o

cdigo tenha as funcionalidades esperadas. Somente os cdigos

testados podem ser integrados ao sistema.

Se um erro for encontrado, novos testes devem ser criados, garantindo

que o erro no passe novamente pelo antigo teste unitrio.

Os testes unitrios so a fonte de coragem para que o desenvolvedor

realize a fatorao, removendo duplicaes e tornando o cdigo mais

flexvel e legvel.

Testes de Aceitao (Acceptance Tests): cada teste de aceitao elaborado pelo cliente para verificar uma funcionalidade descrita numa

histria do usurio. Sempre que houver uma nova integrao devem

ser rodados. So escritos no momento da escrita da histria, devendo

haver pelo menos um teste de aceitao para cada histria. A histria

s declarada terminada quando passar por todos os testes de

aceitao.

4.2.1 Mecanismo de Desenvolvimento no XP

A Figura 4.3 ilustra o mecanismo do Modelo XP, cujo ciclo de vida

compreende as fases de explorao, planejamento, iterao, produo, manuteno

e fim do projeto (BONA, 2002).

Figura 4.3 Ciclo de vida nos projetos XPSANTOS; DAHER (2008, p. 6)

Nova User Story


34/72

33

Explorao

Esta fase iniciada com as regras do negcio e tem como objetivo o bom

entendimento do que o sistema deve fazer para que possa ser estimado. O cliente

escreve as histrias e o programador as estima, encerrando-se esta fase quando

todas as histrias necessrias para a prxima fase tiverem sido estimadas.

Enquanto os clientes vo escrevendo as histrias, os programadores vo

experimentando diferentes tecnologias e configuraes, explorando possibilidades

para a arquitetura do sistema (BONA, 2002).

Planejamento

A melhor maneira de executar esta fase utilizando o Jogo do Planejamento.

O cliente prioriza as histrias e definida a menor data e o maior nmero dehistrias que faro parte desta primeira verso, de acordo com estimativas entre

clientes e programadores. Para auxiliar esta fase, alguns passos podem ser

seguidos:

O cliente seleciona as histrias por valor, enquanto que os programadores

as qualificam por risco: alto, mdio ou baixo;

Os programadores declaram a velocidade, calculada empiricamente,

baseada na experincia dos mesmos; Clientes escolhem o escopo: as histrias que faro parte da prxima

verso.

As histrias do cliente so quebradas em pequenas tarefas e definidos quais

programadores iro trabalhar em cada tarefa. As histrias que sero trabalhadas so

decididas pela equipe no primeiro dia de cada iterao. As tarefas so selecionadas

e pontuadas em dias pelos programadores.

IteraoConforme Beck, 2000 apud Bona (2002), os compromissos so divididos

para serem executados em iteraes que duram de uma a quatro semanas. So

produzidos testes funcionais para cada histria executada naquela iterao.

O desenvolvimento conduzido por uma seqncia de ciclos iterativos,

concentrando o projeto, a codificao, os testes e as verses do produto. Ao final de

cada iterao, o cliente completa todos os testes funcionais, sendo que no final da

ltima iterao, o sistema estar pronto para a fase de produo.


35/72

34

Produo

No final de uma verso, d-se a produo do sistema. Podendo ser

implementados novos testes para provar a estabilidade do sistema ou serem

realizados ajustes no desempenho.

Manuteno

Um projeto XP est constantemente em fase de manuteno, pois

simultaneamente a produo de novas funcionalidades, deve-se manter o sistema

existente rodando, substituir membros da equipe e incorporar novos membros.

Esta a fase que pode-se tentar refactoringsmaiores, que causaram receio

de serem tentados nas verses anteriores. Pode-se testar novas tecnologias ou

migrar a tecnologia em uso para verses mais atualizadas. O cliente pode escrevernovas histrias que melhorem o seu negcio.

Fim do projeto

O momento de finalizar o projeto quando o cliente est satisfeito com o

sistema e no consegue mais escrever histrias.

Sugere-se ento que sejam escritas algumas pginas (de 5 a 10) sobre a

funcionalidade do sistema, para auxiliar futuras alteraes no sistema.

Toda a equipe deve se reunir para uma reavaliao, aproveitando paraanalisar os pontos positivos e negativos do projeto.

4.2.2 Papis

Desenvolvido para equipes pequenas e mdias (BECK, 1999), alguns papis

so fundamentais no XP como programador, cliente, treinador e supervisor, sendo

que outros papis podem ser exercidos pela mesma pessoa, como por exemplo,gerente e supervisor.

O programador responsvel por estimar prazos, definir os cartes de tarefas

a partir dos cartes de histrias, estimar os cartes de tarefas, implementar testes

unitrios, implementar o cdigo de produo, trabalhar em par, fazer refactoring

sempre que necessrio, estar em contato direto com o cliente para feedbacks.

Outro papel essencial o do cliente. Alm de pagar pelo projeto, ele deve

estar disposto a aprender, pois o responsvel por definir os requisitos do sistema,escrever os cartes de histria, definir as prioridades das histrias, validar e definir

os testes funcionais e esclarecer dvidas sempre que solicitado.


36/72

35

O papel do testador em XP aplicar os testes. Sua responsabilidade definir

com o cliente os testes funcionais do projeto, escrev-los, execut-los e publicar os

resultados dos mesmos para a equipe.

O supervisor responsvel por coletar as mtricas do projeto uma ou duas

vezes por semana, manter todos informados do que est acontecendo e tomar

atitudes sempre que as coisas parecerem ir mal.

A funo do treinador garantir que o projeto permanea extremo, ajudar

com o que for necessrio, manter a viso do projeto, no deixando que o time se

desvie do processo, formular e comunicar uma tarefa que um programador queira

trabalhar.

Por fim, ao gerente cabe transmitir coragem, confiana e saber cobrar o que de responsabilidade de cada um. Seu trabalho consiste em gerenciar a equipe e

seus problemas, agendar reunies de planejamento, garantir que as mesmas fluam

como planejado, documentar o que foi definido nas reunies, manter o supervisor

informado dos acontecimentos das reunies e buscar recursos.

Tendo por base que o XP defende que no se deve criar um grande volume

de documentos ou diagramas que podem ficar desatualizados. Uma vez que, o

objetivo ganhar tempo para ir mais rpido (BONA, 2002, p. 59), no prximocaptulo ser apresentada a modelagem do sistema SCVE-BSCJ.


37/72

36

5 MODELAGEM DO SISTEMA SCVE-BSCJ

Este captulo apresenta a modelagem do Sistema SCVE-BSCJ, bem como o

conjunto de prticas empregadas, tendo como base o Modelo de Processo de

Desenvolvimento XP.

5.1 Viso do Sistema

Em um contexto inicial (fase de Explorao), a estratgia proposta pelo XP

consiste em elaborar, em poucas linhas, os objetivos do sistema, para que o mesmo

possa ser estimado. Para isso, fundamental o entendimento do sistema conforme

a viso do cliente.

Neste contexto, foram levantadas, por meio de reunies rpidas, todas as

histrias do usurio, conforme pode ser observado na seo 5.1.3. Eventualmente,

alguma histria foi adicionada ou removida, conforme os requisitos foram sendoesclarecidos. Ressalta-se que um carto de histria apenas um lembrete de uma

conversa com cliente (ASTELS, 2002 apud BONA, 2002), no contendo todos os

detalhes necessrios codificao do comportamento. Para isso, foram necessrias

conversas diretas com o cliente, pessoalmente ou por meio de telefonemas.

Em paralelo as histrias dos clientes, foram exploradas as possibilidades para

a arquitetura do sistema.

Na fase de planejamento foi especificado o projeto, as iteraes e o dia-a-dia,com o objetivo de estimar o menor tempo possvel e o maior nmero de histrias

para a primeira verso. A estimativa foi elaborada com base nos cartes de histrias

e em solues simples, lembrando que o projeto poderia ser replanejado, caso

alguma alterao significativa fosse identificada pelo cliente ou pelos

desenvolvedores.


38/72

37

5.1.1 Composio e tarefas da equipe

A equipe foi composta pelo cliente que definiu os requisitos, fixou as

prioridades e guiou o projeto, pela dupla de programadores que tambm ajudaram o

cliente a definir os testes de aceitao e os requisitos e pelo gerente que provia

recursos e mantinha a comunicao externa, alm de coordenar as atividades. Os

papis no foram exclusivamente de propriedade de um s indivduo, sendo que

todos os membros da equipe colaboraram de todas as formas que puderam, de

acordo com suas habilidades.

5.1.2 Escopo do Produto

O Sistema SCVE-BSCJ tem por objetivo controlar as vendas e o estoque do

Bazar do Sagrado Corao de Jesus, mantendo um cadastro de todos os usurios

do sistema, dos artesos que fornecem os produtos ao bazar e dos produtos

fornecidos pelos mesmos.

A entrada de produtos, bem como a venda dos mesmos, atualiza

automaticamente tanto o estoque de produtos quanto os valores devidos ao artesoe ao bazar, mantendo a integridade dos dados.

Para auxiliar na tomada de decises, relatrios financeiros, de estoque e de

cadastros atualizados podem ser obtidos a qualquer momento por meio do menu

principal.

Todos os usurios do sistema possuem os mesmos acessos, no havendo

nenhum tipo de restrio ou privilgio.

5.1.3 Histrias do usurio

Nesta seo so apresentadas as histrias do usurio. Para facilitar a

visualizao, elas foram organizadas no formato de tabela, conforme pode ser

observado na Tabela 5.1.


39/72

38

Tabela 5.1 Cartes de histria resumidos

N Histria Descrio Prioridade

001 Cadastrar os dados dos usurios do sistema atravs de formulrios. Alta

002 Cadastrar os dados dos artesos (fornecedores) do bazar atravs deformulrios. Alta

003 Cadastrar os produtos que so vendidos no bazar atravs deformulrios.

Alta

004Validar os usurios que tero acesso ao sistema, impedindo quepessoas estranhas tenham acesso ao mesmo. Alta

005Realizar entrada de produtos fornecidos pelos artesos, cujos preospodem variar de produto para produto bem como o mesmo artesoter dois produtos iguais com preos diferentes.

Alta

006 Realizar devoluo de produtos aos artesos. Mdia

007 Realizar venda de produtos. Alta

008 Gerar clculo de repasse do valor das vendas ao arteso. Mdia

009 Disponibilizar formulrio para entradas/sadas de dinheiro do bazar. Mdia

010 Disponibilizar formulrio para pagamento dos artesos. Mdia

011 Imprimir relatrios de controle de estoque. Mdia

012 Imprimir relatrios de produtos com permanncia no bazar maior quetrs meses. Mdia

013 Imprimir relatrios da situao financeira do bazar por perodo. Mdia

014 Imprimir relatrios de repasse ao bazar por perodo. Baixa

015 Imprimir relatrios de cadastro de usurios, artesos e produtos. Baixa

016 Imprimir relatrios de movimentao financeira. Mdia017 Imprimir relatrios de vendas. Mdia

018 Imprimir etiquetas de produtos. Baixa

5.1.4 Estimativa, priorizao e planejamento

Aps o relato das histrias, o cliente as classificou por prioridade, sendo

definido: alta (mxima urgncia), mdia (necessrias, mas poderiam aguardar por

algum tempo) e baixa (interessantes aps a concluso de outras histrias), comotambm pode ser observado na Tabela 5.1.

Com base nestas informaes, a equipe de programao estimou as histrias

em semanas, sendo que cada histria no poderia ultrapassar trs semanas, pois

histrias menores tendem a ter risco menor (WAKE, 2002 apud BONA, 2002, p.52),

alm de permitir a implementao de um conjunto de histrias (as de maior

prioridade) a cada iterao. Caso a estimativa da histria ultrapassasse o prazo, ela

deveria retornar ao cliente para que fosse dividida em histrias menores.


40/72

39

Ainda, foram planejadas as iteraes, total de 4, como pode ser verificado na

Tabela 5.2, alm da estimativa e priorizao. O planejamento das iteraes foi de

suma importncia, pois cada iterao possua as funcionalidades de maior prioridade

para o cliente, agilizando a entrega do sistema ao cliente e permitindo sua avaliao

e feedback, pois o mesmo pde perceber detalhes no previstos inicialmente.

Tabela 5.2 Cartes de histria com prioridades, estimativa e interaes

NHistria

Descrio Prioridade Estimativa Iterao

001Cadastrar os dados dos usurios do sistemaatravs de formulrios.

Alta semana 1

002Cadastrar os dados dos artesos(fornecedores) do bazar atravs deformulrios.

Alta semana 1

003Cadastrar os produtos que so vendidos nobazar atravs de formulrios. Alta semana 1

004Validar os usurios que tero acesso aosistema, impedindo que pessoas estranhastenham acesso ao mesmo.

Alta 1 semana 1

005

Realizar entrada de produtos fornecidospelos artesos, cujos preos podem variarde produto para produto bem como o mesmoarteso ter dois produtos iguais com preosdiferentes.

Alta 1 semanas 2

006 Realizar devoluo de produtos aosartesos.

Mdia 1 semana 3

007 Realizar venda de produtos. Alta 2 semanas 2

008Gerar clculo de repasse do valor dasvendas ao arteso. Mdia 1 semana 3

009 Disponibilizar formulrio paraentradas/sadas de dinheiro do bazar.

Mdia 1 semana 3

010Disponibilizar formulrio para pagamento dosartesos.

Mdia 1 semana 4

011 Imprimir relatrios de controle de estoque. Mdia semana 4012 Imprimir relatrios de produtos compermanncia no bazar maior que trs meses. Mdia 1 semana 4

013Imprimir relatrios da situao financeira dobazar por perodo.

Mdia semana 4

014Imprimir relatrios de repasse ao bazar porperodo.

Baixa semana 4

015Imprimir relatrios de cadastro de usurios,artesos e produtos. Baixa 1 semana 1

016 Imprimir relatrios de movimentaofinanceira.

Mdia 1 semana 3

017 Imprimir relatrios de vendas. Mdia semana 2

018 Imprimir etiquetas de produtos. Baixa semana 4


41/72

40

Observado que os cartes de histria formavam a funcionalidade bsica do

sistema, optou-se por desenvolver a primeira verso do sistema, que foram seguidas

por outras verses para aperfeioamento e complemento de recursos.

5.1.5 Funes do Produto

A soluo proposta para o SCVE-BSCJ consiste em uma srie de mdulos

que trabalham de forma integrada para fornecer as seguintes funcionalidades:

Gerenciar Usurio;

Gerenciar Arteso;

Gerenciar Produto; Gerenciar Movimentao de Produto;

Gerenciar Movimentao Financeira;

Gerenciar Relatrio.

As funcionalidades afins foram agrupadas em mdulos denominados

genericamente por gerenciar. Por exemplo, funcionalidades como o cadastro,

excluso, alterao e consultas relacionadas ao usurio sero agrupadas no mdulo

Gerenciar Usurio.Com base nas histrias dos usurios, para cada mdulo, foram definidos os

requisitos funcionais e no funcionais, os quais seguem a regra:

Requisitos Funcionais possuem o identificador [RFabc]; onde a, b,c

so dgitos que variam entre 0 e 9.

Requisitos No-Funcionais possuem o identificador [RNFabc]; onde a,

b, c so dgitos que variam entre 0 e 9, RNF significa Requisito No

Funcional.No que se refere prioridade dos requisitos foram mantidas as

denominaes sugeridas pelos usurios.

A Tabela 5.3 apresenta os requisitos funcionais e a Tabela 5.4 os requisitos

no funcionais. Ambas foram organizadas pelos mdulos definidos.


42/72

41

Tabela 5.3 Requisitos Funcionais

Gerenciar Usurio

Requisito Descrio Prioridade Iterao

RF001 Cadastrar Usurio O sistema deve permitir ainsero de um usurio. Os itensde informao so cdigo paraidentificar o usurio, nome,endereo, bairro, cidade, CEP,telefones, celular, RG, CPF, logine senha.

Alta 1

RF002 Atualizar dados doUsurio

O sistema deve permitir aalterao dos dados do usurio,com exceo do cdigo queidentifica o usurio.

Alta 1

RF003 Excluir Usurio O sistema deve prover

mecanismos para permitir aexcluso de um determinadousurio.

Alta 1

RF004 Validar Usurio O sistema deve permitir avalidao do usurio para acessos funcionalidades do sistema.

Alta 1

RF005 Localizar Usurio O sistema deve permitir a procurarpida dos dados cadastrais deum determinado usurio atravsde seu nome.

Alta 1

Gerenciar Arteso


RF006 Cadastrar Arteso O sistema deve permitir ainsero de um arteso. Os itensde informao so cdigo paraidentificar o arteso, nome,endereo, bairro, cidade, CEP,telefones, celular, RG, CPF,PAT.SUTACO, e-mail e se elerepassa ou no 10% decontribuio ao bazar, alm docdigo do usurio que ocadastrou.

Alta 1

RF007 Atualizar Dados doArteso

O sistema deve permitir aalterao dos dados do arteso,com exceo do cdigo queidentifica o arteso.

Alta 1

RF008 Excluir Arteso O sistema deve provermecanismos para permitir aexcluso de um determinadoarteso.

Alta 1

RF009 Localizar Arteso O sistema deve permitir a procurarpida dos dados cadastrais deum determinado arteso atravs

de seu nome.

Alta 1


43/72

42

Tabela 5.3 Requisitos FuncionaisGerenciar Produto


RF010 Cadastrar Produto O sistema deve permitir ainsero de um produto. Os itensde informao so cdigo paraidentificar o produto, descrio equantidade.

Alta 1

RF011 Atualizar Dados doProduto

O sistema deve permitir aalterao dos dados do produto,com exceo do cdigo queidentifica o produto.

Alta 1

RF012 Excluir Produto O sistema deve provermecanismos para permitir aexcluso de um determinado

produto.

Alta 1

RF013 Localizar Produto O sistema deve permitir a procurarpida dos dados cadastrais deum determinado produto atravsde seu nome.

Alta 1

Gerenciar Movimentao de Produto


RF014 Inserir Item Fornecido O sistema deve permitir a entradade produtos fornecidos pelosartesos. Os itens de informaoso cdigo para identificar o item

fornecido, data do fornecimento,cdigo do produto, cdigo doarteso que forneceu o produto,cdigo do usurio que recebeu oproduto, descrio do itemfornecido, valor unitrio equantidade fornecida.Automaticamente, ao ser inseridoum produto, deve ser atualizadoo estoque.

Alta 2

RF015 Atualizar Dados doFornecimento do Produto

O sistema deve permitir aalterao dos dados dos produtos

fornecidos, com exceo docdigo que identifica o itemfornecido. Caso seja alterada aquantidade do produto fornecido,bem como o cdigo do produto, osistema deve fazer as alteraesnecessrias no estoque.

Alta 2

RF016 Excluir Item Fornecido O sistema deve provermecanismos para permitir aexcluso de um determinadoproduto, atualizando ao mesmotempo o estoque.

Alta 2

RF017 Localizar Item Fornecido O sistema deve permitir a procurarpida dos dados cadastrais deum determinado produtofornecido atravs de seu cdigo.

Alta 2


44/72


45/72

44

Tabela 5.3 Requisitos Funcionais - ConclusoGerenciar Relatrio


RF025 Emitir Relatrio deEstoque

O sistema deve permitir aemisso de relatrio de estoque.Os itens de informao socdigo do produto, descrio equantidade.

Mdia 4

RF026 Emitir Relatrio de ItensFornecidos a Devolver

O sistema deve permitir aemisso de relatrio de itensfornecidos h mais de trsmeses.

Mdia 4

RF027 Emitir Relatrio de Caixa O sistema deve permitir aemisso de relatrio do caixa pordia determinado pelo usurio.

Mdia 3

RF028 Emitir Relatrio deRepasse ao Bazar

O sistema deve permitir aemisso de relatrio de repasseao bazar por perododeterminado pelo usurio.

Baixa 4

RF029 Emitir Relatrios deCadastro de Artesos, Produtos eUsurios

O sistema deve permitir aemisso de relatrios contendoos dados cadastrais dosartesos, produtos e usurios.

Alta 1

RF030 Emitir Relatrios deMovimentao Financeira

O sistema deve permitir aemisso de relatrios contendotodas as receitas e despesas dedeterminado perodo selecionadopelo usurio.

Mdia 3

RF031 Emitir Relatrios deVendas

O sistema deve permitir aemisso de relatrios contendocdigo, data e usurioresponsvel pela venda.

Mdia 2

Tabela 5.4 Requisitos no FuncionaisRequisito Descrio Prioridade

RNF001 BDE Administrator O sistema necessita que se tenha o BDEAdministratorinstalado na mquina.

Alta

RNF002 Sistema OperacionalWindows

necessrio ter o sistema operacionalWindowsXP ou superior na mquina ondeo sistema ser instalado.

Alta

RNF003 Banco de DadosMSAccess

O MSAccess2000 ou superior deve estarinstalado na mquina.

Alta

RNF004 Programa WinRar necessrio ter o programa WinRarinstalado na mquina.

Alta

RNF005 - Hardware Configurao mnima:

Computador Pentium 4 2,79 GHz ousemelhante

1 Gb de memria RAM

150 Mb de espao livre em discoUnidade de CD-ROM ou USB

Alta


46/72

45

Para melhor visualizao dos processos envolvidos nos mdulos, optou-se

pela utilizao do Diagrama de Fluxo de Dados.

O Diagrama de Fluxo de Dados (DFD) um diagrama grfico, utilizado na

Anlise Estruturada de Sistemas, para mostrar a estrutura de um sistema e todas as

relaes entre os dados, os processos transformadores desses dados e o limite

entre o que pertence ao sistema e o que est fora dele (UNESC, 2009). O Diagrama

ilustrado na Figura 5.1 mostra as funcionalidades do sistema sem muitos

detalhamentos, que so obtidos conforme aumenta-se o nmero de nveis do DFD.

Figura 5.1 Diagrama de Fluxo de Dados do Sistema SCVE-BSCJ


47/72

46

Por se tratar de um processo mais complexo, optou-se, tambm, por

apresentar a decomposio do processo denominado Processar Vendas, conforme

Figura 5.2.

Figura 5.2 Decomposio do Processo: Processar Vendas

Para demonstrar em detalhes as funcionalidades contidas nos mdulosdenominados Gerenciar, apresenta-se a Figura 5.3 que ilustra o Mdulo Gerenciar

Usurios.

Figura 5.3 Decomposio do Processo: Gerenciar Usurios


48/72

47

O Diagrama Entidade-Relacionamento (DER), demonstrado na Figura 5.4, foi

adotado para expressar graficamente toda a estrutura lgica do banco de dados

(MENESES, 2009) do Sistema SCVE-BSCJ. Por motivo de melhor estruturao

deste trabalho, foram ocultados os atributos no DER apresentado na Figura 5.4, os

quais so apresentados na Figura 5.5 juntamente com as definies de chaves

primrias. A Figura 5.5 ilustra o Esquema Relacional, obtido com a ferramenta Case

Studio, voltado para a anlise estruturada de sistemas.

Enquanto o DFD enfatiza as funes do sistema, o DER descreve cada

depsito de dados do DFD e o relacionamento entre eles.

Figura 5.4 Diagrama Entidade-Relacionamento do Sistema SCVE-BSCJ


49/72

48

Figura 5.5 Esquema Relacional do Sistema SCVE-BSCJ

5.1.6 Testes de Aceitao

Da mesma forma que os programadores realizaram os testes no sistema -

teste estrutural e funcional (BONA, 2002), tambm foram realizados os testes de

aceitao pelo cliente. Percebidas algumas inconsistncias, estas foram

prontamente corrigidas pelos programadores. Os testes de aceitao foramrealizados por mdulos disponibilizados ao cliente.


50/72

49

5.1.7 Fim do projeto

Aps a fase de produo, quando foi desenvolvido o Sistema SCVE-BSCJ,

visto que o cliente deu-se por satisfeito, no havendo mais nenhuma histria a

acrescentar, encerrou-se o projeto com a produo da documentao, contendo os

diagramas ilustrados nas Figuras 5.1 5.4, os cartes de histrias do usurio, cujos

resumos so apresentados na Tabela 5.1 e os requisitos funcionais apresentados na

Tabela 5.3 e os requisitos no funcionais apresentados na Tabela 5.4.

No prximo captulo apresentado o prottipo do Sistema SCVE-BSCJ obtido

partir dos diagramas ilustrados neste captulo.


51/72

50

6 PROTTIPO DO SISTEMA

Este captulo tem por objetivo apresentar o prottipo do Sistema SCVE-BSCJ,

explicando cada uma de suas funcionalidades.

Foram implementados os seguintes mdulos:

Gerenciar Usurios;

Gerenciar Artesos;

Gerenciar Produtos;

Validao de Usurios;

Gerenciar Movimentao de Produtos;

Gerenciar Movimentao Financeira;

Gerenciar Relatrios.

O prottipo descrito neste captulo obedecendo seqncia cronolgica de

sua estrutura arquitetural.

6.1 Apresentao do Prottipo do Sistema

Ao acessar o Sistema SCVE-BSCJ, exibida a tela de abertura ilustrada na

Figura 6.1. necessrio o logine a senha do usurio para que, aps autenticados,

possam liberar o acesso s outras funcionalidades. O boto OK apresenta o

formulrio principal, conforme mostra a Figura 6.3, e o boto Alterar Senha permite

ao usurio alterar sua prpria senha, por meio do formulrio apresentado na Figura

6.2.


52/72

51

Figura 6.1 Tela de Abertura do SCVE-BSCJ

Figura 6.2 Alterar Senha

O acesso ao Sistema SCVE-BSCJ idntico para todos os usurios, no

sendo, portanto, necessrio um gerenciamento de acesso. A Figura 6.3, mostra a

tela de Menu Principal, onde o usurio far a seleo das opes desejadas.


53/72

52

Figura 6.3 Menu Principal

As figuras a seguir sero mostradas na sequncia em que aparecem no Menu

Principal. O mdulo Cadastro apresenta os formulrios de Cadastro de Artesos

(Figura 6.4), Cadastro de Produtos (Figura 6.5) e Cadastro de Usurios (Figura 6.6),

bem como as respectivas relaes (Figura 6.7, Figura 6.8 e Figura 6.9).

Pode-se notar pelas figuras ilustradas, que os formulrios de Cadastro de

Artesos (Figura 6.4), Cadastro de Produtos (Figura 6.5) e Cadastro de Usurios

(Figura 6.6) contm os botes necessrios para se movimentar pelas tabelas

Artesos, Produtos e Usurios (botes Anterior, Prximo, Primeiro e ltimo) e para

acessar todas as funcionalidades destas tabelas (botes Inserir, Alterar, Excluir,

Gravar, Imprimir e Procurar).


54/72

53

Figura 6.4 Cadastro de Artesos

Figura 6.5 Cadastro de Produtos


55/72

54

Figura 6.6 Cadastro de Usurios

Figura 6.7 Lista de Artesos


56/72

55

Figura 6.8 Lista de Produtos

Figura 6.9 Lista de Usurios

No mdulo Movimentao, o usurio pode optar pela Movimentao

Financeira, onde possvel realizar movimentaes financeiras como Despesas

(Figura 6.10) e Receitas (Figura 6.11), Fechamento do Caixa Dirio (Figura 6.12),

Pagamento ao Arteso (Figura 6.13) e Vendas do Bazar (Figura 6.15), que abre o

formulrio Itens de Venda (Figura 6.16), ou optar pela Movimentao de Produtos,

onde possvel realizar as transaes com produtos, seja Entrada de Produtos

(Figura 6.17), que imprime inclusive o Recibo de Entrega de Produtos (Figura 6.18)

ou Devoluo de Produtos (Figura 6.19), que imprime o Recibo de Devoluo de

Produtos (Figura 6.20).


57/72

56

Ao fazer o Fechamento do Caixa Dirio, o saldo obtido automaticamente

lanado na Tabela Fechamento como saldo anterior no dia seguinte. Assim como,

ao efetivar uma Venda, alm de atualizar a Tabela Receita, tambm dado baixa na

quantidade do produto em estoque e calculado os valores de repasse ao Bazar e

ao Arteso, para posterior pagamento.

No Formulrio de Pagamento ao Arteso (Figura 6.13), alm de selecionar o

arteso e o perodo desejado, possvel visualizar o relatrio (Figura 6.14), por meio

do boto Relatrio, ou efetivar o pagamento, pelo boto Pagamento.

Ao movimentar produtos, seja entrada ou devoluo, a quantidade de

produtos em estoque automaticamente atualizada, assim como a tabela que

controla os itens fornecidos, mantendo a integridade dos dados tanto do estoquequanto dos itens fornecidos pelos artesos.

Figura 6.10 Formulrio de Despesas do Bazar

Figura 6.11 Formulrio de Receitas do Bazar


58/72

57

Figura 6.12 Formulrio de Fechamento do Caixa Dirio

Figura 6.13 Formulrio de Pagamento ao Arteso


59/72

58

Figura 6.14 Recibo de Pagamento ao Arteso

Figura 6.15 Formulrio de Vendas


60/72

59

Figura 6.16 Formulrio de Itens de Venda

Figura 6.17 Formulrio de Entrada de Produtos


61/72

60

Figura 6.18 Recibo de Entrega de Produtos

Figura 6.19 Formulrio de Devoluo de Produtos


62/72

61

Figura 6.20 Recibo de Devoluo de Produtos

O mdulo Relatrios permite visualizar e imprimir relatrios de Estoque, seja

para controle de permanncia dos produtos em estoque (Figura 6.21) ou para

simples conferncia (Figura 6.22), relatrios Financeiros, como Relatrio de Caixa

Dirio (Figura 6.23) e Resumo Mensal de Fluxo de Caixa (Figura 6.24), que mostraum Resumo do Movimento do Caixa no ms determinado pelo usurio e, por fim,

Relatrio de Repasse ao Bazar (Figura 6.25) pelo perodo determinado pelo usurio.

Figura 6.21 Relatrio de Produtos com tempo de permanncia vencido


63/72

62

Figura 6.22 Relatrio de Produtos em Estoque

Figura 6.23 Relatrio de Caixa Dirio


64/72

63

Figura 6.24 Resumo Mensal de Fluxo de Caixa

Figura 6.25 Relatrio de Repasse ao Bazar

No ltimo mdulo, denominado Ajuda, pode-se realizar a rotina de Backupdo

banco de dados selecionando-se o diretrio de destino no Formulrio de Backup

(Figura 6.26), acessar o Manual de Orientao ao Usurio, cuja capa pode servisualizada na Figura 6.27 e podem ser obtidas informaes sobre o sistema, como


65/72

64

verso, desenvolvedor e base de dados, conforme pode ser observado na Figura

6.28.

Figura 6.26 Formulrio de Backup

Figura 6.27 Capa do Manual de Orientao ao Usurio


66/72

65

Figura 6.28 Formulrio de Informaes do Sistema


67/72

66

7 CONCLUSES E CONSIDERAES FINAIS

Os softwares so utilizados para gerar solues e agregar facilidades para

todas as empresas, sejam elas de pequeno, mdio ou grande porte, com ou sem fins

lucrativos, criando comodidades para seus usurios nas mais diferentes reas:

educao, lazer, comercial, dentre outras.

O sistema SCVE-BSCJ foi criado para atender a pequena empresa, sem fins

lucrativos, denominada, neste trabalho, Bazar do Sagrado Corao de Jesus,

auxiliando-a no conhecimento e controle de seus estoques e de seus movimentos

financeiros.

O desenvolvimento deste sistema permitiu a participao na construo de

um softwareem todas as suas fases, desde o levantamento de requisitos at a fase

de testes, garantindo a aplicao prtica do que foi aprendido, de forma terica, no

perodo acadmico.

Um fator importante foi a possibilidade de trabalhar em equipe, habilidade

muito exigida no mercado de trabalho para qualquer rea, mas principalmente na

rea de informtica, onde necessrio relacionar-se com clientes e usurios, deforma a extrair deles os requisitos necessrios para se obter um software de

qualidade.

O Bazar do Sagrado Corao de Jesus, antes do sistema desenvolvido,

utilizava planilhas de Excel e fichas de papel para realizar, precariamente, seus

controles de estoque e cadastros, o que gerava um grande acmulo de papis a

serem arquivados, alm de dados distorcidos da realidade e inexistncia de um

controle da movimentao financeira do bazar.Com o sistema desenvolvido, todos os controles realizados em planilhas e

fichas de papel foram transformados para serem realizados por computador,

facilitando tanto a organizao quanto agilidade e preciso de dados para realizar

cadastros, gerar relatrios, verificar situao de estoque e financeira e outras opes

oferecidas pelo sistema. Em resumo, o sistema traz facilidades tanto para o bazar

quanto para os clientes.


68/72

67

Como trabalho futuro, prope-se a reestruturao deste software, para que

possa ser utilizado em rede e a adio de novas funcionalidades, como controle de

contas a pagar e a receber e controle de estoque mnimo e mximo, para que possa

ser utilizado por empresas comerciais de fins lucrativos. Sugere-se, tambm, a

implementao de funcionalidades, como impresso de etiquetas com cdigo de

barras e relatrios de fluxo de caixa, que no foram implementadas no prottipo

apresentado.


69/72

68

REFERNCIAS BIBLIOGRFICAS

BDE Administrator. Version5.01. [S.I]:Inprise Corporation, 1998. Parte do produto

Borland Delphi Enterprise. 1 CD-ROM.

BECK, Kent. Extreme Programming Explained: Embrace Change. Boston:Addison Wesley, 1999. Prvia do livro disponvel em:. Acesso em: 10 ago. 2009s 16:40h.

BONA, Cristina. Avaliao de processos de software: Um estudo de caso em XPe Iconix. Dissertao (Mestrado em Engenharia de Produo), Ps-Graduao emEngenharia de Produo, Universidade Federal de Santa Catarina, Florianpolis,SC, 2002. Disponvel em: .Acesso em: 12 ago. 2009 s 16:36h.

BORLANDDelphi Enterprise. Version7.0 [S.I]: Borland Software Corporation, 2002.1 CD-ROM.

CANT

Sistema Vendas e Estoque

Documents

Transcript of Sistema Vendas e Estoque