Ségio Augusto Cola Dias

UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
RELATÓRIO DE ESTÁGIO SUPERVISIONADO
ANÁLISE E DESENVOLVIMENTO DE UM SISTEMA DE
PREVISÃO DE PAGAMENTOS
SERGIO AUGUSTO COLA DIAS
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
RELÁTORIO DE ESTÁGIO SUPERVISIONADO
ANÁLISE E DESENVOLVIMENTO DE UM SISTEMA DE
PREVISÃO DE PAGAMENTOS
SERGIO AUGUSTO COLA DIAS
Relatório
apresentado
Instituto
de
Computação da Universidade Federal de
Mato Grosso, para obtenção do título de
Bacharel em Sistemas de Informação.
CUIABÁ – MT
2016
UNIVERSIDADE FEDERAL DE MATO GROSSO
COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM
SISTEMAS DE INFORMAÇÃO
SERGIO AUGUSTO COLA DIAS
Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de Sistemas
de Informação como uma das exigências para obtenção do título de Bacharel em
Sistemas de Informação da Universidade Federal de Mato Grosso
Aprovado por:
Prof. MSc. Nilton Hideki Takagi
Instituto de Computação
(COORDENADOR DE ESTÁGIOS)
Prof. Dr. Thiago Meirelles Ventura
Instituto de Computação
(ORIENTADOR)
Marcos Antonio dos Santos
Supervisor de Sistemas
Amaggi Exportação de Importação LTDA.
(SUPERVISOR)
DEDICATÓRIA
Dedico este trabalho a toda a minha família, principalmente aos meus pais, Mônica
e Geraldo e ás minhas irmãs, Roberta e Renata, e à minha namorada, Elen, que me
incentivou de todas as maneiras durante a minha jornada.
AGRADECIMENTOS
Agradeço aos meus familiares, que sempre me deram apoio nas horas difíceis
e sempre acreditaram em mim.
Agradeço minha namorada, Elen, pela paciência e incentivo e apoio em
momentos decisivos da minha vida. Ela sempre esteve ao meu lado mesmo em
momentos de dificuldade.
Aos meus amigos, que acompanharam minha longa trajetória na faculdade
desde que entrei até o presente momento, me ajudando a superar os problemas e
trabalhar com as adversidades da vida, meus sinceros agradecimentos.
Agradeço, também aos meus professores do Instituto de Computação da
UFMT, que ajudaram a formar o profissional que sou hoje. E um agradecimento
especial para o meu orientador, Thiago Meirelles Ventura, que pacientemente me
ajudou em momentos de dúvida.
Obrigado a todos.
SUMÁRIO
SUMÁRIO ............................................................................................................................................ 6
LISTA DE FIGURAS .......................................................................................................................... 8
LISTA DE SIGLAS E ABREVIATURAS ......................................................................................... 9
RESUMO ............................................................................................................................................ 10
INTRODUÇÃO .................................................................................................................................. 11
1.
REVISÃO DE LITERATURA ................................................................................................ 13
1.1.
ENGENHARIA DE SOFTWARE .................................................................................. 13
1.1.1. RATIONAL UNIFIED PROCESS ..................................................................................... 13
1.1.1.1. FASE DE CONCEPÇÃO ............................................................................................... 14
1.1.1.2. FASE DE ELABORAÇÃO ............................................................................................. 15
1.1.1.3. FASE DE CONSTRUÇÃO ............................................................................................. 16
1.1.1.4. FASE DE TRANSIÇÃO .................................................................................................. 17
1.1.1.5. INTERAÇÕES ................................................................................................................ 17
1.1.2. UNIFIED MODELING LANGUAGE ........................................................................... 18
1.1.3. PROTOTIPAÇÃO ......................................................................................................... 19
1.1.4. BANCO DE DADOS .................................................................................................... 21
1.1.5. PROGRAMAÇÃO ORIENTADA A OBJETOS ............................................................. 21
1.1.5.1.
CLASSE ................................................................................................................... 22
1.1.5.2.
OBJETO .................................................................................................................. 22
1.1.5.3.
ENCAPSULAMENTO ............................................................................................. 22
1.1.5.4.
POLIMORFISMO .................................................................................................... 22
1.1.5.5.
HERANÇA ............................................................................................................... 22
2.
MATERIAS, TÉCNICAS E MÉTODOS ............................................................................... 24
2.1.
2.1.1.
2.1.2.
2.2.
2.3.
2.3.1
2.3.2.
2.3.3.
2.3.3.1.
3.
ELICITAÇÃO DE REQUISITOS .................................................................................. 24
ENTREVISTA ............................................................................................................... 24
CASOS DE USO ........................................................................................................... 25
BALSAMIQ MOCKUPS ............................................................................................... 26
ARMAZENAMENTO DE DADOS E PROGRAMAÇÃO .............................................. 27
ORACLE 10G ............................................................................................................... 27
PL/SQL DEVELOPER 11.0.......................................................................................... 27
DELPHI 7 ..................................................................................................................... 28
OBJECT PASCAL.................................................................................................... 28
RESULTADOS ......................................................................................................................... 29
3.1.
3.1.1.
3.1.2.
3.1.3.
3.1.4.
3.1.5.
3.1.6.
3.1.7.
3.2.
3.2.1.
3.2.2.
3.2.3.
3.2.4.
3.2.5.
3.2.6.
3.2.7.
3.2.8.
ANÁLISE DO SISTEMA ............................................................................................... 29
ENTREVISTA COM O USUÁRIO ................................................................................ 29
PROPOSTA DE PROJETO .......................................................................................... 29
DOCUMENTO DE REQUISITOS ............................................................................... 30
DIAGRAMA DE CASOS DE USO ............................................................................... 30
DESCRIÇÕES DOS CASOS DE USO.......................................................................... 31
DIAGRAMA DE CLASSES ........................................................................................... 32
PROTÓTIPO ................................................................................................................ 33
DESENVOLVIMENTO ................................................................................................. 34
TELA DE CONSULTA PRINCIPAL ............................................................................ 34
CADASTRO DE NOVO REGISTRO ............................................................................ 36
ALTERAR REGISTRO .................................................................................................. 38
EXPORTAR .................................................................................................................. 39
CRIAÇÃO E CONTROLE DE REGISTROS DE PREVISÃO ....................................... 40
PROCEDIMENTO DE PREVISÕES ............................................................................ 40
PROCEDIMENTO DE VÍNCULO DE FATURAS ÀS PREVISÕES ............................ 43
TRIGGERS ................................................................................................................... 45
4.
DIFICULDADES ENCONTRADAS ...................................................................................... 49
4.1.1.
4.1.2.
DIFICULDADES DE ANÁLISE ................................................................................... 49
DIFICULDADES DE DESENVOLVIMENTO ............................................................. 49
5.
CONCLUSÕES ......................................................................................................................... 51
6.
REFERÊNCIAS BIBLIOGRÁFICAS .................................................................................... 52
APÊNDICES E/OU ANEXOS .......................................................................................................... 54
APÊNDICE 1 – QUESTÕES INICIAIS PARA A ENTEVISTA ................................................... 54
APÊNDICE 2 – PROPOSTA DE PROJETO .............................................................................. 55
APÊNDICE 3 – DOCUMENTO DE REQUISITOS .................................................................... 59
APÊNDICE 4 – DESCRIÇÕES DE CASOS DE USO ................................................................ 63
8
LISTA DE FIGURAS
FIGURA 1 - FASES DO RUP .................................................................................................................... 14
FIGURA 2 - PARADIGMA DE PROTOTIPAÇÃO DE PRESSMAN ................................................................... 20
FIGURA 3 - TELA INICIAL DO ASTAH COMMUNITY ................................................................................. 25
FIGURA 4 - EXEMPLO DE PROTÓTIPO UTILIZANDO O BALSAMIQ MOCKUPS ........................................... 26
FIGURA 5 - DIAGRAMA DE CASOS DE USO ............................................................................................ 31
FIGURA 6 - DESCRIÇÃO DO CASO DE USO "CONSULTAR PLANILHA" .................................................... 32
FIGURA 7 - DIAGRAMA DE CLASSES...................................................................................................... 33
FIGURA 8 - PROTÓTIPO DA TELA DE EDIÇÃO DE REGISTRO .................................................................... 34
FIGURA 9 - TELA PRINCIPAL SEM DETALHES (PROTÓTIPO) .................................................................... 35
FIGURA 10 - TELA PRINCIPAL DE SEM DETALHES (REAL) ...................................................................... 35
FIGURA 11 - TELA PRINCIPAL COM DETALHES (PROTÓTIPO) .................................................................. 35
FIGURA 12 - TELA PRINCIPAL DE COM DETALHE (REAL)........................................................................ 36
FIGURA 13 - TELA DE NOVO REGISTRO (PROTÓTIPO) ............................................................................. 37
FIGURA 14 - TELA DE CADASTRO DE NOVO REGISTRO (REAL) ............................................................... 37
FIGURA 15 - TELA DE ALTERAÇÃO DE REGISTRO (PROTÓTIPO) .............................................................. 38
FIGURA 16 - TELA DE ALTERAÇÃO DE REGISTRO (REAL) ....................................................................... 39
FIGURA 17 - RELATÓRIO EXPORTADO DO SISTEMA ............................................................................... 40
FIGURA 18 - CURSOR PARA DADOS DE NOMEAÇÃO ............................................................................... 41
FIGURA 19 - CURSOR PARA DADOS DE APLICAÇÃO ............................................................................... 41
FIGURA 20 – VALIDAÇÃO E UPDATE NA TABELA DE PREVISÃO .............................................................. 42
FIGURA 21 - INSERÇÃO NA TABELA (REGISTRO NOVO) .......................................................................... 43
FIGURA 22 - CURSOR PARA DADOS DE FATURA ..................................................................................... 44
FIGURA 23 - VALIDAÇÃO SE EXISTE PREVISÃO OU NÃO......................................................................... 44
FIGURA 24 - VALIDAÇÃO DE ITENS DE FATURA E INSERÇÃO ................................................................. 45
FIGURA 25 - TRIGGER PARA CONTROLE DE DATA DE VENCIMENTO DE NOMEAÇÕES .............................. 45
FIGURA 26 - TRIGGER PARA CONTROLE DE DATA DE VENCIMENTO DE APLICAÇÕES .............................. 46
FIGURA 27 - TRIGGER PARA CONTROLE DE STATUS DE APLICAÇÕES ..................................................... 46
FIGURA 28 - TRIGGER PARA CONTROLE DE STATUS DE FATURAS ........................................................... 47
FIGURA 29 - TRIGGER PARA CONTROLE DE STATUS EM NOMEAÇÕES ..................................................... 48
FIGURA 30 - TRIGGER PARA CONTROLE DE ALTERAÇÃO DE VALOR EM CONTRATO................................ 48
FIGURA 31 - CAPA DO DOCUMENTO DE PROPOSTA DE PROJETO ........................................................... 55
FIGURA 32 - SUMÁRIO DO DOCUMENTO DE PROPOSTA DE PROJETO ..................................................... 56
FIGURA 33 - PÁGINA 3 DO DOCUMENTO DE PROPOSTA DE PROJETO ..................................................... 57
FIGURA 34 - PÁGINA 4 DO DOCUMENTO DE PROPOSTA DE PROJETO ..................................................... 58
FIGURA 35 - CAPA DO DOCUMENTO DE REQUISITOS ............................................................................. 59
FIGURA 36 - ÍNDICE DO DOCUMENTO DE REQUISITOS ........................................................................... 60
FIGURA 37 - PÁGINA 3 DO DOCUMENTO DE REQUISITOS....................................................................... 61
FIGURA 38 - PÁGINA 4 DO DOCUMETO DE REQUISITOS ......................................................................... 62
FIGURA 39 - CAPA DA DESCRIÇÃO DO CASO DE USO CONSULTAR PLANILHA ...................................... 63
FIGURA 40 - ÍNDICE DA DESCRIÇÃO DO CASO DE USO CONSULTAR PLANILHA .................................... 64
FIGURA 41 - PÁGINA 3 DA DESCRIÇÃO DO CASO DE USO CONSULTAR PLANILHA ................................ 65
FIGURA 42 – CAPA DA DESCRIÇÃO DE CASO DE USO FILTRAR REGISTROS........................................... 66
FIGURA 43 - ÍNDICE DA DESCRIÇÃO DE CASO DE USO FILTRAR REGISTROS ......................................... 67
FIGURA 44 - PÁGINA 3 DA DESCRIÇÃO DO CASO DE USO FILTRAR REGISTROS ..................................... 68
FIGURA 45 - CAPA DA DESCRIÇÃO DO CASO DE USO FAZER LANÇAMENTO MANUAL .......................... 69
FIGURA 46 - ÍNDICE DA DESCRIÇÃO DO CASO DE USO FAZER LANÇAMENTO MANUAL ........................ 70
FIGURA 47 - PÁGINA 3 DA DESCRIÇÃO DO CASO DE USO FAZER LANÇAMENTO MANUAL ................... 71
FIGURA 48 - PÁGINA 4 DA DESCRIÇÃO DO CASO DE USO FAZER LANÇAMENTO MANUAL ................... 72
FIGURA 49 - CAPA DA DESCRIÇÃO DO CASO DE USO ALTERAR PREVISÃO ........................................... 73
FIGURA 50 - ÍNDICE DA DESCRIÇÃO DO CASO DE USO ALTERAR PREVISÃO ......................................... 74
FIGURA 51 - PÁGINA 3 DA DESCRIÇÃO DO CASO DE USO ALTERAR PREVISÃO ..................................... 75
9
LISTA DE SIGLAS E ABREVIATURAS
COMEX Comercialização Exterior
IBM
International Business Machines
IDE
Integrated Development Environment
LTDA
Limitada
OMG
Object Management Group
POO
Programação Orientada a Objetos
RAD
Rapid Application Development
RUP
Rational Unified Process
SAP
Systeme, Anwendungen und Produkte in der Datenverarbeitung
SGBD
Sistema de Gerenciamento de Bando de Dados
SQL
Structured Query Language
UFMT
Universidade Federal de Mato Grosso
UML
Unified Modeling Language
VCL
Visual Component Library
10
RESUMO
O presente relatório tem por objetivo apresentar as atividades realizadas
durante a disciplina de Estágio Supervisionado do curso de Sistemas de Informação da
Universidade Federal de Mato Grosso, do discente Sergio Augusto Cola Dias, na
empresa Amaggi Exportação e Importação LTDA. São descritos os conceitos e
métodos de análises, técnicas e ferramentas de desenvolvimento de software, para a
criação de um sistema de previsão de pagamentos, afim de facilitar e aprimorar a
automação do trabalho das áreas de Execução e Engenharia Financeira da empresa. O
sistema foi desenvolvido utilizando o SGBD Oracle, programação em banco de dados
com o PL/SQL Developer para controle de regras de negócio, a ferramenta Delphi,
para criação de telas, exibição de dados, geração de relatórios e definição de layouts.
Todos os conceitos, métodos e ferramentas utilizados para o desenvolvimento desta
aplicação, serão descritos ao decorrer do relatório.
11
INTRODUÇÃO
O presente relatório tem por objetivo exibir as atividades desenvolvidas na
empresa Amaggi Exportação e Importação LTDA., em cumprimento à matéria de
estágio supervisionado, do curso de Sistemas de Informação da Universidade Federal
de Mato Grosso (UFMT).
A Amaggi é uma empresa do ramo do agronegócio e tem suas principais
atividades nas áreas de originação, comercialização de grãos e insumos, produção
agrícola e de sementes de soja, operações portuárias, transporte fluvial e geração e
comercialização de energia elétrica, mas o destaque da empresa se dá pela exportação
de commodities. Para isto, são carregados navios com os produtos, que são levados aos
seus destinos e, assim, distribuídos.
O projeto tem como foco desenvolver uma aplicação que substitua a existente
e que faça o controle e apresentação de previsões de pagamento coerentes para, assim,
tornar mais ágil e fácil o trabalho das equipes de execução e engenharia financeira da
empresa. Para a criação deste sistema de previsão de pagamentos, são utilizados dois
outros sistemas base para gerar as informações.
O sistema de Comercialização Exterior (COMEX) é responsável por todas as
entradas de dados, desde a criação de contratos, nomeações de navios e aplicações de
contratos, até a emissão de faturas para as contrapartes. As previsões de pagamento
são criadas no momentos em que as ações de nomeação de navio ou aplicação de
contratos são feitas. Assim que as faturas são criadas no sistema COMEX, suas
informações são enviadas ao segundo sistema, o SAP, que lê todas estas informações,
valida-as, faz a movimentação nas contas contábeis e retorna se a ação teve êxito ou
não.
O sistema existente, feito na plataforma web, apresenta falhas em regras de
cálculo, funcionalidades desnecessárias, exige muito trabalho manual da parte do
usuário e apresenta lentidão no carregamento dos dados. No fluxo atual, muitas vezes
o usuário deve fazer as nomeações de navios e aplicações de contratos e,
posteriormente, criar a previsão manualmente na planilha, devido às falhas de regra.
A planilha atual não apresenta controle e atualização da previsão quando sua origem
sofre alguma alteração. Ao criar uma fatura correspondente a uma previsão, o usuário
deve informá-la manualmente na planilha. Outro problema apresentado é que uma
12
previsão de pagamento pode ter várias faturas e a planilha atual só permite a inserção
de uma fatura por previsão.
Com base nos pontos apresentados acima, foi proposto o desenvolvimento de
um sistema desktop que atenda todas as necessidades dos usuários, utilizando a
ferramenta RAD padrão da empresa, o Delphi. O novo sistema de previsão de
pagamento permitirá que os usuários façam consultas mais rápidas, com todos os
detalhes necessários e de forma totalmente automatizada. A partir do momento em que
o usuário fizer as nomeações de navio e aplicações de contrato, o sistema criará,
automaticamente, as previsões de pagamento e, ao fazer as faturas, as vinculará às
previsões correspondentes. O sistema apresentará funcionalidades novas para
diferenciação de “faturas de compensação”, edição facilitada de dados, além de um
relatório de conferência para usuários do departamento financeiro.
Na primeira seção deste relatório são apresentadas desde tecnologias,
embasamento teórico, metodologia de desenvolvimento, conceito de prototipação de
software, de bancos de dados e de programação.
Na segunda seção serão apresentadas matérias, técnicas e métodos utilizados
para o desenvolvimento da aplicação. Serão apresentadas as ferramentas de
desenvolvimento e suas linguagens, bem como as de modelagem e prototipação.
Na terceira seção serão apresentados os resultados obtidos na análise e
desenvolvimento da aplicação, seguidos pela descrição de dificuldades encontradas no
projeto e conclusões finais, na quarta e quinta seção, respectivamente. Por fim, serão
apresentados os artefatos criados para desenvolvimento do projeto e as telas do
sistema.
13
1. REVISÃO DE LITERATURA
Nesta seção
são
apresentados
conceitos
e
técnicas
utilizadas
no
desenvolvimento deste projeto de estágio e, também, a fundamentação teórica. O
aprendizado que o curso de Sistemas de Informação proporcionou foi base principal
para a concretização do projeto.
1.1. ENGENHARIA DE SOFTWARE
A engenharia de software é uma disciplina relacionada com todos os aspectos da
produção de software, desde os estágios iniciais de especificação do sistema até a sua
manutenção, depois de entrar em operação (Sommerville, 2007).
Bauer (1969 apud Pressman, 2011) afirma que a engenharia de software é o
estabelecimento e o emprego de sólidos princípios de engenharia de modo a obter
software de maneira econômica, que seja confiável e funcione de forma eficiente em
máquinas reais. Esta definição, apesar de superficial – pois não cita a importância de
prazos, qualidade de software e satisfação do cliente, por exemplo – nos dá uma base
para entendermos do que se trata a engenharia de software.
A IEEE (1992 apud Pressman, 2011), tem uma definição mais abrangente e diz
que engenharia de software é a aplicação de uma abordagem sistemática, disciplinada
e quantificável no desenvolvimento, na operação e na manutenção de software, isto é,
a aplicação de engenharia de software.
Este projeto utilizou técnicas e conceitos de engenharia de software que serão
descritas no decorrer deste trabalho.
1.1.1. RATIONAL UNIFIED PROCESS
Segundo a Rational® Software Corporation, uma família de software da IBM,
o Rational Unified Process (RUP) é um Processo de Engenharia de Software que
fornece abordagens disciplinadas para a atribuição de tarefas e responsabilidades
dentro de uma organização de desenvolvimento. Seu objetivo é assegurar uma
14
produção de software de alta qualidade que atenda as necessidades dos usuários finais,
dentro de uma agenda e orçamento previstos.
A empresa diz, ainda, que o RUP é um guia de como utilizar, efetivamente, o
Unified Modeling Language (UML).
O RUP permite que todos os times do projeto tenham acesso a mesma base de
conhecimento, compartilhando da mesma linguagem e processo de desenvolvimento
de software, não importando a área de atuação das equipes (design, desenvolvimento,
testes, gerenciamento entre outras), aumentando a produtividade.
O ciclo de vida do software é dividido em quatro fases, conforme ilustrado na
figura 1: concepção, elaboração, construção e transição. Cada fase é concluída com
um marco bem definido, objetivos devem ser alcançados e decisões tomadas.
Figura 1 - Fases do RUP
Fonte: http://www.infoescola.com/engenharia-de-software/rup/
1.1.1.1. FASE DE CONCEPÇÃO
Nesta primeira fase, é necessário identificar as entidades que estarão em
contato com o sistema e definir seus papéis de uma forma abstrata. Esta fase é
importante para definir metas e prazos do projeto, por meio dos marcos, identificar
casos de uso do sistema, definir o escopo do projeto e estimar os recursos necessários
para o desenvolvimento do software.
Durante esta fase, é recomendada a criação dos seguintes artefatos:

