1 Introdução – INACABADA

Este relatório possui a finalidade de apresentar a aplicação prática dos

conhecimentos adquiridos ao longo do curso Técnico em Informática pelo Instituto
Federal de Educação, Ciências e Tecnologia da Bahia, Campus Camaçari. Sendo
que todo o processo de estágio se deu na Prefeitura de Camaçari – Secretaria de
Educação (SEDUC) / Núcleo de Tecnologia (NTE).
Serão aqui explanados de maneira detalhada as atividades da empresa e do
setor no qual o estágio ocorreu, e a incumbência recebida durante este período.

1.1 Objetivos do estágio

• Aprimorar os conhecimentos adquiridos ao longo do Curso Técnico em

Informática;
• Adquirir experiência em desenvolvimento de softwares para
plataformas web, utilizando a linguagem PHP;
• Compreender como se dá o espaço de trabalho em uma organização
pública e com fins sociais;
• Obter experiência de campo, visando maior possibilidade de conseguir
um lugar no mercado de trabalho;

2 Revisão de literatura

Para o início do processo de estágio foi necessária a aprendizagem de uma

linguagem desconhecida até então. Para obter o conhecimento necessário foram
utilizados materiais de suporte ao longo de todo o período de estágio.
 Para criar proximidade com a linguagem PHP, que é utilizada no setor, foi
utilizado o livro PHP – Programando com Orientação a Objetos, do autor Pablo Dall'
Oglio publicado pela editora NOVATEC. Foi feito o download de um exemplar
eletrônico, porém este livro pode ser encontrado na biblioteca do IFBA – Campus
Camaçari.
Durante o desenvolvimento da aplicação que me foi incumbida, foi utilizada a
documentação da própria linguagem, podendo ser encontrada no site:
https://secure.php.net/manual/pt_BR/index.php.

3 Empresa

Em 28 de Julho de 1925, o até então distrito de Camaçari se tornou um

município, sendo fundada assim a Prefeitura de Camaçari. Este órgão público é
responsável pela gestão do município. Dividido por secretarias que são
responsabilizadas pelo funcionamento da cidade, ou seja, de suma importância para
a população camaçariense. E o local onde foi realizado o estágio, SEDUC, se
encontra inclusa nesse nicho.

a. Missão da empresa

Promover Educação de Qualidade elevando os indicadores educacionais do

Município, implementando políticas que garantam o acesso, permanência e sucesso
das crianças, jovens e adultos, em todos os níveis e modalidades de ensino.

b. Visão da empresa
 A SEDUC visa ser um espaço saudável para o desenvolvimento de ações
benéficas para a educação camaçariense, seguindo os Princípios da Política
Municipal de Educação:
1 – Democratização da Gestão
2 – Melhoria da Qualidade Ensino
3 – Valorização e Qualificação dos Profissionais da Educação
4 – Formação para o Desenvolvimento Profissional Permanente
5 – Educação Inclusiva
6 – Educação de Jovens e Adultos
7 – Ampliação do acesso à Educação Infantil
8 – Tecnologia da Informação e Comunicação

4 Atividades desenvolvidas

Por se tratar de um ambiente no qual o foco é suprir as demandas das

escolas e dos setores administrativos, os desenvolvedores tem que conhecer o
ambiente escolar e as reais necessidades dos servidores da Secretaria de
Educação. Durante o período de estágio foi necessário um período de familiarização
com a linguagem utilizada. Após este momento foi dado início ao projeto do SINPRO
– Sistema de Normas e Procedimentos.

4.1 Núcleo de tecnologia – nte

Dentro da Secretaria de Educação, o NTE é responsável por toda a parte

tecnológica. Desde a gerência, manutenção e testes dos aparelhos eletrônicos das
instituições de ensino e setores administrativos, controle de tráfego na rede, até o
teste e desenvolvimento de softwares que atendam às demandas da SEDUC e seus
servidores.

4.2 Ambientação ao meio ambiente do estágio e linguagem/ferramentas

utilizadas

As aplicações desenvolvidas pelo Núcleo de Tecnologia utilizam a

