tcc em sistemas de informacao divaldo

Prévia do material em texto

6
	
		
UNIVERSIDADE ESTÁCIO DE SÁ
TCC EM SISTEMAS DE INFORMAÇÃO-EAD
 Professor Orientador: MSc. José Carlos Millan
2016
MÓDULO DE PREGÃO ELETRONICO PARA O SISTEMA PARA ORGÃOS PUBLICOS e-Cidade 
Trabalho apresentado na disciplina de Projeto TCC EM SISTEMAS DE INFORMAÇÃO-EAD da Universidade Estácio de Sá, como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação.
	Autor:	
Divaldo Almir Antunes
	Orientadora: MSc. Claudia Abreu Paes
	
2016
MÓDULO DE PREGÃO ELETRONICO PARA O SISTEMA PARA ORGÃOS PUBLICOS e-Cidade
Divaldo Almir Antunes - 201301013889
Trabalho apresentado na disciplina de Projeto TCC EM SISTEMAS DE INFORMAÇÃO-EAD da Universidade Estácio de Sá, como requisito parcial para obtenção do grau de Bacharel em Sistemas de Informação.
Aprovado em <mês> de 2016.
BANCA EXAMINADORA
________________________________________
Prof. MSc Claudia Abreu Paes - Orientador
Universidade Estácio de Sá
2016
Reitora
Paula Caleffi, DSc
Vice-Reitoria de Graduação
Vinícius da Silva Scarpi, DSc
Vice-Reitoria de Pós-Graduação e Pesquisa
Luciano Vicente de Medeiros, PhD
 
Vice-Reitoria de Cultura
Cipriana Nicolitt Cordeiro Paranhos, DSc
	Documento elaborado por:	Divaldo Almir Antunes
Ficha Catalográfica
MÓDULO DE PREGÃO ELETRONICO PARA O SISTEMA PARA ORGÃOS PUBLICOS e-Cidade
 / por 
DIVALDO ALMIR ANTUNES. – Niterói, RJ: [s.n.], 2016
.
nº
 
págs
 f., 29 cm.
Trabalho de conclusão do curso de informática – Faculdade Estácio de Sá, Campus Niterói, Curso
 de Sistemas de Informação, 2016
.
Orientador
a
: 
MSc
 Claudia Abreu Paes
Unitermos
: 
1-Pregão,
 
2-Licitação, 
3-e-Cidade, 
 
4-Pregoeiro. 
 
 
 
RESUMO
	
Pregão é a modalidade de licitação instituída pela lei nº 10520, de 17 de julho de 2002 para aquisição de bens e prestação de serviços comuns, no âmbito da União, Estados, Municípios e Distrito Federal. Neste tipo de julgamento de licitação, os licitantes que apresentaram melhores propostas de preço por escrito serão selecionados para a disputa, em sessão pública, por meio de lances, vencendo o licitante que apresentar o menor preço. 
A maioria dos órgãos públicos, principalmente prefeitura de pequeno porte realiza esta modalidade de licitação de forma precária, manualmente. Recentemente surgiram sistemas independentes para a realização de pregões, mas sem integração com outros módulos que necessitam das informações. O e-Cidade ainda não tem este módulo e após a conclusão do certame, os dados serão redigitados no módulo licitação, o que demanda tempo, informações desencontradas e retrabalho. Com base nos problemas citados surgiu à necessidade de criar um modulo para a realização de pregão de forma integrada ao e-Cidade. 
Este projeto tem por objetivo criar o módulo para a realização de Pregão Eletrônico integrado ao sistema e-Cidade - Software Público para Gestão Municipal, de fácil entendimento e que auxiliará o pregoeiro e equipe de apoio para a condução dos procedimentos durante a sessão pública e que ao finalizar o julgamento, todos os módulos do sistema que necessitem das informações tenham acesso.
Palavras-chave: Pregão, Licitação, e-Cidade, Pregoeiro.
LISTA DE ILUSTRAÇÕES
Figura 1 – Cronograma (Diagrama de Gantt) parte1.........................................................13
Figura 2 – Cronograma (Diagrama de Gantt) parte2.........................................................14
Figura 3 – Organograma da empresa ................................................................................16
Figura 4 – Descrição de Caso de Uso................................................................................24
Figura 5 – Diagrama de Classes.........................................................................................30
Figura 6 – Modelo Conceitual de Dados...........................................................................30
Figura 7 – Módulo e-cidade..............................................................................................31
Figura 8 – Módulo Patrimonial..........................................................................................32
Figura 9 – Módulo Pregão.................................................................................................32
Figura 10 – Menu Cadastro...............................................................................................33
Figura 11 – Menu Relatórios.............................................................................................33
Figura 12 – Menu Procedimentos......................................................................................34
Figura 13 – Tela Cadastro de CGM...................................................................................34
Figura 14 – Tela Cadastro de Fornecedor..........................................................................35
Figura 15 – Tela de Cadastro de Equipe de Apoio............................................................35
Figura 16 – Tela de Cadastro Pregão.................................................................................36
Figura 17 – Tela de Cadastro Habilitação..........................................................................36
Figura 18 – Tela de Cadastro Vinculo...............................................................................37
Figura 19 – Tela de Cadastro Lances.................................................................................37
Figura 20 – Diagrama de Sequencia – Equipe de Apoio...................................................38
Figura 21 – Diagrama de Sequencia – Pregão...................................................................49
Figura 22 – Diagrama de Sequencia – Habilitação............................................................40
Figura 23 – Diagrama de Sequencia – Vinculo.................................................................41
Figura 24 – Diagrama de Sequencia – Lances...................................................................42
Figura 25 – Diagrama de Estado – Pregão ........................................................................43
Figura 26 – Diagrama de Atividades (Processo Realizar Pregão).....................................44
Figura 27- Modelo de Classe de Projeto............................................................................45
Figura 28 – Diagrama de Componentes.............................................................................52
Figura 29 – Diagrama de Implantação...............................................................................53
LISTA DE TABELAS
Tabela 1 – Descrição do Caso de Uso "Controlar Acesso ao Módulo"............................ 24
Tabela 2 – Descrição do Caso de Uso "Cadastrar Equipe de Apoio" .............................. 25
Tabela 3 – Descrição do Caso de Uso "Cadastrar Pregão" .............................................. 25
Tabela 4 – Descrição do Caso de Uso "Cadastrar Habilitação do Fornecedor" .............. 26
Tabela 5 – Descrição do Caso de Uso "Cadastrar Vincular Fornecedor ao Pregão" ....... 26
Tabela 6 – Descrição do Caso de Uso "Cadastrar Lances" .............................................. 27
Tabela 7 – Descrição do Caso de Uso "Ata do Pregão" ................................................... 27 
Tabela 8 – Descrição do Caso de Uso "Relatório de Pregão por Fornecedor" ................. 28
Tabela 9 – Descrição do Caso de Uso "Relatório de Pregão"........................................... 28
Tabela 10 – Descrição do Caso de Uso "Relatório de Lances"..........................................29
Tabela 11– Cadastro Geral do Município (CGM)..............................................................45
Tabela 12 – Fornecedor......................................................................................................45Tabela 13 – Habilitação......................................................................................................46
Tabela 14 – Equipe de apoio..............................................................................................46
Tabela 15 – Pregão.............................................................................................................46
Tabela 16 – Vinculo...........................................................................................................46
Tabela 17 – Lances.............................................................................................................46
Tabela 18 – Projeto Tabela e Arquivos CGM...................................................................47
Tabela 19 – Projeto Tabela e Arquivos Fornecedor..........................................................47
Tabela 20 – Projeto Tabela e Arquivos Equipe.................................................................48
Tabela 21 – Projeto Tabela e Arquivos Habilitação..........................................................48
Tabela 22 – Projeto Tabela e Arquivos Pregão.................................................................49
Tabela 23 – Projeto Tabela e Arquivos Vínculo...............................................................49
Tabela 24 – Projeto Tabela e Arquivos Lances.................................................................50
Sumário
1	Proposta do Projeto...........................................................................................................11
1.1	Método de Trabalho.........................................................................................................11
1.2	Previsão de Alocação de Recursos...................................................................................11
1.3	Cronograma do Projeto (Diagrama de Gantt)..................................................................13
2	Caracterização da Empresa e do Negócio...............................................................................15
2.1	História do Pregão no Brasil ............................................................................................15
2.2	Atividade do Núcleo do Pregão .......................................................................................15
2.3	Organograma...................................................................................................................16
2.4	Mercado Consumidor......................................................................................................16
2.5	Concorrência....................................................................................................................17
2.6	Expansibilidade do negócio.............................................................................................17
2.7	Aspectos Tecnológicos.....................................................................................................17
2.8	Premisssas de restrição do projeto..................................................................................17
3	O Sistema Atual........................................................................................................................18
3.1	Justificativa de Escolha do Sistema...................................................................................18
3.1.1	O Sistema................................................................................................................18
3.1.2	Funcionamento do sistema.....................................................................................18
3.1.3	O Ambiente do Sistema..........................................................................................19
3.1.4	A definição do escopo.............................................................................................19
3.2	Motivação para o novo sistema.......................................................................................19
3.3	Situação Desejada............................................................................................................20
3.4	Problemas do sistema atual.............................................................................................20
4	O sistema proposto (projeto lógico)......................................................................................21
4.1	Requisitos do Sistema......................................................................................................21 
4.2	Casos de Uso....................................................................................................................24
4.3	Especificações dos casos de uso......................................................................................24 
4.4	Modelo Conceitual de Classes (Diagrama de Classe)...................................................... 30
4.5	Modelo Conceitual de Dados (MER)............................................................................... 30
5 Projeto de Interface.........................................................................................................31
 5.1 Tela do Menu Cadastro...................................................................................................34
 5.2 Tela do Menu Procedimentos.........................................................................................37
