Relatorio final anderson(versão final revisada 13-07-2012)

ILHÉUS-BAHIA
2012
UNIVERSIDADE ESTADUAL DE SANTA CRUZ
ANDERSON CONCEIÇÃO RODRIGUES
SIGAPL – SISTEMA DE GESTÃO E ACOMPANHAMENTO DE PROCESSOS
LICITATÓRIOS

LICITATÓRIOS
Trabalho de Conclusão de Curso apresentado, para
obtenção do título de Bacharel em Ciência da
Computação, à Universidade Estadual de Santa Cruz.
Área de concentração: Ciência da Computação
Orientador: Prof. Dr. Dany Sanchez Dominguez

LICITATÓRIOS
Ilhéus-BA, 25/06/2012.
________________________________________________________
Prof. Dr. Dany Sanchez Dominguez
UESC
(Orientador)
________________________________________________________
Prof. Dr. Paulo Eduardo Ambrósio
UESC
________________________________________________________
Prof. Dra. Susana Marrero Iglesias
UESC
________________________________________________________
Prof. Mathias Santos Brito
UESC

IV
DEDICATÓRIA
Dedico este trabalho primeiramente, a minha mãe, meu pai e minha esposa,
pois confiaram em mim e me deram esta oportunidade de concretizar e encerrar
mais uma caminhada da minha vida. Sei que eles não mediram esforços pra que
este sonho se realizasse, sem a compreensão, ajuda e confiança deles nada disso
seria possível hoje.
Ao meu avô José Bento (in memoriam), que infelizmente não pode estar
presente neste momento tão feliz da minha vida, mas que não poderia deixar de
dedicar a ele, pois se hoje estou aqui, devo muitas coisas a ele e por seus
ensinamentos e valores passados. Obrigada por tudo! Saudades eternas!
A minha filha a pequena Manuela que hoje é minha fonte de inspiração.
A estes dedico meu trabalho, sem a ajuda, confiança e compreensão de
todos, esta conquista não teria sido alcançada

V
LICITATÓRIOS
RESUMO
Toda Instituição pública necessita adquirir bem e serviços, no entanto para
isso é necessário executar processo licitatório, conforme previstos nas leis 8.666/93,
10.520/02 e 123/05, algumas instituições de grande porte já possuem um
departamento equipado e treinado unicamente para essa funcionalidade, mas a
maioria instituições de pequeno e médio porte, não dispõe de pessoal qualificado e
nem estrutura que dê suporte à gestão destes processos.
A falta de pessoal capacitado e uma estrutura adequada tornam o processo
sujeito a falhas, demorado, custoso e dificulta a tarefa de fiscalização dos órgãos de
controle externos (TCM Tribunal de contas dos municípios, TCE Tribunal de contas
do estado e CGU Corregedoria geral da união).
É com o objetivo de oferecer agilidade, controle no fluxo processual,
transparência no processo e principalmente segurança que este projeto é proposto.
Para isto foi levantado junto aos futuros usuários as necessidades, as dificuldades
enfrentadas diariamente e os cenários encontrados. Após levantar estas
informações ficou decidido que o software deverá ter como alvo a plataforma web,
deverá ser desenvolvido em linguagem de programação PHP, utilizando a
metodologia de desenvolvimento ágil XP(extreme programing) e aderir aos padrões
de programações.

VI
LISTA DE FIGURAS
Figura 1 – Documento no padrão HTML 4.01 ...........................................................14
Figura 2 - Uso de JavaScript em páginas HTML.......................................................15
Figura 3 - Exemplo uso jQuery em um documento HTML. .......................................16
Figura 4 - Exemplo de código PHP. ..........................................................................20
Figura 5 - IDE Netbeans na versão 7.1.2 manipulando um dos fontes deste projeto.
..................................................................................................................................22
Figura 6 - Layout do sistema cabeçalho dos documentos ........................................24
Figura 7 - Layout do sistema seção de rodapé. ........................................................24
Figura 8 - Tela autenticação de usuários. .................................................................25
Figura 9 - Tela de entrada de dados no sistema, exemplo de validação no lado
cliente, entrada de dados inválidos. ..........................................................................26
Figura 10 - Bloqueio da tela durante chamada Ajax utilização do plugin
jquery.blockUI subsecção 2.6.1.1..............................................................................27
Figura 11 - Resultado do processamento com inserção de dados bem sucedida. ...27
Figura 12 - Resultado do processamento com falha na inserção de dados..............28
Figura 14 - Diagrama de casos de uso .....................................................................42
Figura 15 - Modelo ER entidade relacional lógico.....................................................43
Figura 16 - Estrutura da aplicação ............................................................................55
Figura 17 - Modelo Entidade Relacional (Conceitual/Lógico)....................................57
Figura 18 - Modelo Entidade Relacional (Físico).......................................................59
Figura 19 - Lista de tabelas.......................................................................................60

SUMÁRIO
DEDICATÓRIA IV
RESUMO. V
LISTA DE FIGURAS VI
SUMÁRIO VII
1. INTRODUÇÃO 9
1.1 OBJETIVOS GERAIS E ESPECÍFICOS 10
1.1.1 Objetivo Geral 10
1.1.2 Objetivos Específicos 11
2. FUNDAMENTAÇÃO E METODOLOGIA 11
2.1 Engenharia de software 11
2.2 XP (Extreming Programming) 12
2.3 Desenvolvimento Web 12
2.4 HTML(Hyper Text Markup Language) 13
2.5 JavaScript e AJAX (Asynchronous JavaScript and XML) 14
2.6 A biblioteca jQuery 15
2.6.1 Plugins jQuery 16
2.6.1.1Plugin: jquery.blockUI 16
2.6.1.2Plugin: jquery.maskedinput-1.1.4.pack 17
2.6.1.3Plugin: jquery.validate 17
2.6.1.4Plugin: jquery.tablesorter.min 18
2.6.1.5Plugin: jquery.tablesorter.pager 18
2.6.1.6Plugin: picnet.table.filter.min 18
2.7 PHP 19
2.8 MySQL 20
2.9 UML 21
2.10 Netbeans 21
3. DESENVOLVIMENTO 22
3.1 Especificação de Requisitos 23
3.2 Layout do sistema 23
3.3 Autenticação de Usuários 24
3.4 Entrada de dados 25
3.5 Documentação 28
3.5.1 Documentação Técnica 29

4. RESULTADOS 29
5. CONCLUSÃO 30
6. TRABALHOS FUTUROS 30
7. REFERÊNCIAS 31
8. APÊNDICE 1 – DOCUMENTO DE REQUISITO 33
9. APÊNDICE 2 – DOCUMENTAÇÃO TÉCNICA 47

9
1. INTRODUÇÃO
Toda instituição pública precisa comprar serviços e produtos para viabilizar as
tarefas de administração em todas as suas esferas, seja em uma creche, uma
prefeitura ou quando for construir uma hidroelétrica. A maior parte do dinheiro para
essas compras vem dos impostos pagos pelo contribuinte. Para que o uso do
dinheiro do contribuinte seja bem aplicado, os gestores destas instituições devem
escolher a proposta mais vantajosa para suas compras. Então à aquisição de
insumos, equipamentos e serviços se dão por meio de uma licitação. Em outras
palavras, as licitações tornam lícitas as compras do governo e, como conseqüência,
a forma como os gestores governamentais gastam o dinheiro público.
No Brasil, a primeira legislação que tratava de compras públicas foram as
Ordenações Filipinas, de 1595 (era uma lei portuguesa, que foi importada para o
Brasil nos tempos da colônia). Atualmente, duas leis condicionam as licitações
públicas brasileiras. A lei federal 8.6661
, de 1993, detalha os modelos de licitação
possíveis para todas as esferas (federal, estadual e municipal) e também os
elementos e requisitos que permitem dispensar o processo licitatório.
Em 2002, foi promulgada a lei federal 10.520 2
que regularizou uma nova
modalidade de licitação: o pregão. A lei 8.666 detalha também outras duas
modalidades de licitações, que não são exatamente compras de bens e serviços.
São o concurso público e a alienação ou venda de bens públicos, que normalmente
é feito em forma de leilão. Estes dois tipos de licitação não fazem parte do escopo
deste trabalho.
Após breve pesquisa, foi observada uma deficiência quanto a softwares que
dêem suporte à gestão e acompanhamento do processo licitatório, seja em sua fase
de preparação ou mesmo em sua fase prática, onde as empresas fornecedoras se
reúnem com a instituição pública para apresentar suas propostas, documentos de
habilitação e registrar seus lances.
1
(BRASIL, Lei n. 8.666, de 21 de junho de 1993. Regulamenta o art. 37, inciso XXI, da
Constituição Federal, institui normas para licitações e contratos da Administração Pública e dá outras
providência)
2
(BRASIL, Lei n. 10.520, de 17 de julho de 2002. Institui, no âmbito da União, Estados,
Distrito Federal e Municípios, nos termos do art. 37, inciso XXI, da Constituição Federal, modalidade
de licitação denominada pregão, para aquisição de bens e serviços comuns, e)

