Sistema de Gerenciamento Administrativo/Financeiro da Boneca de Pano Brech

Valdeci Oliveira Cangussu Junior* Professor Orientador: Bruno Silvrio Costa**

RESUMO Este trabalho apresenta detalhadamente todas as fases do processo de desenvolvimento de um software para gerenciamento administrativo e financeiro de uma pequena loja, evidenciando a comunicao entre o gerente responsvel e desenvolvedor de forma a facilitar o levantamento das informaes de forma que obtenha um resultado de acordo com as expectativas iniciais. As dificuldades enfrentadas bem como a experincia tcnica adquirida foram descritas aqui com o maior nmero de detalhes possveis tornando esse material um modelo de abordagem e desenvolvimento de sistemas de informao comercial baseado numa experincia real e numa abordagem prtica.

Palavras-Chave: Sistemas de Informao Comercial. Gerenciamento Administrativo/Financeiro. Desenvolvimento de Software. Elicitao de Requisitos.

Estudante. Universidade Estadual do Sudoeste da Bahia - UESB. Graduando em Cincia da Computao. E-mail: vocjunior_uesb@yahoo.com.br.

** Professor. Universidade Estadual do Sudoeste da Bahia - UESB /Faculdade de Tecnologia e Cincia - FTC/Faculdade Independente do Nordeste - FAINOR. Especialista em Administrao em Sistemas de Informao. Universidade Federal de Lavras. E-mail: bcosta@uesb.br.

1 INTRODUO O sistema proposto ferramenta para gerenciamento administrativo e financeiro de uma pequena loja, que tem como principais funcionalidades o cadastro das informaes (tais como, produtos, vendedores, usurios, etc.), controle de fluxo de caixa (entradas, sadas), controle de estoque, ferramenta de anlise gerencial baseada em relatrios, alm de um sistema de etiquetao dos produtos com cdigo de barras de forma a garantir certo nvel de confiabilidade e segurana, que seria gerado e gerenciado pelo sistema. A interface de venda de produtos seria todo baseado na leitura do cdigo de barras que seria um padro contendo as informaes necessrias quela venda tornando o processo de sada de produtos rpido e eficiente. Para identificao do problema onde o software seria aplicado, foi feita uma anlise completa do funcionamento interno da loja, explorando as vulnerabilidades e deficincias, fazendo um levantamento da situao encontrada e apresentando a soluo proposta e os dos benefcios da utilizao do sistema aplicado a cada situao-problema. Dentre os problemas encontrados os mais significativos foram: ausncia de uma ferramenta de gerenciamento; no foi encontrada nenhuma forma de controle de estoque dos produtos; falta de ferramentas de anlise gerencial; processo essencialmente manual. Com base nas informaes adquiridas foi feita a proposta de construo de um sistema de informao gerencial que seria responsvel por controlar todos os processos internos da loja. O sistema inicialmente seria totalmente voltado para a soluo dos problemas encontrados. Para isso contaria com alguns mdulos importantes: controle de entrada e sada de produtos; controle de estoque; controle financeiro; controle de etiquetao de produtos com cdigo de barras; interface de venda baseada na rapidez e usabilidade. Devido s caractersticas da loja o software teria que ser o mais rpido e funcional possvel, de forma a agilizar o processo gerencial e no de torn-lo ainda mais complexo demorado. Alm de solucionar os problemas da loja o sistema ainda agregaria servios extras que auxiliaria o gerente no processo de tomada de deciso, como relatrios gerenciais, de

previso e estatsticos. Um outro objetivo importante do software garantir um nvel de segurana desejvel tendo em vista a realidade da empresa. O projeto foi divido em trs fases: Elicitao de requisitos e Modelagem; Implementao da interface; Persistncia numa base de dados. Cada fase subseqente depende da fase anterior, sendo assim a qualidade de implementao das fases iniciais so a garantia de um programa de qualidade. Devido a esse fato a fase de levantamento de requisitos e modelagem considerada a mais importante do sistema e demanda um tempo maior de desenvolvimento exatamente por envolver toda a analise da ferramenta a ser construda.

