5

UNESC – Universidade do Extremo Sul Catarinense

CURSO DE CIÊNCIA DA COMPUTAÇÃO

MÓDULO DE GERENCIAMENTO DE CONTAS A RECEBER

WILLIAN JEFFERSON MEURER

LUAN ALANO FORMENTIN
INÓCIO FELIPE

CRICIÚMA, MARÇO DE 2015.

 2

WILLIAN JEFFERSON MEURER

LUAN ALANO FORMENTIN
INÓCIO FELIPE

MÓDULO DE GERENCIAMENTO DE CONTAS A RECECEBER

Trabalho destinado à disciplina de

Engenharia de Software II, solicitado pelo
Profº. M.Sc. Paracelso de Oliveira Caldas.

CRICIÚMA, MARÇO DE 2015.

 5

SUMÁRIO

LISTA DE FIGURAS ................................................................................................... 3

LISTA DE TABELAS .................................................................................................. 4
RESUMO..................................................................................................................... 5
1. INTRODUÇÃO ...................................................................................................... 6
2. ESTUDO PRELIMINAR ........................................................................................ 7
3. REQUISITOS ........................................................................................................ 8
3.1 Levantamentos ............................................................................................... 8
3.2 Análises .......................................................................................................... 9
3.2.1 Requisitos Funcionais e Requisitos Não-Funcionais ........................................................................ 9
3.3 Modelagens .................................................................................................. 10
3.3.1 Diagramas de caso de uso............................................................................................................... 10
3.3.2 Digramas de Classes ....................................................................................................................... 12
3.3.3 Digramas dinâmicos ....................................................................................................................... 14
3.4 Especificações .............................................................................................. 16
3.4.1 Dicionário de dados ........................................................................................................................ 16
3.4.2 Interfaces ........................................................................................................................................ 17
4. PLANEJAMENTO ESTRATÉGICO DA INFORMAÇÃO .................................... 18
4.1 Infra-estrutura de desenvolvimento ............................................................. 18
4.2 Infra-estrutura administrativa ...................................................................... 18
4.3 Infra-estrutura técnica ................................................................................. 18
5. IMPLEMENTAÇÃO ............................................................................................. 19
6. AVALIAÇÃO ....................................................................................................... 20
6.1. Periodicidade ............................................................................................... 20
6.2. Correção ...................................................................................................... 20
7. PROJETO DE CUSTOS ..................................................................................... 21
7.1. Recursos ...................................................................................................... 21
7.2. Cronograma de Execução ........................................................................... 21
7.3. Cronograma de Desembolso ....................................................................... 22
8. ATIVIDADES COMPLEMENTARES .................................................................. 23
9. CRONOGRAMA GERAL .................................................................................... 24
10. CONCLUSÃO ..................................................................................................... 25
11. BIBLIOGRAFIA .................................................................................................. 26

LISTA DE FIGURAS

Figura 01 – Diagrama de Caso De Uso .................................................................... 11

Figura 02 – Diagrama de Classe ............................................................................... 13
Figura 03 – Diagrama de Atividades – Cadastro de Fornecedores .......................... 15
Figura 04 – Tela – Contas a Receber ...................................................................... 17
 4

LISTA DE TABELAS

Tabela 01 – Requisito Funcional: F1 – Cadastrar Produtos ...................................... 10

Tabela 09 – Descrição de caso de uso Entrada no Módulo ...................................... 12
Tabela 10 – Tabela Modelo de Dicionário de Dados................................................. 27
Tabela 11 – Tabela de Produtos ............................................................................... 27
Tabela 17 – Tabela de notas fiscais de entrada ........................................................ 16
Tabela 29 – Cronograma de Execução ..................................................................... 21
Tabela 30 – Cronograma de Desembolso (R$) ......................................................... 22
Tabela 31 – Cronograma de Geral ............................................................................ 25
 5

RESUMO

O presente trabalho consiste em um documento descrevendo o processo de