plataforma WEB, e a linguagem de programação PHP (HyperText Preprocessor, ou
pre-processador de hipertexto) é usada para a criação da parte lógica dos softwares.
Tornando necessário um período de familiarização com a mesma. Processo esse
facilitado devido às aulas de lógica de programação. Pois, ao desenvolver uma
análise lógico-matemática, o aprendizado de qualquer linguagem se resumirá a
conhecer a sintaxe utilizada.
A parte visual dos sistemas foram feitas em HTML – HyperText Markup
Language, ou Linguagem de Marcação de Texto e CSS – Cascate Style Sheets, ou
Folha de Estilo em Cascata. Sendo que o HTML é responsável pela construção das
páginas Web, e o CSS pela organização dos dados exibidos nas mesmas.
A ferramenta utilizada para o desenvolvimento tanto da parte lógica quanto
da visual foi a IDE(Ambiente de Desenvolvimento Integrado) Netbeans. Esta
plataforma Open Source e gratuita é um ambiente completo de desenvolvimento em
várias linguagens, dentre elas o PHP, Java e C. Tendo um conjunto completo de
bibliotecas e suporte ao desenvolvimento de interface gráfica própria através da API
Swing para a linguagem Java. Além de funcionar em qualquer Sistema Operacional
que suporte a JVM – Java Virtual Machine, ou Máquina Virtual Java.
Para o desenvolvimento do Banco de Dados foi utilizado Sistema
Gerenciador de Bando de Dados, ou SGBD, PostgreSql. Sistema Open Source
coordenado pelo PostgreSql Global Development Group, e desenvolvido por
programadores em sua maioria voluntários ao redor do mundo. Para a facilitar o
desenvolvimento e gerenciamento do banco, a interface gráfica PgAdmin3 foi
utilizada. Ferramenta Open Source e gratuita para administração do banco de dados
PostgreSql.
A modelagem do Banco de Dados se deu através do DB Designer,
ferramenta que permite a criação de um modelo visual de como os dados devem se
organizados e quais relacionamentos devem ser estabelecidos.
Para consolidar e testar o conhecimento adquirido foi criada uma “aplicação-
teste”. Um gerenciador de notas, no qual o usuário insere o nome do aluno e as
notas das respectivas unidades. O sistema calculará a média e se o aluno foi
aprovado (caso a média seja superior a 6), guardando os dados no banco e exibindo
para o usuário uma tabela com o nome, média e situação dos respectivos alunos.

4.3 SISTEMA DE NORMAS E PROCEDIMENTOS – SINPRO

O SINPRO foi ideia surgida a partir da dificuldade de suprir os problemas,

dúvidas e necessidades comuns dos servidores, em tempo hábil. Através de
documentos com procedimentos padrões e instruções objetivas para cada área e
tipo de problema, o sistema facilita a sua resolução e faz com que o contato ao
serviço técnico seja feito apenas quando realmente necessário. O projeto foi dividido
em três partes que serão abordadas de maneira individual:
• Levantamento de requisitos
• Modelagem e Desenvolvimento do Banco
• Desenvolvimento do layout e regra de negócio

4.3.1 LEVANTAMENTO DE REQUISITOS

Fazer o levantamento das funcionalidades do software é a parte crucial e

inicial para o desenvolvimento de um sistema coeso. Só após definir de forma
coerente as necessidades do cliente se torna possível dar início ao projeto. Os
requisitos são divididos em Funcionais e Não-Funcionais: Os Funcionais se referem
explicitamente às funcionalidades ou comportamentos do sistema. Os requisitos
Não-Funcionais são relacionados ao desempenho, usabilidade, confiabilidade,
segurança, tecnologias envolvidas, entre outros.

4.3.1.1 REQUISITOS FUNCIONAIS

 Cada requisito terá sua funcionalidade principal descrita e uma explicação
aprofundada acerca dos seus pré-requisitos ou funcionamento.

RF01 – O sistema deverá ser capaz de cadastrar usuários. O cadastro de