10
É cada vez mais explicita a opinião dos órgãos de controle externos (CGU –
Corregedoria Geral da União, TCE – Tribunal de Contas do Estado e TCM – Tribunal
de Contas dos Municípios) para que a licitação na modalidade pregão seja efetuado
por item e não por lote ou global como tem sido feita nos últimos anos, por outro
lado as instituições governamentais rebatem enfatizando a inviabilidade de se
realizar uma licitação desta forma quando o número de itens é volumoso, tornando o
certame licitatório demorado e dispendioso, ferindo o principio da celeridade que
preza por rapidez na realização e finalização da licitação.
Desta forma este trabalho traz a proposta de desenvolver um protótipo de um
software que auxilie na gestão e acompanhamento dos processos licitatórios ao
mesmo tempo em que garante sua celeridade.
Este trabalho está estruturado da seguinte forma, no capítulo 1 serão
descritos os objetivos gerais e específicos que devem ser alcançados durante o
projeto, no capítulo 2 a fundamentação teórica e as ferramentas utilizadas no
desenvolvimento do trabalho, no capítulo 3 o cronograma do trabalho bem como as
etapas de desenvolvimento do mesmo, capítulo 4 faz um análise do resultado obtido
e mostra a conclusão em relação ao desenvolvimento do trabalho, no capítulo 5 é
apresentado o que se pretende desenvolver futuramente e finalmente no capítulo 6
apresentam-se as referências bibliográficas utilizadas neste trabalho.
1.1 OBJETIVOS GERAIS E ESPECÍFICOS
1.1.1 Objetivo Geral
O objetivo deste trabalho é projetar e implementar um protótipo de aplicação
web que forneça suporte à gestão de processos licitatórios na modalidade de pregão
presencial. A ferramenta utilizará a linguagem de PHP do lado do servidor, e o
Sistema Gerenciador de Banco de Dados (SGDB) MySQL. Adicionalmente deve
aderir os principais padrões W3C (World Wide Consortium), em particular HTML
4.01 e CSS 2.1.

11
1.1.2 Objetivos Específicos
Os objetivos específicos deste trabalho são:
1) Estudar a legislação vigente para o processo licitatório na modalidade de
pregão presencial;
2) Criar as regras de negócio que atendam a legislação vigente;
3) Elaborar a documentação de projeto do sistema: análise de requisitos, casos
de uso, diagrama ER;
4) Implementar o protótipo da ferramenta com as funcionalidades essenciais;
5) Testar e validar a ferramenta construída.
2. FUNDAMENTAÇÃO E METODOLOGIA
2.1 Engenharia de software
"Engenharia de Software é a criação e a utilização de sólidos princípios de
engenharia a fim de obter software de maneira econômica, que seja confiável e que
trabalhe em máquinas reais" (Frederich Bauer).
Engenharia de software também pode ser entendida como uma área da
computação voltada à especificação, desenvolvimento e manutenção de sistemas
de software, com aplicação de tecnologias e práticas de gerência de projetos e
outras disciplinas, visando organização, produtividade e qualidade. Atualmente,
essas tecnologias e práticas englobam linguagens de programação, banco de
dados, ferramentas, plataformas, bibliotecas, padrões, processos e a questão da
qualidade de software.
Os fundamentos científicos para a engenharia de software envolvem o uso de
modelos abstratos e precisos que permitem ao engenheiro especificar, projetar,
implementar e manter sistemas de software, avaliando e garantindo sua qualidade.
Além disso, a engenharia de software deve oferecer mecanismos para se planejar e
gerenciar o processo de desenvolvimento de um sistema de informação.

12
Após avaliação das várias metodologias de desenvolvimento ágil disponíveis,
ficou decidido que a mais compatível com o perfil deste projeto é a XP (Extreme
Programming Seção 2.2).
2.2 XP (Extreming Programming)
O método de desenvolvimento de software Programação extrema (XP
Extreme Programming) foi escolhido devido sua filosofia de interação entre o usuário
e o desenvolvedor, tornando o praticamente uma membro da equipe de
desenvolvimento.
Sua característica de trabalho com metáfora modelando o mundo real para o
mundo também foi uma dos pontos que culminaram em sua escolha.
A programação extrema tem sido bem sucedida em projetos pequenos com
equipes pequenas.
2.3 Desenvolvimento Web
Com a disseminação da internet em todo o mundo é cada vez mais comum o
uso de aplicações web, as vantagens são inúmeras, dentre elas se destacam as
seguintes:
Interface HTML(consultar item 2.4) reconhecida por uma grande gama
de usuários já acostumados com o funcionamento dos browsers
(programas de navegação na internet, a exemplo: Google Chrome,
Mozzila Firefox, Internet Explorer e outros).
Desenvolvimento, manutenção e atualização centralizada da aplicação.
Elimina a necessidade de sair instalando a aplicação em diversos
equipamentos diferentes. Basta colocá-lo no servidor para que os
usuários utilizem à aplicação e suas atualizações.
A exportação de dados entre usuários remotos usando o protocolo
HTTP é muito mais fácil do que usar outro protocolo.

13
Escalabilidade no processamento. Se houver necessidade de
aumentar o poder de processamento, basta fazer isto no servidor.
Pelas vantagens descritas atualmente a maioria de aplicações para
gerenciamento de processos e atividades corporativas são construídas para
plataforma web e a nossa aplicação é uma delas.
2.4 HTML(Hyper Text Markup Language)
O HTML (Hyper Text Markup Language) ou linguagem de marcação de texto
é uma linguagem para criação de páginas web, que serão interpretadas e
renderizadas pelos navegadores, a especificação desta linguagem é gerenciada
pela W3C (World Wide Web Consortium).
A linguagem HTML tem sido modificada continuamente para atender as
necessidades crescentes da internet evoluindo da seguinte forma:
1995 – HTML 2.0;
1997 – HTML 3.2;
1997 – HTML 4.0;
1999 – HTML 4.01;
2012 – HTML 5.0;
Especificação atual: HTML 5.0;
Especificação mais utilizada: HTML 4.01
No projeto atual adotaremos a especificação HTML 4.01, observe abaixo um
exemplo de documento no padrão HTML 4.01.

14
Figura 1 – Documento no padrão HTML 4.01
Para validação do padrão HTML dos documentos gerados pelo sistema foi
utilizada a ferramenta (The W3C Markup Validation Service) um validador
oferecido pelo W3C disponível em: http://validator.w3.org/. Ao atendermos o padrão
desenvolvemos uma aplicação robusta e garantimos sua longevidade e seu correto
funcionamento em diferentes navegadores.
2.5 JavaScript e AJAX (Asynchronous JavaScript and XML)
Visando evitar fluxo de dados desnecessário e tornar mais dinâmico o sistema
faz se necessário a utilização de um pré-processamento do lado cliente, e este fica a
cargo da linguagem javascript, por exemplo, em uma validação de um campo onde é
necessário verificar se já há outro registro com mesmo valor, sem o javascript a
página inteira precisa ser recarregada do servidor, já com o uso do javascript isto
não é necessário.
Na figura 2 é possível acompanhar a utilização de JavaScript em uma página
HTML.

15
Figura 2 - Uso de JavaScript em páginas HTML
O JavaScript é uma linguagem que não exige muitos processamento por
parte da máquina cliente, é interpretada e com recursos de orientação a objetos, a
maior parte dos navegadores atuais já incorporam o JavaScript. A combinação desta
tecnologia com o DOM (Document Object Model – modelo de objeto de documento)
é possível manipular os elementos de uma página web, realizando modificações
reposicionamentos e outras ações, ou seja é possível recriar uma página inteira sem
a necessidade de recarregar do servidor. Além do mais é possível utilizar o Ajax
(acrônimo de Asynchronous JavaScript and XML) uma técnica de desenvolvimento
web que combina tecnologias conhecidas, como JavaScript, XML, entre outras, para
tornar as páginas web mais dinâmicas e interativas, para enviar requisições ao
servidor e processar dados sem a necessidade de recarregar todo o documento
HTML.
Levando em consideração que o sistema deve oferecer uma interface bem
dinâmica é indispensável o uso de Ajax durante o projeto.
2.6 A biblioteca jQuery
Como já foi abordado no item 2.5, faz-se necessário o uso de um grande
volume de conteúdo dinâmico através do AJAX, desta forma optou-se pelo uso da
biblioteca jQuery, para facilitar o manuseio das requisições AJAX.
jQuery é uma biblioteca JavaScript criada por John Resig e disponibilizada
como software livre e aberto, ou seja, de emprego e uso regido pela licencia GPL
(GNU General Public LIcense) (Silva M. S., 2010).