desenvolvimento do escopo de um módulo de contas a receber para um sistema
ERP a ser utilizado em uma Loja. Portanto, são considerados desde estudo
preliminar do software e o levantamento de dados para obtenção das informações
necessárias a uma Loja até o projeto lógico, os diagramas UML previstos para o
sistema estabelecendo metas, deveres e valores de custos. O cronograma de
execução do projeto também foi elaborado e, sendo assim, deve ser utilizado como
referência no decorrer do projeto. Caso os prazos mencionados no cronograma
sejam desrespeitados, deve-se observar o item referente a correção neste mesmo
projeto. Questões referentes a infra-estrutura necessária para a implantação do
projeto também foram abordadas e relatadas neste documento. O presente
documento foi elaborado no decorrer da disciplina de Engenharia de Software II e
utilizou como base o conhecimento adquirido na mesma.
 6

1. INTRODUÇÃO

Um dos grandes desafios de micro, pequenas e até mesmo grandes

empresas é administrar recursos financeiros, pois estes representam o meio pela
qual as empresas realizam suas operações. Para obter melhor chance de sucesso,
é importante quantificar adequadamente o retorno financeiro.

Assim, faz-se necessário o gerenciamento de contas a receber para que não

ocorra falta de recursos financeiros a fim de efetuar pagamentos de fornecedores,
funcionários e obviamente saber quais são os lucros reais. É a partir dessas e de
outras definições e prioridades que se desenvolverá o módulo para gerenciamento
de contas a receber de um ERP. Para tal propósito o módulo cuidará dos recursos
financeiros já existentes e a receber, o modulo conterá opções de controle de
acesso, relatórios de contas a vencer, baixa de conta, consultas por cliente, por data
e código da venda.

A utilização de um ERP traz grandes benefícios à empresa. Assim pode-se

citar: maior organização, automatização, rapidez, confiabilidade, e principalmente,
maiores lucros além de dar vida ao sistema corporativo.
 7

2. ESTUDO PRELIMINAR

O estudo preliminar, em todos os quesitos, aponta viabilidade na construção

do software “modelo de gerenciamento de contas a receber” para uma organização.
O resultado do processo de estudo de viabilidade está especificado como segue:

Viabilidade ética

A ética fica aqui preservada tendo em vista que não existe uma solução
financeira que satisfaça os requisitos do módulo de gerenciamento de contas à
receber da empresa. Isto significa que este software é específico e requer o seu
desenvolvimento.

Viabilidade econômica

A capacidade de investimento declarada no levantamento de requisitos pelo

diretor financeiro da Loja foi no valor de R$ 25.000,00 (vinte e cinco mil reais). Este
valor é suficiente e com sobras para arcar com o desenvolvimento do software, pois
o mesmo foi orçado em R$ 10.060,00 (dez mil e sessenta reais). Isto ratifica esta
viabilidade.

Viabilidade técnica

Durante o processo de análise não foram encontrados nenhum impedimento

com relação as técnicas e ferramentas a serem utilizadas no desenvolvimento do
software, tornando-o tecnicamente viável.

Viabilidade legal

O software “modelo de gerenciamento de contas a receber ” serve

exclusivamente para gerenciamento financeiro. Dentro deste escopo ele é
absolutamente viável, pois presta se apenas para gerenciamento de contas à
receber não invocando leis e tributos.
 8

3. REQUISITOS

3.1 Levantamentos

Levando em consideração que o sistema a ser desenvolvido para uma

determinada empresa deve atender prontamente as necessidades da mesma, os
responsáveis pelo software e programadores devem entender e saber de todas as
necessidades e objetivos da empresa.

Para tal desenvolvimento se realizou um levantamento de requisitos, em

forma de questionário e entrevistas com o gerente financeiro e funcionários do setor,
isso fez com que muitas dúvidas fossem explicadas e funcionalidades definidas.
 9

3.2 Análises

3.2.1 Requisitos Funcionais e Requisitos Não-Funcionais

Tabela 01 – Requisito Funcional: F1 – Contas a Receber

F1 Contas a Receber Oculto ( )

