FACULDADE DE PINDAMONHANGABA

Raquel Aparecida Marcondes de Souza

SISTEMA PARA CONTROLE DE VENDAS E ESTOQUE

Pindamonhangaba - SP 2009

Raquel Aparecida Marcondes de Souza

SISTEMA PARA CONTROLE DE VENDAS E ESTOQUE

Monografia apresentada como parte dos requisitos para obteno do Diploma de Bacharel em Sistemas de Informao pelo Curso de Bacharelado em Sistemas da Informao da Faculdade de Pindamonhangaba. Prof. MSc. Alindacir Maria Dalla Vecchia Grassi Prof. Brbara Alessandra Gonalves Pinheiro Yamada

Pindamonhangaba - SP 2009

RAQUEL APARECIDA MARCONDES DE SOUZA SISTEMA PARA CONTROLE DE VENDAS E ESTOQUE

Monografia apresentada como parte dos requisitos para obteno do Diploma de Bacharel em Sistemas de Informao pelo Curso de Bacharelado em Sistemas da Informao da Faculdade de Pindamonhangaba.

Data: ______________________ Resultado: __________________

BANCA EXAMINADORA

Prof. _______________________________ Faculdade de Pindamonhangaba Assinatura __________________________

Prof. _______________________________ Faculdade de Pindamonhangaba Assinatura __________________________

Prof. _______________________________ ___________________________ Assinatura __________________________

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.

RESUMO

Atualmente, a maior parte das empresas comerciais, desde as micro empresas at as grandes redes, possuem um sistema de software para gerenciar todas as suas atividades. Neste sentido, este trabalho apresenta um prottipo para gerenciamento de vendas e estoque de uma pequena empresa comercial, sem fins lucrativos: o Bazar do Sagrado Corao de Jesus. A inexistncia de um sistema informatizado para esse gerenciamento pode gerar muitas inconsistncias e redundncia de dados, alm de atrasos para se obter informaes importantes para a tomada de decises e at mesmo a falncia de empresas. O objetivo informatizar o gerenciamento das principais atividades de uma empresa comercial, provendo com as informaes armazenadas, condies para um controle financeiro e de estoque mais gil, preciso e verdico. O sistema abrange funcionalidades como Gesto de Acesso, Gesto de Cadastro, Gesto de Movimentao Financeira e de Estoque e Gesto de Relatrios, as quais foram modeladas nos diagramas de Fluxo de Dados e Entidade-Relacionamento, disponibilizados na ferramenta Case Studio. O sistema foi implementado na linguagem Object Pascal por meio do IDE Delphi 7, com programao estruturada.

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

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 work aims in demonstrating a prototype to companies for managing their sales and stocks for a non-profit company called The Bazar do Sagrado Corao de Jesus. The lack of 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 main activities in this company, providing it with the information stored, a financial control and faster, accurate and reliable stock. The system includes features such as Access Management, Management of Registration, Financial Transactions Management, Stock Reports Management. It was modeled in Data Flow and Entity-Relationship Diagrams, available in Case Studio tool. The system has been implemented in Object Pascal using the Delphi 7 IDE with structured programming. Keywords: Agility. Stock. Management. Software. Sales.

LISTA DE TABELAS

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

LISTA DE FIGURAS