2 DESENVOLVIMENTO Desenvolver um sistema comercial no uma tarefa trivial. No existe sistema simples. Cada um possui caractersticas e funcionalidades especficas que s so descobertas depois de uma anlise completa do contexto em que ser utilizado, no caso do sistema comercial preciso conhecer a empresa onde ele ser aplicado, entender o processo organizacional, explorar as situaes onde nem mesmo o gerente sabe que existe um problema ou um processo que est funcionando mas pode ser melhorado. Logo, s depois de analisar e modelar que o desenvolvedor sabe exatamente o que ser implementado. Alm disso, as fases posteriores exigem experincia e conhecimento suficientes para se produzir um software com uma interface amigvel, usvel e fcil, mas, tambm rpido. Definir corretamente o modelo de dados pode fazer do sistema um sucesso ou fracasso completo. Organizao fundamental para conseguir alcanar os resultados pretendidos, sendo assim o sistema foi divido trs fases contemplantando os pontos fundamentais do processo de desenvolvimento de software. 2.1 Elicitao de Requisitos e Modelagem Esta fase se inicia com um levantamento completo dos requisitos funcionais, no-funcionais e organizacionais do sistema proposto. Segundo Sommerville (2001), entende-se por requisitos funcionais as declaraes das funes que o sistema deve oferecer. Indica como o sistema deve se comportar. Requisitos no-funcionais incluem restries de tempo (desempenho), padres e qualidades gerais do software. Os organizacionais tratam basicamente das metas e expectativas da empresa. A Elicitao de Requisitos e a etapa onde h mais contado entre a empresa e o desenvolvedor. importante que essa abordagem seja feita de forma bastante dinmica e que se consiga obter o maior nmero de informaes possveis sobre todo o contexto organizacional. Essa abordagem no fcil e precisa muito da colaborao da gerente responsvel. Para isso, o desenvolvedor precisa aplicar

varias tcnicas disponveis para tornar esse processo interessante evitando que se torne cansativo e que altere a rotina normal da empresa. Tendo em mos os requisitos e aps uma anlise minuciosa dos mesmos foi iniciado efetivamente o processo de modelagem, antes, porm, foi definida a plataforma de desenvolvimento. Por ser um padro em termos de recursos tecnolgicos na atualidade e pela gama de recursos que oferece a linguagem de programao adotada foi linguagem o Java, verso 5.0. Como um dos requisitos do sistema desempenho, optou-se por utilizar um dos Bancos de Dados de pequeno-mdio porte mais rpido no mercado: o Firebird em sua verso estvel na poca, 1.5. Aps essas etapas, foi se descrito em detalhes as funcionalidades do sistema em termos de modelos UML1, incluindo Modelo de Classes, Modelo Entidade-Relacionamento, Modelo de Casos de Usos, Modelo de Seqncia e Modelo de Atividades. O processo de modelagem pode ser difcil e trabalhoso e no permite falha, pois um erro na modelagem gera um erro de funcionalidade do sistema gerando problemas de execuo futuros. A empresa foi constantemente consultada e questionada de modo a extrair o mximo de informaes possveis enriquecendo os modelos e contribuindo para a gerao de um modelo detalhado de modo que as fases posteriores fossem fceis de serem executadas. 2.2 Implementao da Interface A definio da interface grfica se torna uma das fases mais tranqilas do projeto a partir do memento que as fases anteriores sejam bem fundamentadas. Nessa etapa os pontos a considerar so os requisitos quanto a uma interface amigvel e usabilidade. O software deve ser agradvel ao usurio. Ele deve se sentir bem em trabalhar com o sistema podendo alterar a sua cara personalizando-o de acordo com as suas preferncias. Para permitir esse nvel de iterao so necessrios alguns cuidados de implementao para garantir que aps as alteraes na
1