Descrição: O sistema deve ter a função de Incluir, Alterar, Excluir, Pesquisar e
Consultar Contas a Receber.
Requisitos Não Funcionais
Desej Permanen
Nome Restrição Categoria
ável te
A função só pode ser acessada Seguranç ( ) (x)
por gerente ou auxiliar financeiro
CR 1.1 a
que deverá estar logado no
Controle de
sistema com privilégios de
Acesso
manutenção no cadastro de
contas a receber.
O sistema deve conter a opção Especific ( ) (x)
“Pesquisar Contas a Receber”.
ação
CR 1.2 A pesquisa deve oferecer opções
Pesquisa tais como pesquisar por data,
nome do cliente, código do
cliente.
As contas à receber devem ser Especific ( ) (x)
provenientes de vendas de
ação
produtos ou serviços. Ao registrar
CR 1.3
a venda o usuário deve informar
Dados de
a forma de pagamento tais como:
Contas a
à vista; cartão; boleto, à prazo.
Receber
bem como o numero de parcelas
e data de vencimento das
mesmas.
Após o recebimento da conta ou Especific () (x)
parcela o usuário deve dar baixa
CR 1.4 Baixa ação
e assim alimentando informações
de “Caixa”.
O sistema deve conter opção de Seguranç ( ) (x)
retificação de alguma informação
a
CR 1.5 em caso de possíveis erros. Essa
Atualização opção deverá ser acessada
apenas por gerente, logado com
privilégios administrativos.
 10

3.3 Modelagens

3.3.1 Diagramas de caso de uso

O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre

os analistas e o cliente. Um diagrama de Caso de Uso descreve um cenário que
mostra as funcionalidades do sistema do ponto de vista do usuário. O cliente deve
ver no diagrama de Casos de Uso as principais funcionalidades de seu sistema.

Figura 1 – Diagrama de Caso de Uso

 11

Tabela 09 – Descrição de caso de uso Entrada no sistema

ordem Nome
1 Entrada no sistema

Quem inicia Ator Responsável Financeiro

Pré-condição Deve estar cadastrado

1 – O responsável financeiro informa o

nome
2 – se o nome não for cadastrado, o
sistema permite informar 3 nomes
inválidos, após encerra.
Cenário 1:
Acesso ao 3 – funcionário informa a senha
sistema
4 – se a senha não for cadastrada, o
sistema permite informar 3 senhas
inválidas, após encerra
5 – o sistema abre o módulo Contas a
Receber
Exceção Informar usuário ou senha inválido
 12

3.3.2 Digramas de Classes

No processo de desenvolvimento de softwares, um diagrama de classes é

uma representação da estrutura e relações das classes que servem de modelo para
objetos.
É uma modelagem muito útil para o sistema, define todas as classes que o
sistema necessita possuir e é a base para a construção dos diagramas de
comunicação, sequência e estados.
 13

Figura 2 – Diagrama de Classe

 14

3.3.3 Digramas dinâmicos

Um Diagrama Dinâmico consiste numa coleção de formas

estruturadas que ajudam a analisar e resumir dados com um formato
visual que facilita a compreensão.

3.3.3.1 Diagramas de Estados

Figura 3 – Diagrama de Estados – Contas a Receber

 15

3.3.3.2 Diagramas de Atividades

Figura 6 – Diagrama de Atividades – Contas a Receber

 16

3.4 Especificações

3.4.1 Dicionário de dados

O dicionário de dados é o detalhamento da modelagem
construída no diagrama de classes entidades.

Tabela 17 – Tabela de contas a receber- Cabeçalho

Tabela ContReceber
Descrição Contém informações de Contas a Receber - Cabeçalho.
Chaves Domínio
Atributo Comentários
PK FK Tipo Nulo Condições Valor Inicial
x Id_ContReceber Int NN Sem sinal Código de pedido contas a receber
nf Varchar NN Sem sinal Número da Nota Fiscal
Valor Float NN 0,00 Now Valor total
IdFormaPagamento INT NN Sem sinal Código da forma de pagamento
x ItensContaRece_idItenContaRece INT NN Sem sinal Código do Itens de contas a receber
x FormaPagamento_idFromaPagamento INT NN Sem sinal Código da Forma de Pagamento
x Cliente_idCliente INT NN Sem sinal Código do cliente
x NF_idNF INT NN Sem sinal Código da Nota Fiscal
 17

3.4.2 Interfaces
A interface é construída a partir da aprovação e negociação com o
cliente da modelagem construída a partir do levantamento de
requisitos.

Figura 8 – Tela de Contas a Receber

 18

4. PLANEJAMENTO ESTRATÉGICO DA INFORMAÇÃO

4.1 Infra-estrutura de desenvolvimento
 O modelo de ciclo de vida escolhido para desenvolvimento da aplicação
foi o iterativo, tendo em vista ser um software pequeno;
 A técnica de levantamento de requisitos predominante foi entrevista;
 A ferramenta de modelagem: Mysql Workbench,JUDE Community ;