Figura 3.1- Aplicao estruturada em Delphi ......................................................................17 Figura 3.2 - Tela inicial do Delphi verso 7..........................................................................18 Figura 3.3 - Tela inicial do Microsoft Office Access 2003 ....................................................21 Figura 3.4 - Tela inicial do BDE Administrator ....................................................................22 Figura 3.5- Case Studio 2 com projeto visualizado em mdulos ........................................25 Figura 4.1 Modelo de Carto de Histria no XP ..............................................................29 Figura 4.2 Modelo de Carto de Tarefa no XP.................................................................30 Figura 4.3 Ciclo de vida nos projetos XP ..........................................................................32 Figura 5.1 Diagrama de Fluxo de Dados do Sistema SCVE-BSCJ .................................45 Figura 5.2 Decomposio do Processo: Processar Vendas ..............................................46 Figura 5.3 Decomposio do Processo: Gerenciar Usurios ...........................................46 Figura 5.4 Diagrama Entidade-Relacionamento do Sistema SCVE-BSCJ ....................47 Figura 5.5 Esquema Relacional do Sistema SCVE-BSCJ ...............................................48 Figura 6.1 Tela de Abertura do SCVE-BSCJ ...................................................................51 Figura 6.2 Alterar Senha.....................................................................................................51 Figura 6.3 Menu Principal ..................................................................................................52 Figura 6.4 Cadastro de Artesos ........................................................................................53 Figura 6.5 Cadastro de Produtos .......................................................................................53 Figura 6.6 Cadastro de Usurios ........................................................................................54 Figura 6.7 Lista de Artesos ...............................................................................................54 Figura 6.8 Lista de Produtos ..............................................................................................55 Figura 6.9 Lista de Usurios ...............................................................................................55 Figura 6.10 Formulrio de Despesas do Bazar .................................................................56 Figura 6.11 Formulrio de Receitas do Bazar ..................................................................56 Figura 6.12 Formulrio de Fechamento do Caixa Dirio ................................................57 Figura 6.13 Formulrio de Pagamento ao Arteso ..........................................................57 Figura 6.14 Recibo de Pagamento ao Arteso ..................................................................58 Figura 6.15 Formulrio de Vendas ....................................................................................58 Figura 6.16 Formulrio de Itens de Venda .......................................................................59 Figura 6.17 Formulrio de Entrada de Produtos .............................................................59 Figura 6.18 Recibo de Entrega de Produtos......................................................................60 Figura 6.19 Formulrio de Devoluo de Produtos..........................................................60 Figura 6.20 Recibo de Devoluo de Produtos..................................................................61 Figura 6.21 Relatrio de Produtos com tempo de permanncia vencido .......................61 Figura 6.22 Relatrio de Produtos em Estoque ................................................................62 Figura 6.23 Relatrio de Caixa Dirio ...............................................................................62 Figura 6.24 Resumo Mensal de Fluxo de Caixa................................................................63 Figura 6.25 Relatrio de Repasse ao Bazar.......................................................................63 Figura 6.26 Formulrio de Backup ....................................................................................64 Figura 6.27 Capa do Manual de Orientao ao Usurio .................................................64 Figura 6.28 Formulrio de Informaes do Sistema ........................................................65

SUMRIO

1 INTRODUO .........................................................................................................9 1.1 Objetivo do Trabalho .....................................................................................10 1.2 Etapas desenvolvidas ...................................................................................11 1.3 Estrutura do Trabalho ...................................................................................11 2 CONTEXTUALIZAO DO SISTEMA ..................................................................13 2.1 Descrio do modelo atual ...........................................................................13 2.2 Proposta .........................................................................................................14 3 FERRAMENTAS UTILIZADAS ..............................................................................16 3.1 Delphi..............................................................................................................16 3.2 Access ............................................................................................................19 3.3 BDE Administrator .........................................................................................21 3.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 .......26 4.2 Extreme Programming (XP) ..........................................................................27 4.2.1 Mecanismo de Desenvolvimento no XP ...................................................32 5 MODELAGEM DO SISTEMA SCVE-BSCJ ...........................................................36 5.1 Viso do Sistema ...........................................................................................36 5.1.1 Composio e tarefas da equipe ...............................................................37 5.1.2 Escopo do Produto.....................................................................................37 5.1.3 Histrias do usurio ...................................................................................37 5.1.4 Estimativa, priorizao e planejamento....................................................38 5.1.5 Funes do Produto ...................................................................................40 5.1.6 Testes de Aceitao ...................................................................................48 5.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

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 software de 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 software so utilizados em todos os lugares e setores, desde equipamentos 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 software de sistema de informaes administrativas, 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 e eliminao da redundncia de dados (SOMMERVILLE, 2003).

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 quem vendeu 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 valor em caixa.

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, com aplicao 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;

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.

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 do arteso 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 acerto financeiro do arteso. Esta planilha separada por arteso, sendo uma para cada

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 procurar para 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 login e 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

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 como o 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 dos produtos 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.

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 Pascal e 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 Borland como 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 clienteservidor 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).

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 caractersticas avanadas do Delphi. Professional Studio Esta edio para desenvolvedores profissionais e possui todas as ferramentas bsicas para trabalhar com banco de dados, programao para web e algumas das ferramentas externas, como ModelMaker e IntraWeb. Enterprise Studio uma edio para o desenvolvimento de aplicativos corporativos. Para isso, conta com ferramentas para XML avanadas tecnologias para Web, e muitas outras ferramentas. Architect Studio Esta edio amplia o suporte da edio Enterprise ao Bold, um ambiente para construir aplicaes com modelo UML e capacidade de mapear seus objetos tanto na base de dados quanto na interface 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 units so 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.
Project 1 (arquivo de projeto) extenso .DPR (Delphi Project)

