SIGLA - SISTEMA INTEGRADO DE GESTÃO LEGISLATIVA E … · 2012-12-04 · and ExtJs jaascriptv...

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.


Ouro Preto

Junho de 2011

UNIVERSIDADE FEDERAL DE OURO PRETO

FOLHA DE APROVAÇÃO

SIGLA - Sistema Integrado de Gestão Legislativa e Administrativa


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

Dedico este trabalho a toda a equipe do Setor de Informática da Câmara Municipal de Ouro

Preto.

iii

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


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


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


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.


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á


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


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


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 19

Figura 5.1: Tela principal do Sigla


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:


<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


Figura 5.3: Exemplo de dados pendentes

Figura 5.4: Exemplo de gerenciamento de atos


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


Figura 5.6: exemplo de con�rmação de senha


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


Figura 5.10: Exemplo de adição de contrato


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


Figura 5.12: Exemplo de cadastro de local


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


Figura 5.14: Exemplo de um ofício gerado pelo sistema


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


Figura 5.16: Exemplo de tela do Módulo de Envio de Proposta


Figura 5.17: Exemplo de cadastro de uma proposta


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


Figura 5.22: Exemplo de edição de uma Matéria Legislativa

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

SIGLA - SISTEMA INTEGRADO DE GESTÃO LEGISLATIVA E … · 2012-12-04 · and ExtJs jaascriptv...

Documents

Transcript of SIGLA - SISTEMA INTEGRADO DE GESTÃO LEGISLATIVA E … · 2012-12-04 · and ExtJs jaascriptv...