6 Diagrama de Sequencia....................................................................................................38
7 Diagrama de Estado..........................................................................................................43
8 Diagrama de Atividades....................................................................................................44
9 Projeto Físico...................................................................................................................45
 9.1 Modelo de Classes do Projeto........................................................................................45
 9.2 Modelo Físico dos Dados................................................................................................45
 9.2.1 Projeto de Tabelas e Arquivos............................................................................47
 9.3 Ambiente do Sistema.....................................................................................................50
 9.3.1 Definição do Ambiente Físico(hardware,software, infraestrutura de redes, 
 internet, etc).......................................................................................................50
 9.3.2 Justificativa da Escolha da Linguagem de Programação.....................................51
 9.3.3 Justificativa da Escolha do SGDB.........................................................................52
 9.4 Arquitetura do Sistema...................................................................................................52
 9.4.1 Diagrama de Componentes.................................................................................52
 9.4.2 Diagrama de Implantação...................................................................................53
10 Conclusões.....................................................................................................................54
 10.1 Reflexões Sobre os Objetivos Iniciais e Alcançados.......................................................54
 10.2 Vantagens do Sistema para a Empresa..........................................................................55
 10.3 Trabalhos Futuros..........................................................................................................55
REFERÊNCIAS BIBLIOGRÁFICAS......................................................................................56Proposta do Projeto
O aumento constante de tecnologias na área de automação nos diversos níveis e a necessidade de eficiência nos processos que envolvem um órgão público torna-se necessário a busca cada vez maior de automatizar rotinas tornando-as segura, de fácil realização e isentas de erros. 
O objetivo do e-Cidade é ter todos os módulo que envolve um sistema para uma prefeitura automatizada e integrada, evitando o retrabalho. Como o Pregão é um processo que envia informações para outros módulos e pode trazer sérias consequências para uma prefeitura caso não seja realizado de forma isenta de erros, viu-se necessário a busca de um meio rápido, eficiente e seguro para sua realização. 
A proposta desse projeto é criar o módulo para a realização de Pregões eletrônicos para o e-Cidade – Software Público de Gestão Municipal, integrado com os outros módulos, para que as prefeituras que o utilizam, possam realizar pregões de maneira eficiente e segura.
Método de Trabalho
Para a realização desse projeto, serão realizadas reuniões com o pregoeiro e equipe de apoio de uma prefeitura, para levantamento dos requisitos que comporão esse projeto, bem como acompanhamento integral de realização de um pregão, documentado por vídeos e fotos. Após cada reunião será elaborado um documento que descreverá detalhadamente todos os itens que foram abordados, documento este que será validado no final por cada componente da equipe. Ao final, participará ainda da análise dos requisitos um assessor técnico da área de compras e licitações.
Novas reuniões serão realizadas, para esclarecimentos de dúvidas, caso julgue necessário.
Será utilizada a UML (Unified Modeling Language) para representação dos modelos.
Previsão de Alocação de Recursos
Recursos Humanos
Um Analista de Sistema;
Um Pregoeiro;
		Uma equipe de apoio, composta de cinco técnicos;
 Um assessor técnico da área de licitação; 
Recursos Materiais (Hardware)
Dois Microcomputadores core i7 4gb;
Uma Impressora Lazer Jet HP M1132;
Recursos Materiais (Software)
MS Office 2007;
Windows 10;
Ubuntu 12.04 – servidor;
PostgreSql 9.2;
Apache 2.2.22;
PHP 5.3.10-1ubuntu3.11;
Javascript;
Cronograma do Projeto (Diagrama de Gantt)
As atividades a serem realizadas no escopo deste projeto estão planejadas no cronograma, Figura 1 e Figura 2.
Figura 1 – Cronograma (Diagrama de Gantt) parte1 
Figura 2 – Cronograma (Diagrama de Gantt) parte2 
	
	
	
	
	
	
Caracterização da Empresa e do Negócio
História do Pregão no Brasil
O pregão, também conhecido como leilão holandês ou reverso, é uma das seis modalidades licitatórias existentes no Brasil. Caracteriza-se pela inversão de fases do processo licitatório comum previsto na lei 8.666/83.  É um aprimoramento das demais modalidades licitatórias, possibilitando que a Administração Pública Federal, Estadual, Distrital e Municipal realizem aquisições de bens e serviços comuns através de lances sucessivos e decrescentes de forma fácil e rápida, gerando economia.
No Brasil, o pregão surgiu com o advento da Lei nº 9.472/97 (Lei Geral de Telecomunicações) que dispôs sobre a organização dos serviços de telecomunicações, criação e funcionamento de um órgão regulador e outros aspectos institucionais, prevendo nos seus artigos 54 e 56 o pregão como modalidade licitatória.
Após este primeiro momento, a Lei Federal nº 9.986/00, dispondo sobre a gestão de recursos humanos das Agências Reguladoras, ampliou o âmbito de utilização do pregão para as demais agências reguladoras, conforme previsto no artigo 37 desta lei.
Posteriormente, a Medida Provisória nº 2.026/00 instituiu, no âmbito da União, em consonância com o art. 37, inciso XXI, da Constituição Federal, o pregão como modalidade de licitação para aquisição de bens e serviços comuns. Essa Medida Provisória foi transformada na Medida Provisória nº 2.182/01 que foi reeditada por diversas vezes.
As Medidas Provisórias foram, então, convertidas na Lei nº 10.520/02 que não revogou a Lei no 8.666.
Atividades do Núcleo de Pregão
No inicio de cada sessão o pregoeiro procederá ao credenciamento dos representantes legais, em seguida será solicitada a entrega dos envelopes de habilitação e proposta. Serão abertos e checados os envelopes de habilitações e logo em seguida os de propostas. Depois de feita a análise dos requisitos formais e materiais das propostas, as mesmas serão classificadas e ordenadas sobre o critério de menor preço. Passa-se para a fase de lances onde os participantes serão chamados a reduzirem suas propostas, até que no final o participante com melhor proposta será declarado vencedor.
 