Form 1 extenso .DFM (Delphi Form)

Form 2 extenso .DFM

Unit 3 extenso .PAS

Unit 1 extenso .PAS (PAScal)

Unit 2 extenso .PAS

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

18

O Delphi possui dois nveis de programao: nvel de design em 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, o Delphi 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 7 BORLAND (2002)

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 e independncia 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 Access 2003 (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, no necessitando 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 Visual Basic for Application. No MSAccess, os bancos de dados consistem em quatro objetos principais:

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 MSAccess e 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 Create para criao do banco de dados e das tabelas, o comando Open para abrir o banco de dados ou as tabelas antes do incio das atividades com os mesmos, o comando Insert para inserir novos registros na tabela, o comando Delete para excluir registro de uma tabela, o comando Update para 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 a tarefa esto relacionados, podendo ser reunidos da maneira que for especificado (MICROSOFT, 2009). A Figura 3.3 ilustra a tela inicial do MSAccess 2003.

21

Figura 3.3 - Tela inicial do Microsoft Office Access 2003 MICROSOFT (2003)

3.3 BDE Administrator

O BDE (Borland Database Engine) um mecanismo fornecido pelo Delphi para acessar banco de dados locais por meio de drivers ODBC (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 para desenvolvimento de aplicativos de bancos de dados em Delphi e nem os usurios

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 driver para o Microsoft Access. Outros drivers so instalados separadamente. Para abrir ou criar tabelas do Microsoft Access basta utilizar o driver MSAccess do 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 os componentes 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 Administrator BDE (1998)

23

3.4 Case Studio

CASE significa computer-aided software engineering, ou seja, engenharia de software com 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 software sobre o que fazer em seguida (SOMMERVILLE, 2003). Pressman (1995) deixa claro que o verdadeiro poder do CASE s 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 software para a seguinte, aumento no controle do projeto, obtido por meio de um melhor planejamento, monitorao e comunicao e coordenao 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 dadosferramenta, 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, Modelo Entidade Relacionamento, dentre outros. Algumas so comercializadas e outras no.

24

Exemplos de ferramentas so Case Studio, Case Design Studio, IBDataWorks, argoUML, Visual-Paradigm, Dia, Jude Community, ErWin, dentre outros. Neste trabalho ser utilizada a ferramenta Case Studio (CASE, 2006) por possuir todos os diagramas necessrios ao desenvolvimento de software proposto 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 scripts com muitas opes de configurao, entre elas scripts para 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 e disponibiliza 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: Access 2000, Access 97, Advantage 7, Clipper 5, DBIsam 3.23, DB2 UDB ver. 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 Studio 2.

25

Figura 3.5- Case Studio 2 com projeto visualizado em mdulos CASE (2006)

26

MODELO

DE

PROCESSO

DE

DESENVOLVIMENTO

DE

SOFTWARE UTILIZADO

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 software e o desenvolvimento de ferramentas, mtodos e teorias que dem apoio produo de software, com a finalidade de produzir software de 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

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 com sua 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 de escopo (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.

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 outras necessidades, 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 forma mais simples possvel. Estas histrias substituem os longos documentos

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 de Histria.

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 release no 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 releases em espaos menores para reduzir o tempo para o feedback com o cliente, pois dois meses um

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 XP BONA (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 cada uma 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 (Fix XP): 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

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 mesmo tempo 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 de solues 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 para que 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

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).

Nova User Story

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

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 de histrias 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. Iterao Conforme 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.

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 refactorings maiores, 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 escrever novas 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 para analisar 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.

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 prximo captulo ser apresentada a modelagem do sistema SCVE-BSCJ.

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 sendo esclarecidos. 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.

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 arteso e 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.

38

Tabela 5.1 Cartes de histria resumidos

N Histria 001 002 003 004 005 006 007 008 009 010 011 012 013 014 015 016 017 018 Descrio Cadastrar os dados dos usurios do sistema atravs de formulrios. Cadastrar os dados dos artesos (fornecedores) do bazar atravs de formulrios. Cadastrar os produtos que so vendidos no bazar atravs de formulrios. Validar os usurios que tero acesso ao sistema, impedindo que pessoas estranhas tenham acesso ao mesmo. Realizar entrada de produtos fornecidos pelos artesos, cujos preos podem variar de produto para produto bem como o mesmo arteso ter dois produtos iguais com preos diferentes. Realizar devoluo de produtos aos artesos. Realizar venda de produtos. Gerar clculo de repasse do valor das vendas ao arteso. Disponibilizar formulrio para entradas/sadas de dinheiro do bazar. Disponibilizar formulrio para pagamento dos artesos. Imprimir relatrios de controle de estoque. Imprimir relatrios de produtos com permanncia no bazar maior que trs meses. Imprimir relatrios da situao financeira do bazar por perodo. Imprimir relatrios de repasse ao bazar por perodo. Imprimir relatrios de cadastro de usurios, artesos e produtos. Imprimir relatrios de movimentao financeira. Imprimir relatrios de vendas. Imprimir etiquetas de produtos. Prioridade Alta Alta Alta Alta Alta Mdia Alta Mdia Mdia Mdia Mdia Mdia Mdia Baixa Baixa Mdia Mdia 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), como tambm 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.

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
N Histria 001 002 003 004 Descrio Cadastrar os dados dos usurios do sistema atravs de formulrios. Cadastrar os dados dos artesos (fornecedores) do bazar atravs de formulrios. Cadastrar os produtos que so vendidos no bazar atravs de formulrios. Validar os usurios que tero acesso ao sistema, impedindo que pessoas estranhas tenham acesso ao mesmo. Realizar entrada de produtos fornecidos pelos artesos, cujos preos podem variar de produto para produto bem como o mesmo arteso ter dois produtos iguais com preos diferentes. Realizar devoluo artesos. de produtos aos Prioridade Alta Alta Alta Alta Estimativa semana semana semana 1 semana Iterao 1 1 1 1

005

Alta

1 semanas

006 007 008 009 010 011 012 013 014 015 016 017 018

Mdia Alta Mdia Mdia Mdia Mdia Mdia Mdia Baixa Baixa Mdia Mdia Baixa

1 semana 2 semanas 1 semana 1 semana 1 semana semana 1 semana semana semana 1 semana 1 semana semana semana

3 2 3 3 4 4 4 4 4 1 3 2 4

Realizar venda de produtos. Gerar clculo de repasse do valor das vendas ao arteso. Disponibilizar formulrio entradas/sadas de dinheiro do bazar. para

Disponibilizar formulrio para pagamento dos artesos. Imprimir relatrios de controle de estoque. Imprimir relatrios de produtos com permanncia no bazar maior que trs meses. Imprimir relatrios da situao financeira do bazar por perodo. Imprimir relatrios de repasse ao bazar por perodo. Imprimir relatrios de cadastro de usurios, artesos e produtos. Imprimir relatrios financeira. de movimentao

Imprimir relatrios de vendas. Imprimir etiquetas de produtos.

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.

41

Tabela 5.3 Requisitos Funcionais

Gerenciar Usurio Requisito RF001 Cadastrar Usurio Descrio O sistema deve permitir a insero de um usurio. Os itens de informao so cdigo para identificar o usurio, nome, endereo, bairro, cidade, CEP, telefones, celular, RG, CPF, login e senha. do O sistema deve permitir a alterao dos dados do usurio, com exceo do cdigo que identifica o usurio. O sistema deve prover mecanismos para permitir a excluso de um determinado usurio. O sistema deve permitir a validao do usurio para acesso s funcionalidades do sistema. O sistema deve permitir a procura rpida dos dados cadastrais de um determinado usurio atravs de seu nome. Gerenciar Arteso Requisito RF006 Cadastrar Arteso Descrio O sistema deve permitir a insero de um arteso. Os itens de informao so cdigo para identificar o arteso, nome, endereo, bairro, cidade, CEP, telefones, celular, RG, CPF, PAT.SUTACO, e-mail e se ele repassa ou no 10% de contribuio ao bazar, alm do cdigo do usurio que o cadastrou. do O sistema deve permitir a alterao dos dados do arteso, com exceo do cdigo que identifica o arteso. O sistema deve prover mecanismos para permitir a excluso de um determinado arteso. O sistema deve permitir a procura rpida dos dados cadastrais de um determinado arteso atravs de seu nome. Prioridade Alta Iterao 1 Prioridade Alta Iterao 1

RF002 Usurio

Atualizar

dados

Alta

RF003 Excluir Usurio

Alta

RF004 Validar Usurio

Alta

RF005 Localizar Usurio

Alta

RF007 Arteso

Atualizar

Dados

Alta

RF008 Excluir Arteso

Alta

RF009 Localizar Arteso

Alta

42

Tabela 5.3 Requisitos Funcionais

Gerenciar Produto Requisito RF010 Cadastrar Produto Descrio O sistema deve permitir a insero de um produto. Os itens de informao so cdigo para identificar o produto, descrio e quantidade. do O sistema deve permitir a alterao dos dados do produto, com exceo do cdigo que identifica o produto. O sistema deve prover mecanismos para permitir a excluso de um determinado produto. O sistema deve permitir a procura rpida dos dados cadastrais de um determinado produto atravs de seu nome. Gerenciar Movimentao de Produto Requisito RF014 Inserir Item Fornecido Descrio O sistema deve permitir a entrada de produtos fornecidos pelos artesos. Os itens de informao so cdigo para identificar o item fornecido, data do fornecimento, cdigo do produto, cdigo do arteso que forneceu o produto, cdigo do usurio que recebeu o produto, descrio do item fornecido, valor unitrio e quantidade fornecida. Automaticamente, ao ser inserido um produto, deve ser atualizado o estoque. do O sistema deve permitir a alterao dos dados dos produtos fornecidos, com exceo do cdigo que identifica o item fornecido. Caso seja alterada a quantidade do produto fornecido, bem como o cdigo do produto, o sistema deve fazer as alteraes necessrias no estoque. O sistema deve prover mecanismos para permitir a excluso de um determinado produto, atualizando ao mesmo tempo o estoque. O sistema deve permitir a procura rpida dos dados cadastrais de um determinado produto fornecido atravs de seu cdigo. Prioridade Alta Iterao 2 Prioridade Alta Iterao 1

RF011 Produto

Atualizar

Dados

Alta

RF012 Excluir Produto

Alta

RF013 Localizar Produto

Alta

RF015 Atualizar Dados Fornecimento do Produto

Alta

RF016 Excluir Item Fornecido

Alta

RF017 Localizar Item Fornecido

Alta

43

Tabela 5.3 Requisitos Funcionais

Gerenciar Movimentao de Produto Requisito RF018 Devolver Item Fornecido Descrio O sistema deve permitir a devoluo de um item fornecido, provendo atualizao automtica do estoque e da quantidade de item fornecido. O sistema deve permitir a impresso de etiquetas de produtos, contendo o cdigo do item fornecido, sua descrio, o nome do arteso que o forneceu e o respectivo valor unitrio. Descrio O sistema deve permitir a venda de um produto. Os itens de informao so cdigo para identificar a venda, cdigo do usurio que efetuou a venda, data, cdigo do item fornecido vendido e quantidade. Ao ser efetuada uma venda, o estoque deve ser atualizado, bem como o valor das receitas e o valor devido ao arteso decorrente da venda. O sistema deve permitir inserir despesas financeiras. Os itens de informao so cdigo da despesa, cdigo do usurio responsvel, data, descrio e valor. O sistema deve permitir inserir receitas. Os itens de informao so cdigo da receita, cdigo do usurio responsvel, data, descrio e valor. O sistema deve prover mecanismos para que seja feito o fechamento do caixa diariamente, obtendo o saldo para verificao do caixa. O sistema deve calcular o valor devido ao arteso por perodo determinado pelo usurio, emitindo um recibo de pagamento e atualizando o caixa. Prioridade Mdia Iterao 3

RF019 Imprimir Etiquetas de Produtos

Baixa

Gerenciar Movimentao Financeira Requisito RF020 Efetuar Vendas Prioridade Alta Iterao 2

RF021 Inserir Despesas

Mdia

RF022 Inserir Receitas

Mdia

RF023 Fechar Caixa Dirio

Mdia

RF024 Pagar Arteso

Mdia

44

Tabela 5.3 Requisitos Funcionais - Concluso

Gerenciar Relatrio Requisito RF025 Emitir Relatrio de Estoque Descrio O sistema deve permitir a emisso de relatrio de estoque. Os itens de informao so cdigo do produto, descrio e quantidade. O sistema deve permitir a emisso de relatrio de itens fornecidos h mais de trs meses. O sistema deve permitir a emisso de relatrio do caixa por dia determinado pelo usurio. O sistema deve permitir a emisso de relatrio de repasse ao bazar por perodo determinado pelo usurio. O sistema deve permitir a emisso de relatrios contendo os dados cadastrais dos artesos, produtos e usurios. O sistema deve permitir a emisso de relatrios contendo todas as receitas e despesas de determinado perodo selecionado pelo usurio. O sistema deve permitir a emisso de relatrios contendo cdigo, data e usurio responsvel pela venda. Prioridade Mdia Iterao 4

RF026 Emitir Relatrio de Itens Fornecidos a Devolver

Mdia

RF027 Emitir Relatrio de Caixa

Mdia

RF028 Emitir Relatrio de Repasse ao Bazar

Baixa

RF029 Emitir Relatrios de Cadastro de Artesos, Produtos e Usurios RF030 Emitir Relatrios de Movimentao Financeira

Alta

Mdia

RF031 Emitir Relatrios de Vendas

Mdia

Tabela 5.4 Requisitos no Funcionais

Requisito RNF001 BDE Administrator RNF002 Sistema Operacional Windows RNF003 Banco de Dados MSAccess RNF004 Programa WinRar RNF005 - Hardware Descrio O sistema necessita que se tenha o BDE Administrator instalado na mquina. necessrio ter o sistema operacional Windows XP ou superior na mquina onde o sistema ser instalado. O MSAccess 2000 ou superior deve estar instalado na mquina. necessrio ter o programa WinRar instalado na mquina. Configurao mnima: Computador Pentium 4 2,79 GHz ou semelhante 1 Gb de memria RAM 150 Mb de espao livre em disco Unidade de CD-ROM ou USB Prioridade Alta

Alta Alta Alta Alta

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

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 mdulos denominados Gerenciar, apresenta-se a Figura 5.3 que ilustra o Mdulo Gerenciar Usurios.

Figura 5.3 Decomposio do Processo: Gerenciar Usurios

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

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 foram realizados por mdulos disponibilizados ao cliente.

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.

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 login e 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.

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.

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).

53

Figura 6.4 Cadastro de Artesos

Figura 6.5 Cadastro de Produtos

54

Figura 6.6 Cadastro de Usurios

Figura 6.7 Lista de Artesos

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).

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 estoque quanto dos itens fornecidos pelos artesos.

