relatorio final anderson(versão final revisada 13-07-2012)

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

Upload: anderson-rodrigues

Post on 04-Jul-2015

307 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Relatorio final   anderson(versã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

Page 2: Relatorio final   anderson(versão final revisada 13-07-2012)

ANDERSON CONCEIÇÃO RODRIGUES

SIGAPL – SISTEMA DE GESTÃO E ACOMPANHAMENTO DE PROCESSOS

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

Page 3: Relatorio final   anderson(versão final revisada 13-07-2012)

ANDERSON CONCEIÇÃO RODRIGUES

SIGAPL – SISTEMA DE GESTÃO E ACOMPANHAMENTO DE PROCESSOS 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

Page 4: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 5: Relatorio final   anderson(versão final revisada 13-07-2012)

V

SIGAPL – SISTEMA DE GESTÃO E ACOMPANHAMENTO DE PROCESSOS

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.

Page 6: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 7: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 8: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 9: Relatorio final   anderson(versão final revisada 13-07-2012)

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 2que 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)

Page 10: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 11: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 12: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 13: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 14: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 15: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 16: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 17: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 18: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 19: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 20: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 21: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 22: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 23: Relatorio final   anderson(versão final revisada 13-07-2012)

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,

Page 24: Relatorio final   anderson(versão final revisada 13-07-2012)

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)

Page 25: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 26: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 27: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 28: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 29: Relatorio final   anderson(versão final revisada 13-07-2012)

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;

Page 30: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 31: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 32: Relatorio final   anderson(versão final revisada 13-07-2012)

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/

Page 33: Relatorio final   anderson(versão final revisada 13-07-2012)

33

APÊNDICE I – Documento de Requisitos

SIGAPL

SISTEMA DE GERENCIAMENTO E

ACOMPANHAMENTO DE PROCESSOS LICITATÓRIOS

Especificação de Requisitos

Anderson C. Rodrigues

Floresta Azul – Ba, 15 de Maio de 2012

Page 34: Relatorio final   anderson(versão final revisada 13-07-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

Page 35: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 36: Relatorio final   anderson(versão final revisada 13-07-2012)

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;

Page 37: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 38: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 39: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 40: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 41: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 42: Relatorio final   anderson(versão final revisada 13-07-2012)

42

Figura 14 - Diagrama de casos de uso

Page 43: Relatorio final   anderson(versão final revisada 13-07-2012)

43

MODELO ER(ENTIDADE RELACIONAL) LÓGICO

Figura 15 - Modelo ER entidade relacional lógico

Page 44: Relatorio final   anderson(versão final revisada 13-07-2012)

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)

Page 45: Relatorio final   anderson(versão final revisada 13-07-2012)

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)

Page 46: Relatorio final   anderson(versão final revisada 13-07-2012)

46

APÊNDICE 2 – DOCUMENTAÇÃO TÉCNICA

SIGAPL

SISTEMA DE GERENCIAMENTO E

ACOMPANHAMENTO DE PROCESSOS LICITATÓRIOS

Documentação Técnica

Anderson C. Rodrigues

Floresta Azul – Ba, 20 de junho de 2012