ambiente de desenvolvimento: NetBeans; banco de dados; Mysql. Vale
lembrar que esta infra-estrutura é do desenvolvedor;
 A avaliação será realizada a cada iteração de acordo com o cronograma
de desenvolvimento, Caso haja atrasos durante as iterações as partes
serão isentas de multas desde que corrigidas e que não afetem o prazo
total. No caso em que o atraso seja provocado pela contratante, cada dia
de atraso acima do prazo total custará a mesma 5% do valor do
contrato.
4.2 Infra-estrutura administrativa

Será necessário a contratação de um profissional da área de T.I (Tecnologia

da Informação) , para operacionalizar o módulo.
4.3 Infra-estrutura técnica

O funcionamento do software requer os recursos descritos abaixo, sem o

que não ocorre a sua efetividade.

 Computador c/processador Intel I7, 8gb RAM, 500gb HD;

 Impressora 2ppm;
 Estabilizador 0,5 kva;
 SO Windows – última versão;
 Banco de dados;
 Software módulo estoques
 Criar um ponto de rede.
 19

5. Implementação

A operacionalização da implementação será efetivada com o ambiente

NetBeans de desenvolvimento, apoiado pelas ferramentas de modelagem Mysql
Workbench e com suporte de armazenamento no banco de dados Mysql.
 20

6. AVALIAÇÃO

6.1. Periodicidade

Uma vez por semana será feita uma reunião com o cliente para verificar o
andamento do desenvolvimento do módulo em relação ao cronograma geral
estabelecido.
Os eventuais atrasos serão compensados com horas extras custeadas por
quem os causou.

6.2. Correção

Cada vez que alguma atividade prevista no contrato de desenvolvimento do

módulo não for atendida pelo cliente, isso lhe acarretará uma multa (acréscimo) de
2% no valor da implementação.

Da mesma forma, o que não for atendido pelo contratado, lhe acarretará uma
multa (desconto no software) de 2% no valor da implementação.
 21

7. PROJETO DE CUSTOS

7.1. Recursos

Os recursos que devem ser adquiridos para garantir à infra-estrutura

necessária conforme analisado no cliente, está descrita no quadro abaixo. .

7.2. Cronograma de Execução

Tabela 29 – Cronograma de Execução

Atividade/período Abr14 Mai14 Jun14 Jul14 Ago14 Set14 Out14

1 Ponto de rede
com cabeamento
par trançado na X
sala
1 Treinamento no X
sistema
 22

7.3. Cronograma de Desembolso

Tabela 30 – Cronograma de Desembolso (R$)

Atividade/período Abr14 Mai14 Jun14 Jul14 Ago14 Set14 Out14

8 Computadores 2000,00 2000,00 1000,00 1000,00 1000,00 1000,00

8 mesas p/comp 120,00 120,00 60,00 60,00 60,00 60,00

2 Impressoras 300,00 300,00

2 mesas p impr 60,00 60,00

8 cadeiras p/ comp 100,00 100,00 50,00 50,00 50,00 50,00

1 Software p/ Back 330,00

01 Switches 12port 180,00

01 Modem ADSL 250,00

01 Bracket 10 U 420,00

01 Patc Panel 24 P 455,00

02 Guias de cabo 70,00

02 Réguas 6 tomad 80,00

08 Conec RJ 45 f 25,00

08 Patc cord 2,5 m 45,00

01 Servidor 4000,00

01 Banco Dados 300,00

08 Patc cord 2,5 m 45,00

08 Patc cord 1,5 m 30,00

Cabo AWG 4 pares 3,30

Implementação 2000,00 1500,00 1000,00 500,00 250,00

Treinamento 3000,00

Total 10123,30 3720,00 1060,00 1970,00 1360,00 1410,00 4440,00

Total Geral: R$ 24083,30.

Observações Importantes:

Caso houver customizações Extra-Projeto, o valor das horas técnicas será de

R$80,00.
 23

8. Atividades Complementares

Testes
Durante o desenvolvimento serão realizados exaustivos testes nos para
cobertura funcional, para os quais serão utilizadas ferramentas atualizadas e
técnicas adequadas as especificidades das funcionalidades.

Implantação
O planejamento realizado para a implantação contempla processamento em
paralelo durante 15 dias a ser realizado com término previsto em 30 dias antes
do inicio da operação do software.