Organograma
A estrutura organizacional da empresa está organizada de acordo com a representação em Figura 3.
Figura 3 – Organograma 
Mercado Consumidor
 Os setores de Compra e Licitação dos órgãos públicos em todo o Brasil no julgamento de licitações que necessitem desta modalidade.
Concorrência
	Por se tratar de um setor único, o Núcleo de Pregão não possui concorrência, sendo apenas uma área de apoio ao Setor de Compras e Licitações de órgãos como: Prefeituras; Câmaras Municipais; Autarquias; Governos Estaduais; Governo Federal; etc.
Expansibilidade dos Negócios
Não se aplica.
Aspectos Tecnológicos
Para garantir a celeridade e clareza nos julgamentos, menor custo na aquisição de produtos e serviços, os órgãos públicos desde a criação dessa modalidade de licitação vêm investindo em recursos tecnológicos como: aquisição de sistemas; projetores multimídia, computadores, impressoras, etc.
Portanto, o órgão dispõe de tecnologia para desenvolvimento e implantação do sistema, escopo deste projeto.
Premissas de Restrição do Projeto
Como o módulo será inserido no sistema e-Cidade, onde o órgão público poderá optar por usar ou não este recurso, não foram identificadas restrições para a continuidade do projeto. Contudo para que o módulo seja implantado será necessário treinamento para toda a equipe e aquisição de alguns equipamentos mínimos como: computadores, impressoras e Projetor Multimídia.
O Sistema Atual
Atualmente há duas formas de realizar um Pregão. A primeira, e mais utilizada, principalmente em prefeituras de pequeno porte, é manualmente, onde a equipe de apoio procede com a coleta de valores relativos aos itens do processo e classifica-os, mostrando o resultado em um guadro negro ou em data show, fazendo uso de planilha eletrônica ou editor de texto. A segunda é adquirindo um sistema para realização de Pregão e proceder com os cadastros necessários e em seguida realizar o julgamento. O inconveniente deste tipo de sistema é que os dados terão que ser novamente digitados no e-Cidade ou em outro sistema.
Justificativa de Escolha do Sistema
A escolha por desenvolver um módulo de Pregão integrado ao e-Cidade baseia-se na necessidade de fazer uso dos recursos tecnológicos que se tem atualmente, além disso, esse módulo trará agilidade ao processo e a integração garantirá a clareza nas informações pois a entrada de dados acontecerá apenas uma vez, evitando ser redigitados o que aumetaria a chance de erros.
O Sistema
O módulo pretendido se baseia no controle total do julgamento de licitações na modalidade Pregão. 
Funcionamento do Sistema
	O funcionamento do sistema hoje é a forma tradicional, onde na data previamente marcada, toda empresa interessada a participar do certame deve estar presente, através de um representante legal, com dois envelopes contendo: documentos de credenciamento e proposta de preço inicial. Cada envelope deve ser entregue ao pregoeiro e equipe de apoio que após checá-los declarará a participante apta para o certame ou não, após o encerramento do credenciamento o pregoeiro abrirá o envelope de cada empresa, contendo o preço dos itens. A equipe de apoio verificará e classificará os itens que serão mostrados em telão ou quadro negro. Cada participante interessado a continuar no certame será convidado a fazernova proposta melhorando o preço, o processo se repetirá até restar apenas um participante. Finalizando é lavrada a ata de registros de preco que será assinada por todos os participantes e equipe de apoio encerrando o certame.
O Ambiente do Sistema
O sistema é utilizado pelo núcleo de pregão que é responsavel por proceder o credenciamento dos participantes e mostrar os resultados obtidos. Pelo pregoeiro para conduzir o andamento do certame, pelo setor juridico para concluir o contrato com o vencedor e pelo setor de compras e licitação para efetuar a aquisição de bens e serviços com base no resultado.
.
A Definição do Escopo
A criação do modulo Pregão integrado ao e-Cidade tem por finalidade a automatização completa do processo licitatório nessa modalidade desde o seu recebimento até seu julgamento final, atendendo as necessidades básicas de Cadastro de membros da equipe, representante legal, pregão e emissão de atas de encerramento, com consultas aos itens cadastrados e emissao dos relatorios exigidos. Os demais dados necessários já são cadastrados no e-Cidade nos módulos de compras e licitações.
O objetivo é que o núcleo de Pregão tenha total controle do processo, bem como segurança nos resultados obtidos.
O módulo enviará informações aos setores de compras e licitações garantindo maior agilidade e eficiência nos processos de compras.
Motivação Para o Novo Sistema
Após o levantamento e análise de informações e necessidades atuais do núcleo de pregão, foram obtidas as seguintes causas para o desenvolvimento do novo módulo:
- Dificuldade em manter e consultar o histórico de fornecedores;
- Classificação de resultados feitos em planilhas eletrônicas;
- Atas de encerramentos feitos em editores de textos e mantidos apenas em papel impresso;
- Falta de confiabilidade das informações;
- Falta de opções de relatórios;
- Risco de informações desencontradas nos módulos que recebem informações.
Situação Desejada
- Agilidade, segurança e simplificação no procedimento licitatório, permitindo que todos os participantes do certame tenha a oportunidade de ver examinada e discutida a sua proposta;
- Modernização no sistema de licitação, objetivando a administração um meio mais econômico, célere e eficaz para as contratações de serviços e aquisições de bens;
- Economia na realização do certame;
- Integração com os setores de compras, licitações, contabilidade, etc;
- Maiores opções de relatórios;
Problemas do Sistema Atual
	 O sistema atual na maioria dos órgãos públicos é feito de forma manual, os lances são mostrados em quadro negro ou em planilhas eletrônicas, o que causa demora na realização. Apenas os dados do participante vencedor são lançados no e-Cidade, ficando os demais em pastas e arquivos comuns, o que trará problemas caso acha necessidade de rever um processo. Pode haver desencontros de informações ao repassar os dados para outros setores. 