Unified Modeling Language , Linguagem de Modelagem Unificada

interface o software continue se comportando da maneira esperada, sem perder desempenho nem usabilidade. (Fig. 01) Mas acima de tudo um software precisa ser fcil de usar. O usurio precisa ter a informao que precisa da forma mais simples possvel. Os passos para se realizar determinadas tarefas devem ser minimizados de forma que ele no se perca entre as telas e acabe fazendo algo indesejado pro sistema. Deve se evitar ao mximo o uso do mouse pois mais produtivo que o usurio acione as funes sem ter que tirar a mo do teclado que obviamente o que ele utiliza para inserir dados no sistema. Caso o uso do mouse seja necessrio preciso que o nmero de cliques seja consideravelmente reduzido por uma razo simples: vrios cliques exigem varias aes do usurio. Essas consideraes embora simples contribuem significativamente para tornar um sistema usvel e alm disso aumenta a produtividade do usurio tornando-se interessante para a gerencia empresarial. Como dito anteriormente a implementao foi feita na linguagem de programao Java, porm algumas ferramentas e bibliotecas foram bastante teis nessa etapa: Eclipse IDE: Ferramenta Integrada de Desenvolvimento (IDE), onde foi projetado e construdo todo o sistema. Por ser um ambiente integrado oferece recursos indispensveis em projetos de software de qualidade. o Visual Editor: Plugin do eclipse, framework visual para definio da interface. Permitido um desenvolvimento rpido de tarefas repetitivas e maantes atravs de uma API totalmente visual. o SwingX: Biblioteca de extenso da biblioteca padro do Java para definio de GUI (Graphic User Interface), oferecendo classes importantes e extremamente teis em termos de funcionalidade de uma aplicao nesses moldes.

Fig.01 Tela principal do sistema De forma a produzir um software de qualidade e minimizar o tempo de desenvolvimento e de futuras manutenes foi empreendido uma estrutura de construo de interfaces explorando os recursos da Programao Orientada a Objetos, onde apenas uma interface padro foi definida e todas as outras telas herdam os estados e comportamentos dessa interface padro. Dessa forma no h a necessidade da construo repetitiva de layout e comportamento em nenhuma das classes bases pois elas herdam esses comportamentos da superclasse. (Fig. 02)

A interface usvel importante sobretudo para minimizar os custos com treinamentos pelo fato de se tratar de uma pequena empresa que no dispem de tantos recursos para treinamento de pessoal.

Fig. 02: Exemplo de uma tela de cadastro 2.3 Persistncia de dados Alm de ser a parte onde o sistema se torna realmente funcional, a persistncia tambm onde se define o sucesso ou fracasso do sistema.

Devido aos inmeros cuidados necessrios a definio de um modelo de persistncia razovel, faz-se necessria nessa etapa a utilizao de um framework2 de persistncia. Inicialmente foi utilizado o framework objeto relacional da OJB (Object Relational Bridge), porm a medida que as funcionalidades foram sendo desenvolvidas percebeu-se que OJB pecava em alguns situaes. Sendo assim o framework de persistncia foi mudado para o Hibernate. Hibernate um padro no ambiente Java para mapeamento ORM, alm de possuir um suporte excelente s Anotaes (Annotations) do Java 5.0 o que simplifica e garante um desempenho melhor aplicao na medida em que no se faz mais necessria a utilizao de documentos XML para definio dos mapeamentos de forma simples e pratica. Todo o cdigo de acesso base de dados relacional e totalmente encapsulada restando ao desenvolvedor apenas utilizar as funes de persistncia especficas de acordo com a sua necessidade. Para automatizar o processo de desenvolvimento e agilizar a programao foram desenvolvidas algumas classes especficas. Classe de conexo com o Banco de Dados: Uma classe Java responsvel por setar e gerenciar a conexo com o Banco de Dados, oferecendo um componente visual onde o usurio pode informar os dados de sua conexo. Isso ser chamado sempre que houver algum problema de conexo com o Banco. (Fig. 03)