Figura 6.10 Formulrio de Despesas do Bazar

Figura 6.11 Formulrio de Receitas do Bazar

57

Figura 6.12 Formulrio de Fechamento do Caixa Dirio

Figura 6.13 Formulrio de Pagamento ao Arteso

58

Figura 6.14 Recibo de Pagamento ao Arteso

Figura 6.15 Formulrio de Vendas

59

Figura 6.16 Formulrio de Itens de Venda

Figura 6.17 Formulrio de Entrada de Produtos

60

Figura 6.18 Recibo de Entrega de Produtos

Figura 6.19 Formulrio de Devoluo de Produtos

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 mostra um 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

62

Figura 6.22 Relatrio de Produtos em Estoque

Figura 6.23 Relatrio de Caixa Dirio

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 Backup do 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 ser visualizada na Figura 6.27 e podem ser obtidas informaes sobre o sistema, como

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

65

Figura 6.28 Formulrio de Informaes do Sistema

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 software em 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, de forma 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.

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.

68

REFERNCIAS BIBLIOGRFICAS
BDE Administrator. Version 5.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: <http://books.google.com.br/books?id=G8EL4H4vf7UC&printsec=frontcover&source =gbs_v2_summary_r&cad=0#v=onepage&q=&f=false >. Acesso em: 10 ago. 2009 s 16:40h. BONA, Cristina. Avaliao de processos de software: Um estudo de caso em XP e Iconix. Dissertao (Mestrado em Engenharia de Produo), Ps-Graduao em Engenharia de Produo, Universidade Federal de Santa Catarina, Florianpolis, SC, 2002. Disponvel em: <http://trac.itapirunet.com.br/browser/MONOPONTES/Monografia-Pontes/matRef/Monografias/10816.pdf?rev=740&format=raw>. Acesso em: 12 ago. 2009 s 16:36h. BORLAND Delphi Enterprise. Version 7.0 [S.I]: Borland Software Corporation, 2002. 1 CD-ROM. CANTU, Marco. Dominando o Delphi 2005: a Bblia. So Paulo: Pearson Prentice Hall, 2006. CASE Studio 2, verso 2.25.0. [S.I]: Quest Software, Inc., 2006. Disponvel em: <www.casestudio.com>. Acesso em: 29 jan. 2009 s 13:46h. DATE, Christopher J. Introduo a Sistemas de Bancos de Dados. 6. ed. Rio de Janeiro: Elsevier Editora Ltda., 2004. EXTREME. Extreme Programming. Don Wells. Disponvel em: <http://www.extremeprogramming.org/index.html>. Acesso em: 21 jul. 2009 s 07:20h. GARCIA, Carlos A. Universidade delphi. So Paulo: Digerati Books, 2005. KUHN, Giovane Roslindo; PAMPLONA, Vitor Fernando. Apresentando XP: Encante seus clientes com Extreme Programming. Disponvel em: <http://javafree.uol.com.br/artigo/871447/Apresentando-XP-Encante-seus-clientescom-Extreme-Programming.html>. Acesso em: 15 mar. 2009 s 15:36h. MANZANO, Jos Augusto N. G.; MENDES, Sandro Santa Vicca. Estudo Dirigido de Delphi 7. 3. ed. So Paulo: rica Ltda., 2006.