16
“O foco principal da biblioteca jQuery é a simplicidade. Por que submeter os
desenvolvedores ao martírio de escrever longos e complexos códigos para
criar simples efeitos?”(Resig Jhon).
Na figura 3 é possível verificar o uso da biblioteca jQuery em uma página
HTML.
Figura 3 - Exemplo uso jQuery em um documento HTML.
2.6.1 Plugins jQuery
A biblioteca jQuery é um software de código aberto e extensível. Isto significa
que qualquer um, com conhecimento da linguagem de programação JavaScript,
pode modificar, acrescentar ou retirar funcionalidades de seu código original para
satisfazer necessidades de seu projeto, assim surgem os plugins que atendem
distintas necessidades. Neste projeto pretende-se utilizar vários plugins de terceiros
para a biblioteca jQuery, os mesmos são listados nas próximas subseções:
2.6.1.1 Plugin: jquery.blockUI

17
Algumas requisições precisam ser feitas de forma síncrona para evitar que durante a
requisição o usuário modifique o estado de algum elemento do DOM, cancelando
assim a requisição. Faz-se necessário o bloqueio da tela ao mesmo tempo que um
feedback (retorno) é apresentado ao usuário, este plugin oferece estas
funcionalidades através da função $.blockUI(mensagem), que bloqueia a tela ao
mesmo tempo que exibe uma mensagem. Também se utiliza a função $.unblockUI()
que desbloqueia a interface do usuário.
A documentação deste plugin esta disponível no endereço:
http://jquery.malsup.com/block/ .
2.6.1.2 Plugin: jquery.maskedinput-1.1.4.pack
Durante o preenchimento dos campos de um formulário é necessário o uso de
máscaras em campos de documento como datas, valores e outros, uma forma
simples de gerar estas mascaras é através do uso deste plugin. Para ativar a
mascara em um determinado elemento basta chamar a função:
$(„#idElemento‟).mask(mascara) passando a mascara como parâmetro.
A documentação detalhada do plugin esta disponível no endereço:
http://digitalbush.com/projects/masked-input-plugin/ .
2.6.1.3 Plugin: jquery.validate
Durante a entrada de dados através de formulários faz-se necessário uma
verificação do lado cliente com o objetivo de atestar se os dados estão em
conformidade com as necessidades da aplicação. Este plugin oferece uma forma
ágil e simples de verificar se os campos estão preenchidos de maneira adequada e
ainda permite a configuração de mensagens de advertência, o que poupa
processamento do lado do servidor uma vez que é assegurado que os dados só
serão enviados se estiverem em conformidade com a estrutura esperada pelo
servidor.

18
A documentação deste plugin pode ser encontrada no endereço:
http://bassistance.de/jquery-plugins/jquery-plugin-validation/ .
2.6.1.4 Plugin: jquery.tablesorter.min
Visando evitar o fluxo de dados desnecessário e reduzir o processamento no
servidor, utiliza-se ao máximo o processamento no lado cliente. Optou-se neste caso
pelo uso deste plugin que possibilita uma ordenação em tabelas sem a necessidade
de processamento no servidor, para isso depois de aplicado o plugin no documento
HTML basta clicar no título da coluna da tabela. Possibilitando assim que o próprio
usuário ordene os relatórios gerados antes da impressão. Este plugin ainda
possibilita o zebramento, o processo de colorir linhas alternadas visando destacar o
conteúdo da tabela.
Para a maioria dos computadores utilizados uma quantidade de 5000
registros em uma tabela com 10 colunas é ordenada em pouco mais de 1 segundo
sem tornar lento o processamento.
A documentação detalhada do plugin esta disponível em:
http://tablesorter.com/docs/.
2.6.1.5 Plugin: jquery.tablesorter.pager
Outra característica que requer bastante processamento por parte do servidor
é a paginação de resultados, este plugin que é uma extensão do item anterior,
permite a paginação, processo de dividir resultados numerosos em pequenas
porções, no lado cliente o que torna mais rápido e dinâmico a visualização dos
relatórios gerados pelo sistema. A documentação completa esta disponível no
endereço: http://tablesorter.com/docs/.
2.6.1.6 Plugin: picnet.table.filter.min

19
Além da ordenação e da paginação de tabelas, uma outra necessidade é a
filtragem de resultados, seja ela em uma coluna ou a combinação de filtros em
várias colunas. Este plugin oferece este recurso através de campos localizados logo
abaixo do titulo das colunas, onde é possível montar e combinar os filtros de forma
simples e intuitiva.
A documentação desta funcionalidade esta disponível no endereço:
http://www.picnet.com.au/picnet-table-filter.html .
2.7 PHP
Para que o servidor web possa interagir com o cliente é necessário uma
linguagem de programação para processar as requisições feitas pelos clientes,
construindo uma resposta que integre os dados disponíveis com as tecnologias
utilizadas, desta forma optou-se pelo PHP (Personal Home Page). O PHP é uma
linguagem robusta e ágil, além da facilidade de se encontrar hospedagem a um
preço razoável.
O PHP é uma linguagem de criação de scripts para execução do lado do
servidor que foi projetada especificamente para Web. Dentro de uma página HTML,
é possível embutir código PHP que será executado toda vez que a página for
visitada. Esse código é interpretado no servidor web e gera o HTML renderizado
pelos navegadores (Thomson & Welling, 2001).
Outra vantagem é que o PHP é Open Source (Código aberto/livre), ou seja é
possível acessar o seu código fonte, utilizá-lo, modificá-lo e redistribuí-lo. A versão
atual do PHP é a 5.4.4, essa versão é o resultado de aperfeiçoamentos significativos
na linguagem.
Por todas estas vantagens além de ser a linguagem cujo possuo maior
habilidade é que o PHP foi escolhida como linguagem de desenvolvimento para este
projeto.
Na figura 4 é mostrado um exemplo de código PHP gerando saída em HTML.

20
Figura 4 - Exemplo de código PHP.
2.8 MySQL
O MySQL é um SGBD(Sistema gerenciador de banco de dados) que foi
desenvolvido tendo como referência os sistemas mais utilizados do mercado
(Microsoft SQL Server e Oracle), capaz de operar com os comandos SQL
(Structured Query Language) e é gratuito. O sucesso do MySQL deve-se em grande
medida à fácil integração com o PHP incluído nos pacotes de hospedagem de sites
da Internet oferecidos atualmente. Empresas como Yahoo! Finance, MP3.com,
Motorola, NASA, Silicon Graphics e Texas Instruments usam o MySQL em
aplicações de missão crítica.Sua versão atual é a 5.6
Optou-se pelo uso deste SGBD devido a sua fácil integração com PHP pelo
fato de que a maioria dos serviços de hospedagem já oferecerem hospedagem
grátis no pacote PHP, além do mais é um SGBD leve e que oferece uma gama de
ferramentas utilitárias para seu manuseio.
Sua documentação completa pode ser encontrada no endereço:
http://dev.mysql.com/doc/refman/5.6/en/index.html.

21
2.9 UML
Na fase de projeto é necessário ilustrar as necessidades do sistema bem
como suas regras de negócio de forma abstrata, visando orientar o processo mais
detalhado do desenvolvimento do sistema, desta forma durante esta fase faz se uso
da UML (Unified Modeling Language – Linguagem de modelagem unificada).
A UML ilustra através de objetos e suas representações as ações que o
software deverá desempenhar durante sua execução, ela também oferece um
padrão de diagramação que pode facilmente ser integrado à documentação técnica
do software.
2.10 Netbeans
Diante de tantas tecnologias envolvidas no desenvolvimento do software é
necessário uma IDE (Integrated Development Environment, ambiente integrado de
desenvolvimento) para organizar e editar os arquivos fontes, neste caso optou-se
pelo uso da IDE Netbeans em sua versão 7.1.2.
O Netbeans é um ambiente de desenvolvimento gratuito e de código aberto
para desenvolvedores de software em várias linguagens dentre elas o PHP. O IDE
pode ser executado em várias plataformas, Windows, Linux, Solaris e MacOS. O
Netbeans IDE oferece aos desenvolvedores ferramentas necessárias para criar
aplicativos profissionais de desktop, empresariais, Web e móveis multiplataformas
além de oferecer suporte a ferramentas de versionamento (Git, Mercurial,
Subversion) e ainda ferramentas de teste de unidade como phpUNIT.
A tela principal do Netbeans manipulando um dos fontes deste projeto é
mostrada na figura 5.

22
Figura 5 - IDE Netbeans na versão 7.1.2 manipulando um dos fontes deste projeto.
3. DESENVOLVIMENTO
Nesta sessão será descrito o processo de desenvolvimento do projeto. Na
tabela abaixo é possível acompanhar o cronograma de desenvolvimento do projeto.
Na primeira coluna listamos as tarefas, e nas restantes o período de tempo em que
foram executadas. As tarefas executadas visavam atender os objetivos específicos
do projeto que foram descritos na seção 1.1.2.
Tabela 1 - Cronograma de desenvolvimento.
TAREFAS
QUINZENAS
ABRIL MAIO JUNHO JULHO
1ª 2ª 1ª 2ª 1ª 2ª 1ª 2ª
Efetuar levantamento das necessidades dos
futuros usuários
X
Estudar a legislação que rege os processos
licitatórios X X

23
Documentação: Analise de requisitos e
diagramas X X
Documentação: Técnica X
Estudo de tecnologias aplicáveis X X X X
Implementar protótipo X X X X X
Modelagem e modificações no banco de
dados X X X
Testes de protótipo X
Elaboração do relatório de estágio X X X X X
3.1 Especificação de Requisitos
Esta é uma das fases mais importantes do projeto, pois nela são levantadas
as necessidades que deverão ser atendidas pelo sistema. Nesta etapa foram
levantados os requisitos funcionais e também os requisitos não funcionais, os quais
são documentados através do uso de UML.
Estas informações foram levantadas através da analise da legislação vigente
em termo de processo licitatório através das leis: 8.666/93, 10.520/02 e
complementar 123/05, e ainda da observação do fluxo processual in locu na
Prefeitura Municipal de Santa Cruz da Vitória.
A partir das informações levantadas elaborou-se o documento que detalha os
principais requisitos do sistema, o qual está disponível no Apêndice 1 – Documento
de Requisitos.
3.2 Layout do sistema
O layout do sistema segue os padrões de validação da W3C, foi elaborado
para resoluções de no mínimo 1024px x 768px e está dividido basicamente em 3
partes:
1. Cabeçalho com dimensões de 980px x 134px: acomodará o brasão da
instituição, o título do sistema, o menu de acesso (Cadastros,

24
relatórios, configurações e sair) e o menu de acessibilidade. Esta
seção do layout é ilustrado na figura 6.
Figura 6 - Layout do sistema cabeçalho dos documentos
2. Conteúdo com 980px de largura acomodará todo o tipo de conteúdo
seja formulários, filtros, listagem ou relatórios. A altura da seção de
conteúdo se adaptara à quantidade de informações a ser exibida
limitando-se no mínimo à 460px para se adequar ao tamanho da tela.
3. Rodapé com dimensões de 989px x 55px: acomodará as informações
de rodapé, que incluem as informações de copyright. Esta seção do
layout pode ser vista na figura 7.
Figura 7 - Layout do sistema seção de rodapé.
3.3 Autenticação de Usuários
A autenticação de usuários é uma área do sistema que requer atenção
especial, é nesta parte que os usuários inserem suas credenciais (login e senha).
Estes dados serão enviados para o sistema, se as credenciais estiverem corretas se
permite o acesso, ademais são identificadas as restrições de uso conforme o papel
do usuário. Nesta funcionalidade faz se uso de criptografia MD5 (Message-Digest
algorithm 5) algoritmo de 128bits unidirecional utilizado no armazenamento das
senhas no banco de dados.
“A técnica usada em Criptografia envolve pura e simples matemática. O
sistema de criptografia usado atualmente é extremamente seguro.
Especialistas estimam que para alguém conseguir quebrar uma criptografia
usando chaves de 64 bits na base da tentativa e erro, levaria cerca de
100.000 anos usando um PC comum.” (Vale, 2011)

25
Além da utilização da criptografia MD5 para armazenar as senhas foi utilizado
HTTPS (hyper text transfer protocol secure – protocolo de transferência de hiper
texto seguro) na comunicação entre o cliente e o servidor no momento da
autenticação visando que os dados não trafeguem desprotegidos pela rede. A tela
de autenticação do sistema é mostrada na figura 8.
Figura 8 - Tela autenticação de usuários.
3.4 Entrada de dados
A entrada de dados também é uma das funcionalidades do sistema que
requer atenção, pois a depender do nível de experiência do usuário é necessária
uma validação mais robusta. Na figura 9 mostramos a ilustração de uma das telas
de entrada de dados do sistema. Como citado anteriormente na seção 2.6.1 são
utilizados plugins para máscara de campos e plugins para validação de campos no

26
lado cliente a fim de facilitar a entrada de dados por parte dos usuários e impedir
erros de digitação.
O layout de entrada de dados, ou seja a disposição dos campos no formulário
não segue o padrão convencional em linha na vertical que na maioria das vezes não
utiliza adequadamente a área da tela tornando os formulários grandes e cansativos,
neste sistema optou-se por atribuir o tamanho dos campos dinamicamente a fim de
fazer uso de toda a área da tela, o que oferece uma visão mais ampla aos usuários.
Durante a requisição Ajax, visando evitar possíveis modificações de estado, é
utilizado o plugin jquery.blockUI para bloquear a tela até que a requisição seja
concluída conforme é ilustrado na figura 10.
Para garantir o dinamismo do sistema o retorno da requisição é feito na
própria página, utilizando o padrão de cor verde, quando o cadastro for realizado
com sucesso e a cor vermelha com a descrição do erro quando não houver sucesso
na requisição conforme ilustrado nas figuras 11 e 12.
Figura 9 - Tela de entrada de dados no sistema, exemplo de validação no lado
cliente, entrada de dados inválidos.

27
Figura 10 - Bloqueio da tela durante chamada Ajax utilização do plugin
jquery.blockUI subsecção 2.6.1.1.
Figura 11 - Resultado do processamento com inserção de dados bem sucedida.

28
Figura 12 - Resultado do processamento com falha na inserção de dados.
Figura 13 - Tela gestão (Cadastro, edição, exclusão e listagem) de departamentos
3.5 Documentação
A documentação de software é uma atividade essencial no processo de
desenvolvimento de software. É através dela que a evolução do software é
registrada para que sejam criadas as bases necessárias para as etapas posteriores
do processo de software, incluindo treinamento, utilização e manutenção de
software.

29
3.5.1 Documentação Técnica
A documentação técnica é voltada ao desenvolvedor, pois descreve o
funcionamento interno do sistema através de dicionários de dados, fluxogramas de
processos, descrição das tecnologias usadas, árvore de diretórios e descrição dos
principais scripts. A documentação técnica do projeto está disponível no Apêndice 2
– Documentação Técnica – deste documento.
4. RESULTADOS
Foram levantados 17(dezessete) requisitos funcionais, 3 (três) requisitos não
funcionais, 8 (oito) papéis.
Foi elaborada toda a documentação técnica a qual descreve toda a estrutura
da aplicação, estrutura de diretórios, o dicionário de dados, o modelo ER conceitual
e físico.
O Banco de dados já foi modelado, dispondo de 24 (vinte e quatro) tabelas e
5 (cinco) visões.
O fontes básicos de manipulação de dados, segurança e validações já foram
completamente implementado alem dos modelos que serão utilizados em todo o
projeto.
As telas básicas já foram implementadas, testadas e validadas, dentre elas:
Autenticação de usuário;
Cadastro, atualização, exclusão de instituições, configurações de
papéis da instituição e listagem de instituições;
Gestão (Cadastro, atualização, exclusão, configuração de papéis) dos
departamentos/Órgãos;
Log de atividades no sistema;
Auditoria no sistema;

30
Cadastro, atualização, exclusão, listagem de funcionários/Pessoas;
Geração de login de usuário;
5. CONCLUSÃO
Neste projeto foi desenvolvido o protótipo de um software, que permitiu criar
as bases para a futura implementação de um software completo para Gestão e
Acompanhamento de Processos Licitatórios, respeitando todas as regras
estabelecidas pela engenharia de software.
Não é possível afirmar o ganho de desempenho do software em relação às
práticas utilizadas atualmente por ser apenas um protótipo e não ter todas as suas
funcionalidades implementadas. Entretanto, espera-se que o uso do sistema uma
vez implementado venha a diminuir significativamente os erros processuais e
permita uma maior transparência e celeridade nos processos licitatórios.
Por outro lado o presente trabalho contribuiu para a minha formação pelo
ganho de conhecimentos em diferentes metodologias e ferramentas, e experiência
real no processo de desenvolvimento de um software. Neste projeto foram aplicados
conhecimento adquiridos em diversas disciplinas do curso de ciências da
computação.
6. TRABALHOS FUTUROS
Futuramente pretende-se dar continuidade à conclusão do software utilizando
uma equipe maior e dispondo de mais tempo podendo concluir o projeto de forma a
oferecer às instituições públicas um software de qualidade e que forneça as
ferramentas adequadas no auxilio a gestão de seus processos licitatórios,
eliminando falhas e oferecendo maior agilidade no processo.

31
7. REFERÊNCIAS
BABIN, L. (2007). Ajax com PHP – Do Iniciante ao Profissional. 1ª edição.
ALTABOOKS.
BRASIL. (s.d.). Lei n. 10.520, de 17 de julho de 2002. Institui, no âmbito da
União, Estados, Distrito Federal e Municípios, nos termos do art. 37, inciso XXI, da
Constituição Federal, modalidade de licitação denominada pregão, para aquisição
de bens e serviços comuns, e. Acesso em 2012 de 03 de 27, disponível em
http://www.planalto.gov.br/ccivil_03/ leis/2002/L10520.htm
BRASIL. (s.d.). Lei n. 8.666, de 21 de junho de 1993. Regulamenta o art. 37,
inciso XXI, da Constituição Federal, institui normas para licitações e contratos da
Administração Pública e dá outras providência. Acesso em 15 de 03 de 2012,
disponível em http://www.planalto.gov.br/ccivil_03/ leis/L8666compilado.htm
Dall'Oglio, P. (2007). php - Programando com orientação a objetos. São
Paulo: novatec.
Ferrari, F. A. (2007). Crie Banco de Dados em MYSQL. São Paulo: novatec.
Flamagan, D. (2002). JavaScript - O guia definitivo 4ª edição. SÃO PAULO:
ARTMED.
FREEMAN, E. (2008). Use a Cabeça HTML com CSS e XHTML. 2ª Edição.
ALTABOOKS.
Larman, C. (2005). UTILIZANDO UML E PADRÕES - Uma introdução à
analise e ao projeto orientados a objetos e ao desenvolvimento iterativo. SÃO
PAULO: BOOKMAN.
MAGELA, R. (2006). Engenharia de Software Aplicada: Princípios (volume 1).
Alta Books.
Niederauer, J. WEB INTERATIVA COM AJAX E PHP. NOVATEC.
Rezende, D. A. (2006). ENGENHARIA DE SOFTWARE E SISTEMA DE
INFORMAÇÃO 3ª EDIÇÃO. SÃO PAULO: BRASPORT.

32
SHORE, J. e. (2007). A ARTE DO DESENVOLVIMENTO AGIL. 1ª Edição.
ALTABOOKS.
Silva, C. C. (2012). O pregão: breves condiderações sobre o procedimento, a
aplicabilidade, a necssidade e as vantagens do pregão. Caro Gestor , 82-90.
Silva, M. S. (2010). jQuery - A biblioteca do Programador JavaScript. São
Paulo: novatec.
Spyman. (2000). Introdução Manual Completo do hacker - 3ª Edição. Book
Express.
Thomson, L., & Welling, L. (2001). PHP e MySQL - Desenvolvimento Web.
Rio de Janeiro: Campus.
TONSIG, S. L. (2006). MYSQL – Aprendendo na prática. 1ª Edição. CIÊNCIA
MODERNA EDIT.
Vale, C. R. (2011). Criptografia MD5. Acesso em 01 de 06 de 2012, disponível
em devMedia: http://www.devmedia.com.br/criptografia-md5/2944
Vanessa B. Nunes, A. O. (2004). Apoio à Documentação em um Ambiente de
Desenvolvimento de Software. Acesso em 05 de 06 de 2012, disponível em UFES -
Universidade Federal do Espirito Santos: http://inf.ufes.br/~falbo/download/pub/2004-
IDEAS-1.pdf
Wells, D. (06 de 2012). Extreme Programming by Don Wells. Acesso em 06
de 2012, disponível em http://www.extremeprogramming.org/

33
APÊNDICE I – Documento de Requisitos
SIGAPLSISTEMA DE GERENCIAMENTO E
ACOMPANHAMENTO DE PROCESSOS LICITATÓRIOS
Especificação de Requisitos
Anderson C. Rodrigues
Floresta Azul – Ba, 15 de Maio de 2012

34
Sumário
1. APRESENTAÇÃO 35
1.1 DESCRIÇÃO DO USUÁRIO 35
2. REQUISITOS 36
2.1 REQUISITOS FUNCIONAIS 36
2.2 REQUISITOS NÃO FUNCIONAIS 40
3. DIAGRAMAS 41
3.1 CASOS DE USO 41
3.2 MODELO ER(ENTIDADE RELACIONAL) LÓGICO 43

35
1. APRESENTAÇÃO
Este documento visa a descrição das funcionalidades que deveram ser
oferecidas pelo sistema SIGAPL – Sistema Gerenciamento e Acompanhamento de
Processos Licitatórios, utilizando diagramas e descrição textual para exemplificar as
funcionalidades.
1.1 DESCRIÇÃO DO USUÁRIO
O SIGAPL tem como público alvos servidores públicos que exerçam
funções/cargos relacionados a processos licitatórios, tais como Administrador,
Gestor, Pregoeiro, Ordenador, Assistente, Diretor Financeiro e Fornecedores.
O Administrador irá gerenciar o sistema, efetuando cadastros básicos para o
funcionamento do sistema e atribuindo as devidas permissões aos usuários.
Ao Gestor cabe mudança de status em algumas etapas do Processo, e cabe
também a delegação de funções tais como a do pregoeiro, Diretor Financeiro e
Ordenador.
Ao Pregoeiro cabe a função de manutenção do processo licitatório como
avanço nas fases e gerenciamento do sistema no decorrer do certame nas fases de
Credenciamento, Cadastro de proposta de preço, Lances Verbais, Habilitação e
Adjudicação.
Ao Ordenador cabe a função de solicitar o inicio de um processo Licitatório.
Ao Assistente cabe o lançamento de dados tais como cadastro de
fornecedores, cadastro de itens e outras tarefas administrativas em geral permitidas
pelo Administrador.
Ao Diretor Financeiro cabe a função de informar a disponibilidade de recurso
para prosseguimento do processo licitatório.
Aos Fornecedores cabe a função de atualizar seus dados cadastrais,
certidões fiscais e informar as categorias a quais estarão aptas a licitar.

36
REQUISITOS
Tomando como base a legislação vigente tendo como principal referencias as
leis 8.666/93 lei geral de Licitações, 10.520/02 lei que institui o pregão presencial
em âmbito Federal e Lei Complementar 123/05 lei de amparo a micro e pequena
empresas, Pode-se extrair os requisitos funcionais e não-funcionais a serem
contemplados no projeto.
Resumo:
Código Descrição
RF001 Gestão de Usuários
RF002 Gestão de Instituições
RF003 Gestão de Departamento / Órgãos
RF004 Gestão de Família de Itens
RF005 Gestão de Itens
RF006 Gestão de Processos Licitatórios
RF007 Credenciamento de Fornecedores
RF008 Habilitação de Fornecedores
RF009 Gestão de propostas de preço
RF010 Gestão de Lances Verbais
RF011 Checkin Documentos Habilitação
RF012 Autenticação de Usuários
RF013 Geração de Relatórios
RF014 Filtro de Relatórios
RF015 Ordenação de Relatórios
RF016 Impressão de Relatórios
RF017 Recuperação de Senha
RNF001 Legislação vigente (Leis 8.666/93, 10.520/02 e demais
resoluções atinentes)RNF002 Segurança do Sistema(Anti-SQL-injection, MD5, SSL)
RNF003 Performance do sistema
REQUISITOS FUNCIONAIS
Código: RF001
Nome do Requisito: Gestão de Usuários
Descrição: Cadastro, Edição, bloqueio/desbloqueio e Desabilitação de
Usuários;

37
Código: RF002
Nome do Requisito: Gestão de Instituições
Descrição: Cadastro, Edição, bloqueio/desbloqueio e Desabilitação de
Instituições;
Código: RF003
Nome do Requisito: Gestão de Departamento / Órgãos
Descrição: Cadastro, Edição e Exclusão de Departamento / Órgãos;
Código: RF004
Nome do Requisito: Gestão de Família de itens
Descrição: Cadastro, Edição e Exclusão de Família de itens(Classe / Grupo).
Código: RF005
Nome do Requisito: Gestão de Itens
Descrição: Cadastro, Edição e Exclusão de Itens, classificação por família;
Código: RF006
Nome do Requisito: Gestão de Processos Licitatórios
Descrição: Cadastro, Edição e Exclusão de processos licitatórios,
Acompanhamento das fases, modificação de status dos processos;
Código: RF007
Nome do Requisito: Credenciamento de Fornecedores

38
Descrição: Conferir documentos solicitados em edital, para credenciamento
dos fornecedores.
Código: RF008
Nome do Requisito: Habilitação de Fornecedores
Descrição: Efetuar habilitação dos fornecedores já credenciados para o
certame mediante a o checkin dos documentos exigidos em edital e que serão
predefinidos ao cadastrar o processo licitatório.
Código: RF009
Nome do Requisito: Gestão de propostas de preço
Descrição: Cadastro e ordenação automática das propostas de preço
apresentados pelos licitantes (Fornecedores interessados em participar da licitação
que compareçam ao local designado ou que envie envelope através de portador ou
não),
Código: RF010
Nome do Requisito: Gestão de lances verbais
Descrição: Cadastro, correção e exclusão de lances verbais de um
determinado item, ordenação automática, controle da rodada de lances, controle de
desistência de ofertas.
Código: RF011
Nome do Requisito: Checkin documentos habilitação
Descrição: Check-list de documentos entregues no envelope B (Documentos
de habilitação) conformidade com o edital.

39
Código: RF012
Nome do Requisito: Autenticação de usuários
Descrição: Processo de validação de dados de usuários para definição de
restrições de segurança e controle de tarefas executadas pelo usuário.
Código: RF013
Nome do Requisito: Geração de relatórios
Descrição: Listagem dados por tipo, (usuários, processos, itens, famílias,
departamentos...).
Código: RF014
Nome do Requisito: Filtro de relatórios
Descrição: Aplicação de filtros de dados nas listagens.
Código: RF015
Nome do Requisito: Ordenação de relatórios
Descrição: Aplicação de ordem no relatórios.
Código: RF016
Nome do Requisito: Impressão de relatórios
Descrição: Permite a impressão do resultados das listagens, filtradas e
ordenadas.

40
Código: RF017
Nome do Requisito: Recuperação de senha
Descrição: Possibilidade de recuperação de senha do usuário mediante
informação de dados básicos.
REQUISITOS NÃO FUNCIONAIS
Código: RNF001
Nome do Requisito: Legislação vigente (Leis 8.666/93, 10.520/02 e demais
resoluções atinentes)
Descrição: O sistema deve estar de acordo com a legislação vigente contida
nas Leis 8.666/93 lei Geral de licitações, Lei 10.520/02 lei que institui o pregão
presencial em âmbito federal e Lei complementar 123/06 lei de amparo à ME (Micro
empresas ) e PE(Pequenas empresas).
Código: RNF002
Nome do Requisito: Segurança do sistema
Descrição: Fazer validação de dados no lado cliente e no lado servidor afim
de evitar SQL-Injection (Técnica utilizada por pessoas mal intencionadas objetivando
injetar instruções não esperadas no Banco de dados dos sistema), oferecer
criptografia de senhas, restrições de segurança mediante papel do usuário.
Código: RNF003
Nome do Requisito: Performance do sistema

41
Descrição: Procurar aplicar tecnologias interativas de segundo plano com
Ajax, para aumentar a performance do sistema, evitando fluxo de dados
desnecessário e redução do tempo de resposta ao usuário final.
DIAGRAMAS
CASOS DE USO
Diagrama que descreve através de atores e balões, os papeis dos usuários
envolvidos e as ações possibilitadas aos usuários.
Na Figura 14, podemos acompanhar as principais ações realizadas pelos
usuarios do sistema, ilustrando de forma a clara a diferença de acesso entre os
diferentes papeis, onde informações e ações da alçada de cada usuarios é
restringida e onde apenas os administradores tem acesso ilimitado.

42
Figura 14 - Diagrama de casos de uso

43
MODELO ER(ENTIDADE RELACIONAL) LÓGICO
Figura 15 - Modelo ER entidade relacional lógico

44
FLUXOGRAMA DO PROCESSO LICITATORIO
FASES DO PREGÃO PRESENCIAL
Fase interna:
Requisição do objeto (Ordenador)
Justificativa para a contratação (Ordenador)
A requisição e a justificativa são efetuadas por meio do oficio
requisitório ao qual é direcionado ao gestor contendo as especificações e
justificativa da necessidade de aquisição do objeto.
Autorização para realização do certame (Gestor);
Após o recebimento do Oficio Requisitório o gestor verifica a
viabilidade da aquisição, se considerar viável, Verifica ao Chefe de Finanças
a disponibilidade Dotações Orçamentárias (recursos), caso contrário notifica-
se ao órgão interessado e arquiva os documentos.
Disponibilidade de recursos orçamentários (Chefe de Finanças)
Elaboração e aprovação do termo de referência (Ordenador)
Designação do pregoeiro e da equipe de apoio (Gestor)
Elaboração e aprovação do edital (Pregoeiro /Equipe apoio)
Parecer jurídico (Consultoria Jurídica /Advogado)
- Fase Externa:
Publicação do aviso contendo o resumo do edital (Pregoeiro /Equipe de
apoio)
Abertura da sessão (Pregoeiro e Equipe de apoio)
Credenciamento (Pregoeiro /Equipe de apoio)

45
Entrega dos envelopes (propostas e documentação) (Empresas)
Abertura das propostas (Pregoeiro)
Classificação das propostas (Pregoeiro / Equipe de Apoio)
Lances verbais sucessivos (Empresas Credenciadas )
Exame da aceitabilidade da oferta (Pregoeiro)
Negociação com o licitante vencedor da fase de lances (Pregoeiro)
Habilitação (Pregoeiro)
Declaração do vencedor (Pregoeiro)
Recursos (Pregoeiro)
Adjudicação (Pregoeiro)
Homologação (Gestor)

46
APÊNDICE 2 – DOCUMENTAÇÃO TÉCNICA
SIGAPLSISTEMA DE GERENCIAMENTO E
ACOMPANHAMENTO DE PROCESSOS LICITATÓRIOS
Documentação Técnica
Anderson C. Rodrigues
Floresta Azul – Ba, 20 de junho de 2012

47
Conteúdo
1. RESUMO DO SISTEMA 48
2. PLATAFORMA 48
3. ARQUIVOS DE CONFIGURAÇÃO 48
3.1 O ARQUIVO “config.inc.php” 48
3.2 O ARQUIVO “DB.inc.php” 51
3.3 O ARQUIVO “Lib.inc.php” 54
4. ESTRUTURA DA APLICAÇÃO 55
4.1 O DIRETÓRIO “BD” 55
4.2 O DIRETÓRIO “CONTROLES” 55
4.3 O DIRETÓRIO “MODELOS” 55
4.4 O DIRETÓRIO “VISOES” 56
4.4.1 O DIRETÓRIO ”VISOESIMG” 56
4.4.2 O DIRETÓRIO “VISOESCSS” 56
4.4.3 O DIRETÓRIO “VISOESJS” 56
5. PLUGINS 56
5.1 JQUERY 57
6. BANCO DE DADOS 57
6.1 MODELO ENTIDADE RELACIONAL (CONCEITUAL/LÓGICO) 57
6.2 MODELO ENTIDADE RELACIONAL (FÍSICO) 59
6.3 TABELAS BD 60
6.4 DICIONARIO DE DADOS 60

48
2. RESUMO DO SISTEMA
O SIGAPL Sistema de Gestão e Acompanhamento de Processos Licitatórios
é um sistema que visa auxiliar servidores públicos no acompanhamento e
gerenciamento dos processos licitatórios em órgãos aos quais são lotados. O
objetivo do sistema é eliminar falhas administrativas que muitas vezes tornam o
processo licitatório ineficaz, reduzindo o tempo de geração de relatórios e
oferecendo ferramentas de forma a agilizar o desenvolvimento na fase de lances
verbais um dos principais gargalos dos processos licitatórios atualmente.
3. PLATAFORMA
A opção foi por um sistema WEB uma vez que o sistema tem de acompanhar
as mudanças na legislação, torna-se muito mais fácil a atualização em um servidor
do que atualizar cada software cliente, além de possibilitar um controle mais amplo
no gerenciamento das instituições. Desta forma as seguintes características foram
propostas:
SGBD (Sistema Gerenciador de Banco de Dados): MySQL ver
5.5.20;
Servidor de Páginas Web: Apache 2.2.21
Tecnologia: PHP 5.3.9
Para o correto funcionamento do sistema é indicado que estejam instalados e
rodando os serviços acima.
ARQUIVOS DE CONFIGURAÇÃO
As necessidades podem variar durante a utilização do sistema por isso faz-se
necessário a parametrização de algumas variáveis.
O ARQUIVO “config.inc.php”
Muitas vezes algumas configurações se repetem por todas as partes do
sistemas, e podem mudar de acordo a necessidade dos usuários para evitar que
precise modificar todas as páginas para alterar uma simples configuração, este

49
arquivo reuni todas as parametrizações do sistema e é incluído em todas as demais
paginas.
-------------------------------------------- config.inc.php --------------------------
/*
********************************************
***********CONFIGURAÇÕES DO SISTEMA***********
**********************************************
*/
/* CONFIGURAÇÃO EXIBIÇÃO DE ERROS */
//error_reporting(0); //modo produção
error_reporting(E_ALL); //modo desenvolvimento
/*
* INICIO SESSÃO EM TODOS OS ARQUIVOS
*/
@session_start();
/* CONFIGURAÇÃO CODIFICAÇÃO DA PAGINA*/
header('Content-Type: text/html; charset=utf-8');
/*
* BLOQUEIO DE SISTEMA PARA MANUTENÇÃO
*/
define('SYSTEMBLOCKED', false);
/*
* SISTEMA EM MODO DEBUG
* Se ativado irá mostrar erros
*/
define('DEBUG', true);
/*
* IDIOMA
*/
define('LANGUAGE', 'pt-BR');
#define('LANGUAGE', 'en-US');
/*
* TEMPO PARA EXPIRAR COOKIE DE SESSÃO
* Tempo em segundos
* Ex.: 1800 segundos. Que equivale a 30 minutos.
*/
define('COOKIETIMEAWAY', 1800);
/*
* IMAGEM FAVICON
* Internet explorer na versão (IE8) não suporta icones animados, portanto caso deseje usar ícones
* animados deve-se ter um estado para uso no IE.
*/
define('FAVICON', 'favicon.ico');
define('ANIMATEDFAVICON', 'favicon_animated.ico');
/*
* E-MAIL PADRÃO PARA ENVIO DE EMAILS ATRAVES DO SISTEMA
*/
define('DEFAULTURL','http://127.0.0.1/sigapl');

50
define('DEFAULTEMAILHOST', 'ssl://smtp.127.0.0.1');
define('DEFAULTEMAILPORT', 465);
define('DEFAULTEMAIL', 'admin@127.0.0.1');
define('DEFAULTPASS', 'turbo123');
/*
* E-MAILS PADRÕES PARA RECEBIMENTO DE SOLICITAÇÕES
* Caso venha a ter mais emails basta adicionar seguindo o padrdão 'EMAILALGUMACOISA'.
*/
define('EMAILCONTATO', 'contato@itech10.com');
/*
* URL E DOMINIO PADRÃO
*/
#define('DEFAULTURL', 'http://www.itech10.com');
#define('DOMAIN', 'itech10.com');
/*
* TÍTULO DO SITE
*/
define('SITETITLE', 'SIGAPL - Sistema de Gestão e Acompanhamento de Processos Licitatórios');
/*
**********************************************
***********BANCO DE DADOS*********************
**********************************************
*/
define('DBNAME', 'sigapl');
define('DBPASS', '');
define('DBHOST', 'localhost');
define('DBUSER', 'root');
//define('DBSGBD', 'pgsql');
define('DBSGBD', 'mysql');
/*
**********************************************
***********UPLOAD*****************************
**********************************************
*/
define('FTPHOST', '');
define('FTPUSER', '');
define('FTPPASS', '');
define('FTPFOLDER', '/');
define('FTPPORT', 21);
define('FTPTIMEOUT', 36000);
/*
* LARGURA E ALTURA MINIMA E MAXIMA PARA UPLOAD DE IMAGENS
*/
define('MAXIMGWIDTH', 1024);
define('MAXIMGHEIGHT', 768);
define('MIMIMGWIDTH', 350);
define('MIMIMGHEIGHT', 240);
/*
* TAMANHO Mdz?XIMO PARA ENVIO DE UPLOAD
* 2 MBytes = 2048 KBytes
* 2048 KBytes = 2097152 Bytes
* Para calcular corretamente favor utilizar http://www.wilkinsonpc.com.co/free/articulos/calculadorabytes.html
*/
define('MAXUPLOAD', 2097152);

51
O ARQUIVO “DB.inc.php”
Este arquivo oferece uma interface de conexão com o banco de dados, neste
caso o MySQL, caso o de desenvolvedor tenha interesse em mudar de SGBD em
algum momento basta substituir as funções assim não precisa modificar toda a
aplicação.
---------------------------- DB.inc.php -------------------------
<?php
/**
* Description of DB *
* @author Anderson Rodrigues
* @data 02/05/2012
*/
include_once 'config.inc.php';
include_once 'Lib.class.php';
/**
* classe DB responsavel pela conexão com o banco de dados
* irá gerenciar as conexões
*/
class DB {
private $conn ;
private $lastQuery;
/**
* Construtor da classe efetua a conexão com o banco
* Caso haja qualquer erro ele retornará
*/
function __construct() {
if (($this->conn = mysql_connect(DBHOST, DBUSER, DBPASS )) or die('Não foi possível conectar a base de
dados.n'));
if(mysql_select_db(DBNAME, $this->conn) or die('Base de dados inexistente.'));
//se for modo de debug
if (!$this->conn && DEBUG) {
die('Não foi possível conectar ao mysql: ' . mysql_connect_error());
}
}
private function converteObjeto($objeto){
$dados = get_object_vars($objeto);
return $dados;
}
//TIPOS: 1 - NORMAL; 2 - COLECAO
public function geraArray($result,$tipo){
if($tipo == 1){
$array = array();
while($res = mysql_fetch_array($result)){
$array[] = $res;
}
mysql_free_result($result);
return $array;
} else if($tipo == 2){
$cont = 0;
foreach($result as $objeto){

52
$cont++;
$dados = $this->converteObjeto($objeto);
foreach($dados as $coluna => $valor){
$array[$coluna][$cont] = $valor;
}
}
return $array;
} else{
//ARRAY UTILIZADO NOS M� TODOS QUE GERAM A LISTAGEM DE COMPARAÇÃO PARA OS LOGS
$dados = $this->converteObjeto($result);
foreach($dados['fields'] as $coluna => $valor){
if(is_string($coluna)){
$coluna = $coluna;
$array[$coluna] = $valor;
}
}
return $array;
}
}
/**
* FUNÇÃO QUE RETORNA ULTIMO ERRO
*
* @return String
*/
public function getLastQuery() {
return $this->lastQuery;
}
/**
* FUNÇÃO QUE SETA ULTIMO ERRO
* @param String $lastQuery
*/
public function setLastQuery($lastQuery) {
$this->lastQuery = $lastQuery;
}
/**
* FUNÇÃO QUE IRÁ MOSTRAR ERROS NOS DIVS OU SUCESSO E SUAS MENSAGENS
* @param <String> $msg
* mensagem a ser exibida um erro ou sucesso na operação ou ainda um parametro invalido
* @param <Boolean> $success
* false / true a depender do sucesso da operação
* @param <String> $url
* url de destino após operação
* @return <String/Json>
* retorno tipo json
*/
public static function aviso($msg = '',$success = false, $url = ''){
$res = array(
'success' => $success,
'msg' => $msg,
'url' => $url
);
//echo json_encode($res);
die(json_encode($res));
return json_encode($res);
}
/**
* METODO DESTRUTOR IRÁ ENCERRAR A CONEXÃO COM O BANCO
*/
function __destruct() {
$this->closeDB();
}

53
public function getLib() {
return $this->lib;
}
public function setLib($lib) {
$this->lib = $lib;
}
/**
* FUNÇÃO QUE RETORNA CONEXÃO ATUAL
* @return Int Identificador da Conexão
*/
function getConn(){
return $this->conn;
}
/**
* FUNÇÃO QUE ENCERRA A CONEXÃO
* @return boolean
*/
function closeDB(){
if( @mysql_close($this->conn))
return true;
else
return false;
}
/**
* METHODO QUE EXECUTA COMANDO SQL, INSERT, UPDATE,
* @param <String> $query
* @return <Resource>
*/
function execSQL($query){
$this->lastQuery=$query;
if(!$this->getConn()){
//echo "a conexão foi perdida.n";
if (($this->conn = mysql_connect(DBHOST, DBUSER, DBPASS )) or die('Não foi possivel conectar a base de
dados.'));
if (!$this->conn) {
if(DEBUG)
die('Não foi possível conectar ao Banco.'. mysql_connect_error());
else
die('Não foi possível conectar ao Banco.');
}
}
if (mysql_query($query))
return true;
else{
if(DEBUG)
$this->aviso(mysql_error($this->conn));
else
$this->aviso('Erro ao Executar Sql.');
return false;
}
}
/**
* MÉTODO QUE IRÁ RETORNAR UMA CONSULTA
*
* @param String $query
* @return Mixer
*/
function openSQL($query){
$this->lastQuery=$query;
if(!$this->getConn()){

54
//echo "a conexão foi perdida.n";
if (($this->conn = mysql_connect(DBHOST, DBUSER, DBPASS )) or die('Não foi possivel conectar a base de
dados.'));
if (!$this->conn) {
if(DEBUG)
die('Não foi possível conectar ao Banco.'. mysql_connect_error());
else
die('Não foi possível conectar ao Banco.');
}
}
if ($result = @mysql_query($query)){
return $this->geraArray($result,1);
}else{
if(DEBUG)
$this->aviso(mysql_error($this->conn));
else
$this->aviso('Erro ao Executar Consulta.');
return false;
}
}
/**
* FUNÇÃO QUE RETORNA ULTIMA ID INSERÇÃO GERADA POR AUTOINCREMENT
* @return int
*/
public function lastId(){
return mysql_insert_id($this->getConn());
}
}
?>
O ARQUIVO “Lib.inc.php”
Este arquivo contempla as funções de validação, conversão e outras que
serão usadas em toda a aplicação, desta forma caso uma determinada página
necessite de uma função especifica basta incluir este arquivo antes de chamá-la.

55
ESTRUTURA DA APLICAÇÃO
Figura 16 - Estrutura da aplicação
A estrutura da aplicação em parte segue o padrão MVC (Model-View- Control)
é um modelo de desenvolvimento de Software, atualmente considerado uma
"arquitetura padrão" utilizada na Engenharia de Software. O modelo isola a "lógica"
(A lógica da aplicação) da interface do usuário (Inserir e exibir dados), permitindo
desenvolver, editar e testar separadamente cada parte.
O DIRETÓRIO “BD”
Este diretório contém o script de criação e povoamento inicial do banco de
dados, e armazenará os scripts de possíveis atualizações do banco.
O DIRETÓRIO “CONTROLES”
Este diretório segue o padrão MVC e é a pasta responsável por armazenar os
controles, ou seja arquivos que fazem a comunicação das telas(visões) e suas
regras de negócio estabelecidas pelos (modelos).
O DIRETÓRIO “MODELOS”
Este diretório segue o padrão MVC e é a pasta responsável por armazenar os
modelos ou seja arquivos que descreveram as entidades do banco eles serão

56
responsáveis pelas operações relacionadas às entidade e a persistência dos dados
através de operações no banco de dados.
O DIRETÓRIO “VISOES”
Este diretório segue o padrão MVC e é a pasta responsável por armazenar as
visões ou telas, estes arquivos serão a interface de iteração entre o sistema e o
usuário.
O DIRETÓRIO ”VISOESIMG”
Este diretório irá armazenar todas as imagens utilizadas no sistema.
O DIRETÓRIO “VISOESCSS”
Este diretório irá armazenar todas as folhas de estilo utilizadas pelo sistema.
O DIRETÓRIO “VISOESJS”
Este diretório irá armazenar os scripts Java script e as bibliotecas JQuery
utilizadas no sitema
PLUGINS
Para a geração, filtro e ordenação de relatórios e adicionar objetos de
interfaces foram incluídos alguns plugins ao sistema. Estes plugins foram
desenvolvidos por terceiros e seu uso e distribuição são gratuito, no caso de precisar
acrescentar ou modificar funcionalidades de algum plugin recomenda-se consultar a
documentação específica.

57
JQUERY
JQuery é uma biblioteca Javascript criada por John Resig e disponibilizada
como software livre e aberto, esta biblioteca contempla varias funções simples que
possibilitam o desenvolvedor fazer muito mais escrevendo menos.
BANCO DE DADOS
MODELO ENTIDADE RELACIONAL (CONCEITUAL/LÓGICO)
Figura 17 - Modelo Entidade Relacional (Conceitual/Lógico)

58
Este diagrama visa descrever o banco de dados de forma superficial abstraindo
os dados que serão armazenados, ele visa apenas uma ilustração dos
relacionamentos entre as tabelas.

59
MODELO ENTIDADE RELACIONAL (FÍSICO)
Figura 18 - Modelo Entidade Relacional (Físico)

60
Este diagrama ilustra as tabelas contidas no banco bem como seus atributos e
relacionamentos.
TABELAS BD
Figura 19 - Lista de tabelas
DICIONARIO DE DADOS
cargos
Campo Tipo Nulo Padrão Comentários MIME
id_cargo int(11) Não identificador
cargo varchar(20) Sim NULL cargo
cidades

61
Campo Tipo Nulo Padrão Comentários Links para
id_cidade int(11) Não identificador
cidade varchar(25) Não cidade
id_uf tinyint(4) Não identificador do
uf
ufs -> id_uf
class_itens
id_classe_item char(2) Não identificador
classe varchar(45) Não classe de item
credenciados
Campo Tipo Nulo Padrão Links para Comentários
id_credenciado int(11) Não identificador
id_licitacao int(11) Não licitacoes ->
id_licitacao
chave
estrangeira de
llicitação
vinculada
id_fornecedor int(11) Não fornecedores ->
id_fornecedor
chave
estrangeira de
fornecedor
vinculado
registro_empresa tinyint(1) Sim NULL 1 para entrega
de contrato
social 0 não
entrega
rg_proprietario tinyint(1) Sim NULL 1 para
apresentação
de rg
proprietario 0
não
apresentação
representante int(10) Não pessoas ->
id_pessoa
chave
estrangeira
tabela pessoa
para identificar
o credenciado
documentos_habiilitação
id_documentos_habiilita
ção
int(11) Não identificador
id_credenciado int(11) Não credenciados ->
id_credenciado
chave
estrangeira do
id do
credenciado

62
habilitacao_id_habilitac
ao
int(11) Não habilitacao ->
id_habilitacao
chave
estrangeira
indetificação
da habilitação
valido bit(1) Não b'0' 1 para
habilitacao ok
0 para
habilitação
irregular
familia
id_grupo char(2) Não grupos ->
id_grupo
chave
estrangeira
grupo
id_classe_item char(2) Não class_itens ->
id_classe_item
chave
estrangeira
classe item
id_familia int(11) Não identificador
fornecedores
id_fornecedor int(11) Não identificador
id_pessoa int(10) Não pessoas ->
id_pessoa
chave
estrangeira
para
especialização
pessoa
fornecedores_familia
id_fornecedor int(11) Não fornecedores ->
id_fornecedor
identificador
id_familia int(11) Não familia ->
id_familia
chave na
tabela familia
para
identificação
de familia
fornecida
funcionarios
id_funcionario int(11) Não identificador

63
id_pessoa
id_orgao int(11) Não orgaos ->
id_orgao
id_cargo int(11) Não cargos ->
id_cargo
dt_admissao date Sim NULL
grupos
id_grupo char(2) Não identificador
grupo varchar(45) Não
habilitacao
id_habilitacao int(11) Não identificador
id_tipo_documentos smallint(6) Não tipo_documentos
->
id_tipo_documen
tos
id_licitacao
instituicao
id_instituicao int(11) Não identificador
gestor int(10) Não pessoas ->
id_pessoa
diretor_financeiro int(10) Não pessoas ->
id_pessoa
id_pessoa
itens
id_item int(11) Não identificador
id_familia int(11) Não familia ->
id_familia
descricao varchar(80) Não
id_unidade int(11) Não unidades ->
id_unidade
licitacoes

64
id_licitacao int(11) Não identificador
num_licitacao varchar(4) Sim NULL
ano varchar(4) Sim NULL
id_fase int(11) Sim NULL
dt_certame timestamp Sim NULL
dt_homologacao date Sim NULL
dt_aviso date Sim NULL
dt_adjudicacao date Sim NULL
licitacoes_itens
id_licitacao
identificador
id_item int(11) Não itens -> id_item
quantidade decimal(8,3) Não 1.000
oferta_inicial decimal(8,3) Sim NULL
oferta_final decimal(8,3) Sim NULL
id_vencedor int(11) Não
logs
id_log int(11) Não identificador
hora timestamp Não CURREN
T_TIMES
TAMP
texto varchar(25) Sim NULL
id_tipo_log int(11) Não tipos_log ->
id_tipo_log
id_usuario int(10) Não usuarios ->
id_usuario
ofertas
idofertas bigint(20) Não identificador
id_licitacao int(11) Não
id_item int(11) Não
id_credenciado int(11) Não credenciados ->
id_credenciado
rodada smallint(6) Não 1
desistiu tinyint(1) Não 0
valor decimal(8,3) Não
orgaos

65
id_orgao int(11) Não identificador
id_instituicao int(11) Não instituicao ->
id_instituicao
ordenador int(10) Não pessoas ->
id_pessoa
nome_orgao varchar(45) Não
pessoas
id_pessoa int(10) Não identificador
nome varchar(45) Não
tipo_pessoa char(1) Não
rg varchar(12) Não
org_exp varchar(6) Não
uf_exp char(2) Não
dt_emissao date Não
cnpf varchar(14) Não
dt_nascimento date Não
end_rua varchar(45) Não
end_bairro varchar(35) Não
id_cidade int(11) Não cidades ->
id_cidade
apelido varchar(15) Sim NULL
telefone varchar(10) Sim NULL
telefone2 varchar(10) Sim NULL
celular varchar(10) Sim NULL
email varchar(60) Sim NULL
tipo_documentos
id_tipo_documentos smallint(6) Não identificador
tipo_documento varchar(45) Não
tipos_log
id_tipo_log int(11) Não identificador
tipo_log varchar(10) Não
ufs

66
id_uf tinyint(4) Não identificador
uf varchar(18) Não
sigla char(2) Não
unidades
id_unidade int(11) Não identificador
unidade varchar(12) Não
sigla char(2) Não
usuarios
id_usuario int(10) Não identificador
login varchar(15) Não
senha char(32) Não
dt_criacao timestamp Não CURREN
T_TIMES
TAMP
criador int(11) Não
ult_login timestamp Sim NULL
num_acessos mediumint(8) Sim 0
id_pessoa
admin bit(1) Não b'0'
bloqueado bit(1) Não b'0'

Relatorio final anderson(versão final revisada 13-07-2012)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Relatorio final anderson(versão final revisada 13-07-2012)

Ähnlich wie Relatorio final anderson(versão final revisada 13-07-2012) (20)

Relatorio final anderson(versão final revisada 13-07-2012)