novos usuários deve ser realizado a partir da inserção do e-mail, da senha pessoal e
do tipo de utilizador e só pode ser feito por um usuário do tipo Coordenador.
RF02 – O usuário deverá realizar o login para acessar o sistema. Para obter
acesso à plataforma é necessário informar o e-mail e senha cadastrados.
RF03 – O sistema deverá disponibilizar tipos diferentes de utilizador. O
Coordenador é o administrador do sistema, tendo total poder sobre seus
utilizadores. O Gerente é o perfil para os gerentes dos núcleos. O Técnico é o perfil
para servidores que trabalham alimentando o sistema com os procedimentos O
Usuário é o perfil para usuários comuns que apenas acessam a plataforma para a
resolução de seus problemas.
RF04 – O sistema deverá permitir a alteração/deleção dos dados do usuário.
Os usuários do tipo Coordenador terão livre acesso aos dados de todos os usuários,
podendo alterar seu e-mail, senha e tipo de utilizador. Os demais tipos de utilizador
terão o poder apenas para alterar sua própria senha.
RF05 – O sistema deverá listar todos os usuários cadastrados. Apenas
usuários do tipo Coordenador poderão visualizar esta lista
RF06 – O sistema deverá ser capaz de cadastrar núcleos. Para o cadastro
dos núcleos será necessário informar o nome, endereço, contato e o responsável
pelo respectivo núcleo. Apenas usuários do tipo Gerente podem ser responsáveis
por núcleos, cada núcleo pode contar com apenas um responsável e somente
usuários do tipo Coordenador poderão realizar esta ação.
RF07 – O sistema deverá permitir a alteração/deleção dos dados dos
núcleos. Somente os usuários do tipo Coordenador poderão realizar esta ação.
RF08 – O sistema deverá listar todos os núcleos cadastrados. Apenas
usuários do tipo Coordenador poderão visualizar esta lista.
RF09 – O sistema deverá ser capaz de vincular os usuários aos núcleos aos
quais pertencem. Apenas usuários do tipo Coordenador e Gerente poderão realizar
esta tarefa.
RF10 – O sistema deverá listar todos os vínculos entre os usuários e os
núcleos. Apenas usuários do tipo Coordenador e Gerente poderão visualizar esta
lista.
RF11 – O sistema deverá ser capaz de cadastrar novos procedimentos. Para
o cadastro dos procedimentos será necessário informar o nome, descrição, núcleo
pertencente e fazer o upload de um arquivo do tipo pdf contendo as orientações.
Usuários do tipo Coordenador, Gerente e Técnico podem realizar esta ação.
RF12 – O sistema deverá permitir a alteração/deleção dos procedimentos
cadastrados. Usuários do tipo Coordenador, Gerente e Técnico poderão realizar esta
ação.
RF13 – O sistema deverá listar os procedimentos relacionados a cada
núcleo. Os usuários poderão visualizar os procedimentos dos núcleos aos quais
estão vinculados. Usuários do tipo Coordenador, Gerente e Técnico poderão
visualizar esta lista.
RF14 – O sistema deverá ser capaz de exibir arquivos que auxiliarão na
resolução de um determinado problema. Os arquivos contendo os procedimentos
serão visualizados no próprio navegador.
RF15 – O sistema deverá ser capaz de cadastrar os tipos de procedimentos.
Cada procedimento será relacionado a um tipo de problema: uma área (Ex:
Informática) e um foco (Ex: Desenvolvimento de Sistemas). Usuários do tipo
Coordenador, Gerente e Técnico poderão realizar esta ação.
RF16 – O sistema deverá permitir a alteração/deleção dos tipos de
procedimentos. Usuários do tipo Coordenador, Gerente e Técnico poderão realizar
esta ação.
RF17 – O sistema deverá ser capaz de vincular os procedimentos a seus
devidos tipos. Será permitido classificar os procedimentos em seus respectivos
tipos. Usuários do tipo Coordenador, Gerente e Técnico poderão realizar esta ação.
RF18 – O sistema deverá listar os procedimentos e seus devidos tipos (qual
área está relacionado e qual seu foco). Usuários do tipo Coordenador, Gerente e
Técnico poderão realizar esta ação.
RF19 – O sistema deverá ser capaz de cadastrar categorias para os tipos de
problemas. As categorias são caracterizadas por ramos (Ex: Tecnologia da
Informação. Administração, etc). Usuários do tipo Coordenador, Gerente e Técnico
poderão realizar esta ação.
RF20 – O sistema deverá permitir a alteração/deleção das categorias.
Usuários do tipo Coordenador, Gerente e Técnico poderão realizar esta ação.
 RF21 – O sistema deverá listar as categorias cadastradas. Usuários do tipo
Coordenador, Gerente e Técnico poderão visualizar esta lista.
RF22 – O sistema deverá ser capaz de vincular os tipos de problemas a
suas devidas categoria. Será possível classificar os tipos de problemas em
categorias. Usuários do tipo Coordenador, Gerente e Técnico poderão realizar esta
ação.
RF23 – O sistema deverá listar os tipos e suas respectivas categorias.
Usuários do tipo Coordenador, Gerente e Técnico poderão visualizar esta lista.
RF24 – O sistema deverá exibir uma lista contendo o nome do
procedimento, sua descrição, o núcleo relacionado e a categoria da qual faz parte.
Esta lista será exibida apenas aos usuários do tipo Usuário, sendo necessário
apenas estar logado no sistema e vinculado ao seu respectivo núcleo

4.3.1.2 REQUISITOS NÃO-FUNCIONAIS

RNF1 – O sistema será uma plataforma web, necessitando de conexão à

internet para seu funcionamento.
RNF2 – O sistema pode ser utilizado em qualquer navegador, porém é
recomendado o uso do Mozilla Firefox (Navegador no qual o sistema foi
devidamente desenvolvido e testado).
RNF3 – Para obter acesso ao sistema é necessário ser servidor da
Secretaria da Educação e ter uma conta de e-mail da prefeitura de camaçari
devidamente cadastrada.

4.3.2 MODELAGEM E DESENVOLVIMENTO DO BANCO DE DADOS

4.3.3 DESENVOLVIMENTO DO LAYOUT E REGRA DE NEGÓCIO

 O projeto foi concebido segundo o padrão de projetos MVC – Model View