Documento de visão;
15

Modelo de casos de uso (inicial);

Glossário inicial do projeto;

Casos de negócio, que incluem contextos de negócio e critérios de sucesso;

Avaliação inicial de riscos;

Plano de projeto, mostrando as fases e interações;

Modelo de negócio (se necessário);

Um ou mais protótipos.
Apesar de recomendado, não é obrigatório passar por todas as atividades e criar
todos os artefatos indicados. Esta é uma decisão que cabe ao gestor, dependendo da
realidade do negócio e necessidade do cliente.
O primeiro e um dos principais marcos do projeto aparece ao final da sua fase
de concepção. Ele é chamado, em sua tradução literal, de “Marco dos Objetivos do
Ciclo de Vida” (Lifecycle Objectives). Para que esta fase seja aprovada, serão aplicados
alguns critérios de avaliação, com o risco de o projeto ser cancelado ou totalmente
repensado caso não passe:

Consentimento dos envolvidos na definição do escopo, prazos e custos de
projeto;

Entendimento dos requisitos evidenciados pelos casos usos iniciais;

Credibilidade dos prazos, custos, prioridades, riscos e procedimentos de
desenvolvimento;

Profundidade e amplitude dos protótipos desenvolvidos;

Despesas planejadas versus despesas realizadas.
1.1.1.2. FASE DE ELABORAÇÃO
Nesta fase é definido o segundo marco: o “Marco da Arquitetura do Ciclo de
Vida” (Lifecycle Architecture), que tem por objetivo analisar o domínio do problema,
desenvolver o plano do projeto, estabelecer a arquitetura e mitigar elementos de risco.
Ao final desta fase, o processo de engenharia é considerado concluído e o próximo
passo é decidir se o projeto seguirá parar as próximas fases; construção e transição. Os
artefatos resultantes desta fase incluem:
16