O Sistema Proposto (projeto lógico)
O e-Cidade por padrão é hospedado em um servidor que usa o sistema operacional Linux Ubuntu 12.04, servidor web apache 2.2.22, banco de dados postgreSQL 9.02, desenvolvido em PHP, Javascript, Ajax e HTML. O módulo Pregão será parte integrante do sistema e-Cidade e usará os mesmos recursos.
O objetivo da criação deste módulo é dar ao e-Cidade controle total na realização de Pregões de modo prático, simples, seguro e com rapidez. 
Descrição dos passos do módulo
Cadastros:
Cadastro de membros da equipe de apoio.
Cadastro do pregão.
Entrada de dados da habilitação do fornecedor.
Vincular fornecedor ao Pregão.
Cadastrar lances.
Relatórios:
Ata do pregão. 
Pregão por fornecedor. 
Pregão
Relatório de lances.
Requisitos do Sistema
Em análise junto ao núcleo de pregões da prefeitura tomada como base, podemos verificar os problemas existentes na realização dos pregões. Como a maioria dos órgãos públicos que usam o e-Cidade já dispõe de equipamentos necessários para o desenvolvimento do módulo, e diante da necessidade de melhor gerenciamento dessa área, segue abaixo os requisitos julgados como necessários para a implantação do módulo Pregão integrado com o e-Cidade – Software Público de Gestão Municipal.
Requisitos Funcionais:
- [RF1] Cadastrar, alterar e excluir membros da equipe de apoio: O sistema deverá permitir cadastrar alterar excluir membros da equipe de apoio. Todos os membros deverão ser previamente cadastrados no CGM(Cadastro Geral do Município), opção onde se cadastra toda pessoa física ou jurídica que tem relacionamento com o e-Cidade . O sistema não poderá permitir o cadastro de um membro mais de uma vez. O sistema deverá permitir a exclusão de membros da equipe de apoio. O sistema devera permitir a alteração dos membros da equipe de apoio. O cadastro devera conter apenas código, código do cgm e cargo na equipe de apoio, os demais dados estarão no cgm.
-[RF2] Cadastrar, excluir e alterar pregões: O sistema deverá permitir cadastrar, alterar e excluir pregões. O sistema devera permitir cadastrar novos pregões com seus atributos básicos. O Cadastro não poderá ser realizado no caso de já existir no sistema um cadastro de pregão com o mesmo numero. O sistema deverá permitir a exclusão do pregão por número, exceto no caso de já ter sido realizado. O sistema deverá permitir alterar os dados do Pregão exceto no caso de já ter sido realizado. Deverá constar no cadastro o número da ordem de compra, previamente cadastrada no módulo compras, que contem todos os itens e serviços que irão compor o pregão.
- [RF3] Cadastrar, excluir e alterar habilitação de fornecedores: O sistema deverá permitir cadastrar novas habilitações de fornecedores com todas as suas exigências. Caso já exista cadastro de habilitação para o fornecedor em questão o sistema informara a existência e não permitirá novo cadastro. O sistema deverá permitir a exclusão de habilitações de fornecedores por código do fornecedor. O sistema deverá permitir alterar habilitações de fornecedores, uma vez que habilitações têm prazos de validades. O fornecedor será previamente cadastrado no modulo compras.
- [RF4] Cadastrar e excluir vínculo de fornecedor ao pregão: O sistema deverá permitir o cadastro de novos vínculos de fornecedores a um determinado pregão com a proposta inicial. O sistema não poderá permitir mais de um vinculo de um fornecedor ao mesmo pregão. O sistema deverá permitir a exclusão do vinculo do fornecedor a um pregão. Caso o pregão já tenha sido realizado cadastros ou exclusões dos vínculos não serão permitidos.
- [RF5] Cadastrar, alterar e excluir lances: O sistema deverá permitir o cadastro de lances por fornecedor ao pregão. O Cadastro deverá gerar sequencia automática como campo chave para permitir mais de um lance por fornecedor ao mesmo pregão. O sistema devera permitir a exclusão de lances por fornecedor. O sistema deverá permitir a alteração de valores de lances por fornecedor. Caso o pregão já tenha sido realizado cadastros, exclusões ou alterações de lances não serão permitidas.
- [RF6] Relatórios, emitir ata de encerramento do pregão: O sistema deverá ao finalizar o pregão permitir a impressão da ata de encerramento do pregão com base nos dados cadastrados.
- [RF7] Relatórios, emitir relatório de pregão por fornecedor. O sistema deverá permitir a impressão de relatório de pregão por fornecedor vencedor dentro de um período especificado. Devendo conter o número do pregão, fornecedor vencedor, data da realização e valor final.
- [RF8] Relatórios, emitir relatório de pregão. O sistema devera permitir a impressão de relatório com detalhes do pregão. Devendo conter o número e a relação de todos os itens que compõem o pregão. Este relatório será emitido antes do julgamento para ser enviado aos interessados.
-[RF9] Relatórios, emitir relatório de lances. O sistema deverá permitir a impressão de relatório com todos os lances ofertados a um determinado pregão. Devendo conter no cabeçalho: Numero, data, breve resumo sobre os itens. No corpo: Hora, participante,valor do lance. O relatório devera ser em ordem decrescente de valor do lance. 
Requisitos Não Funcionais:
- [RNF1] Será criado um documento contendo um diagrama de classes, diagrama de caso de uso com suas descrições e com os demais diagramas, como também informações sobre o código fonte.
- [RNF2] Será criado um cronograma detalhado para o processo de desenvolvimento no qual constem: as atividades a serem desenvolvidas e em que período e com que recursos humanos e físicos serão desenvolvidos o sistema.
- [RNF3] A interface do sistema será agradável, objetiva e trivial ao usuário. Suas funcionalidades e informações deveram estar bem visíveis e disponíveis.
- [RNF4] Comunicação entre o sistema e usuário será com mensagens simples, explicando o erro gerado e evitando termos técnicos.
- [RNF5] Os relatórios não deverão demorar mais que 7 segundos para serem gerados.
- [RNF6] O tempo de resposta para as operações do banco de dados deverá ser de, no máximo, 3 segundos.
Casos de Uso
Nesta seção estão os diagramas onde estão registradas todas as funcionalidades do sistema, assim como os atores, onde ficará explicito suas responsabilidades.
Os requisitos do sistema ora proposto no escopo deste projeto estão representados no Diagrama de Caso de Uso, Figura 4.
Figura 4 – Diagrama de Caso de Uso
Especificações dos Casos de Uso
	Tabela 1 - Descrição do Caso de Uso "Controlar Acesso ao Módulo"
	Nome do Caso de Uso
	Controlar Acesso ao Módulo
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Atores Secundários
	
	Resumo
	Este caso de uso controla o acesso ao módulo Pregão e devera ser definido no módulo configurações ->Libera permissões de Menu
	Pré-condições
	Usuário já deve estar cadastrado no CGM - Cadastro Geral do Município
	Pós-Condições
	Definir usuários que terão acesso ao módulo Pregão
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Acessar o módulo Configurações.
	
	2. Selecionar o Menu Procedimentos
	
	3. Selecionar Libera Permissões de Menu
	
	
	4.Apresentar tela com as Instituições
	5.Selecionar a instituição Prefeitura
	
	
	6. Apresentar tela com os Módulos
	7. Selecionar módulo Pregão
	
	
	8. Apresentar tela com as opções de Menu
	9. Selecionar as opções de menu que o usuário terá acesso
	
	
	10. Salvar os dados do formulário
	Restrições/Validações
	Não há