Framework uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido.
2

Fig. 03: Erro de Conexo Caso o usurio tenha conhecimento suficiente e deseje entender as razes pelas quais os erros aconteceram ele pode visualizar os detalhes do erro. Como essa informao nem sempre interessante, pois a maioria dos usurios no tem conhecimento necessrio para tal os detalhes do erro no so exibidos diretamente, necessrio que ele se proponha a visualiz-los caso ache conveniente. (Fig. 04)

Fig. 04: Exemplo de detalhes do erro Quando o usurio confirma a visualizao do erro, ele levado a uma tela onde pode configurar a conexo com a base de dados. Isso acontece porque na maioria dos casos um erro de conexo acontece em virtude de algum problema nessa configurao.

Fig. 05: Tela de Configurao do Banco de Dados

Se o usurio clica em OK essa classe tenta se conectar com o Banco de Dados utilizando as informaes oferecidas pelo usurio, se no conseguir a tela exibida novamente e o ciclo se repete at que o usurio entre com a informao de conexo correta ou ele clique em cancelar. Classe personalizada para trabalhar com tabelas Pensando em oferecer o maior nmero de facilidades ao usurio foi desenvolvida uma classe para trabalhar com tabelas oferecendo recursos como ordenao, colorao alternada das linhas etc. (Fig. 02) Classe para fixar o numero mximo de caracteres Limitar a ao do usurio mais do que uma opo uma necessidade. Com o objetivo de definir o numero mximo de caracteres possveis em um campo de texto foi desenvolvida essa classe auxiliar.

2.6 Resultados O software resultante atende completamente aos requisitos descritos quando de seu planejamento e modelagem, o que leva a crescer que o modelo vlido e vivel j que foi implementando e houve uma comprovao prtica do seu funcionamento. Apresentado realidade da empresa o software atendeu completamente aos requisitos, resolvendo os problemas apresentados e contribuindo para uma melhoria do processo gerencial.

3 CONCLUSO Embora o desenvolvimento de um software no seja trivial, as etapas de desenvolvimento so praticamente iguais em sistemas diversos. Sendo assim possvel desenvolver uma rotina padro desenvolvimento, uma espcie de algoritmo, com as etapas e passos necessrios para constru-lo. Existem diversas rotinas possveis, mas poucas realmente so implementadas e testadas para verificar sua viabilidade prtica. O modelo de desenvolvimento aqui descrito foi implementado e provou com os resultados obtidos que no apenas vivel mas tambm pratico e funcional. As ferramentas e tecnologias descritas foram utilizadas ou por serem um padro no mercado de desenvolvimento de software, o que comprova o seu total funcionamento e as torna confiveis suficientes para aplicar a qualquer projeto de software, ou por serem ferramentas baseadas em software livre o que no acarreta nenhum custo para a empresa ou desenvolvedor j que no necessrio pagamento de licenas para sua utilizao. A experincia e o conhecimento adquirido durante esse projeto e aqui descrito constituem-se numa referncia prtica funcional de desenvolvimento de software, um modelo, que pode ajudar aos desenvolvedores iniciantes de modo a evitar que caiam na armadilhas de primeiro projeto.

4 REFERNCIAS SOMMERVILLE, I. Software Engineering. 6th Edition, Addison Wesley, 2001. Sun MicroSystems. Java Object Oriented Language. <http://java.sun.com>. Acessado em 10 mar de 2007 Eclipse Foundation. Eclipse IDE Home Page. <http://www.eclipse.org>. Acessado em 10 out de 2006. JBoss Company. Hibernate Site Reference. <http://www.hibernate.org>. Acessado em 10 out de 2006. Swing Labs. SwingX Project. Acessado em 19 set de 2006. Disponivel em Disponvel Disponivel Disponivel em em em

<http://www.swinglabs.org>.