Modelo de casos de uso (todos os casos de uso e atores identificados e
descrição de alguns casos de uso);

Requisitos funcionais e não funcionais;

Descrição de arquitetura do software;

Protótipo funcional;

Lista revisada de riscos e casos de uso;

Manual de usuário preliminar.
Para decidir se o projeto segue para as próximas fases ou é cancelado (ou
repensado), a avaliação para a fase de elaboração se dá pelas respostas às seguintes
perguntas:

A visão do produto é estável?

A arquitetura é estável?

O plano de construção é suficientemente detalhado e preciso?

As entidades envolvidas estão de acordo com o que foi apresentado até aqui?

Despesas planejadas versus despesas realizadas são aceitáveis?
1.1.1.3. FASE DE CONSTRUÇÃO
A terceira fase do projeto, segundo a Rational®, é o processo de produção com
ênfase no gerenciamento de recursos e controle de operações, com o objetivo de
otimizar custos, além de qualidade e custo de software. Nesta fase todos os
componentes construídos devem ser testados, a fim de decidir se o software e os
usuários estão preparados para entrarem em operação real.
Ao final deste marco – o “Marco da Capacidade Operacional Inicial” (Initial
Operational Capability), o sistema está pronto para ser liberado ao usuário final e
precisa atender os seguintes pontos:

Produto e plataforma devem estar adequadamente integrados;

O manual do usuário deve estar pronto.
17
Caso este marco não passe na avaliação, os prazos são estendidos. A avaliação é
feita pelas respostas às seguintes perguntas:

O sistema está estável para ser liberado aos usuários?

As entidades envolvidas estão preparadas para a transição?

Despesas planejadas versus despesas realizadas ainda são aceitáveis?
1.1.1.4. FASE DE TRANSIÇÃO
A quarta e última fase define o marco de “Liberação do Produto” (Product
Release). Nesta fase, o produto é liberado aos usuários para que possam fazer a
primeira utilização, onde podem-se encontrar bugs não previstos, elaborar novas
funcionalidades e sugerir melhorias nas funcionalidades desenvolvidas. É uma fase de
muita interação entre os usuários do sistema e os times de desenvolvimento, pois é
liberada a então chamada “versão beta” do sistema, além de haver treinamento dos
usuários e divulgação do sistema.
Os objetivos desta fase são:

Garantir que o usuário consiga utilizar o sistema sem acompanhamento;

Garantir que haja consentimento das entidades envolvidas.
Neste ponto, é avaliado se o sistema atende o que era esperado e se será necessário
começar outro ciclo de desenvolvimento. Para isto, é necessário que as perguntas
abaixo sejam respondidas:

O usuário final está satisfeito?

Despesas planejadas versus despesas realizadas ainda são aceitáveis?
1.1.1.5. INTERAÇÕES
Cada marco do projeto pode, ainda, ser dividido em interações, que permite
que o sistema seja construído de forma gradual até ser alcançado o produto final. A
abordagem interativa tem alguns benefícios quando comparado ao modo tradicional:

Riscos são identificados mais cedo;

Facilidade em mudanças;
18

Maior nível de reuso;

O time de projeto pode aprender ao longo do caminho;

No geral, o produto final tem mais qualidade.
1.1.2. UNIFIED MODELING LANGUAGE
De acordo com Martin Fowler (2005), UML é uma família de notações gráficas
apoiada por um meta-modelo único, que ajuda na descrição e no projeto de sistemas
de software, particularmente daqueles construídos utilizando o estilo orientado a
objetos (OO).
Para Guedes (2009), o UML é uma linguagem visual utilizada para modelar
softwares baseados no paradigma de orientação a objetos. É uma linguagem de
modelagem de propósito geral que pode ser aplicada a todos os domínios de aplicação.
Guedes reforça que a UML não é uma linguagem de programação, mas, sim, de
modelagem que auxilia os engenheiros de softwares a modelarem o sistema,
identificando suas características, requisitos e interações necessárias.
Com o surgimento do UML 2.0 muitos diagramas originais sofreram uma retenção
ou expansão. Na versão 2.0, a linguagem evoluiu para ajudar engenheiros e
modeladores de sistemas a detalhar mais todas as etapas do processo de criação de
software. Segundo a Object Management Group (2005), existem treze tipos de
diagramas, divididos em categorias, sendo seis diagramas para estrutura, três para
comportamento e quatro para interações, conforme descrito abaixo:
Diagramas de estrutura:

Diagrama de classes

Diagrama de Objetos

Diagrama de Componente

Diagrama de Estrutura Composta

Diagrama de Pacotes

Diagrama de Implantação
19
Diagramas de Comportamento:

Diagrama de Casos de Uso

Diagrama de Atividades

Diagrama de Estado de Máquina
Diagramas de Interação:

Diagrama de Sequência

Diagrama de Comunicação

Diagrama de Tempo

