PAULO HENRIQUE CALAES OLIVEIRA
Orientador: Túlio Ângelo Machado To�olo
SIGLA - SISTEMA INTEGRADO DE GESTÃO
LEGISLATIVA E ADMINISTRATIVA
Ouro Preto
Junho de 2011
Universidade Federal de Ouro Preto
Instituto de Ciências ExatasBacharelado em Ciência da Computação
SIGLA - SISTEMA INTEGRADO DE GESTÃO
LEGISLATIVA E ADMINISTRATIVA
Monogra�a apresentada ao Curso de Bachare-lado em Ciência da Computação da Universi-dade Federal de Ouro Preto como requisito par-cial para a obtenção do grau de Bacharel emCiência da Computação.
PAULO HENRIQUE CALAES OLIVEIRA
Ouro Preto
Junho de 2011
UNIVERSIDADE FEDERAL DE OURO PRETO
FOLHA DE APROVAÇÃO
SIGLA - Sistema Integrado de Gestão Legislativa e Administrativa
PAULO HENRIQUE CALAES OLIVEIRA
Monogra�a defendida e aprovada pela banca examinadora constituída por:
Prof. Msc. Túlio Ângelo Machado Toffolo � OrientadorUniversidade Federal de Ouro Preto
Prof. Msc. Marco Antônio Moreira de CarvalhoUniversidade Federal de Ouro Preto
Msc. Rodrigo Reis PereiraUniversidade Federal de Ouro Preto
Prof. Rafael Antônio Marques GomesInstituto Federal de Minas Gerais
Ouro Preto, Junho de 2011
Resumo
Com a popularização da internet as informações são disponibilizadas de maneira mais rápida
e fácil. O cidadão hoje consegue acompanhar notícias de seu interesse através de portais na
rede.
No trabalho que segue, é mostrado o desenvolvimento do Sigla, um sistema de gestão
utilizado na Câmara Municipal de Ouro Preto. Trata-se de um sistema web, multiplataforma,
que foi desenvolvido utilizando PHP e o framework javascript ExtJs, e que tem como principal
diferencial a integração dos dados Legislativos e Administrativos, além de uso de noti�cações
via mensagens no celular.
i
Abstract
With the popularization of the Internet, information is made available more quickly and easily.
The citizen today can follow the news that interests through portals on the web.
In the work that follows, will be show the development of Sigla, a management system
used in the �Ouro Preto City Council�, a web system, multiplatform, developed using PHP
and ExtJs javascript framework, whose main di�erential data integration Legislative and Ad-
ministrative, and use of mobile noti�cations.
ii
Agradecimentos
Agradeço ao Presidente da Câmara Municipal de Ouro Preto, Júlio Ernesto de Grammont
Machado de Araújo, por ter con�ado em meu trabalho.
Aos colegas da Câmara, pois sem a cooperação de todos esse projeto não seria possível.
Em especial ao Setor de Informática, que se esforçou muito para a conclusão de todo o
trabalho.
iv
Sumário
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Organização do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Descrição do Problema 3
2.1 Análise Preliminar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1 Sistemas legados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2 Sistemas adquiridos de terceiros . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Portal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Processo de criação de uma lei . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3 Exigências Fiscais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3 Tecnologias Utilizadas 9
3.1 Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Apache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5 ExtJS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.6 MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Sistema Desenvolvido 13
4.1 Ações Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2 Desenvolvimento do Sistema Integrado de Gestão Legislativa e Administra-
tiva(Sigla) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.1 Requisitos de Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.2 Requisitos Não Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.3 Requisitos Funcionais . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.4 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
v
5 Detalhamento dos Principais Módulos 18
5.1 Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2 Módulos Administrativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1 Recursos Humanos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
5.2.2 Minhas Informações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.2.3 Batidas de Ponto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
5.2.4 Verba Indenizatória . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
5.2.5 Contratos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2.6 Protocolos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2.7 Arquivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.2.8 Ofícios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.9 Agendamento de RG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.3 Módulos Legislativos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.1 Envio de Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.3.2 Recebimento de Proposta . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3 Sessão Plenária . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3.4 Tramitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3.5 Gerenciamento de Atas . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.6 Norma Jurídica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.3.7 Matérias Legislativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Impactos e Resultados 45
7 Conclusões 47
Referências Bibliográ�cas 48
vi
Lista de Figuras
3.1 Exemplo de código JSON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Drag e Drop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 Tela principal do Sigla . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.2 Exemplo de tela do Módulo de Recursos Humanos . . . . . . . . . . . . . . . . . . 21
5.3 Exemplo de dados pendentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.4 Exemplo de gerenciamento de atos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.5 Exemplo de tela do Módulo Minhas Informações . . . . . . . . . . . . . . . . . . . 23
5.6 exemplo de con�rmação de senha . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.7 Exemplo de tela do Módulo Batidas de Ponto . . . . . . . . . . . . . . . . . . . . . 25
5.8 Exemplo de tela do Módulo Verba Indenizatória . . . . . . . . . . . . . . . . . . . 26
5.9 Exemplo de tela do Módulo de Contratos . . . . . . . . . . . . . . . . . . . . . . . 27
5.10 Exemplo de adição de contrato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.11 Exemplo de edição de documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.12 Exemplo de cadastro de local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.13 Exemplo de tela do Módulo de Ofícios . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.14 Exemplo de um ofício gerado pelo sistema . . . . . . . . . . . . . . . . . . . . . . . 33
5.15 Exemplo da con�guração de uma agenda . . . . . . . . . . . . . . . . . . . . . . . . 34
5.16 Exemplo de tela do Módulo de Envio de Proposta . . . . . . . . . . . . . . . . . . 36
5.17 Exemplo de cadastro de uma proposta . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.18 Exemplo de tela do Módulo de Recebimento de Proposta . . . . . . . . . . . . . . 38
5.19 Exemplo de tela do Módulo de Sessão Plenária . . . . . . . . . . . . . . . . . . . . 39
5.20 Exemplo de digitação de ata utilizando player . . . . . . . . . . . . . . . . . . . . . 41
5.21 Exemplo de tela do Módulo de Matérias Legislativas . . . . . . . . . . . . . . . . . 43
5.22 Exemplo de edição de uma Matéria Legislativa . . . . . . . . . . . . . . . . . . . . 44
6.1 Reprodução da matéria publicada pelo jornal O Tempo . . . . . . . . . . . . . . . 45
vii
Capítulo 1
Introdução
Com a popularização da internet no Brasil, informações relacionadas aos mais variados temas
têm hoje fácil acesso. Nesse sentido o cidadão consegue agora obter informações que no
passado eram difíceis de serem conseguidas.
No cenário político essa prática começa a se tornar comum, pois com essa ferramenta o
eleitor agora pode acompanhar e �scalizar mais facilmente os mandatos de seus representantes
através de portais.
1.1 Motivação
O volume de informações gerado pelo processo legislativo é muito alto e para ser gerenciado
é necessário uma ferramenta de produção, gerenciamento e divulgação destes dados. Logo
se tornou prioridade a disponibilização de tal ferramenta para suprir a demanda na Câmara
Municipal de Ouro Preto (CMOP).
Integrar as partes legislativa e administrativa é um ponto chave, visto que, na prática, o
processo está ligado. É importante destacar que essa ferramenta não deve gerar mais trabalho
e sim automatizar o processo de forma que o resultado de todo o trabalho �que disponível no
portal da CMOP.
1.2 Objetivos
O objetivo geral do trabalho é a informatização do processo legislativo e administrativo da
CMOP. Processos legislativos são processos relacionados a criação de leis, a emissão de Atos,
Ofícios e Memorandos. Ainda na parte administrativa compreende o controle de Recursos
Humanos (RH), Verba Indenizatória (verba destinada ao gabinete do vereador), gestão de
contratos e controle do arquivo de documentos gerados no processo legislativo.
São objetivos secundários agilizar, de forma segura, todos os processos da CMOP, além de
tornar essas informações mais acessíveis ao cidadão através de um portal web.
1
1. Introdução 2
O projeto objetiva ainda satisfazer as exigências �scais impostas pelos agentes reguladores
para conseguir mais transparência em todo o processo legislativo e administrativo da CMOP.
1.3 Organização do Trabalho
Como foi visto, o primeiro Capítulo expõe uma introdução sobre o trabalho.
No Capítulo 2 é feita uma descrição do problema como um todo, onde serão apontados
pontos positivos e negativos, além de contextualizar o processo de criação de uma lei, processo
que é a base do sistema.
Em seguida, no Capítulo 3, são mostradas as tecnologias utilizadas no desenvolvimento
das soluções, tendo como destaque o uso de mensagens de celular, visando facilitar ainda mais
a interação do cidadão com o meio político.
No Capítulo 4 são relatadas as ações iniciais para a resolução do problema, além da análise
e implementação do sistema.
A apresentação dos principais módulos existentes no sistema é detalhada no Capítulo 5.
No sexto Capítulo é feita uma análise dos impactos e resultados obtidos pelos sistema.
Finalmente no Capítulo 7 é feita uma conclusão a respeito de todo o trabalho realizado.
Capítulo 2
Descrição do Problema
Com a troca de legislatura ocorrida em janeiro de 2009, foi solicitado pelo Presidente da
Câmara Municipal de Ouro Preto (CMOP) Júlio Ernesto de Grammont Machado de Araújo
junto ao Assessor de Informática Rafael Antônio Marques Gomes um relatório a respeito do
Setor de Informática visando saber a atual situação do setor em relação ao atendimento das
demandas da CMOP. A partir deste momento, o relatório de avaliação inicial foi criado e está
resumido nas Seções seguintes.
2.1 Análise Preliminar
Antes do início deste projeto, a CMOP possuía vários projetos de desenvolvimento de software
que tinham como propósito gerenciar as informações da Casa Legislativa. Estes sistemas
vinham sendo desenvolvidos há muitos anos, e poucos de fato contribuíram para melhorias no
funcionamento da Câmara, segundo o Assessor de Informática.
Este gerenciamento inadequado resultou em diversos sistemas com informações duplicadas,
sem integração entre si, além de não possuírem documentação. Grande parte deles não foi
utilizada dentro da Câmara.
Abaixo segue a relação destes sistemas com o respectivo detalhamento feito pela equipe
de desenvolvimento, composta pelo Assessor de Informática, um Técnico de Informática, um
Agente Legislativo e dois estagiários.
2.1.1 Sistemas legados
2.1.1.1 Sistemas de Recursos Humanos
Objetivo: Armazenar todas informações referentes à vida pro�ssional dos funcionários da
Câmara tal que pudessem ser extraídas informações referentes a benefícios, agendamento de
férias, cópias de contra-cheques, visualização de presenças, entre outras informações pro�ssi-
onais.
3
2. Descrição do Problema 4
Situação no início deste projeto: O sistema contemplava somente o cadastro básicos dos da-
dos dos funcionários e não estava em funcionamento. Necessitava de testes e desenvolvimento
de novas ferramentas.
2.1.1.2 Sistema de Notícias
Objetivo: Cadastrar as notícias que são publicadas no portal da Câmara.
Situação no início do projeto: Este sistema foi desativado, pois o portal da CMOP seria
posteriormente desenvolvido com uma tecnologia de gerenciamento de conteúdo que permite
este gerenciamento diretamente em sua área administrativa, não necessitando desenvolver
aplicações à parte.
2.1.1.3 Sistema de Rotinas
Objetivo: Cadastrar as rotinas de manutenção e suporte frequentes do setor de informática.
Situação no início deste projeto: Este sistema foi convertido apenas em um simples cadastro
de rotinas básicas vinculados ao portal da CMOP.
2.1.1.4 Sistema de Homenagem
Objetivo: Cadastro de honra ao mérito, moção de aplauso, medalha.
Situação no início deste projeto: Começou a ser utilizado no início e caiu em desuso, visto
que uma Homenagem é um tipo de Matéria Legislativa e deveria ser cadastrada juntamente
com as outras matérias e não em um sistema a parte.
2.1.1.5 Sistema de Protocolos
Objetivo: Cadastro de Protocolos
Situação no início deste projeto: Este módulo funcionava somente como um simples ca-
dastro dos protocolos, ou seja, uma transcrição do livro.
2.1.1.6 Sistema de atendimento ao cidadão
Objetivo: Cadastro de pessoas e registro de atendimentos
Situação no início deste projeto: Foi desenvolvido o cadastro de cidadão com registro de
atendimentos, porém em um banco de dados próprio. Este sistema encontra-se inativo
2.1.1.7 Sistema de Atas
Objetivo: Registrar as Atas das sessões plenárias para publicação no portal da Câmara.
Situação no inicio deste projeto: Este sistema possuía um banco de dados próprio onde as
atas eram inseridas sem nenhum tipo de formatação, somente um texto simples. Os arquivos
2. Descrição do Problema 5
de áudio utilizados como base para a transcrição destas atas eram salvos em uma pasta
compartilhada com baixo nível de organização. Estes arquivos também eram armazenados em
formato (.wav), o que torna o gerenciamento inviável em termos de armazenamento e backups,
além de gerar grande tráfego na rede.
2.1.1.8 Sistema de Agendamento de Plenário
Objetivo: Fazer as reservas do plenário podendo informar a estrutura necessária de equipa-
mentos.
Situação no inicio do projeto: Sistema era utilizado com frequência utilizando um banco
de dados próprio tendo como consequência falta de integração entre os sistemas.
2.1.1.9 Verba Indenizatória
Objetivo: Registrar os gastos dos vereadores utilizando a verba indenizatória e publicá-los no
portal da Câmara.
Situação no início deste projeto: O sistema foi utilizado pelos assessores dos vereadores e
as informações são publicadas no portal, também possuía um banco de dados próprio mas não
contempla algumas informações essenciais como CPF e CNPJ dos fornecedores, nem mesmo
um banco de dados seguindo as regras de normalização.
2.1.1.10 Sistema de Manutenção Diária
Objetivo: Controlar as tarefas executadas pelo setor de informática.
Situação no início deste projeto: O sistema não era utilizado por uma falta de de�nição
por parte da Chefe do Setor de Informática e também possuía banco de dados próprio.
2.1.1.11 Sistema de Planejamento
Objetivo: Sistema para atribuições de tarefas.
Situação no início deste projeto: Foi substituído pelo software livre dotProject que possuía
mais funções, atendendo de maneira mais satisfatória as demandas.
2.1.1.12 Sistema de Patrimônio
Objetivo: Controlar o patrimônio do setor de informática.
Situação no início deste projeto: Sistema inativo e com base de dados própria.
2. Descrição do Problema 6
2.1.2 Sistemas adquiridos de terceiros
2.1.2.1 Sapl
Sistema desenvolvido pela Interlegis que visa a organização das informações do processo legis-
lativo em uma plataforma web onde os dados são apresentados, em sua maioria, no portal da
Câmara. É um software livre onde o acesso aos códigos fonte é di�cultada por ter sido desen-
volvido em Python/Zope, linguagem essa que não é conhecida pelos atuais desenvolvedores.
Estava sendo desenvolvido novamente pela equipe de informática contemplando módulos que
hoje não existem na solução pronta e sendo adaptado à realidade da Casa. Os dados deste
sistema estão totalmente desorganizados e sem critério algum para inserção. Atualmente, não
se pode garantir quais documentos legislativos estão de fato registrados pois este sistema não
apresenta diretamente a falta deles. Um grande planejamento e mobilização da equipe deverá
ser feito para que se possa avaliar a atual situação dos cadastros e ao mesmo tempo, digitalizar,
digitar e lançar no novo sistema as informações que faltarem.
2.1.2.2 iPonto
Sistema de pontos dos funcionários desenvolvido em plataforma web com banco de dados Post-
gre armazenado em servidor Linux. Este sistema foi adquirido sob licença de software livre,
porém não foi disponibilizada a documentação do sistema por parte da empresa desenvolve-
dora, fazendo com que a equipe da CMOP não conseguisse fazer ajustes no mesmo. É um dos
sistemas que mais demandava atenção da equipe, onde ao contrário do que se propõe em um
projeto de modernização, está inviabilizando os trabalhos do Setor de Recursos Humanos pelas
constantes falhas e alto grau de dependência da informática. Os lançamentos das batidas de
ponto têm que ser feitos em sua grande maioria manualmente no banco de dados, ocasionando
também grande demanda desta equipe.
2.1.2.3 Sistema Memory
Sistema para gerenciamento de toda parte contábil da Câmara. É um sistema que exige atua-
lizações constantes e backups. Este sistema atende perfeitamente às necessidades da Câmara,
necessita somente de melhorias no relacionamento desta Casa com a empresa proprietária do
sistema (Memory), para que o suporte se tornasse satisfatório.
2.1.3 Portal
O portal da CMOP precisa ser reformulado para que além das informações disponibilizadas,
tenhamos novas funções como:
• Consultas diretamente na base de dados do sistema da CMOP;
2. Descrição do Problema 7
• Disponibilização das reuniões transmitidas online onde o usuário, além de poder assistir
as reuniões em alta qualidade, poderá acompanhar todas as informações da reunião
como:
� Matérias que fazem parte da reunião (Indicações, Leis, Moções,etc);
� Lista dos vereadores presentes;
� Chat para discussão dos visitantes que será monitorado por um moderador, onde
somente os comentários relevantes serão publicados;
• Manutenção dos vídeos para os visitantes assistirem a qualquer momento e saber tudo
que foi discutido.
• Plataforma de chat online para comunicação direta do funcionário com a Câmara para
tirar dúvidas e agendar serviços, como emissão de carteira de identidade, por exemplo.
2.2 Processo de criação de uma lei
Um dos principais problemas é a automatização do processo de criação de uma lei, visto que,
ele é feito sem nenhum tipo de informatização, os documentos não seguem a padronização que é
de�nida no manual da CMOP e acontecem problemas de perdas de documentos frequentemente
por não existir um controle e�caz.
O processo de criação de uma lei segue os seguintes passos:
1o Passo: O vereador cria um documento chamado proposta de lei.
2o Passo: A proposta de lei é assinada e encaminhada à secretaria para ser protocolada.
3o Passo: A proposta de lei após ser protocolada é inserida na pauta da próxima sessão
plenária (reuniões dos vereadores).
4o Passo: Após sua apreciação por parte dos vereadores ela retorna a secretaria e é enca-
minhada às comissões pertinentes.
5o Passo: Se aprovada a proposta é encaminhada novamente a sessão plenária para votação,
caso contrario é devolvida ao vereador que a criou para fazer as alterações necessárias.
6o Passo: Sendo aprovada ela é encaminhada ao gabinete da presidência, caso contrario,
retorna ao passo 1.
7o Passo: Na presidência é gerado um ofício, que deve ser assinado pelo presidente e
encaminhado ao Executivo contendo as propostas aprovadas na sessão plenária anterior.
8o Passo: Dentro da prefeitura ela sofre tramitações internas e pode ser ou não aprovada.
9o Passo: Caso seja aprovada ela é encaminhada a CMOP como ofício e se torna uma Lei,
caso contrário é devolvida ao vereadores.
10oPasso: A Lei devolvida é então armazenada no arquivo físico da CMOP.
2. Descrição do Problema 8
2.3 Exigências Fiscais
A Lei Complementar no 131, de 27 de maio de 2009, obriga os municípios a partir de 50
mil habitantes a divulgarem os gastos públicos na internet. De acordo com a lei, os sites
governamentais deverão contar com os balanços orçamentários, �nanceiros e patrimonial, além
de informações sobre contratos, convênios, demonstrativos da Lei de Responsabilidade Fiscal,
as receitas e despesas, e a relação de compras e despesas com viagens.
Capítulo 3
Tecnologias Utilizadas
Para a resolução dos problemas citados no capítulo anterior foram utilizadas as seguintes
tecnologias:
• Javascript
• JSON
• Apache
• PHP
• ExtJS
• MySQL
Segue abaixo uma breve descrição de cada uma delas.
3.1 Javascript
Lançada em 1995, a linguagem Javascript, que segundo Goodman (2001) ganhou o nome
por �motivos de marketing�, era uma linguagem que basicamente agregava funcionalidades às
páginas de internet, tornando-as mais interativas.
É uma linguagem interpretada, executada no navegador do cliente, e foi criada inicialmente
para atender a validação de formulários e interação com a página. Mas em pouco tempo �cou
claro que as possibilidades de interação eram surpreendentes. Tanto que até mesmo um de
seus criadores, Brendan Eich, deixou isto registrado em sua apresentação no livro �Javascript
a Bíblia� (Goodman (2001)).
A linguagem tem tipagem mutável e dinâmica, sem a declaração de tipos e oferece um
bom suporte a expressões regulares. De forma geral, o Javascript torna muito mais fácil
o tratamento de eventos no navegador, tanto que toda a interface com o usuário e alguns
módulos do browser Mozilla foram implementados utilizando a linguagem.
9
3. Tecnologias Utilizadas 10
3.2 JSON
JSON (JavaScript Object Notation - Notação de Objetos JavaScript) é uma formatação de
dados simples de ser gerada e interpretada, utilizada por diversas linguagens como C, C++,
Java, JavaScript e muitas outras. Segundo seu site o�cial, �json.org�, essas propriedades fazem
do JSON um formato ideal para troca de dados.
O JSON é constituído em duas estruturas, uma coleção de pares nome/valor e uma lista
ordenada de valores, sendo a primeira análoga ao Objeto em outras linguagens e a segunda
como um arranjo, vetor ou lista. Um exemplo dessa estrutura pode ser visto na Figura 3.1
Figura 3.1: Exemplo de código JSON
3.3 Apache
O servidor Web Apache é considerado por Marcelo (2005) um dos mais robustos e seguros
utilizados atualmente, mantendo cerca de 60% das páginas de internet do mundo.
Seu desenvolvimento começou em 1995, quando a National Center for Computer Aplicati-
ons (NCSA) criou a NCSA Web Server, um importante servidor de HTTP (Hipertext Transfer
Protocol). No entanto, o projeto �cou estagnado e uma parte da equipe se desligou, criando
a Apache Foundation ou Fundação Apache que hoje é responsável por sua manutenção.
Suas principais vantagens são o suporte a várias linguagens, entre elas o PHP, con�guração
rápida e simples, além de ser software livre e ter código fonte aberto.
3.4 PHP
A linguagem PHP (um acrônimo recursivo para �PHP: Hypertext Preprocessor �) segundo
Niederauer (2007) e Groupr (2010) é uma das linguagens de programação mais utilizadas no
3. Tecnologias Utilizadas 11
desenvolvimento de aplicações dinâmicas para web.
A principal diferença do PHP para o Javascript é que o código é executado do lado
do servidor, que gera o código HTML enviado ao cliente. Desse modo o código PHP �ca
inacessível para o receptor impossibilitando a cópia do script.
Segundo o site o�cial do PHP (php.net), uma das grandes vantagens de se usar a lingua-
gem é que ela é extremamente simples para os iniciantes e uma ferramenta poderosa para
programadores avançados. Ela é suportada por diversos servidores web, como o Apache.
O PHP, por ser portável, pode ser usado em diversos sistemas operacionais, comoWindows,
Mac OS e Linux, e também pode ser usado em programação, tanto estruturada como orientada
a objetos (a partir da versão 4).
Além de gerar códigos HTML, com PHP é possível gerar imagens, arquivos PDF e anima-
ções, todos de forma dinâmica do lado do servidor.
Outra importante propriedade da linguagem é a existência de módulos de conexão a vários
bancos de dados, como o MySQL e Postgre.
3.5 ExtJS
Criado por Jack Slocum, o software de código livre ExtJs é um framework Javascript cri-
ado primeiramente para ser utilizado no site Yahoo, como extensão do YUI (Yahoo! User
Interface). É suportado por praticamente todos os navegadores, incluindo Internet Explorer,
Mozilla Firefox e Google Chrome.
Segundo da Rosa (2010), uma de suas principais características é o fácil desenvolvimento
de interfaces para páginas e sistemas web com alta performance, customização e aparência
agradável.
ExtJS possui uma extensa documentação que �ca localizada em seu site o�cial
(www.sencha.com), que facilita eventuais consultas em sua API.
Como funcionalidades principais possui o fácil intercâmbio de dados entre seus scripts
PHP, de uma forma ágil, fácil e e�ciente, através do JSON. Possui também o recurso Drag
e Drop, que é o de arrastar e soltar, onde o usuário tem a possibilidade de arrastar algum
elemento da pagina e colocar em outro, exempli�cado na �gura 3.2.
A facilidade na criação de formulários é um fator que merece destaque, visto que grande
parte do sistema desenvolvido utiliza esse tipo de ferramenta de entrada de dados.
Para a exibição dos dados, o framework utiliza Grids (tabelas de dados), onde a exibição
dos dados �ca clara. Por meio de todas suas ferramentas, o ExtJS torna mais fácil de uma
maneira geral o desenvolvimento de aplicações web, possibilitando a criação de interfaces ricas
e e�cientes.
3. Tecnologias Utilizadas 12
Figura 3.2: Drag e Drop
3.6 MySQL
O MySQL é um sistema de gerenciamento de banco de dados (SGDB), lançado na década
de 1990 que utiliza SQL (Linguagem de Consulta Estruturada) como interface. Segundo seu
site o�cial (www.mysql.com) é um dos mais utilizados atualmente, contando com mais de
10 milhões de instalações pelo mundo. Entre seus principais usuários estão: Nasa, Banco
Bradesco, HP, Nokia, Sony, U.S. Army e Google.
Tem como características principais a portabilidade (pode ser usado em diversas platafor-
mas), compatibilidade (pode trabalhar com diversas linguagens, incluindo o PHP), excelente
desempenho e estabilidade, além de ser um software livre.
Capítulo 4
Sistema Desenvolvido
Nesse capítulo será mostrado o processo de desenvolvimento do sistema, mostrando algumas
características como o acoplamento de mensagens de celular no software.
4.1 Ações Iniciais
Feita a análise preliminar dos sistemas, foi traçado um plano de metas com os principais
pontos a serem discutidos durante o projeto.
Primeiramente foi necessária uma reestruturação física do setor a �m de disponibilizar
um ambiente mais propício para o suporte, manutenção e área de desenvolvimento. Isso foi
necessário pois o ambiente não era adequado para o desenvolvimento de softwares. Também
foi feita a contratação de dois estagiários para compor a equipe de desenvolvimento.
Com a parte de infra-estrutura melhor organizada, foi possível dar mais foco à parte de
desenvolvimento de sistemas, de�nindo as prioridades e decidindo se estes seriam desenvolvidos
internamente ou adquiridos de terceiros.
Os primeiros sistemas a serem colocados em pauta foram os terceirizados, sendo que o
primeiro deles foi o iPonto, que era o que mais demandava serviço da equipe de programadores,
além de ser um software que teve custos na implantação e com manutenção. Depois de uma
pesquisa de mercado e levantamento de informações junto a clientes de alguns fornecedores,
chegou-se a conclusão que seria melhor a substituição do software pelo sistema Ponto Secullum.
A solução para o Memory, que é um sistema que já suportava a demanda da CMOP e
possui um custo mensal relativamente baixo pelo que é proposto, foi apenas transferir seu
software para um servidor dedicado.
Após analisar o SAPL, percebeu-se que o mesmo não atendia os propósitos da CMOP
gerando retrabalho (como exemplo o cadastro de informações tanto no SAPL como no portal),
e deveria ser substituído. Feita uma pesquisa no mercado constatou-se que não existia uma
solução gratuita satisfatória e que as soluções pagas gerariam um custo muito alto para a
Casa, além de não atender todos os requisitos da forma como se propunha.
13
4. Sistema Desenvolvido 14
Nesse contexto foi estudada a possibilidade do desenvolvimento de um sistema para ge-
renciar todo o processo legislativo e administrativo de forma integrada. Após veri�car a
viabilidade iniciou-se a construção do SIGLA: Sistema de Gestão Legislativa e Administra-
tiva.
4.2 Desenvolvimento do Sistema Integrado de Gestão
Legislativa e Administrativa(Sigla)
A seguir será visto o processo de desenvolvimento do SIGLA, passando pelos levantamentos
até sua implementação.
4.2.1 Requisitos de Ambiente
4.2.1.1 Ambiente Físico
O Sigla foi desenvolvido para funcionar no ambiente interno da CMOP, com a possibilidade
ainda de ser acessado em sua totalidade pela internet.
4.2.1.2 Integração com Sistemas Existentes
O sigla deve ser capaz de se comunicar à base de dados SQLServer do sistema de controle
de ponto biométrico Ponto Secullum para coletar os dados, além de se comunicar com a
protocoladora Henry Prot II para colher dados de protocolo de documentos e se conectar à
uma impressora térmica de código de barras que utiliza a linguagem TLP (característica das
impressoras Zebra).
4.2.1.3 Fatores Humanos
Os usuários do sistema na sua maioria têm ensino médio completo, restrita familiaridade com
computador e tem resistência a implantação de um novo software.
4.2.1.4 Documentação
Deverá ser a feita documentação do software, além da criação de manuais para usuários do
sistema e ajuda online.
4.2.1.5 Recursos
De acordo com o Assessor de Informática e com os recursos disponíveis para contratação de
pessoal para composição da equipe, �cou de�nido que o seriam necessários três programadores,
um gerente de projeto, dois técnicos de suporte e manutenção e três estagiários para adequa-
ção de cadastros. É importante destacar que esta equipe foi composta por funcionários já
4. Sistema Desenvolvido 15
pertencentes ao quadro funcional da CMOP, não havendo necessidade de aumentar os gastos
com mais contratações.
O investimento em hardware e software deve ser bem reduzido, porém não foi de�nido um
limite orçamentário.
Foram adquiridas uma protocoladora, uma impressora térmica de código de barras e lei-
tores de código de barras.
O prazo para a conclusão do projeto foi de dois anos, inciado em janeiro de 2009 e terminado
em dezembro de 2010, exatamente a duração gestão da Mesa Diretora da CMOP.
4.2.2 Requisitos Não Funcionais
Os requisitos não funcionais mais importantes têm relação com con�abilidade e segurança,
visto que os dados gerados pelo sistema são de grande importância por se tratarem das leis
do município, além de informações sigilosas.
Por ser também um sistema web, outros requisitos importantes para a implementação
foram a robustez, desempenho e portabilidade, visto que o sistema precisa ser executado em
qualquer ambiente web, de forma e�ciente, e considerando o volume signi�cante de dados, isso
se torna um fator crítico a ser levado em consideração durante a implementação do sistema.
Por �m, facilidade de uso e produtividade, pontos chaves no desenvolvimento, já que é
objetivo do sistema o aumento da produtividade utilizando automatização em diversos pro-
cessos, lembrando ainda que a maioria dos funcionários não possui tanta familiaridade no uso
do computador.
O sistema deve possuir licença livre, atendendo as recomendações do governo em sua
política de utilização de softwares livres.
4.2.3 Requisitos Funcionais
Os requisitos funcionais de todos os módulos foram levantados junto aos usuários, através
de entrevistas e questionários, além de testes com protótipos de alta �delidade. Também foi
alvo de pesquisa o regimento interno da CMOP, de onde foram gerados os �uxogramas dos
processos legislativos.
4.2.4 Implementação
Após levantados todos requisitos e feita uma análise preliminar de toda a situação, foi de�nido
pelo Assessor de Informática, em consenso com toda a equipe, um cronograma para imple-
mentação dos módulos levando em consideração a prioridade e a interdependência de cada
um.
O próximo passo foi a escolha das linguagens e ferramentas a serem utilizadas durante a im-
plementação. As linguagens escolhidas foram PHP, Javascript e HTML, e ainda o framework
4. Sistema Desenvolvido 16
ExtJS, para dar maior agilidade ao desenvolvimento e padronizar os módulos do sistema. Tais
escolhas foram feitas devido ao conhecimento prévio das linguagens e ferramentas pela equipe.
Para banco de dados foi escolhido o Sistema Gerenciador de Banco de Dados (SGBD)
MySQL, pela sua robustez e con�abilidade, além de ser uma ferramenta livre. De�nido o
banco de dados, passamos então para a implementação, levando em consideração os requisitos
levantados e diversas reuniões da equipe de desenvolvimento.
A plataforma de desenvolvimento foi o DreamWeaver. Devido ao conhecimento prévio da
ferramenta pelos programadores, isso proporcionou um maior rendimento, se comparado com
as ferramentas antes utilizadas.
Iniciando a codi�cação do sistema, primeiramente foi dada atenção especial às classes
genéricas, como por exemplo a classe de ligação com banco de dados e conversão dos dados
do MySQL em JSON, chamada �Gerencia�, criada pelo programador Vinicius Nunes Lages,
estudante do curso de Engenharia de Controle e Automação da Universidade Federal de Ouro
Preto.
De�nidas as classes genéricas passamos a desenvolver os módulos de forma que cada pro-
gramador era responsável por um módulo, sendo coordenados pelo responsável pelo Setor de
Informática, Rafael Antônio Marques Gomes.
Os módulos eram desenvolvidos utilizando prototipação evolutiva, ou seja, à medida que
cada versão do módulo �cava pronta era levada aos usuários e se colhia novas informações
para que se conseguisse chegar ao produto �nal.
É importante ressaltar que alguns módulos demandaram mais trabalho, como por exemplo
o módulo de Recebimento de Propostas, que após pesquisas por soluções para conexão da
impressora térmica ao sistema, foi decidido desenvolver essa parte do sistema na linguagem
Java, que possuía um bom suporte e fácil implementação nesse caso.
Outro problema encontrado foi a disponibilização dos áudios e vídeos das reuniões que
eram transmitidas ao vivo, pois disponibilizá-los utilizando a estrutura de internet para serem
acessados externamente gerava uma demanda signi�cativa na rede interna, gerando assim
alguns transtornos. A solução foi disponibilizar para uso interno os arquivos em rede local e
armazenar cópias desses arquivos em um servidor web contratado, onde o portal é hospedado,
lembrando que essas cópias são feitas durante a madrugada, período que não exige demanda
da rede interna.
Após chegar a uma versão satisfatória, todos os módulos passaram por uma bateria de
testes que eram executados pela equipe de suporte e manutenção coordenada pelo Assessor
em Tecnologia da Informação II Denilson Silva Maciel.
Estes testes eram focados numa simulação de uso e com isso ao mesmo tempo em que
eram testados os módulos era possível um conhecimento maior dos mesmos por parte dessa
equipe, o que propiciou maior facilidade na confecção dos manuais dos módulos criados pelo
Agente Legislativo III, Kierley Sebastião da Silva, que ainda era responsável pelo treinamento
4. Sistema Desenvolvido 17
dos usuários.
Uma ferramenta importante que foi incorporada às noti�cações dentro dos módulos, como
con�rmação de agendamento de confecção de registro geral (RG) ou aviso de direito de férias
adquirido, que inicialmente era feita somente através de e-mail, foi a utilização de mensagens
de celular através da contratação de uma empresa especializada no serviço. Para acoplar tal
ferramenta ao sistema era utilizada uma API, em que era feita uma requisição ao servidor
da empresa passando o número do telefone e a mensagem a ser enviada. Essas mensagens
eram enviadas a um baixo custo além de serem monitoradas, controlando o gasto de envio por
número de celular, evitando assim um tipo de ataque que pudesse gerar um ônus maior.
Capítulo 5
Detalhamento dos Principais Módulos
Nas seções seguintes estão detalhados os módulos de maior destaque separados em Módulos
Administrativos e Módulos Legislativos. Estas seções mostram suas funcionalidades, caracte-
rísticas e os problemas encontrados durante sua implementação.
5.1 Desktop
É o módulo principal do sistema, onde todos os outros módulos são exibidos e controlados
dependendo das permissões e atribuições do usuário dentro da CMOP.
Seguir o modelo de desktop visto na �gura 5.1 foi uma sugestão do Técnico em Informática
Hugo Leonardo, a �m de se aproximar mais da realidade de interfaces que usuários tinham,
tornando mais fácil a utilização do sistema.
18
5. Detalhamento dos Principais Módulos 20
5.2 Módulos Administrativos
Os Módulos Administrativos são aqueles de suporte às atividades do Legislativo, entre ele
estão:
• Recursos Humanos
• Minhas Informações
• Batidas de Ponto
• Verba Indenizatória
• Prestadores de Serviço
• Contratos
• Protocolos
• Arquivos
• Visualizar Eventos
• Ofícios
• Memorandos
• Agendamento de RG
A seguir serão detalhados os módulos de maior destaque.
5.2.1 Recursos Humanos
O módulo de Recursos Humanos agrega todas as informações dos funcionários, possuindo
funções como o cadastro de funcionários, criação de atos de nomeação e exoneração (veja a
�gura 5.4) lançamento de férias, quinquênios, grati�cações e digitalização de contracheques.
Tem como grande destaque as noti�cações que são recebidas por e-mail e celular, lem-
brando aos funcionários de seus direitos de férias ou até mesmo uma incorporação de salário.
Para assegurar que os dados de todos os funcionários estão completos no módulo, quando
uma funcionária do Recursos Humanos abre o sistema uma tela aparece solicitando a adição
dos dados pendentes (ver �gura 5.3).
Durante o desenvolvimento foi percebido um problema quando era feita a substituição da
foto do funcionário, pois ela �cava no cache, e não atualizava quando era substituída. Para
solucionar o problema ao �m do nome da imagem no trecho de código onde ela é carregada
foi concatenado um número randômico como mostrado à seguir:
5. Detalhamento dos Principais Módulos 21
<img src=imagem.jpeg?123456789>
Com isso o problema foi resolvido de forma satisfatória sem precisarmos limpar o cache.
Figura 5.2: Exemplo de tela do Módulo de Recursos Humanos
5. Detalhamento dos Principais Módulos 22
Figura 5.3: Exemplo de dados pendentes
Figura 5.4: Exemplo de gerenciamento de atos
5. Detalhamento dos Principais Módulos 23
5.2.2 Minhas Informações
Módulo onde o funcionário pode visualizar suas informações (ver �gura 5.5), conferir seus
prazos de férias, ou fazer algum tipo de solicitação.
É possível também que a pessoa imprima uma cópia de seus contracheques através dessa
ferramenta.
Para aumentar a segurança, o módulo pede uma con�rmação de senha para que sejam
exibidas as informações do funcionário, como visto na �gura 5.6.
Figura 5.5: Exemplo de tela do Módulo Minhas Informações
5. Detalhamento dos Principais Módulos 25
5.2.3 Batidas de Ponto
No módulo de Batidas de Ponto os funcionários podem veri�car seus horários e ver até se
possuem direito a horas extras. Os chefes de seções, setores e departamentos podem também
controlar o horário de cada funcionário (ver �gura 5.7).
Na próxima versão do sistema esse módulo será parte do módulo Minhas Informações.
Figura 5.7: Exemplo de tela do Módulo Batidas de Ponto
5. Detalhamento dos Principais Módulos 26
5.2.4 Verba Indenizatória
Verba Indenizatória é o módulo que controla o gasto da verba de gabinete de cada vereador.
Nele são cadastrados todos os gastos a serem reembolsados posteriormente pela CMOP (ver
�gura 5.8).
Esses dados �cam disponibilizados no portal, para que o cidadão tenha acesso, propiciando
assim maior transparência do Poder Legislativo.
Esse módulo teve um grande destaque no início da implementação dos módulos, pois foi
um dos primeiros a entrar em produção e teve um grande reconhecimento, sendo inclusive
matéria do Jornal O Tempo, como mostra na �gura 6.1.
Figura 5.8: Exemplo de tela do Módulo Verba Indenizatória
5. Detalhamento dos Principais Módulos 27
5.2.5 Contratos
O módulo de Contratos registra todos os contratos vigentes e vencidos da CMOP (ver �gura
5.9), sendo que um grande diferencial, como no módulo de recursos humanos, são seus avisos,
que noti�cam os setores responsáveis dos vencimentos de contratos com 30, 15 e 1 dia antes
do �m de cada contrato.
Outra funcionalidade do módulo é a criação de termos aditivos de contratos, exempli�cado
na �gura 5.10, além da confecção de relatórios tanto sintéticos como analíticos, tendo como
sintéticos os relatórios que possuem apenas os principais dados dos contratos, e os analíticos
os relatórios mais detalhados, ou seja, com uma maior quantidade de informações.
Figura 5.9: Exemplo de tela do Módulo de Contratos
5. Detalhamento dos Principais Módulos 29
5.2.6 Protocolos
O módulo de Protocolos gerencia o envio e recebimento de todos os documentos da Casa. Esse
controle é feito através de uma máquina protocoladora, que é conectada via rede ao sistema,
que por sua vez recolhe os dados enviados e registra no banco de dados. Feito isso, é enviado
para a impressora térmica um código no seguinte formato utilizando a linguagem TPL, própria
das impressoras Zebra:
Q80,030
q832
rN
S4
D7
ZT
JB
OD
R235,0
N
B285,91,2,1,2,6,37,B,"1000000000775"
P1
No código acima é importante destacar o trecho �B285,91,2,1,2,6,37,B,"1000000000775"� '
que é onde é passado o valor a ser usado para gerar o código de barras e imprimir na etiqueta.
As outras partes do código dizem respeito à parte de formatação, fonte e espaçamentos.
Esse código é enviado utilizando um aplicativo Java, visto que não foi encontrada uma
solução para o problema utilizando a linguagem PHP.
5. Detalhamento dos Principais Módulos 30
5.2.7 Arquivos
Como o volume de documentos dentro da CMOP é alto, para facilitar o acesso a esses dados,
foi criado o módulo Arquivos, onde são cadastrados as referências de cada documento e sua
localização física dentro do arquivo da CMOP.
Com o módulo a localização dos documentos da CMOP �ca muito mais ágil, visto que
atualmente essas informações se encontram em registros impressos (ver �gura 5.11).
É possível a adição de novos locais físicos como mostra a �gura 5.12, pois com a ampliação
da CMOP novos locais serão disponibilizados e essa inclusão será frequente.
Figura 5.11: Exemplo de edição de documento
5. Detalhamento dos Principais Módulos 32
5.2.8 Ofícios
O módulo de Ofícios é responsável pela criação e gerenciamento dos ofícios emitidos pela
CMOP.
É interessante destacar que os ofícios agora tem uma numeração padrão e seu formato
também foi padronizado de acordo com o manual da presidência (ver �gura 5.14). É possível
também consultar um histórico de ofícios, além de imprimir relatórios analíticos e sintéticos
dos dados cadastrados (ver �gura 5.13).
Para os funcionários da secretaria o módulo oferece a função de relacionar matérias ao
ofício, para que se torne mais ágil o envio de matérias ao executivo.
Figura 5.13: Exemplo de tela do Módulo de Ofícios
5. Detalhamento dos Principais Módulos 34
5.2.9 Agendamento de RG
Um dos serviços prestados pela CMOP é a confecção de carteiras de identidade. Como a
demanda é muito grande é preciso um agendamento prévio feito por telefone. Para melhorar
esse agendamento que era originalmente feito em papel, foi criado o Módulo de Agendamento
de RG que, além de organizar melhor a agenda, que é dinâmica e sofre alterações de horário
frequentemente (ver �gura 5.15), possui ainda o recurso de noti�car a pessoa que solicitou o
agendamento via e-mail e celular, informando o dia, horário e documentos necessários para
a confecção da carteira. O módulo ainda conta com um controle de produção das carteiras
facilitando assim a emissão de relatórios de produtividade.
Figura 5.15: Exemplo da con�guração de uma agenda
5. Detalhamento dos Principais Módulos 35
5.3 Módulos Legislativos
Os Módulos Legislativos são aqueles que estão diretamente ligados ao Legislativo, entre ele
estão:
• Envio de Propostas
• Recebimento de Propostas
• Sessão Plenária
• Tramitação
• Gerenciamento de Atas
• Normas Jurídicas
• Matérias Legislativas
• Comissões
A seguir serão detalhados os módulos de maior destaque.
5.3.1 Envio de Proposta
No módulo de Envio de Propostas, vereadores podem criar seus requerimentos, indicações,
projetos de lei ou qualquer outro tipo de matéria legislativa, como pode ser visto na �gura
5.17.
Todos os documentos gerados pelo módulo são padronizados e recebem uma numeração que
facilita a organização de seus arquivos (ver �gura 5.16). Nele um vereador tem um parecer do
envio de sua matéria, pois se ela contiver algum erro pode ser rejeitada ou aceita na secretaria.
Com o módulo é possível fazer pesquisas no histórico e imprimir relatórios a �m de aferir
a produtividade do parlamentar.
5. Detalhamento dos Principais Módulos 36
Figura 5.16: Exemplo de tela do Módulo de Envio de Proposta
5. Detalhamento dos Principais Módulos 38
5.3.2 Recebimento de Proposta
O Recebimento de Propostas funciona como complemento do Envio de Propostas. Assim
que um documento é enviado, este aparece na tela do funcionário responsável, como mostra
a �gura 5.18. Quando está correto é impresso, assinado pelo vereador e protocolado na
secretaria, onde recebe um código de barras para facilitar o acesso a seus dados.
O recebimento dos dados e a impressão do código de barras é feito da mesma forma como
no cadastro de protocolos.
Figura 5.18: Exemplo de tela do Módulo de Recebimento de Proposta
5. Detalhamento dos Principais Módulos 39
5.3.3 Sessão Plenária
O módulo de Sessão Plenária é responsável pelo controle de todas as reuniões que acontecem
na CMOP (ver �gura 5.19) tem como principais funcionalidades o cadastro das reuniões, com
seus áudios e pautas, que são geradas automaticamente.
A adição de uma matéria dentro de uma reunião é feita através de leitores óticos para
agilizar o processo e não é preciso re-digitar todos os dados da matéria.
O upload dos áudios das reuniões tiveram que ter uma atenção especial, pois o tamanho
dos arquivos eram em média 150 MB, e se fosse feito em horário de expediente atrapalharia
o desempenho da rede. Então foi feito um script, que envia todo dia às 0h os dados para o
servidor web externo onde os usuários de fora da Câmara tem acesso pelo site. E para os
funcionários que tem acesso local, os áudios �cam em um servidor local para um acesso mais
rápido as informações.
Figura 5.19: Exemplo de tela do Módulo de Sessão Plenária
5. Detalhamento dos Principais Módulos 40
5.3.4 Tramitação
O módulo de tramitação é responsável por controlar o andamento de um documento dentro
da Casa. A cada movimentação do documento, o cidadão que solicitou o acompanhamento
de algum desses projetos no portal recebe um aviso via e-mail e celular dizendo a atual
localização do documento e qual ação ele sofreu. É bom ressaltar que grande parte dessas
ações são alimentadas de forma automática.
5. Detalhamento dos Principais Módulos 41
5.3.5 Gerenciamento de Atas
O módulo de Atas é utilizado pelo Setor de Atas para controle dos áudios das reuniões e
transcrição desses áudios, a�m de disponibilizá-los no Portal da Câmara.
A digitação da ata é feita dentro o módulo utilizando um componente de edição de texto
e um player do ExtJs, como visto na �gura 5.20.
No módulo também é feita a publicação da ata no Portal da Câmara, após aprovação em
Reunião.
Figura 5.20: Exemplo de digitação de ata utilizando player
5. Detalhamento dos Principais Módulos 42
5.3.6 Norma Jurídica
O módulo de Norma Jurídica é onde são armazenadas todas as leis do município. Nele é
possível pesquisar leis e fazer downloads de documentos digitalizados. Vale destacar que são
mais de dez mil leis registradas, e praticamente todas as leis estão com seus dados corretos e
possuem uma cópia digital.
No módulo também é feita a digitação das leis para que a pesquisa se torne mais e�ciente.
Para a digitação das leis foi utilizado um plugin do ExtJs. É possível também a impressão de
relatórios sintéticos e analíticos.
5. Detalhamento dos Principais Módulos 43
5.3.7 Matérias Legislativas
Omodulo de Matéria Legislativa funciona de forma parecida com o módulo de Norma Jurídica,
porém ele é responsável pelo gerenciamento de projetos de lei, que quando aprovados se tornam
uma Norma Jurídica. Para se ter uma ideia da utilização do módulo, só no período de
01/01/2010 à 01/12/2010 foram lançadas no sistema mais de mil matérias.
No módulo podem ser feitos cadastros de matérias que não entraram no sistema via módu-
los de Envio e Recebimento de Propostas, como por exemplo as propostas criadas pelo Poder
executivo, que não tem acesso ao sistema (ver �gura 5.22).
É possível também a impressão de novas etiquetas para substituição de etiquetas contendo
o código de barras de identi�cação que tenham perdido sua coloração (ver �gura 5.21).
Existe também um gerenciador de documentos digitalizados e digitados, a �m de manter
o controle de todo o material. É inclusive possível gerar relatórios analíticos e sintéticos, que
sempre são exigidos no �m do ano e anteriormente eram feitos a mão.
Figura 5.21: Exemplo de tela do Módulo de Matérias Legislativas
Capítulo 6
Impactos e Resultados
Os resultados começaram a aparecer logo no início do projeto, tendo um destaque no jornal
O Tempo, onde um dos módulos do Sigla, o módulo de Verba Indenizatória, foi citado como
fonte de pesquisa e �scalização dos gastos dos vereadores, sendo ainda o único sistema até
então que fazia controle de notas �scais.
Figura 6.1: Reprodução da matéria publicada pelo jornal O Tempo
É necessário um estudo sobre o impacto da implantação do sistema no ambiente da CMOP,
mas a princípio pode-se destacar que apesar das rejeições iniciais motivadas pela mudança para
um novo sistema, essa ação teve vários pontos positivos como a padronização e agilidade na
45
6. Impactos e Resultados 46
confecção de documentos do legislativo, trazendo assim uma maior produtividade. Ainda é
importante ressaltar que o sistema contribuiu também para ampliar a transparência política,
fator muito relevante visto o contexto da aplicação.
O sucesso inicial do sistema é notado, visto que várias outras instituições tem procurado a
CMOP a �m de buscar parcerias para que o Sigla também possa ser utilizado em suas Casas
Legislativas.
Capítulo 7
Conclusões
Neste trabalho foi desenvolvido um sistema para o gerenciamento da Câmara Municipal de
Ouro Preto (CMOP).
Para justi�car o desenvolvimento de tal sistema, foi feita uma análise e levantados os pro-
blemas relacionados a gestão de informações da CMOP. Percebeu-se uma grande de�ciência na
infra-estrutura, além da falta de um sistema que pudesse gerenciar o ambiente administrativo
da Casa, bem como o Legislativo. A partir desse levantamento inicial algumas ações foram
tomadas para reorganizar o Setor de Informática, para que se conseguisse uma condição ideal
de trabalho.
Neste sentido, houve então uma reformulação da equipe baseada na necessidade técnica
para o projeto, além de uma nova organização funcional do Setor onde criou-se o Departamento
de Tecnologia da Informação da Câmara Municipal de Ouro Preto, agrupando os setores de
Desenvolvimento de Sistemas e o de Suporte e Manutenção da Casa. O agrupamento resultou
em uma infra-estrutura tecnológica estável e con�ável, além de permitir condições favoráveis
ao Setor de Desenvolvimento no desempenho de suas atividades.
A partir dessa reformulação, as responsabilidades de cada membro �caram mais de�nidas,
e assim o projeto teve um rendimento maior, podendo ser concluído nos prazos estabelecidos.
O sistema foi lançado o�cialmente em uma sessão solene no Plenário da Câmara Municipal
em dezembro de 2010.
É importante destacar também que este sistema deve ser aprimorado a sua continuidade
ao longo do tempo, além de distribuido sob licença livre para outras Casas Legislativas. Desta
maneira, é importante que se mantenha a regularidade e padronização do desenvolvimento
deste software, para que este se mantenha adaptável a qualquer realidade na prática.
47
Referências Bibliográ�cas
da Rosa, E. (2010). Extjs: Um excelente framework de javascript.
de Software, I. D. (2010). Ifractal desenvolvimento de software.
de Tecnologia, G. I. (2010). Projeto sapl - grupo interlegis de tecnologia.
ERP (2010). Erp.
Flanagan, D. (2004). Javascript - O Guia De�nitivo. Bookman Companhia ED.
Gilmore, W. (2007). Dominando PHP e MySQL do iniciante ao pro�ssional. Alta Books.
Goodman, D. (2001). JavaScript: a bíblia. Campus.
Groupr, P. (2010). Php: Hypertext preprocessor.
Herrington, J. (2010). Php Hacks. Bookman Companhia ED.
Informatica, M. (2010). Memory informatica.
Marcelo, A. (2005). Apache - Con�gurando o servidor web para linux. Brasport.
Niederauer, J. (2007). Guia de Consulta Rapida PHP 5. Novatec.
48
Top Related