Page 47: Relatorio final   anderson(versão final revisada 13-07-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 ”\VISOES\IMG” 56

4.4.2 O DIRETÓRIO “\VISOES\CSS” 56

4.4.3 O DIRETÓRIO “\VISOES\JS” 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

Page 48: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 49: Relatorio final   anderson(versão final revisada 13-07-2012)

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');

Page 50: Relatorio final   anderson(versão final revisada 13-07-2012)

50

define('DEFAULTEMAILHOST', 'ssl://smtp.127.0.0.1');

define('DEFAULTEMAILPORT', 465);

define('DEFAULTEMAIL', '[email protected]');

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', '[email protected]');

/*

* 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);

Page 51: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 52: Relatorio final   anderson(versão final revisada 13-07-2012)

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();

}

Page 53: Relatorio final   anderson(versão final revisada 13-07-2012)

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(mysql_select_db(DBNAME, $this->conn) or die('Base de dados inexistente.'));

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()){

Page 54: Relatorio final   anderson(versão final revisada 13-07-2012)

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(mysql_select_db(DBNAME, $this->conn) or die('Base de dados inexistente.'));

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.

Page 55: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 56: Relatorio final   anderson(versão final revisada 13-07-2012)

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 ”\VISOES\IMG”

Este diretório irá armazenar todas as imagens utilizadas no sistema.

O DIRETÓRIO “\VISOES\CSS”

Este diretório irá armazenar todas as folhas de estilo utilizadas pelo sistema.

O DIRETÓRIO “\VISOES\JS”

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.

Page 57: Relatorio final   anderson(versão final revisada 13-07-2012)

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)

Page 58: Relatorio final   anderson(versão final revisada 13-07-2012)

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.

Page 59: Relatorio final   anderson(versão final revisada 13-07-2012)

59

MODELO ENTIDADE RELACIONAL (FÍSICO)

Figura 18 - Modelo Entidade Relacional (Físico)

Page 60: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Page 61: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Campo Tipo Nulo Padrão Comentários MIME

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

Campo Tipo Nulo Padrão Links para Comentários

id_documentos_habiilitação

int(11) Não identificador

id_credenciado int(11) Não credenciados -> id_credenciado

chave estrangeira do id do credenciado

Page 62: Relatorio final   anderson(versão final revisada 13-07-2012)

62

habilitacao_id_habilitacao

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

Campo Tipo Nulo Padrão Links para Comentários

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

Campo Tipo Nulo Padrão Links para Comentários

id_fornecedor int(11) Não identificador

id_pessoa int(10) Não pessoas -> id_pessoa

chave estrangeira para especialização pessoa

fornecedores_familia

Campo Tipo Nulo Padrão Links para Comentários

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

Campo Tipo Nulo Padrão Links para Comentários

id_funcionario int(11) Não identificador

id_pessoa int(10) Não pessoas ->

Page 63: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Campo Tipo Nulo Padrão Comentários MIME

id_grupo char(2) Não identificador

grupo varchar(45) Não

habilitacao

Campo Tipo Nulo Padrão Links para Comentários

id_habilitacao int(11) Não identificador

id_tipo_documentos smallint(6) Não tipo_documentos -> id_tipo_documentos

id_licitacao int(11) Não licitacoes -> id_licitacao

instituicao

Campo Tipo Nulo Padrão Links para Comentários

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 int(10) Não pessoas -> id_pessoa

itens

Campo Tipo Nulo Padrão Links para Comentários

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

Campo Tipo Nulo Padrão Comentários MIME

Page 64: Relatorio final   anderson(versão final revisada 13-07-2012)

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

Campo Tipo Nulo Padrão Links para Comentários

id_licitacao int(11) Não licitacoes -> 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

Campo Tipo Nulo Padrão Links para Comentários

id_log int(11) Não identificador

hora timestamp Não CURRENT_TIMESTAMP

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

Campo Tipo Nulo Padrão Links para Comentários

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

Page 65: Relatorio final   anderson(versão final revisada 13-07-2012)

65

Campo Tipo Nulo Padrão Links para Comentários

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

Campo Tipo Nulo Padrão Links para Comentários

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

Campo Tipo Nulo Padrão Comentários MIME

id_tipo_documentos smallint(6) Não identificador

tipo_documento varchar(45) Não

tipos_log

Campo Tipo Nulo Padrão Comentários MIME

id_tipo_log int(11) Não identificador

tipo_log varchar(10) Não

ufs

Page 66: Relatorio final   anderson(versão final revisada 13-07-2012)

66

Campo Tipo Nulo Padrão Comentários MIME

id_uf tinyint(4) Não identificador

uf varchar(18) Não

sigla char(2) Não

unidades

Campo Tipo Nulo Padrão Comentários MIME

id_unidade int(11) Não identificador

unidade varchar(12) Não

sigla char(2) Não

usuarios

Campo Tipo Nulo Padrão Links para Comentários

id_usuario int(10) Não identificador

login varchar(15) Não

senha char(32) Não

dt_criacao timestamp Não CURRENT_TIMESTAMP

criador int(11) Não

ult_login timestamp Sim NULL

num_acessos mediumint(8) Sim 0

id_pessoa int(10) Não pessoas -> id_pessoa

admin bit(1) Não b'0'

bloqueado bit(1) Não b'0'