Tabela 2 - Descrição do Caso de Uso "Cadastrar Equipe de Apoio"
	Nome do Caso de Uso
	Cadastrar Equipe de Apoio
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Ator Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Cadastro da Equipe de Apoio
	Pré-condições
	Os membros devem ser cadastrados previamente no módulo CGM - Cadastro Geral do Município
	Pós-Condições
	Manter Cadastro da Equipe de Apoio
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Cadastro de Equipe de apoio Inclusão
	
	
	2.Apresenta tela de Cadastro de Equipe de apoio
	3. Preenche dados do formulário
	4. Valida dados
	
	5. Salva dados do formulário.
	Restrições/Validações
	
	Fluxo alternativo – Equipe de apoio já existe
	
	
	1. Informa ao usuário que a equipe já está cadastrada
	
	2. O usuário poderá fazer consulta, alteração ou exclusão
Tabela 3 - Descrição do Caso de Uso "Cadastrar Pregão"
	Nome do Caso de Uso
	Cadastrar Pregão
	Caso de Uso Geral
	
	Ator Principal 
	Equipe de apoio
	Ator Secundário
	Pregoeiro
	Resumo
	Este caso de uso descreve a Etapa de Cadastro do Pregão
	Pré-condições
	A solicitação de compras já deve estar cadastrada no modulo Compras.
	Pós-Condições
	Manter Cadastro do Pregão
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Cadastro de Pregão-Inclusão
	
	
	2.Apresenta tela de Cadastro de Cadastro de Pregão
	3. Preenche dados do formulário
	4. Valida dados
	
	5. Salva o Pregão.
	Restrições/Validações
	
	Fluxo alternativo – Pregão já cadastrado
	
	
	1. Informa ao usuário que o Pregão já esta cadastrado
	
	2. O usuário poderá fazer consulta, alteração ou exclusão
Tabela 4 - Descrição do Caso de Uso "Cadastrar Habilitação do Fornecedor"
	Nome do Caso de Uso
	Cadastrar Habilitação do Fornecedor
	Caso de Uso Geral
	
	Ator Principal 
	Equipe de apoio
	Ator Secundário
	Pregoeiro
	Resumo
	Este caso de uso descreve a Etapa de Cadastro da Habilitação do Fornecedor
	Pré-condições
	O Fornecedor deve estar previamente cadastrado no módulo compras.
	Pós-Condições
	Manter Cadastro da Habilitação do Fornecedor
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Cadastro da Habilitação do Fornecedor-Inclusão
	
	
	2.Apresenta tela de Cadastro de Habilitação do Fornecedor
	3. Preenche dados do formulário
	4. Valida dados
	
	5. Salva o Habilitação do Fornecedor.
	Restrições/Validações
	
	Fluxo alternativo – Habilitação já Cadastrada
	
	
	1. Informa ao usuário que a Habilitação para o Fornecedor já esta cadastrado
	
	2. O usuário poderá fazer consulta, alteração ou exclusão
Tabela 5 - Descrição do Caso de Uso "Cadastrar Vincular Fornecedor ao Pregão"
	Nome do Caso de Uso
	Cadastrar Vincular Fornecedor ao Pregão
	Caso de Uso Geral
	
	Ator Principal 
	Equipe de apoio
	Ator Secundário
	Pregoeiro
	Resumo
	Este caso de uso descreve a Etapa de Cadastro do vínculo do Fornecedor ao Pregão com a proposta inicial
	Pré-condições
	Habilitação e o Pregão já devem estar previamente cadastrados
	Pós-Condições
	Manter Cadastro do Vínculo do Fornecedor ao Pregão
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Cadastro do vínculo do Fornecedor ao Pregão-Inclusão
	
	
	2.Apresenta tela de Cadastro do Vínculo do Fornecedor ao Pregão
	3. Preenche dados do formulário
	4. Valida dados
	
	5. Salva o Vínculo do Fornecedor ao Pregão.
	Restrições/Validações
	
	Fluxo alternativo – Vínculo já Cadastrada
	
	
	1. Informa ao usuário que o Vínculo do Fornecedor ao Pregão já esta cadastrado
	
	2. O usuário poderá fazer consulta, alteração ou exclusão
Tabela 6 - Descrição do Caso de Uso "Cadastrar Lances"
	Nome do Caso de Uso
	Cadastrar Lances
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Ator Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Cadastro de lances de fornecedores ao Pregão 
	Pré-condições
	Vínculo do fornecedor ao pregão com a Proposta inicial já devem estar previamente cadastrados.
	Pós-Condições
	Manter Cadastro de lances
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Cadastro de Lances de Fornecedores ao Pregão-Inclusão
	
	
	2.Apresenta tela de Cadastro de Lances de Fornecedores ao Pregão
	3. Preenche dados do formulário
	4. Valida dados
	
	5. Salva o lance do Fornecedor ao Pregão.
	
	6. Atualiza a grade de dados por ordem de menor preço
	Restrições/Validações
	
	Fluxo alternativo – Exclusão de Lance
	
	
	1. Permite ao usuário a excluir ou alterar lance no caso de digitação errado
	
	2. Abre o formulário
Tabela 7 - Descrição do Caso de Uso "Ata do Pregão"
	Nome do Caso de Uso
	Ata do Pregão
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Ator Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Emissão da Ata do Pregão
	Pré-condições
	O pregão já deve ter sido encerrado.
	Pós-Condições
	
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Relatório, Ata de Pregão.
	
	
	2. Apresenta tela de Emissão da Ata do Pregão
	3. Entra com o Número do Pregão 
	
	
	4. Imprime a Ata do Pregão.
Tabela 8 - Descrição do Caso de Uso "Relatório de Pregão por Fornecedor"
	Nome do Caso de Uso
	Relatório de Pregão por Fornecedor
	Caso de Uso Geral
	
	Ator Principal 
	PregoeiroAtor Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Emissão do Relatório de Pregão por Fornecedor
	Pré-condições
	O pregão já deve ter sido encerrado.
	Pós-Condições
	
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Relatório, Pregão por Fornecedor.
	
	
	2. Apresenta a tela de Emissão do Relatório de Pregão por Fornecedor
	3. Entra com o Período 
	
	
	4. Imprime o Relatório de Pregão por Fornecedor no período especificado
Tabela 9 - Descrição do Caso de Uso "Relatório de Pregão"
	Nome do Caso de Uso
	Relatório de Pregão
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Ator Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Emissão do Relatório de Pregão para envio aos participantes
	Pré-condições
	O pregão já deve ter sido Cadastrado.
	Pós-Condições
	
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Relatório, Pregão.
	
	
	2. Apresenta a tela de Emissão do Relatório de Pregão.
	3. Entra com o Número do Pregão
	
	
	4. Imprime o Relatório com todos os itens do Pregão
Tabela 10 - Descrição do Caso de Uso "Relatório de Lances por Pregão"
	Nome do Caso de Uso
	Relatório de Lances por Pregão
	Caso de Uso Geral
	
	Ator Principal 
	Pregoeiro
	Ator Secundário
	
	Resumo
	Este caso de uso descreve a Etapa de Emissão do Relatório de Lances por Pregão
	Pré-condições
	O pregão já deve ter sido encerrado.
	Pós-Condições
	
	
Fluxo Principal
	
	Ações do Ator
	Ações do Sistema
	1. Selecionar opção Relatório, Lances por Pregão.
	
	
	2. Apresenta a tela de Emissão do Relatório de Lances por Pregão
	3. Entra com o Número do Pregão
	
	
	4. Imprime o Relatório de Lances por Pregão