69

MARTINEZ, Maria Laura. Um mtodo de Web Design baseado em usabilidade. In: 16 SIMPSIO NACIONAL DE GEOMETRIA DESCRITIVA E DESENHO TCNICO - V INTERNATIONAL CONFERENCE ON GRAPHICS ENGINEERING FOR ARTS AND DESIGN, 2003, Santa Cruz do Sul, RS. Disponvel em: <http://www.lsi.usp.br/~martinez/works/_artigos/martinez03a.pdf> Acesso em: 22 mar. 2009. MENESES, Prof. Francisco Gerson A. de. Banco de Dados Unidade III Diagrama Entidade-Relacionamento. Instituto Federal de Educao, Cincia e Tecnologia do Piau, Campus Parnaba. Disponvel em: <http://www.cefetparnaiba.edu.br/index.php?option=com_docman&task=doc_view&g id=213&tmpl=component&format=raw&Itemid=79>. Acesso em: 19 ago. 2009 s 22:13h. MICROSOFT Office Access 2003. Version 11.0. [S.I]: Microsoft Corporation, 2003. Parte do produto Microsoft Office Professional Edio 2003. 1 CD-ROM. MICROSOFT. Microsoft Office Online: Treinamento. Disponvel em: <http://office.microsoft.com/training/training.aspx?AssetID=RC061181381046>. Acesso em: 24 mar. 2009 s 14:40h. NOGUEIRA, Carlos Eduardo; FERRETI, Eliana. Modelos de processo de desenvolvimento de software: abordagens voltadas internet. 2005. Monografia (Graduao em Computao Bacharelado) - Departamento de Informtica, Universidade de Taubat, 2005 PRESSMAN, Roger S. Engenharia de Software. So Paulo: Pearson Makron Books, 1995. RATIONAL. IBM: Software. Disponvel em: <http://www-01.ibm.com/software/br/rational/rup.shtml>. Acesso em: 29 abr. 2009 s 10:11h. SANTOS, Vencios Gustavo; DAHER, Professor Nesley. Utilizao de storytelling como ferramenta de aquisio de requisitos em processo de desenvolvimento de software apoiados em modelos geis: o uso apoiado no Extreme Programming. 2008. Revista Cientfica do Departamento de Tecnologia do Uni-BH, Belo Horizonte, v.1, n.1, nov 2008. Disponvel em: <http://docs.google.com/gview?a=v&q=cache:PxRMCCxErQEJ:site1.unibh.br/imgMa rketing/revistas/dtec/include/getdoc.php%3Fid%3D46%26article%3D2%26mode%3D pdf+storytelling+extreme+programming&hl=pt-BR&gl=br>. Acesso em: 12 ago. 2009 s 20:30h. SILVA, Camila C.; PAULA, Everaldo A. Delphi 7 Desvendando os Mistrios. Santa Cruz do Rio Pardo: Viena, 2007. SOMMERVILLE, Ian. Engenharia de Software. 6. ed. So Paulo: Pearson Addison Wesley, 2003.