Diagrama de Visão Geral
Com a criação de diagramas, os envolvidos no projeto podem ter uma visão mais
completa do sistema, facilitando tanto o entendimento ao construí-lo, quanto ao
modificá-lo, se necessário.
Na seção a seguir, é mostrada uma parte muito importante em um projeto de
desenvolvimento de software: a prototipação.
1.1.3. PROTOTIPAÇÃO
Segundo Guedes (2009), a prototipação é uma técnica bastante popular e de
fácil aplicação, que consiste em desenvolver rapidamente um “rascunho” do que seria
o sistema de informação quando ele estivesse finalizado. Um protótipo, normalmente,
apresenta pouco mais do que a interface do software a ser desenvolvido, ilustrando
como as informações seriam inseridas e recuperadas no sistema, apresentando alguns
exemplos com dados fictícios dos quais seriam os resultados apresentados pelo
software, principalmente em forma de relatórios. O autor diz, ainda, que o processo de
prototipação pode evitar que, depois de meses ou, até mesmo, anos de
desenvolvimento, ao implantar o sistema, seja descoberto que o software não atende
as necessidades do cliente. A prototipação pode, também, mostrar falhas de
comunicação nas entrevistas iniciais.
Sommerville (2007) define um protótipo como uma versão inicial de um
sistema de software usado para demonstrar conceitos, experimentar opções de projeto
e, geralmente, conhecer mais sobre o problema e suas possíveis soluções.
20
O paradigma da prototipação, por Pressman (2011), figura 2, é apresentado em
uma sequência de ações que começam com a Comunicação, seguida pelo Projeto
Rápido, Modelagem de Projeto rápido, Construção de um protótipo e, fechando o
ciclo, Emprego, Entrega e Realimentação.
Na fase de Comunicação, são definidos os objetivos principais do sistema e é
identificado se há necessidade de melhor definição em alguma das áreas. O Projeto
Rápido apresenta os aspectos palpáveis para o cliente, como o layout. Esta fase tem
como consequência a Modelagem de Projeto Rápido, que podemos chamar de
protótipo. A última fase é a fase de feedback do sistema, onde a equipe de
desenvolvimento pode apresentar o protótipo para verificar se as necessidades do
cliente estão sendo atendidas.
Figura 2 - Paradigma de prototipação de Pressman
Explicados os conceitos de planejamento e modelagem do projeto, são
apresentadas, abaixo, a definição das ferramentas utilizadas para a implementação
deste software.
21
1.1.4. BANCO DE DADOS
Segundo Ramakrishnan (1999), um banco de dados é uma coleção de dados,
tipicamente descrevendo as atividades de uma ou mais organizações relacionadas. O
autor define, também, o Sistema de Gerenciamento de Banco de Dados (SGBD) como
um software desenhado para auxiliar na manutenção e utilizar grandes coleções de
dados, levando em consideração que os dados de um sistema em utilização crescem
rapidamente.
A Oracle (2016), diz que um banco de dados é uma coleção de informações
tratadas como uma unidade e tem como propósito coletar, armazenar e recuperar as
informações relacionadas para uso de aplicações de bancos de dados. SGBD é
definido, pela Oracle (2016), como um software que controla o armazenamento,
organização e recuperação de dados.
A implementação das regras de negócio deste sistema foi feita, em sua grande
maioria, via procedimentos em banco de dados, utilizando a linguagem PL/SQL, da
Oracle.
1.1.5. PROGRAMAÇÃO ORIENTADA A OBJETOS
Segundo Farinelli (2007), a Orientação a Objetos é uma tecnologia que enxerga
os sistemas como sendo uma coleção de objetos integrantes, permitindo aplicar o reuso
e extensibilidade dos softwares e, ainda, que Orientação a Objetos consiste em
considerar os sistemas computacionais como uma coleção de objetos que interagem
de maneira organizada.
De acordo com Schildt (2014), a Programação Orientada a Objetos é uma
forma poderosa de programação que combinou as melhores ideias da programação
estruturada e as combinou com diversos novos conceitos. Para auxiliar na POO, todas
a linguagens de programação apresentam alguns traços em comum: classe, objeto,
encapsulamento, polimorfismo e herança, que o autor define conforme abaixo.
22
1.1.5.1. CLASSE
Uma classe é um modelo que define a forma de um objeto, especificando as
variáveis que contém e os métodos que opera. A classe é, essencialmente, um conjunto
de planos de como construir um objeto, é uma abstração lógica.
1.1.5.2. OBJETO
O objeto nada mais é do que a “materialização” da classe. Diferentemente da
classe, o objeto, assim que instanciado, “ganha vida” e pode executar as operações
predefinidas pela sua classe.
1.1.5.3. ENCAPSULAMENTO
Encapsulamento é um mecanismo de programação que une o código e os dados
que manipula e os mantém reservados dentro da classe, evitando que haja
interferências externas e o uso inapropriado.
Estes métodos e atributos podem ser definidos como públicos ou privados.
Quando privados, eles são protegidos dentro da classe. Quando públicos, outras partes
do programa podem acessá-los.
1.1.5.4. POLIMORFISMO
Polimorfismo é uma qualidade que permite que uma interface acesse uma
classe geral de ações. O conceito de polimorfismo pode ser expressado pela frase “uma
interface, diversos métodos”, o que significa que é possível desenhar uma interface
genérica para um grupo de atividades relacionadas.
1.1.5.5. HERANÇA
Herança é o processo no qual um objeto pode adquirir propriedades de outro.
Utilizando esta característica da POO, os objetos precisam apenas definir quais as
qualidades que o diferem da classe genérica.
23
Os paradigmas da POO foram utilizados na ferramenta Delphi, que é uma das
principais ferramentas utilizadas nos sistemas legado da empresa. Sua definição é
apresentada no tópico 2.3.3. deste arquivo.
24
2. MATERIAS, TÉCNICAS E MÉTODOS
Nesta seção, são abordadas as tecnologias, ferramentas e técnicas que foram
utilizadas para o desenvolvimento das atividades de análise e desenvolvimento para
atendimento deste estágio.
O desenvolvimento da parte estrutural do sistema foi feito utilizando a
tecnologia Delphi e a implementação de regras de negócio foram feitas via
procedimentos em banco de dados utilizando a ferramenta PL/SQL Developer, versão
11.1, e os dados armazenados no banco de dados Oracle 10g.
Nos próximos tópicos serão abordadas todas as técnicas e tecnologias que
auxiliaram no desenvolvimento do software; elicitação de requisitos, prototipação e
desenvolvimento, respectivamente.
2.1. ELICITAÇÃO DE REQUISITOS
Para identificar as dificuldades dos usuários com o sistema existente, bem
como entender suas necessidades para o novo sistema, considerando que a empresa
facilita bastante a conversa entre analistas e usuários, não necessitando de reuniões
formais, foi feita uma entrevista informal, porém seguindo um pequeno roteiro para
ter um ponto de partida e manter o foco da conversa. Em complemento a entrevista,
foram feitos os casos de uso para que sejam ilustradas as ações dos usuários em relação
ao sistema. Ambas as técnicas são definidas nos próximos tópicos.
2.1.1. ENTREVISTA
Segundo Sommerville (2007), entrevistas formais ou informais com os
stakeholders do sistema fazer parte da maioria dos processos de engenharia de
software. O autor diz que as entrevistas são úteis para obter um entendimento geral
sobre o que os stakeholders fazer, como eles podem interagir com o sistema e as
dificuldades que enfrentam ao utilizar os sistemas atuais.
A entrevista é uma técnica simples e que, geralmente, gera bons resultados,
pois, por mais que a conversa comece utilizando um roteiro, os stakeholders acabam
25
se abrindo mais em relação ao que esperam do sistema e pontos que, possivelmente,
não estavam previstos são tocados, melhorando ainda mais a percepção da equipe de
desenvolvimento sobre o sistema.
2.1.2. CASOS DE USO
De acordo com Fowler e Scott (1997 apud Sommerville, 2007), um caso de uso
engloba um conjunto de cenários, sendo cada cenário um encadeamento isolado ao
longo do caso de uso. Se um cenário incluir vários encadeamentos, existirá um cenário
para interação normal e mais cenários para cada possível exceção.
Guedes (2009) diz que o diagrama de casos de uso é o diagrama mais geral e
informal da UML, utilizado, normalmente, nas fases de levantamento e análise de
requisitos do sistema, embora venha a ser consultado durante todo o processo de
modelagem e possa servir de base para outros diagramas.
O diagrama de casos de uso do presente sistema foi criado utilizando a
ferramenta Astah Community. Na figura 3 a tela inicial do software é mostrada.
Figura 3 - Tela inicial do Astah Community
Ainda antes de começar o desenvolvimento, de fato, foi feita a prototipação do
sistema para ilustrar um modelo próximo à realidade. Foi utilizada a ferramenta
Balsamiq Mockups, descrita a seguir.
26
2.2. BALSAMIQ MOCKUPS
Segundo a Balsamiq (2016), o Balsamiq Mockups é uma ferramenta de desenho
de interface para criar wireframes (também conhecidos como mockups ou protótipos
de baixa fidelidade). A ferramenta ajuda a gerar rascunhos digitais de ideias de produto
afim de facilitar as discussões e entendimentos antes de começar a codificação. Na
figura 4 é apresentado um exemplo de prototipação de software.
Figura 4 - Exemplo de protótipo utilizando o Balsamiq Mockups
Fonte: Balsamiq (2016)
O Balsamiq Mockups oferece uma vasta biblioteca de componentes que vai de
botões até painéis, menus, formulários, mídia, símbolos, entre outros. A ferramenta é
de fácil utilização por utilizar a tecnologia drag-and-drop.
Na próxima seção, são citadas as tecnologias de armazenamento de dados e
programação em banco de dados, utilizando ferramentas da Oracle.
27
2.3. ARMAZENAMENTO DE DADOS E PROGRAMAÇÃO
Nos próximos tópicos serão abordadas as ferramentas para armazenamento e
controle de dados e desenvolvimento de software.
2.3.1 ORACLE 10G
O Oracle 10g, da Oracle, é primeiro SGBD desenhado para a utilização de
computação em grid, o que melhora a facilidade de manipulação dos dados e,
consequentemente, a qualidade do serviço.
Tendo a sua primeira versão liberada em janeiro de 2004, o Oracle 10g
proporciona diversas vantagens que alteram o jeito em que os data centers operam. A
computação em grades representa a culminação de estratégias de longo prazo em
reduções dramáticas no custo de computação, ao passo em que aumenta sua qualidade.
Para a implementação de regras de negócio, procedimentos de cálculo e
inteligência de sistema, foi utilizada a ferramenta PL/SQL Developer, também da
Oracle, descrita abaixo.
2.3.2. PL/SQL DEVELOPER 11.0
Segundo a Allround Automations (2016), o PL/SQL Developer é um Ambiente
de Desenvolvimento Integrado (do inglês, Integrated Development Environment, IDE)
que é especificamente utilizado para o desenvolvimento de procedimentos para bancos
de dados Oracle.
Esta ferramenta apresenta algumas características facilitadoras para o
desenvolvimento em banco, como, por exemplo, assistente de código, dicas de
compilação, ferramenta de endentação automática, debugger integrado, entre outras.
O PL/SQL foi utilizado para o desenvolvimento de procedimentos
responsáveis pelo controle de regras de negócio. Os procedimentos são executados por
Jobs com um tempo pré-definido. O desenvolvimento de layout de sistema, exposição
de dados e de relatório utilizaram a ferramenta Delphi, descrito no próximo tópico, que
é a principal ferramenta de desenvolvimento dos sistemas legado da empresa.
28
2.3.3. DELPHI 7
De acordo Leão (2003), o Delphi 7 é uma ferramenta de desenvolvimento
rápido de aplicações (RAD), criada pela Borland Software Corporation, que alia a
faciliade do Visual Basic ao poder da linguagem Object Pascal. O Delphi aprsenta uma
biblioteca de componentes inteiramente desenvolvida em Object Pascal, a VCL
(Visual Component Library), na qual cada componente é representado por uma classe.
2.3.3.1. OBJECT PASCAL
Segundo o Guia da Linguagem Object Pascal, da Borland Software
Corporation, o Object Pascal é uma linguagem de programação de alto nível que
suporta tanto a programação estruturada, quanto a POO. Seus benefícios incluem
códigos de fácil leitura, rápida compilação e a utilização de múltiplas unidades de
arquivos para programação modular.
29
3. RESULTADOS
Nesta disciplina de estágio supervisionado, o objetivo era desenvolver um sistema
que fizesse previsões de pagamentos para cada operação de nomeação de navio e/ou
aplicação de contrato da empresa, afim de facilitar o controle para o fluxo de baixa da
empresa.
Nesta seção são apresentados os resultados obtidos com a utilização dos conceitos,
tecnologias e ferramentas apresentadas nas seções anteriores.
3.1. ANÁLISE DO SISTEMA
Nesta fase, alguns artefatos foram produzidos como resultado da análise do sistema
a ser desenvolvido, conforme sugere o processo unificado da Rational®.
3.1.1. ENTREVISTA COM O USUÁRIO
Para ajudar no entendimento das dificuldades encontradas utilizando o sistema
atual, bem como para esclarecimento das necessidades dos usuários para o novo
sistema, foram feitas entrevistas de cunho indireto, apesar de haver um roteiro para
iniciação da conversa e, também, para manter o foco nas características do sistema. As
perguntas iniciais da entrevista podem ser verificadas no Apêndice 1.
3.1.2. PROPOSTA DE PROJETO
O documento de proposta de projeto é fundamental para que sejam
identificados, junto aos stakeholders, quais são os objetivos do projeto, as principais
dificuldades com o sistema atual, qual é o escopo de atuação do novo sistema, bem
como o seu não-escopo, premissas e restrições.
A proposta de projeto nos fornece uma visão geral do que se trata o sistema e,
também, uma noção inicial dos requisitos do sistema. O documento pode ser visto no
Apêndice 2.
30
3.1.3. DOCUMENTO DE REQUISITOS
No Apêndice 3, é apresentado o documento de requisitos. Este é um dos
principais artefatos da análise de sistemas, pois é a apresentação oficial do que os
desenvolvedores devem implementar. Deve incluir os requisitos de usuário e uma
especificação detalhada dos requisitos de sistema (Sommerville, 2007).
3.1.4. DIAGRAMA DE CASOS DE USO
O diagrama de casos de uso foi desenhado para que fique clara a forma que os
usuários irão interagir com o sistema, apresentando suas principais funcionalidades,
conforme é apresentado na figura 5.
Todos os usuários envolvidos podem executar a ação Visualizar Planilha, pois
é a principal funcionalidade do sistema, bem como filtrar registros. A ação de Alterar
Registro, só pode ser acessada pelos analistas do departamento de Execução. A
alteração de um registro tem suas limitações, isto é, como os dados das previsões são
oriundos de contratos fechados, nomeações de navios e aplicações de contratos, o
usuário não pode modificar nenhum dado sensível a estas três funcionalidades do
sistema, sendo permitida, assim, apenas a alteração de datas de vencimento e status. O
lançamento manual de registros pode ser feito apenas pelo Gerente do departamento
de execução. Esta funcionalidade foi solicitada para caso haja alguma falha nos
procedimentos regulares, levando em consideração que todos os procedimentos e
regras de negócios são controlados via banco de dados.
31
Figura 5 - Diagrama de Casos de Uso
3.1.5. DESCRIÇÕES DOS CASOS DE USO
A descrição de um caso de uso tem o objetivo de detalhar os passos da ação do
usuário, apresentando seus atores, premissas, fluxos principais, alternativos e de
exceção e, também, os resultados da ação. A figura 6 demonstra a descrição do caso
de uso “Consultar Planilha”, que é a ação principal do usuário no sistema.
Na fase de análise do sistema, foram desenvolvidos artefatos de descrição de casos
de uso para cada uma das ações do usuário no sistema, conforme apresentado no
Apêndice 4.
32
Figura 6 - Descrição do Caso de Uso "Consultar Planilha"
3.1.6. DIAGRAMA DE CLASSES
Segundo Guedes (2009), o diagrama de classes, como o próprio nome diz, define
a estrutura de classes utilizadas pelo sistema, determinando os atributos e métodos que
cada classe tem, além de estabelecer como as classes se relacionam e trocam
informações entre si.
O Diagrama de Classes do presente sistema, apresentado abaixo, na figura 6,
demonstra características de cada classe e as relações entre si, começando pelas ações
de usuário com as validações de login e permissões, detalhando os atributos de uma
previsão e, posteriormente de suas faturas.
33
Figura 7 - Diagrama de Classes
3.1.7. PROTÓTIPO
Para este projeto, foram desenvolvidos protótipos descartáveis das telas do sistema
e apresentados ao usuário para melhor esclarecimento de como o sistema deveria
funcionar quando pronto e levantar requisitos não previstos na entrevista.
Foram construídos protótipos para cada tela do sistema, apresentados no Apêndice
5. Na figura 7 é apresentado um exemplo do protótipo criado para a tela de edição de
registro. Como demonstrado, o sistema limita o usuário a fazer apenas modificações
em que não há impacto nos calculos de previsão e nem alteração de dados sensíveis,
evitando inconsistência entre os dois sistemas.
34
Figura 8 - Protótipo da tela de edição de registro
3.2. DESENVOLVIMENTO
Ao fim do término da fase de análise, foi dado o início da fase de desenvolvimento
para colocar tudo o que foi acordado com os stakeholders em prática. As telas do
sistema estão representadas nos tópicos abaixo.
3.2.1. TELA DE CONSULTA PRINCIPAL
A tela principal do sistema são exibidos os dados de previsão, como contrato,
quantidade e valo da previsão, datas de aplicação e vencimento, produto, navio, entre
outros. A tela disponibiliza, também, botões de novo registro, exportação e
processamento (para atualizar os registros). O usuário tem a opção de ver detalhes da
previsão, para quando há faturas vinculadas.
Abaixo é demonstrada a comparação entre o que foi prototipado para o usuário
e seu resultado final. As figuras 9 e 10 representam o protótipo da tela principal sem
35
detalhamento e o resultado real da tela, respectivamente. As figuras 11 e 12 mostram
a mesma tela com detalhes de fatura.
Figura 9 - Tela principal sem detalhes (protótipo)
Figura 10 - Tela principal de sem detalhes (real)
Figura 11 - Tela principal com detalhes (protótipo)
36
Figura 12 - Tela principal de com detalhe (real)
3.2.2. CADASTRO DE NOVO REGISTRO
A funcionalidade de lançamento manual de registros foi criada apenas para caso
haja alguma falha de sistema, como comunicação do banco com o sistema. Quando o
usuário, com permissão para tal, tenta criar um novo registro, é necessário informar o
contrato em que esta previsão será vinculada e o sistema apenas deixa criar aplicações
que existem para o contrato, de forma a manter sempre a previsão em linha com o que
acontece no sistema. As figuras 13 e 13 demonstram seu protótipo e a tela real,
respectivamente.
37
Figura 13 - Tela de novo registro (protótipo)
Figura 14 - Tela de cadastro de novo registro (real)
38
3.2.3. ALTERAR REGISTRO
Como o sistema preza em manter os dados de previsão consistentes com o que é
apresentado no sistema, a tela de alteração de registro mantém todos os campos
sensíveis bloqueados, permitindo apenas a alteração da data de vencimento e status da
previsão. As figuras 15 e 16 demonstram a prototipação e a tela real de alteração de
registros, respectivamente.
Figura 15 - Tela de alteração de registro (protótipo)
39
Figura 16 - Tela de alteração de registro (real)
3.2.4. EXPORTAR
Os usuários podem exportar os dados de previsão para Excel, afim de que possam
fazer suas análises e conferências em uma plataforma mais maleável. O resultado do
relatório é apresentado na figura 12.
40
Figura 17 - Relatório exportado do sistema
3.2.5. CRIAÇÃO E CONTROLE DE REGISTROS DE PREVISÃO
A criação e o controle das previsões de pagamento são feitos via procedimento em
banco de dados. As tabelas que armazenam os dados de nomeação de navio e aplicação
de contrato possuem uma flag de controle para informar se a previsão de pagamento
já foi criada para aquele registro.
Os procedimentos são executados por um job no banco de dados, a cada minuto,
ou podem ser executados manualmente pelo botão “Processar”, na tela. Existem dois
procedimentos para controle de previsões: um exclusivo para previsões de pagamento
e outro para inserção de registros de previsão que não são originados em aplicações
regulares, como por exemplo, faturas. Estes dois procedimentos são explicados nos
dois próximos tópicos.
3.2.6. PROCEDIMENTO DE PREVISÕES
O que este procedimento faz é levantar os registros de nomeações e aplicações
de contrato, por meio de dois cursores, demonstrados nas figuras 13 e 14,
respectivamente, que possuem o status de “previsão não criada”.
41
Figura 18 - Cursor para dados de nomeação
Figura 19 - Cursor para dados de aplicação
Após levantar os dados, o sistema faz validações para ver se é um registro novo
ou se ele já existe na tabela de previsões de pagamento para, enfim, inseri-lo ou
42
editá-lo. Este controle é demonstrado na figura 15 e a inserção na figura 16. As
mesmas validações são feitas utilizando o cursor de aplicações.
Figura 20 – Validação e update na tabela de previsão
43
Figura 21 - Inserção na tabela (registro novo)
3.2.7. PROCEDIMENTO DE VÍNCULO DE FATURAS ÀS PREVISÕES
O procedimento de criação de vínculo de faturas às previsões olha para a tabela de
faturas, ao invés das tabelas de aplicações, afim de que sejam identificadas as faturas
criadas para as previsões feitas e, também, para atender a previsão de custos (bancos,
taxas portuárias, entre outros), pois não são definidos no momento da nomeação ou
aplicação do contrato. As previsões, neste caso, são criadas a partir do momento em
que as faturas são contabilizadas.
Analogamente ao procedimento de criação de previsão para nomeações e
aplicações, existe uma flag na tabela de faturas que possibilita a identificação de quais
já estão no sistema de previsão. Ao levantar os dados da fatura (figura 17), o sistema
identifica se esta tem relacionada a alguma previsão existente no sistema (figura 18),
se sim, o procedimento inclui esta fatura para a previsão, se não (caso custos) o sistema
cria a previsão (figura 18) e vincula a fatura a ela (figura 19).
44
Figura 22 - Cursor para dados de fatura
Figura 23 - Validação se existe previsão ou não
45
Figura 24 - Validação de itens de fatura e inserção
3.2.8. TRIGGERS
O controle de modificações de previsão é feito via triggers. Quando um usuário
faz qualquer tipo de modificação, sensível à previsão, em um registro de nomeação ou
aplicação, o sistema as triggers são ativadas e o status de “previsão criada” retorna
para o status “0” (não). Os procedimentos lerão novamente este registro e farão as
atualizações na previsão conforme deve ser. Para este projeto, são utilizadas seis
triggers; três para controle de status de previsão, duas para controle de data de
vencimento e uma para controle de valor de previsão.
Figura 25 - Trigger para controle de data de vencimento de nomeações
46
Figura 26 - Trigger para controle de data de vencimento de aplicações
Figura 27 - Trigger para controle de status de aplicações
47
Figura 28 - Trigger para controle de status de faturas
48
Figura 29 - Trigger para controle de status em nomeações
Figura 30 - Trigger para controle de alteração de valor em contrato
49
4. DIFICULDADES ENCONTRADAS
Durante este projeto, foram encontradas algumas dificuldades tanto na análise,
quanto no desenvolvimento do sistema. Tais dificuldades são descritas abaixo,
divididas por tópicos específicos.
4.1.1. DIFICULDADES DE ANÁLISE
Apesar do ambiente empresarial permitir o contato facilitado com os
stakeholders, foram enfrentadas algumas dificuldades na fase de análise relacionadas
ao funcionamento do novo sistema. O sistema antigo não apresentava documentação
alguma. Além disso, os usuários, no começo do projeto, não sabiam explicar como
gostariam que o novo sistema funcionasse e não propunham novas ideias para as
soluções defasadas do sistema antigo por acharem que seu modelo era o máximo que
se podia conseguir de um sistema de previsão de pagamentos. Apenas depois de
algumas conversas informais foi possível começar a realmente explicar tudo o que era
possível fazer e que algumas regras do sistema antigo estavam equivocadas e
desnecessárias.
A demora no entendimento e alinhamento de ideias, causou atraso na análise
e, consequentemente, no desenvolvimento do sistema.
4.1.2. DIFICULDADES DE DESENVOLVIMENTO
Na empresa, existem algumas equipes de desenvolvimento para diferentes
sistemas em diferentes plataformas. O sistema base, o qual gera as informações para a
o sistema de previsão, é um sistema na plataforma .Net, desenvolvido na linguagem
Visual Basic. A exigência era para que o novo sistema fosse desenvolvido parte em
banco de dados (via procedimentos e jobs) e parte utilizando a ferramenta Delphi (que
é a ferramenta mais utilizada em sistemas legados). Como o desenvolvedor Delphi,
selecionado pelo gerente, não tinha familiaridade com o funcionamento do sistema
50
base, foram despendidas algumas horas de conversa para a explicação de como o
sistema funciona.
Outro ponto de dificuldade foi a falta de familiaridade com a ferramenta
Delphi. Foi necessário despender algumas horas de estudo da ferramenta para que
fossem entendidas as suas limitações e características.
51
5. CONCLUSÕES
Durante o projeto foram aplicadas diversas técnicas e métodos de engenharia
de software para a análise e desenvolvimento do sistema de previsão de pagamentos.
A fase de análise foi de grande importância para a realização do projeto, pois com os
artefatos gerados durante esta fase, como diagrama de casos de uso e documento de
requisitos, pudemos ter um entendimento aprimorado das regras de negócio junto ao
usuário. Tais artefatos poderão ser utilizados em melhorias futuras no sistema.
As tecnologias escolhidas para o desenvolvimento do sistema se deram
devido à urgência da implementação de um sistema coerente com o negócio; o Delphi
para desenvolvimento rápido de telas e funcionalidades básicas, como controles de
usuário, exibição de dados, geração de relatórios e layouts, e o banco de dados como
controle de regras de negócio, via procedimentos e triggers.
Em suma, este projeto de estágio supervisionado proporcionou a
oportunidade de ter experiências novas e aprimorar conhecimentos, obtidos durante o
curso de Sistemas de Informação, tanto na área de análise quanto na de
desenvolvimento de sistemas, ajudou a entender mais sobre as regras de negócio e
operações da empresa. Apesar do curto período de disponibilidade para a realização
desta atividade, foi uma experiência muito proveitosa.
52
6. REFERÊNCIAS BIBLIOGRÁFICAS
Allround
Automations;
2016,
PL/SQL
Developer
11.0,
Disponível
em
https://www.allroundautomations.com/plsqldev.html (Acessado em setembro de
2016).
Balsamiq;
2016,
Mockups
Application
Overview,
Disponível
em
https://docs.balsamiq.com/desktop/overview/ (Acessado em setembro de 2016)
LEÃO, Marcelo; 2003, Borland® Delphi™ 7 Curso Completo, Sem Edição, Rio de
Janeiro, Axcel Books do Brasil Editora Ltda.
Borland Software Corporation, 2002, Object Pascal Language Guide, Edição única,
Califórnia
FOWLER, Martin; 2007, UML Essencial, um breve guia para a linguagem-padrão de
modelagem de objetos, 3ª Edição, Porto Alegre, Artmed® Editora S.A.
Farinelli, Fernanda; 2007, Conceitos Básicos de Programação Orientada a Objetos,
Edição Única, Editora não informada
GUEDES, Gilleanes T. A., 2009, UML 2, uma abordagem prática, Sem Edição, São
Paulo, Novatec Editora LTDA.
Juliana
Kolb,
Prototipagem.
Disponível
em
https://julianakolb.wordpress.com/tag/prototipagem/ (Acessado em setembro de
2016)
Marina Martinez. RUP. Disponível em http://www.infoescola.com/engenharia-desoftware/rup/ (Acessado em setembro de 2016)
Object Management Group, Introduction to OMG’s Unified Modeling Language®
(UML®). Disponível em http://www.uml.org/what-is-uml.htm (Acessado em
setembro de 2016)
Oracle,
Introduction
to
Oracle
Database,
Disponível
https://docs.oracle.com/cd/E11882_01/server.112/e40540/intro.htm#CNCPT001
(Acessado em setembro de 2016)
em
53
Oracle, Oracle Database 10g Release 2: A Revolution in Database Technology,
Disponível
em
http://www.oracle.com/technetwork/pt/database/database10g/overview/index.html
(Acessado em setembro de 2016)
Oracle,
Oracle
Database
12c
PL/SQL,
Disponível
em
http://www.oracle.com/technetwork/database/features/plsql/index.html (Acessado em
setembro de 2016)
PRESSMAN, Roger S.; 2011, Engenharia de software, uma abordagem profissional,
7ª Edição. Porto Alegre: AMGH Editora Ltda
Rational® Software. Rational Unified Process, Best Pratices For Software
Development
Teams.
Disponível
em
https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/125
1_bestpractices_TP026B.pdf (Acessado em setembro de 2016)
RAMAKRISHNAN, Raghu, GEHRKE, Johannes; 1999, Sistemas de Gerenciamento
de Banco de Dados, 2ª Edição. Sem local. Sem editora
SCHILDT, Herbert; 2014, Java™, A Beginner’s Guide, 6ª Edição, Estados Unidos,
McGraw-Hill Education
SOMMERVILLE, Ian; 2007. Engenharia de software. 8ª Edição. São Paulo: Addison
Wesley
54
APÊNDICES E/OU ANEXOS
APÊNDICE 1 – QUESTÕES INICIAIS PARA A ENTEVISTA
55
APÊNDICE 2 – PROPOSTA DE PROJETO
Figura 31 - Capa do Documento de Proposta de Projeto
56
Figura 32 - Sumário do Documento de Proposta de Projeto
57
Figura 33 - Página 3 do Documento de Proposta de Projeto
58
Figura 34 - Página 4 do Documento de Proposta de Projeto
59
APÊNDICE 3 – DOCUMENTO DE REQUISITOS
Figura 35 - Capa do Documento de Requisitos
60
Figura 36 - Índice do Documento de Requisitos
61
Figura 37 - Página 3 do Documento de Requisitos
62
Figura 38 - Página 4 do Documeto de Requisitos
63
APÊNDICE 4 – DESCRIÇÕES DE CASOS DE USO
Figura 39 - Capa da Descrição do Caso de Uso Consultar Planilha
64
Figura 40 - Índice da Descrição do Caso de Uso Consultar Planilha
65
Figura 41 - Página 3 da Descrição do Caso de Uso Consultar Planilha
66
Figura 42 – Capa da Descrição de Caso de Uso Filtrar Registros
67
Figura 43 - Índice da Descrição de Caso de Uso Filtrar Registros
68
Figura 44 - Página 3 da Descrição do Caso de Uso Filtrar Registros
69
Figura 45 - Capa da Descrição do Caso de Uso Fazer Lançamento Manual
70
Figura 46 - Índice da Descrição do Caso de Uso Fazer Lançamento Manual
71
Figura 47 - Página 3 da Descrição do Caso de Uso Fazer Lançamento Manual
72
Figura 48 - Página 4 da Descrição do Caso de Uso Fazer Lançamento Manual
73
Figura 49 - Capa da Descrição do Caso de Uso Alterar Previsão
74
Figura 50 - Índice da Descrição do Caso de Uso Alterar Previsão
75
Figura 51 - Página 3 da Descrição do Caso de Uso Alterar Previsão