Modelo Conceitual de Classes (Diagrama de Classe)
Os dados que dão suporte aos requisitos do sistema proposto no escopo deste projeto estão representados na Figura 5 através do Diagrama de Classe.
Figura 5 – Diagrama de Classes
Modelo Conceitual de Dados (MER)
O modelo conceitual de dados (Figura 6) representa os relacionamentos entre as informações que dão suporte aos requisitos do sistema proposto no escopo deste projeto.
 
Figura 6 – Modelo Conceitual de Dados
5 Projeto de Interface
O e-cidade já foi naturalmente estruturado para ser o mais intuitivo possível, assim buscamos desenvolver o projeto de interface sem fugir desta característica, desta forma mostraremos abaixo as telas principais do módulo:
Figura 7 – Tela com todos os módulos de todas as áreas do e-cidade
Figura 8 – módulo Patrimonial – Entrada para o módulo Pregão
Figura 9 – Tela Principal do módulo pregão
Figura 10 – Tela do item de Menu “Cadastros”
Figura 11 – Tela do Item de Menu “Relatórios” – Relatórios emitidos pelo módulo
Figura 12 - Tela do item de Menu “Procedimentos”
5.1 Telas do Menu Cadastro
As telas do Menu Cadastro, são as principais telas de entrada de dados relevantes para o módulo, os itens que se seguem não necessários para que o pregão aconteça, neste item será mostrado a tela de cadastro do CGM – Cadastro Geral do Município, ela se encontra em outro módulo mas seus dados são utilizados em todo o sistema, assim para que se tenha entendimento do funcionamento dos itens do módulo Pregão, faz-se necessários que se mostre esta tela e a tela da figura 14 de cadastro de fornecedores.
Figura 13 – Tela de Cadastro de CGM – módulo Protocolo
Figura 14 – Tela principal do cadastro de fornecedores – Módulo Patrimonial->Compras (já existente no e-cidade)
Figura 15 – Tela de Cadastro da equipe de apoio
Figura 16 - Tela de Cadastro do pregão e seu objeto
Figura 17 – Tela de cadastro de habilitação
5.2 Telas do Menu Procedimentos
As telas do Menu Procedimentos, são as telas onde o pregão acontece, após os cadastros preliminares no Menu Cadastro, passa-se para a tela de procedimentos onde o fornecedor previamente habilitado será vinculado ao pregão e o lance inicial de cada fornecedor será lançado, a partir desse procedimento ocorre as novas propostas onde cada fornecedor poderá dar um novo lance, baixando o preço até que um saia vencedor.
Figura 18 – Procedimento “Vinculo do fornecedor ao pregão”
Figura 19 – Procedimento “Lances de fornecedores ao pregão”
6. Diagrama de Sequencia 
Consiste nos diagramas que irão mostrar a sequencia de atividades entre os atores e os objetos no sistema, para a realização das tarefas.
Descrição
O diagrama a seguir mostra a sequencia que o ator ira fazer para o caso de uso manter equipe de apoio, mostrando a troca de mensagens entre os objetos.
Figura 20 – Diagrama de sequencia – Equipe de apoio
Descrição
O diagrama a seguir mostra a sequencia feita pelo usuário para o caso de uso manter pregão, mostrando a troca de mensagens entre os objetos.
Figura 21 – Diagrama de sequencia – Cadastro do pregão
Descrição
O diagrama a seguir mostra a sequencia feita pelo usuário para o caso de uso cadastrar habilitação do fornecedor que irá participar de um pregão, mostrando a troca de mensagens entre os objetos.
Figura 22 – Diagrama de sequencia – Cadastro de habilitação do fornecedor
Descrição
O diagrama a seguir mostra a sequencia que o usuário fará para o caso de uso manter vinculo de fornecedor ao pregão, mostrando a troca de mensagens entre os objetos.
Figura 23 – Diagrama de sequencia – Cadastro do vinculo do fornecedor ao pregão
Descrição
O diagrama a seguir mostra a sequencia que o usuário fará para o caso de uso manter lances, mostrando a troca de mensagens entre os objetos.
Figura 24 – Diagrama de sequencia – Cadastro de lances
	
7. Diagrama de Estados
O diagrama de estados é uma ferramenta desenvolvida em estudos de máquinas finitas, na matemática, e tem sido adaptado a várias aplicações na informática.  Na análise essencial existe uma variação destes diagramas que são chamados de diagramas de transição de estados (DTE).  Em todas essas variações, usam-se os mesmos conceitos com representações diferentes.
Nesse diagrama, representamos os eventos, que podem ser para um caso e uso ou para tratamento de uma classe e também se modelam processos, por isto, é comum alguns “processos” serem analisados e documentados com diagramas de estado. O diagrama abaixo mostra a mudança de estados do resultado final do pregão.
Figura 25 – Diagrama de estado para realização do pregão
8. Diagrama de Atividades
O diagrama de atividades é um dos cincos diagramas disponíveis na UML para modelagem de aspectos dinâmicos do sistema. O diagrama abaixo mostra o fluxo de controle do processo para realização do pregão.
Figura 26 – Diagrama de atividades
9. O Projeto Físico
9.1 Modelo de Classes do Projeto
Na figura abaixo será demonstrado os relacionamento entre as classes do projeto
Figura 27 – modelo de classes do projeto
9.2 Modelo Físico dos Dados
Tabela 11 - cgm (cadastro geral do município)
Tabela 12 - fornecedor
Tabela 13 - habilitação
Tabela 14 -equipe
Tabela 15 - pregao
Tabela 16 - vinculo
Tabela 17 – lance
9.2.1 Projeto de Tabelas e Arquivos
O SGDB usado pelo e-cidade é o postgreSQL 9.2, desta forma as tabelas serão criadas utilizando scripts SQL padrão postgreSQL.
	
	Objetivo: Armazenar dados do cgm (cadastro geral do município)
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	Z01_NUMCGM
	int
	
	Não
	
	NOME
	varchar
	100
	Não
	
	ENDERECO
	varchar
	100
	Não
	
	CPF_CNPJ
	varchar
	14
	Não
	
	RG
	varchar
	15
	Não
Tabela 18 – projeto tabela cgmCREATE TABLE protocolo.cgm
(
 z01_numcgm integer NOT NULL DEFAULT 0,
 nome varchar(100) NOT NULL,
 endereco varchar(100) NOT NULL,
 cpf_cnpj varchar(14) NOT NULL,
 rg varchar(15) NOT NULL,
 CONSTRAINT cgm_numc_pk PRIMARY KEY (z01_numcgm)
)
	
	Objetivo: Armazenar dados do fornecedor
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_FORN
	Int
	
	Não
	FK
	Z01_NUMCGM
	int
	
	Não
	
	ATIVIDADE
	varchar
	50
	Não
	
	CPF_REPRESENTANTE
	varchar
	11
	Não
	
	NOME_REPRESENTANTE
	varchar
	60
	Não