Controller. Este padrão é um modelo que divide uma aplicação em três camadas. A
View, ou camada de apresentação/visualização é a responsável pela exibição do
conteúdo ao usuário final, ou seja, o design do software. O Model é responsável pela
regra de negócio da aplicação, armazenamento, manipulação e geração de dados.
O Controller, ou controlador é a camada intermediária entra a View e o
Model, sendo responsável por controlar o fluxo de dados. Enviando comandos para
o Model realizar suas ações, ou para a View apresentar os resultados das
operações.
Existem quatro tipos de usuários que podem ser cadastrados no sistema,
coordenador, gerente, técnico e usuário. Cada um tem suas particularidades e
diferentes níveis de acesso. Para o gerenciamento dos usuários, o sistema possui
um módulo que permite o cadastro, deleção e edição dos mesmos, vide Figura 1.

Figura 1 – Módulo de gerenciamento de usuários

Fonte: Elaborada pelo próprio autor

 Na figura 2, pode ser observado o módulo que exibe uma lista dos usuários
cadastrados e seus respectivos níveis de acesso.

Figura 2 – Módulo de listagem de usuários

Fonte: Elaborada pelo próprio autor

O sistema foi dividido em módulos principais e secundários (junção de

módulos principais), que eram exibidos de acordo com o nível de acesso do usuário.
O coordenador tem o nível de acesso mais alto, com controle total sobre o sistema,
como pode ser observado na Figura 3. Podendo assim, gerenciar os usuários,
núcleos, problemas e procedimentos (respeitando a integridade dos dados e da
regra de negócio definidas no banco de dados).

Figura 3 – Tela principal ao coordenador.

 Fonte: Elaborada pelo próprio autor.

Abaixo do coordenador, o gerente possui o mais alto controle do sistema,

podendo relacionar os usuários aos núcleos, gerenciar os procedimentos e
problemas, como visto na Figura 4. Ao gerente não é permitido adicionar ou remover
usuários e núcleos.

Figura 4 – Tela principal exibida ao gerente.

Fonte: Elaborada pelo próprio autor.

 O técnico possui o terceiro maior nível de acesso, podendo gerenciar os
procedimentos e problemas. Como observado na Figura 5, não o é permitido
relacionar usuários com os núcleos.

Figura 5 – Tela principal exibida ao gerente

Fonte: Elaborada pelo próprio autor

O usuário comum detém o mais baixo nível de acesso, sendo possível

apenas visualizar a lista de problemas e os arquivos contendo procedimentos para
solucioná-los, como pode ser observado na Figura 6.

Figura 6 – Tela principal exibida ao usuário comum

 Fonte: Elaborada pelo próprio autor

Cada usuário está ligado a apenas um núcleo específico, exceto o

coordenador, que tem vínculo com todos os núcleos. Os núcleos são departamentos
dentro das secretarias, que tem demandas específicas, e por isto, necessita de
atendimento específico. É possível criar, editar e remover os núcleos dentro do
sistema, e seus vínculos com os usuários. Para gerenciar o núcleo, como pode ser
observado na Figura 7, é necessário que haja um responsável pelo mesmo, tendo
este o nível de acesso gerente, ou superior, a descrição do núcleo, endereço e
contato.

Figura 7 – Módulo de gerenciamento de núcleos

 Fonte: Elaborada pelo próprio autor

É possível ter acesso à lista de núcleos cadastrados, vide Figura 8, onde são
exibidas as informações dos respectivos núcleos. É possível realizar operações
diretamente na lista, como deletar o núcleo e pesquisar um objeto em específico.
Além do botão para cadastrar um novo núcleo.

Figura 8 – Lista de núcleos cadastrados

 Fonte: Elaborada pelo próprio autor

Para associar usuários a núcleos específicos, existe um módulo que

gerencia esta relação, utilizando o e-mail do usuário para realizar a operação. A
Figura 9 exibe o módulo de gerenciamento, enquanto a Figura 10 mostra a tela que
exibe a listagem de relações entre os usuários e os núcleos existentes.

Figura 9 – Módulo de gerenciamento da relação entre usuários e núcleos

Fonte: Elaborada pelo próprio autor

Figura 10 – Módulo de listagem das relações existentes entre usuários e

núcleos
 Fonte: Elaborada pelo próprio autor

Se faz necessário criar os problemas, com as áreas as quais estão

relacionados e o foco do problema em si. Analogamente aos módulos anteriores, o
sistema permite criar, editar e remover estes problemas, além de exibir a lista de
problemas cadastrados. Como pode ser observado nas Figuras 11 e 12,
respectivamente.

Figura 11 – Módulo de gerenciamento dos problemas

Fonte: Elaborada pelo próprio autor

Figura 12 – Módulo de listagem dos problemas cadastrados

Fonte: Elaborada pelo próprio autor