70

UNESC. Diagrama de Fluxo de Dados. Curso de Cincia da Computao, Anlise e Projeto de Sistemas I, Universidade do Extremo Sul Catarinense, SC. Disponvel em: < http://www.ead.unesc.net/resources/files/615/diagrama_fluxo_dados.doc>. Acesso em: 17 ago. 2009 s 17:20h. UNITRI. Captulo 1: O BDE Administrador e os SQL Links. Uberlndia: Centro Universitrio do Tringulo. Disponvel em: <http://www.computacao.unitri.edu.br/downloads/professores/DelphiBDModulo01.pdf >. Acesso em: 14 mai. 2009 s 16:10h.

71

REFERNCIAS BIBLIOGRFICAS COMPLEMENTARES

PONTES, Artur Moltocaro. Influncia do processo de desenvolvimento sobre prazo e custo de construo de software. 15 CONGRESSO DE INICIAO CIENTFICA. Disponvel em: <http://www.unimep.br/phpg/mostraacademica/anais/5mostra/1/202.pdf>. Acesso em: 14 mai. 2009 s 16:10h. TELES, Vincius Manhes. Um estudo de caso da adoo das prticas e valores do Extreme Programming. 2005. Dissertao (Mestrado em Informtica) Universidade Federal do Rio de Janeiro, Rio de Janeiro, RJ, 2005. Disponvel em: <http://improveit.com.br/xp/dissertacaoXP.pdf>. Acesso em: 12 ago. 2009 s 20:19h.