Tabela 19 – projeto tabela fornecedor
CREATE TABLE compras.fornecedor
(
 Id_forn integer NOT NULL DEFAULT 0,
 z01_numcgm integer NOT NULL DEFAULT 0,
 atividade varchar(50) NOT NULL,
 CPF_representante varchar(11) NOT NULL,
 nome_representante varchar(60) NOT NULL,
 CONSTRAINT id_forn_pk PRIMARY KEY (id_forn),
 CONSTRAINT fornecedor_z01_numcgm_fk FOREIGN KEY (z01_numcgm)
 REFERENCES protocolo.cgm (z01_numcgm) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION
)
	
	Objetivo: Armazenar dados do equipe de apoio
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_EQUIPE
	Int
	
	Não
	PK
	Z01_NUMCGM
	int
	
	Não
	
	CARGO_EQUIPE
	varchar
	50
	Não
Tabela 20 – projeto tabela equipe
CREATE TABLE pregão.equipe
(
 id_equipe integer NOT NULL DEFAULT 0,
 z01_numcgm integer NOT NULL DEFAULT 0,
 cargo_equipe character varying(50) NOT NULL,
 CONSTRAINT id_equipe_pk PRIMARY KEY (id_equipe, z01_numcgm)
)
	
	Objetivo: Armazenar dados da habilitação
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_HABIL
	Int
	
	Não
	FK
	ID_FORN
	Int
	
	Não
	
	FAZENDA_NACIONAL
	boolean
	 
	Não
	
	FGTS
	boolean
	
	Não
	
	SEGURIDADE_SOCIAL
	boolean
	
	Não
	
	RECEITA_ESTADUAL
	boolean
	
	Não
	
	RECEITA_MUNICIPAL
	boolean
	
	Não
Tabela 21 – projeto tabela habilitação
CREATE TABLE pregao.habilitacao
(
 Id_habil integer NOT NULL DEFAULT 0,
 Id_forn integer NOT NULL DEFAULT 0,
 fazenda_nacional boolean DEFAULT false,
 fgts boolean DEFAULT false,
 seguridade_social boolean DEFAULT false,
 receita_estadual boolean DEFAULT false,
 receita_municipal boolean DEFAULT false,
 CONSTRAINT id_habilitacao_pk PRIMARY KEY (id_habil),
 CONSTRAINT habilitação_id_forn_fk FOREIGN KEY (id_forn)
 REFERENCES compras.fornecedor (id_forn) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION
)
	
	Objetivo: Armazenar dados do pregão
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_PREGAO
	Int
	
	Não
	FK
	ID_EQUIPE
	Int
	
	Não
	
	OBJETO
	text
	 
	Não
	
	DATA_DIVULGACAO
	date
	
	Não
	
	DATA_REALIZACAO
	date
	
	Não
	
	HORARIO
	varchar
	5
	Não
Tabela 22 – projeto tabela pregao
CREATE TABLE pregao.pregao
(
 Id_pregao integer NOT NULL DEFAULT 0,
 Id_equipe integer NOT NULL DEFAULT 0,
 objeto text NOT NULL,
 data_divulgacao date NOT NULL,
 data_realizacao date NOT NULL,
 horário varchar(5) NOT NULL,
 CONSTRAINT id_pregao_pk PRIMARY KEY (id_pregao),
 CONSTRAINT pregao_id_equipe_fk FOREIGN KEY (id_equipe)
 REFERENCES pregao.equipe (id_equipe) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION
)
	
	Objetivo: Armazenar dados do vinculo
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_VINCULO
	Int
	
	Não
	FK
	ID_HABIL
	Int
	
	Não
	FK
	ID_PREGAO
	int
	 
	Não
	
	VALOR_PROPOSTA
	double precision
	
	Não
Tabela 23 – projeto tabela vinculo
CREATE TABLE pregao.vinculo
(
 Id_vinculo integer NOT NULL DEFAULT 0,
 Id_habil integer NOT NULL DEFAULT 0,
 Id_pregao integer NOT NULL DEFAULT 0,
 valor_proposta double precision,
 CONSTRAINT id_vinculo_pk PRIMARY KEY (id_vinculo),
 CONSTRAINT vinculo_id_habil_fk FOREIGN KEY (id_habil)
 REFERENCES pregao.habilitacao (id_habil) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION,
 CONSTRAINT vinculo_id_pregao_fk FOREIGN KEY (id_pregao)
 REFERENCES pregao.pregao (id_pregao) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION
)
	
	Objetivo: Armazenar dados do lance
	Chave
	Nome do Campo
	Tipo do Campo
	Tamanho
	Nulo
	PK
	ID_LANCE
	Int
	
	Não
	FK
	ID_VINCULO
	int
	 
	Não
	
	LANCE
	double precision
	
	Não