Operação
Para resguardar o perfeito funcionamento foram planejados e executados
treinamentos com usuários no ambiente real de funcionamento durante um
período de 30 dias com termino estabelecido de 30 dias antes do inicio da
operação do software.

Manutenção
A partir do inicio da implantação do software durante no mínimo 6 meses serão
feitas reuniões quinzenais para adequação a dinâmica de funcionamento com
relação a evolução natural.
Na seqüência dos 6 meses de funcionamento será feita a manutenção corretiva
tradicional.
 24

9. CRONOGRAMA GERAL

Tabela 31 – Cronograma de Geral

2015
Ativ/ Período
Abr Mai Jun Jul Ago Set Out Nov Dez
Últimas
decisões junto X
ao Cliente
Implementação X X X

Reuniões com X X X X X X X X
X
Cliente
Montagem da X X
Rede
Implantação X X X

Testes X X X

Treinamento de X X X
Usuários
Acompanh X X X X

Obs: O suporte será dado ao cliente em prazo determinado até o final do Projeto,
caso o contrário o cliente pagará por hora técnica.
 25

10. CONCLUSÃO

Visando melhorar a qualidade dos produtos de software e aumentar a

produtividade no processo de desenvolvimento, a Engenharia de Software trata de
aspectos relacionados ao estabelecimento de processos, métodos, técnicas,
ferramentas e ambientes de suporte ao desenvolvimento de software.

O planejamento do software para seu desenvolvimento nos previne de uma

série de erros futuros onde pode envolver desde custos para o desenvolvedor e
cliente, e também perda de tempo para ambos.

A empresa teve liberdade para a escolha dos requisitos do programa, durante

todo o período de desenvolvimento a mesma apresentou sua opinião, sugerindo
melhorias e mudanças para se adequar melhor ao seu método de trabalho, e ate a
linguagem a ser usada no programa que pudesse se adequar melhor a sua região
em que vai ser utilizado.

Algumas mudanças sugeridas pelo cliente tornaram o seu desenvolvimento

mais demorado, porém, todas essas mudanças foram negociadas em reuniões, e
com essa dificuldade de atender as mudanças sugeridas pelo cliente no período,
houve um prolongamento do cronograma de execução.
O dinamismo do sistema, atendendo todas as necessidades da empresa com
funcionários treinados a utilizar-lo, foram os pontos importantes citados pelo cliente
para demonstrar a sua satisfação com o investimento.

As funcionalidades propostas no módulo “Contas a Receber” foram

implementadas e devidamente testadas.

O projeto desenvolvido gerenciamento de contas a receber é essencial para

que não ocorra falta de recursos financeiros a fim de efetuar pagamentos de
fornecedores, funcionários e obviamente saber quais são os lucros reais.

Vale lembrar que este módulo foi desenvolvido a fim de interagir com outros
módulos desenvolvidos e assim formar um sistema integrado para uma dada
empresa.
 26

11. BIBLIOGRAFIA

BALLOU, Ronald H.. Logística empresarial: transportes, administração

de materiais e distribuição física. São Paulo: Atlas, 1993.

BEZERRA, Eduardo. Princípios de analise e projeto de sistemas com

UML. Rio de Janeiro: Campus, 2002.

GRANEMANN, S.; RODRIGUES, C.T.. Logística Aplicada nas

Empresas de Transporte. Florianópolis: IDAQ, 1996.

MAGEE, John F.. Logística industrial - Análise e administração dos

sistemas de suprimento e distribuição. São Paulo: Pioneira, 1977.

DATE, C.J. Introdução a Sistemas de Banco de Dados. Rio de Janeiro:

Campus, 2004.

PRESSMAN, Roger S.; Engenharia de Software. São Paulo : Makron

Books, 1995.

SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN . S.

Sistema de Banco de Dados. 5ª ed. São Paulo: Campus, 2006.

BEZERRA, Eduardo. Princípios de analise e projeto de sistemas com

UML. Rio de Janeiro: Campus, 2002.

Disponível em: http://pt.wikipedia.org/wiki/Diagrama_de_classes. Acesso

em: 29 março 2009.

Disponível em: http://office.microsoft.com/pt-pt/visio/HA10014196207

0.aspx. Acesso em: 29 março 2009.