Tabela 24 – projeto tabela lances
CREATE TABLE pregao.lance
(
 Id_lance integer NOT NULL DEFAULT 0,
 Id_vinculo integer NOT NULL DEFAULT 0,
 lance double precision,
 CONSTRAINT id_vinculo_pk PRIMARY KEY (id_vinculo),
 CONSTRAINT lance_id_vinculo_fk FOREIGN KEY (id_vinculo)
 REFERENCES pregao.vinculo (id_vinculo) MATCH SIMPLE
 ON UPDATE NO ACTION ON DELETE NO ACTION
)
9.3 Ambiente do Sistema
9.3.1 Definição do Ambiente Físico (hardware, software, infraestrutura de rede e internet, etc)
Como o e-cidade um software livre distribuído sem custo pelo Portal do Software Público (https://softwarepublico.gov.br), o ambiente físico mínimo, já se encontrava pré-definido, conforme descrição a seguir:
HARDWARE 
Servidor: A maioria das prefeituras faz opção por usar Servidores Cloud, com 2GB de memória, disco 500gb, com sistema operacional ubuntu 12.04, pois sendo o e-cidade um sistema web a arquitetura em nuvens reduz muito o custo com redes entre os diversos órgãos que em muitos casos ficam distantes uns dos outros, desta forma basta ter acesso a internet para acessar o sistema sem grandes complicações, contudo alguns órgão por motivo de segurança preferem servidores internos, assim qualquer computador Dual core ou superior com a configuração citada é suficiente para se trabalhar com o sistema.
Clientes: O e-cidade foi desenvolvido para trabalhar com o browser Firefox, mas suporta também o Google chrome sem nenhum problema, por esse motivo não há necessidade de exigir muito das estações de trabalhos, qualquer máquina que rodar estes dois browsers será suficiente para se trabalhar com o e-cidade, independente do sistema operacional.
SOFTWARE
O e-cidade não tem muita exigência para as máquinas clientes, desde que rode o Firefox 12 ou superior com bom desempenho, pois foi desenvolvido em PHP que trabalha do lado do servidor, contudo o servidor terá que ser configurado adequadamente, como sugerido pelos desenvolvedores do e-cidade.
Requisitos Mínimos
Apache 2.x (http://httpd.apache.org)
Firefox 12.0+ (http://www.mozilla.com/firefox)
PHP 5.3 (http://www.php.net)
PostgreSQL 9.2.x (http://www.postgresql.org)
CVS (http://cvs.nongnu.org/)
Eclipse PDT (http://www.eclipse.org/pdt)
Ubuntu Linux (http://www.ubuntu.com)
Java (http://www.java.com) - Business Intelligence
INFRAESTRUTURA DE REDES E INTERNET
A internet é a melhor opção para se trabalhar com o e-cidade, pois todo o seu desenvolvimento foi voltada para essa característica, justamente para evitar o gasto com grandes estruturas de redes, a única exigência nesse ponto é que o servidor tenha um IP fixo para que seja possível o acesso de qualquer computador conectado a internet, entretanto é possível trabalhar apenas em rede interna, desta forma qualquer rede que tenha um bom desempenho de comunicação entre clientes e servidor será suficiente para trabalhar com um desempenho satisfatório. 
9.3.2 Justificativa da Escolha da Linguagem de Programação
PHP é uma das linguagens mais usadas no mundo para desenvolvimento web oferecendo um ótimo desempenho e de fácil entendimento, como o objetivo era criar um sistema voltado totalmente para o acesso web, foi considerada a ideal.
9.3.3 Justificativa da Escolha do SGDB
A escolha foi pelo PostgreSQL 9.2, por ser um sistema Open-source, sem necessidade de licença, e ainda, robusto, fácil, simples, seguro, boa documentação, várias listas de discussões. Suporta grandes volumes de dados com ótimo desempenho. Para a escolha foi criado uma base de dados e foiinserido dados continuamente durante uma semana, em seguida foi feito vários testes de alterações, exclusões, consultas e o SGDB suportou o teste com grande eficácia.
9.4 Arquitetura do Sistema
9.4.1 Diagrama de Componentes
O diagrama de componentes tem como objetivo mostrar como o módulo pregão ira funcionar, mostrando a relação e dependências entre seus componentes por meio de interfaces, o módulo segue o mesmo princípio de todo o sistema que trabalha de forma dinâmica enviando e recebendo dados.
Figura 28 – Diagrama de componentes módulo pregão 
9.4.2 Diagrama de Implantação
O diagrama de implantação é grande importância na efetivação da conclusão dos trabalhos no desenvolvimento de sistemas, pois demonstra todos os requisitos necessários para que o sistema seja efetivamente implantado como características de hardwares, protocolos de comunicação, softwares. 
Por fim o diagrama de implantação é o roteiro utilizado para colocar o sistema em prática.
Figura 29 - Diagrama de implantação
10. Conclusões
O contato com prefeituras mostra que existem grande dificuldades para realizar tarefas consideradas simples e, como a mudança de gestores é relativamente curta, a preocupação com uma informatização eficiente e eficaz torna-se algo em segundo plano. De acordo com o site http://www.cidadedigitalbrasil.com.br/site/index.php/informatizacao-secretarias-da-prefeitura.html, os processos dos órgãos públicos nem sempre estão informatizados e normalmente fazem uso de diversos programas para conseguir realizar uma determinada atividade, consumindo muito tempo e apresentando falhas, este é o principal motivo para que prefeituras pelo Brasil tenham grades deficiências nas áreas de TI. 
Por volta do ano 2009 uma empresa do Rio Grande do Sul, a DBSeller – Serviços de Informática Ltda, numa atitude louvável, disponibilizou o e-cidade, um ERP desenvolvido pela empresa, com objetivo suprir um órgão publico em todas as suas áreas, entretanto, algumas deficiências existem e outras surgem a partir da evolução do setor público, como é o caso do pregão, que tornou uma exigência em alguns casos e surgiu depois do desenvolvimento do e-cidade. Para realizar pregões, várias empresas desenvolveram pequenos sistemas para esse fim, mas, sistemas que não interagem com setores de compras, licitação e contabilidade o que causa retrabalho para manter estes setores com informações atualizadas. Pensando nisso decidiu-se suprir esta necessidade criando um módulo integrado com as áreas citadas, e esse projeto tornou-se uma oportunidade para empregar os conhecimentos adquiridos nesse curso e ainda assim atender a necessidade do sistema.
.
10.1 Reflexões Sobre os Objetivos Iniciais e os Alcançados
Com a ocorrência de novas situações na realização de procedimentos nos setores públicos são constantes, existe uma necessidade de que empresas que trabalham no ramo mantenham atualizados seus sistemas de forma que acompanhem essas evoluções, isso não poderia ser diferente com o e-cidade.
Desta forma, o objetivo inicial desse projeto foi tornar o e-cidade moderno, evoluindo juntamente com o setor público brasileiro. E apesar de existir outras áreas de setores públicos que precisam do mesmo procedimento, procurou-se interagir e verificar a área de maior prioridade, assim, decidiu-se então pela área de compra e licitações, mais precisamente a área de pregão.
O objetivo alcançado é que ao final ter-se-á em mãos um projeto todo detalhado, baseado na linguagem UML para fazer as atualizações necessárias e tornar o e-cidade eficiente no que diz respeito às inovações que surgiram nos setores públicos nos últimos anos.
10.2 Vantagens do Sistema para a Empresa
Não é difícil encontrar sistemas no mercado para a realização de pregões com bastante eficiência, entretanto estes tipos de sistemas são de certo modo “solitários”, não interagem com os módulos que precisam destas informações, todos os dados gerados por este tipo de sistemas terão que ser redigitados no e-cidade ou em outro sistema, causando assim o retrabalho.
A vantagem de criar-se o módulo pregão dentro do e-cidade, é que os dados gerados estão na mesma base de dados, e serão automaticamente usados pelos outros módulos sem a necessidade de fazer tudo novamente, como se faz atualmente. 
10.3 Trabalhos Futuros
Como dito anteriormente, existem outras áreas de órgãos públicos que sofreram evoluções, pode-se exemplificar a área de controle interno, assim que esse projeto for concluído e o módulo pregão estiver efetivamente em funcionamento, voltar-se-á as atenções para outras áreas que também precisam do mesmo procedimento. Mesmo assim, atualizações necessárias na área estudada nesse projeto, serão sempre verificadas e estruturadas, isto será sempre um objetivo futuro. 
 
REFERÊNCIAS BIBLIOGRÁFICAS
DA SILVA, Alberto M. R; Videira, Carlos Alberto Escaleira, UML, Metodologias e Ferramentas CASE. 1ª.ed. Editora: Centro Atlântico: Portugal/2001
GIL, Antonio Carlos. Como Elaborar Projetos de Pesquisa. 5ª ed/2010. São Paulo: Atlas.
GILLEANES T. A. Guedes , Uml 2 - Uma Abordagem Prática. 2ª.ed Editora: NOVATEC, 2011.
http://www.ambitojuridico.com.br/site/index.php?n_link=revista_artigos_leitura&artigo_id=11202 Acesso em: 13 abril de 2016
http://www.tecmundo.com.br/excel/826-excel-criando-graficos-de-gantt.htm Acesso: 13 abril de 2016
Vídeo aulas da Universidade Estácio de Sá.(indisponíveis para não alunos da instituição.)
https://www.youtube.com/watch?v=FrCUJAOvwhs&list=PLcWKbfpRW2hmK1PuHsD32eRfz2BuUrKUE&index=8 Acesso em: 05 setembro de 2016
SILVA, Bruno Henrique Viladela; ALMEIDA, Juliano Garcia de; MOTA, Marcos Vinicius, Monografiasysarts-120204141241-phpapp01 2010 
SILVA, Allan, TCC em Sistema de Informação – 2014
http://tech.e-tinet.com/tech/o-melhor-banco-de-dados-postgres/ Acesso em: 12 setembro de 2016
http://dropsti.blogspot.com.br/2015/06/uml-diagrama-de-componentes.html#!/2015/06/uml-diagrama-de-componentes.html Acesso em: 15 setembro de 2016
		6		
		13