Análise e Desenvolvimento Do Sistema de Gerenciamento de Plano Executivo

UNIVERSIDADE FEDERAL DE MATO GROSSO

COORDENAÇÃO DE ENSINO DE GRADUAÇÃO EM

CIÊNCIA DA COMPUTAÇÃO

RELATÓRIO DE ESTÁGIO SUPERVISIONADO:

ANÁLISE E DESENVOLVIMENTO DO SISTEMA DE

GERENCIAMENTO DE PLANO EXECUTIVO

BRUNO SANTOS ABDALLA

CUIABÁ – MT

2013




RELÁTORIO DE ESTÁGIO SUPERVISIONADO:

ANÁLISE E DESENVOLVIMENTO DO SISTEMA DE

GERENCIAMENTO DE PLANO EXECUTIVO


Relatório apresentado ao Instituto de

Computação da Universidade Federal de

Mato Grosso, para obtenção do título de

Bacharel em Ciência da Computação.

CUIABÁ – MT

2013





Relatório de Estágio Supervisionado apresentado à Coordenação do Curso de

Ciência da Computação como uma das exigências para obtenção do título de

Bacharel em Ciência da Computação da Universidade Federal de Mato Grosso

Aprovado por:

Prof. MsC. Roberto Benedito de Oliveira Pereira

Instituto de Computação

Prof. Dr. Mauricio Fernando Lima Pereira


Prof. Dr. João Paulo Ignácio Ferreira Ribas


DEDICATÓRIA

Primeiramente a Deus, pois sem ele

nada disso seria possível, à minha

família e a minha namorada pelo

apoio em toda a minha caminhada.

AGRADECIMENTOS

Agradeço primeiramente a Deus pelo dom da vida e pela oportunidade de

vencer os obstáculos diários.

Agradeço minha família pelo amor, carinho, dedicação e apoio, em todas as

circunstâncias.

Agradeço aos meus amigos pelo companheirismo e apoio de sempre.

Agradeço a minha namorada pela eterna amizade, apoio e carinho.

Agradeço ao meu orientador Roberto Benedito, pela paciência, dedicação, e

apoio.

Em geral, agradeço a todos os meus professores do IC, pelo tempo de

companheirismo, dedicação, e muito aprendizado.

6

SUMÁRIO

LISTA DE FIGURAS .......................................................................................................................... 8

LISTA DE TABELAS .......................................................................................................................... 9

LISTA DE SIGLAS E ABREVIATURAS ....................................................................................... 11

RESUMO ............................................................................................................................................ 12

INTRODUÇÃO .................................................................................................................................. 13

1 REVISÃO DE LITERATURA ...................................................................................................... 15

1.1 ENGENHARIA DE SOFTWARE ...................................................................................................... 15

1.2 LINGUAGEM DE MODELAGEM UNIFICADA .................................................................................. 15

1.3 BANCO DE DADOS RELACIONAL ................................................................................................. 16

1.4 SERVIDOR WEB APACHE E PHP ................................................................................................ 17

1.5 MYSQL ..................................................................................................................................... 17

1.6 MODEL - VIEW – CONTROLER .................................................................................................... 19

1.7 CODEIGNITER ............................................................................................................................. 21

2 MATERIAIS, TÉCNICAS E MÉTODOS .................................................................................... 25

3 RESULTADOS ................................................................................................................................ 27

3 .1 LEVANTAMENTO DE REQUISITOS .............................................................................................. 27

3.1.1 Requisitos Funcionais ........................................................................................................ 27

3.1.2 Requisitos Não Funcionais ................................................................................................ 36

3.2 CASOS DE USO ........................................................................................................................... 38

3.3 DIAGRAMA DE CLASSE ............................................................................................................... 41

3.4 MODELAGEM ENTIDADE RELACIONAMENTO ............................................................................. 46

3.5 DIAGRAMA DE SEQUÊNCIA......................................................................................................... 51

3.6 DIAGRAMA DE ATIVIDADE ......................................................................................................... 52

3.7 IMPLEMENTAÇÃO ....................................................................................................................... 54

4 DIFICULDADES ENCONTRADAS ............................................................................................. 58

5 CONCLUSÕES ............................................................................................................................... 60

6 REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................... 62

APÊNDICES E/OU ANEXOS .......................................................................................................... 63

ANEXO 1 – FORMULÁRIO DE PLANO EXECUTIVO ............................................................................. 63

ANEXO 2 – PARTE DO FORMULÁRIO REFERENTE AO CADASTRO DO PLANO EXECUTIVO .................. 67

ANEXO 3 – PARTE DO FORMULÁRIO REFERENTE AO ACOMPANHAMENTO DO PLANO EXECUTIVO .... 68

ANEXO 4 – PARTE DO FORMULÁRIO REFERENTE AO VINCULO ESTRATÉGICO ................................... 69

7

ANEXO 5 – PARTE DO FORMULÁRIO REFERENTE À INDICAÇÃO DE PRIORIDADE................................ 70

APÊNDICE 1 – CÓDIGO DO CONTROLLER PERMISSÃO.PHP ................................................................ 71

APÊNDICE 2 – CÓDIGO DO MODEL PERMISSAO_MODEL.PHP ........................................................... 72

APÊNDICE 3 – CÓDIGO DA VIEW NOVO_VIEW.PHP ........................................................................... 73

8

LISTA DE FIGURAS

FIGURA 1 - INTERFACE PRINCIPAL DO PHPMYADMIN ........................................................................... 19

FIGURA 2 – ESTRUTURA MVC .............................................................................................................. 20

FIGURA 3 - FLUXO DE DADOS MVC COM CODEIGNITER ....................................................................... 22

FIGURA 4 - ESTRUTURA DO CODEIGNITER ............................................................................................ 23

FIGURA 5 - PASTA APPLICATION DO CODEIGNITER ............................................................................... 23

FIGURA 6 - CASO DE USO DO ADMINISTRADOR DO SISTEMA .................................................................. 38

FIGURA 7 - CASO DE USO DO ASSISTENTE E DO AUXILIAR ..................................................................... 39

FIGURA 8 - CASO DE USO DO TÉCNICO .................................................................................................. 40

FIGURA 9 - CASO DE USO DO COORDENADOR ....................................................................................... 40

FIGURA 10 - CASO DE USO DO SUPERINTENDENTE ................................................................................ 41

FIGURA 11 - VISÃO GERAL DO DIAGRAMA DE CLASSE .......................................................................... 42

FIGURA 12 - DIAGRAMA DE CLASSE ESTRATÉGIA DO PLANO EXECUTIVO ............................................. 43

FIGURA 13 - DIAGRAMA DE CLASSE ACOMPANHAMENTO DO PLANO EXECUTIVO .................................. 44

FIGURA 14 - DIAGRAMA DE CLASSE DO PLANO EXECUTIVO .................................................................. 45

FIGURA 15 - DIAGRAMA DE CLASSE DOS ACESSOS E LOGS .................................................................... 45

FIGURA 16 - DIAGRAMA ENTIDADE RELACIONAMENTO DO SGPE ....................................................... 46

FIGURA 17 - DER ASSOCIADO À ESTRATÉGIA DA SVS .......................................................................... 47

FIGURA 18 - DER ASSOCIADO À ESTRATÉGIA DA SES .......................................................................... 47

FIGURA 19 - DER ASSOCIADO AOS LOGS DO SISTEMA ........................................................................... 48

FIGURA 20 - DER ASSOCIADO AO CONTROLE DE ACESSO ...................................................................... 48

FIGURA 21 - DER ASSOCIADO AOS DADOS GERAIS DO PLANO EXECUTIVO ............................................ 49

FIGURA 22 - DER ASSOCIADO ÀS ETAPAS DO PLANO EXECUTIVO ......................................................... 50

FIGURA 23 - DIAGRAMA DE SEQUÊNCIA DE NOVO PLANO EXECUTIVO .................................................. 51

FIGURA 24 - DIAGRAMA DE ATIVIDADE DE CADASTRO DE UM NOVO PLANO EXECUTIVO ...................... 52

FIGURA 25 - DIAGRAMA DE ATIVIDADE DE ACOMPANHAMENTO DO PLANO EXECUTIVO ....................... 53

FIGURA 26 - TELA DE LOGIN ................................................................................................................. 54

FIGURA 27 - TELA PRINCIPAL PARTE USUÁRIO ...................................................................................... 54

FIGURA 28 - TELA PRINCIPAL DA ESTRATÉGIA DA SVS ......................................................................... 55

FIGURA 29 - TELA PRINCIPAL DA ESTRATÉGIA DA SES ......................................................................... 55

FIGURA 30 - TELA DA PERSPECTIVA DA SVS ........................................................................................ 56

FIGURA 31 - TELA DA NATUREZA DO PLANO EXECUTIVO ...................................................................... 56

FIGURA 32 - TELA DOS LOGS DE ACESSO .............................................................................................. 57

FIGURA 33 - TELA DOS LOGS DE ATIVIDADE ......................................................................................... 57

9

LISTA DE TABELAS

TABELA 1 - REQUISITO FUNCIONAL PARA CADASTRAR PLANO EXECUTIVO .......................................... 27

TABELA 2 - REQUISITOS FUNCIONAL CADASTRO DE ACOMPANHAMENTO DO PLANO EXECUTIVO ......... 27

TABELA 3 - REQUISITO FUNCIONAL PARA RELATÓRIO SIMPLIFICADO DO PLANO EXECUTIVO ............... 28

TABELA 4 - REQUISITO FUNCIONAL DE NÍVEIS DE USUÁRIO DO SGPE .................................................. 28

TABELA 5 - REQUISITOS FUNCIONAL DO RELATÓRIO DETALHADO DE PLANO EXECUTIVO .................... 28

TABELA 6 - REQUISITO FUNCIONAL VINCULO ESTRATÉGICO ................................................................ 29

TABELA 7 - REQUISITO FUNCIONAL DA HOMOLOGAÇÃO DO PLANO EXECUTIVO ................................... 29

TABELA 8 - REQUISITO FUNCIONAL NÚMERO DO PLANO EXECUTIVO .................................................... 29

TABELA 9 - REQUISITOS FUNCIONAL DE GERAR RELATÓRIO EM PDF ..................................................... 29

TABELA 10 - REQUISITO FUNCIONAL CADASTRO PRIORIDADE PLANO EXECUTIVO ................................ 29

TABELA 11 - REQUISITO FUNCIONAL VISUALIZAÇÃO DE ANEXO ........................................................... 30

TABELA 12 - REQUISITO FUNCIONAL DE AUTENTICAÇÃO DE USUÁRIO ................................................. 30

TABELA 13 - REQUISITO FUNCIONAL DA ALTERAÇÃO DO PLANO EXECUTIVO ....................................... 30

TABELA 14 - REQUISITO FUNCIONAL ACOMPANHAMENTO DO PLANO EXECUTIVO ................................ 30

TABELA 15 - REQUISITO FUNCIONAL DA ALTERAÇÃO DO VÍNCULO ESTRATÉGICO ................................ 30

TABELA 16 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA PRIORIDADE DO PLANO EXECUTIVO.............. 31

TABELA 17 - REQUISITO FUNCIONAL DA EXCLUSÃO DE PLANO EXECUTIVO .......................................... 31

TABELA 18 - REQUISITO FUNCIONAL DE CADASTRO DE PARCEIRO ........................................................ 31

TABELA 19 - REQUISITO FUNCIONAL DE EXCLUSÃO DE PARCEIROS ...................................................... 31

TABELA 20 - REQUISITO FUNCIONAL DE CADASTRO DE TIPOS DE RESULTADOS .................................... 31

TABELA 21 - REQUISITO FUNCIONAL DE EXCLUSÃO DE TIPOS DE RESULTADO ...................................... 31

TABELA 22 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE TIPOS DE RESULTADO .................................... 32

TABELA 23 - REQUISITO FUNCIONAL DE CADASTRO DE DESTINAÇÃO DE RESULTADO .......................... 32

TABELA 24 - REQUISITO FUNCIONAL DE EXCLUSÃO DA DESTINAÇÃO DO RESULTADO .......................... 32

TABELA 25 - REQUISITO FUNCIONAL DE ALTERAÇÃO DA DESTINAÇÃO DO RESULTADO........................ 32

TABELA 26 - REQUISITO FUNCIONAL DE CADASTRO DA NATUREZA DA AÇÃO ....................................... 32

TABELA 27 - REQUISITO FUNCIONAL DE EXCLUSÃO DA NATUREZA DA AÇÃO ....................................... 32

TABELA 28 - REQUISITO FUNCIONAL DE ALTERAÇÃO DA NATUREZA DA AÇÃO..................................... 33

TABELA 29 - REQUISITO FUNCIONAL DE FINALIZAÇÃO DO PLANO EXECUTIVO ..................................... 33

TABELA 30 - REQUISITO FUNCIONAL DE CADASTRO DE USUÁRIO ......................................................... 33

TABELA 31 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE DADOS DO USUÁRIO...................................... 33

TABELA 32 - REQUISITO FUNCIONAL DE DESATIVAÇÃO DE USUÁRIO .................................................... 33

TABELA 33 - REQUISITO FUNCIONAL DE GERAR LOGS DE ACESSO ........................................................ 33

TABELA 34 - REQUISITO FUNCIONAL DE GERAR LOGS DE ATIVIDADE .................................................. 34

TABELA 35 - REQUISITO FUNCIONAL DE EXIBIR LOGS ........................................................................... 34

TABELA 36 - REQUISITO FUNCIONAL DE CADASTRO DE SETORES.......................................................... 34

10

TABELA 37 - REQUISITO FUNCIONAL DE ALTERAÇÃO DE SETORES ....................................................... 34

TABELA 38 - REQUISITO FUNCIONAL DE EXCLUSÃO DE SETORES .......................................................... 34

TABELA 39 - REQUISITO FUNCIONAL DE CADASTRO DE GRUPOS RESPONSÁVEIS ................................... 34

TABELA 40 - REQUISITOS FUNCIONAIS DE ALTERAÇÃO DE GRUPOS RESPONSÁVEIS .............................. 34

TABELA 41 - REQUISITO FUNCIONAL DE EXCLUSÃO DE GRUPOS RESPONSÁVEIS ................................... 35

TABELA 42 - REQUISITO FUNCIONAL DO CADASTRO DE ETAPA ............................................................. 35

TABELA 43 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA ETAPA .......................................................... 35

TABELA 44 - REQUISITO FUNCIONAL DA EXCLUSÃO DA ETAPA............................................................. 35

TABELA 45 - REQUISITO FUNCIONAL DO CADASTRO DE SUB ETAPA ...................................................... 35

TABELA 46 - REQUISITO FUNCIONAL DA ALTERAÇÃO DA SUB ETAPA ................................................... 35

TABELA 47 - REQUISITO FUNCIONAL DA EXCLUSÃO DA SUB ETAPA ...................................................... 36

TABELA 48 - REQUISITOS FUNCIONAIS DE CADASTRO DAS ESTRATÉGIAS ADOTADAS ........................... 36

TABELA 49 - REQUISITOS FUNCIONAIS DE EDIÇÃO DAS ESTRATÉGIAS ADOTADAS ................................ 36

TABELA 50 - REQUISITOS FUNCIONAIS DE EXCLUSÃO ESTRATÉGIAS ADOTADAS .................................. 36

TABELA 51 - REQUISITO NÃO FUNCIONAL SERVIDOR WEB .................................................................... 36

TABELA 52 - REQUISITO NÃO FUNCIONAL SISTEMA DE BACKUP ........................................................... 37

TABELA 53 - REQUISITO NÃO FUNCIONAL CONEXÃO COM A INTERNET ................................................. 37

TABELA 54 - REQUISITO NÃO FUNCIONAL INTERFACE AMIGÁVEL ........................................................ 37

11

LISTA DE SIGLAS E ABREVIATURAS

ANSI American National Standards Institute

BSC Balanced Scorecard

CD Compact Disc

CGI Common Gateway Interface

CSS Cascading Style Sheets

DER Diagrama Entidade Relacionamento

HTML HyperText Markup Language

HTTP HyperText Transfer Protocol

IDE Integrated Development Environment

JDBC Java Database Conectivity

MER Modelo Entidade Relacionamento

MVC Model View Controller

ODBC Open Database Connectivity

OMT Object, Modeling Thechnique

OOSE Object-Orinetd Software Engineering

PDF Portable Document Format

PHP Hypertext Preprocessor

SES Secretaria de Estado de Saúde

SGBD Sistema de Gerenciamento de Banco de Dados

SGPE Sistema de Gerenciamento de Plano Executivo

SQL Structured Query Language

SVS Superintendência de Vigilância em Saúde

UML Unified Modeling Language

12

RESUMO

Este Relatório foi produzido como parte das atividades do estágio

supervisionado, realizada na Secretaria de Estado de Saúde de Mato Grosso (SES),

juntamente com a Superintendência de Vigilância em Saúde (SVS), no período de

Janeiro a Março de 2013.

A atividade de estágio, tinha como finalidade a análise e o

desenvolvimento de um sistema capaz de gerenciar os planos executivos criados pela

SVS. Atualmente eles são feitos manualmente, utilizando formulários impressos.

Na parte de análise para a documentação do aplicativo SGPE, foram

empregados o levantamento de requisitos, a modelagem por meio do diagrama de

classe, diagrama de sequência, diagrama de atividades e caso de uso. Já, para o banco

de dados aplicou-se o mapeamento entidade relacionamento.

No desenvolvimento, foi utilizado a IDE NetBeans, com a linguagem de

programação PHP, o SGBD MySQL, juntamente com a ferramenta PhpMyAdmin,

que serve para gerenciar através de uma interface gráfica, as tabelas do banco de

dados, o framework CodeIgniter e padrão de desenvolvimento model-view-controller

(MVC), cujo o mesmo, tem a finalidade de tornar o desenvolvimento mais rápido e

uniformizado.

Como resultado a SVS obteve toda a documentação do aplicativo e um

sistema parcial do gerenciamento de plano executivo, com intuito de trazer melhorias

no que tange ao acompanhamento das ações planejadas.

13

Introdução

A Superintendência de Vigilância em Saúde da Secretaria de Estado de

Saúde de Mato Grosso, conduz atualmente, os planos executivos, por meio de

formulários manuais. O plano executivo é o planejamento das futuras ações da SVS,

o qual será avaliado pelos coordenadores e pelo superintendente, selecionando os

projetos de acordo com os objetivos e conforme o orçamento do mesmo, além de se

estabelecer uma prioridade de execução.

Dando o fato de ser feito através de formulários tem se o acúmulo de

documentos referentes aos relatórios de cada etapa de execução, onerando o controle

dos planos em vigência e dificultando o processo de auditoria.

Assim a Superintendência de Vigilância em Saúde tinha um trabalho

moroso no que tange ao monitoramento do andamento dos planos executivos e suas

respectivas auditorias sobre as responsabilidades dos técnicos, teve-se a necessidade

de um sistema de informação a fim de se estabelecer uma nova metodologia no que

se refere ao gerenciamento atual.

Mesmo depois de um plano ser aprovado, existe a necessidade de

acompanhar as atividades desenvolvidas em cada etapa do planejamento, pois dessa

maneira permite averiguar se a prática está de acordo com as disposições

estabelecidas no plano executivo e se cada técnico está exercendo as suas obrigações.

Com base nessas premissas e em razão da SVS possuir uma gestão

geograficamente descentralizada, a elaboração de um sistema WEB, utilizando o

padrão de desenvolvimento MVC (Model View Controlle), permitirá a integração de

toda a Superintendência de Vigilância em Saúde, além de dispor de uma ferramenta

que auxiliará na padronização do preenchimento do Plano Executivo.

Dessa maneira a utilização do padrão MVC, na elaboração do sistema de

gerenciamento de plano executivo (SGPE), permite o reaproveitamento de código

tornando a programação mais ágil. Com isso a implantação desse sistema tornará o

gerenciamento mais simples e eficiente, com um melhor custo benefício,

possibilitando um controle eficaz sobre a responsabilidade de cada técnico.

14

Assim, o trabalho de estágio tem como objetivo projetar, documentar e

desenvolver o sistema de informação SGPE, para gerenciar os planos executivos da

Superintendência de Vigilância em Saúde da Secretaria de Estado de Saúde de Mato

Grosso, a fim de estabelecer melhores práticas na administração dos planos

executivos e suas respectivas auditorias.

Os objetivos específicos são:

Analisar os formulários do plano executivo, para um melhor entendimento do

funcionamento.

Levantar os requisitos funcionais e não funcionais do sistema.

Elaborar os diagramas de classe, caso de uso, entidade relacionamento, sequência

e atividade.

Gerar a estrutura do banco de dados.

Implementar o sistema em um ambiente web utilizando o padrão MVC.

Assim este relatório de estágio está organizado em 05 (cinco) capítulos.

O primeiro capítulo contém a revisão de literatura, abordando as teorias sobre o

servidor WEB Apache e PHP, MySQL, CodeIgniter e o MVC. No capítulo seguinte

foram expostos os materiais, as técnicas e os métodos utilizados durante a execução

do plano de estágio. O capítulo três apresenta os resultados obtidos no período da

realização do projeto. No quarto capítulo foram abordadas as dificuldades

encontradas na execução da proposta. No capítulo final foi demonstrada a conclusão

sobre o trabalho realizado.

15

1 REVISÃO DE LITERATURA

Neste capítulo será abordada a fundamentação teórica sobre os principais

conceitos e tecnologias utilizadas durante o período de realização do estágio

supervisionado.

1.1 Engenharia de Software

A cada dia que passa, os sistemas têm se tornados cada vez mais

complexos, e com isso o seu desenvolvimento se tornou mais trabalhoso, nesse

sentido a engenharia de software surgiu para auxiliar no desenvolvimento até a

manutenção do software.

A engenharia de software é a área da computação relacionada com a

produção de um software, “desde os estágios iniciais de especificação do sistema até

a sua manutenção, depois que este entra em operação” (Sammerville, pg 5, 2007).

O engenheiro de software deve aplicar métodos apropriados para cada

etapa da produção de um software, esses métodos devem estar de acordo com as

restrições organizacionais e financeiras.

1.2 Linguagem de modelagem unificada

A linguagem de modelagem unificada, ou Unified Modeling Language

(UML), é uma linguagem visual utilizada para a modelagem de software, durante a

análise, ele é utilizado para definir as características e documentar o sistema.

A primeira versão surgiu em 1995, com a união de três métodos de

modelagem, o método Booch, OMT (Object, Modeling Thechnique) de Jacobson, o

OOSE (Object-Orinetd Software Engineering) de RumBaugh. A versão atual foi

lançada em 2005 e se encora na 2.0.

Alguns dos diagramas utilizados pela UML é o diagrama de caso de uso,

classe, sequência e atividades.

16

O diagrama de caso de uso é um diagrama utilizado na fase de

levantamento e análise de requisitos e serve de base para o desenvolvimento dos

demais diagramas. Ele “é o diagrama mais geral e informal da UML” (Guedes, pg

30, 2011), pois apresenta uma linguagem simples de fácil compreensão pelo cliente.

Esse diagrama procura apontar os atores e as funcionalidades do sistema.

O diagrama de classe irá definir a estrutura das classes do sistema,

determinando os seus atributos e métodos, além de indicar como serão os

relacionamentos entre eles. O diagrama de sequencia serve para demonstrar a ordem

temporal de troca de mensagem entre os objetos. Já o diagrama de atividade descreve

as sequencias a serem desenvolvidas do inicio até o fim de uma atividade especifica.

1.3 Banco de dados Relacional

Atualmente, a maioria dos sistemas que conhecemos utiliza algum tipo

de banco de dados, podemos entender que o banco de dados é um conjunto de dados

que relacionam entre si. No caso do banco de dados relacional os dados são

armazenados em tabelas, o qual é dividido em linhas e colunas, as colunas são os

atributos e as linhas são os dados armazenados.

No banco de dados relacional as tabelas se relacionam e ela ocorre

através de atributos comuns entre as duas tabelas, que são chamados de atributos

chave.

Existem sistemas responsáveis pelo armazenamento, recuperação,

exclusão, segurança e integridade dos dados em um banco de dados, sendo

caracterizados como sistemas de gerenciamento de banco de dados (SGBD).

Para fazer operações no banco de dados são utilizados, na maioria das

vezes, a linguagem SQL, ou Structured Query Language, existem diversos tipos de

padrões SQL e um deles é o ANSI SQL, permitindo a padronização da linguagem de

operações e torna as migrações de SGBDs mais simples.

17

1.4 Servidor WEB Apache e PHP

O Apache é um servidor WEB open source, que pode ser executado nos

sistemas operacionais baseados em Linux, Unix e no Windows, sendo capaz de

suportar vários tipos de linguagens de scripts, como o PHP.

Outras características desse servidor são:

Utiliza o mais recente protocolo HTTP;

Tem suporte para CGI (Common Gateway Interface), responsável por oferecer

recursos como: personalização das variáveis de ambiente e suporte à depuração;

Permite a utilização de Hosts virtuais;

Possui um servidor Proxy integrado;

Possibilita a customização dos logs e status do servidor.

A configuração do servidor Apache é feita através de um arquivo texto

chamado “http.conf” e não possui uma interface gráfica para os administradores.

Já o PHP, é uma linguagem de programação de uso geral do tipo

interpretada, ou seja, ele executa o código conforme lê. “É um software de código

fonte aberto” (Niederauer, pg 24, 2011) e gratuito, muito utilizado em aplicações

web por causa de suas facilidades, em especial pela possibilidade de incorporar com

o código HTML e de gerar HTML como saída.

Em uma aplicação WEB, o navegador do cliente faz as requisições ao

servidor WEB Apache. Esse por sua vez, se houver necessidade de trabalhar com as

informações recebidas, solicita ao PHP para fazê-lo, quando o PHP terminar, gera os

códigos HTML e envia-os para o Apache, o qual retorna para o browser do cliente.

1.5 MySQL

O MySQL é um sistema de gerenciamento de banco de dados (SGBD)

responsável por controlar o acesso ao banco de dados, permitindo que vários usuários

possam trabalhar com os dados simultaneamente, e que o acesso seja feito por apenas

por pessoas autorizadas, além de designar quais os bancos de dados cada usuário

18

poderá acessar, portanto, “o MySQL é um servidor multiusuário” (Welling &

Thomson, pg 27, 2003). Ele é muito utilizado para as aplicações web devido às

características abaixo:

A alta velocidade, “desde os primeiros lançamentos, os desenvolvedores do

MySQL tem com foco no desempenho, mesmo à custa de um conjunto de

recursos reduzida” (Gilmore, pg 478, 2010);

É distribuído sob a licença open source, “GPL license” (Valade, pg 12, 2007), e

existe também uma distribuição com a licença comercial;

Roda em vários sistemas operacionais como o Windows, Linux, Mac OS, Unix e

outros.

Esse SGBD suporta o Open Database Connectivity (ODBC) e o Java

Database Conectivity (JDBC), ambos são um padrão de conjunto de interfaces que

permitem diversas aplicações trabalharem com um mesmo banco de dados,

utilizando os métodos e acessos especializados desse padrão, porém, o JDBC é usado

somente pelos applets Java.

É possível encontrar duas versões do MySQL, a binária a qual cria uma

instalação padrão do banco de dados, e o código fonte, geralmente utilizado para

compilar o MySQL para as plataformas em que não se encontra uma versão binária

disponível, além de “personalizar a instalação do servidor MySQL” (Suehring, pg

35, 2002), possibilitando assim o atendimento das mais diversas realidades.

O MySQL utiliza o ANSI SQL como linguagem de banco de dados,

porém existem aplicativos com interface gráfica para gerenciar o MySQL. O

PHPMyAdmin, mostrado na Figura 01, é um exemplo desse tipo de aplicativo. Ele é

desenvolvido em PHP, permitindo gerenciar o banco de dados, a tabela e os

conteúdos, sem precisar escrever na linguagem SQL, facilitando a administração do

banco de dados.

19

1.6 Model - View – Controler

O padrão de desenvolvimento de software MVC (Model – View –

Controller), propõe a separação da camada lógica de negócio da camada de

apresentação, utilizando três tipos de classes, o qual tem como objetivo organizar a

aplicação em três camadas (modelo, visão e controle) aumentando a flexibilidade e o

reuso de códigos.

Cada camada é bem definida e independente, onde as regras de negócios

e a lógica do controlador são separadas da apresentação, isso facilita a manutenção e

permite a inclusão de novos elementos de visão, sem a necessidade de modificar as

demais classes.

O Model ou modelo é o objeto de aplicação. Esta camada contêm as

regras de negócio que diz como os dados serão trabalhados, um exemplo do modelo

se encontra no apêndice 2, nele é possível observar a lógica de negócio

implementado na classe “Permissao”.

A View ou visão é o objeto de apresentação, esta camada tem a finalidade

de apresentar as informações para os usuários, contudo não tem o conhecimento da

Figura 1 - Interface principal do phpMyAdmin

20

existência do model. No apêndice 3, é demonstrado a visão do formulário de cadastro

de nível de acesso, pode-se notar a existência de marcadores HTML, são eles que

geram o formulário visto pelo usuário.

O Controller ou controlador define como a interface gráfica reage a uma

entrada do usuário, realizando a união do Model com a View. Ele é quem recebe os

pedidos e define qual a visão mostrar e operação a ser realizada. O exemplo do

controlador se encontra no apêndice 1, nele observamos que é feito requisições ao

modelo e envia os dados para a visão.

Dessa forma pode-se entender que:

“Cada peça da arquitetura MVC é bem definida e independente, o

qual é referido como a separação de preocupações. A lógica que

manipula os dados no model, está contido apenas no model, a lógica

que exibe dados é apenas a view, e o código que lida com

solicitações de usuários e de entrada está contida apenas no

controller. Com uma divisão clara entre cada uma das peças, sua

aplicação vai ser mais fácil de manter e estender ao longo de sua

vida, não importa o quão grande ele se tornará.” (Freeman &

Sanderson, pg 64, 2011)

A Figura 2 ilustra o funcionamento do MVC, na qual toda a solicitação

do usuário chega primeiramente ao controller, o qual faz a requisição dos dados para

o model, esse por fim, trabalha os dados e envia a resposta de volta para o controller,

que por sua vez escolhe a view e envia os dados para ela, finalmente a view mostra os

dados para o usuário.

Figura 2 – Estrutura MVC

Fonte: adaptada pelo autor (Freeman & Sanderson, 2011)

21

A utilização do padrão MVC permitirá o reaproveitamento de código,

como por exemplo, vários controllers usando uma mesma classe do tipo view, dessa

forma, tornando o desenvolvimento mais ágil.

1.7 CodeIgniter

Lançado em 2006 pela EllisLab, o framework CodeIgniter encontra-se na

versão 2.1.3. Foi implementado para acelerar a programação de aplicações WEB,

para isso dispõem de conjuntos de “ferramentas” como funções, bibliotecas e

interfaces, os quais facilitam a execução das tarefas mais rotineiras, como conexão

ao banco, manipulação de sessões, entre outras, minimizando a escrita de código e

possibilitando que o programador foque no projeto em si.

Desenvolvido na linguagem PHP, possibilita o funcionamento em

qualquer servidor web, desde que tenha o PHP 4 ou superior instalado. Utiliza o

paradigma Orientado Objeto, permitindo assim a utilização do padrão MVC.

É um framework sob a licença de código aberto, que se tem a autorização

de usar, copiar, modificar e distribuir o software e seus documentos, com ou sem

alterações, para qualquer fim, desde que se cumpra as seguintes condições

(CodeIgniter - Guia do Usuário, 2013):

Deve ter uma cópia da licença incluía na distribuição;

É essencial manter o aviso de copyright em todos códigos fontes distribuídas;

Redistribuições em formato binário devem conter o aviso de copyright na

documentação e/ou outros materiais fornecidos com a distribuição.

Todos os arquivos que alterados devem conter avisos sobre a natureza da

mudança e os nomes de quem fez essas alterações.

Os Produtos derivados do framework deve incluir a informação de que são

provenientes do CodeIgniter em sua documentação e/ou em outros materiais

distribuídos com a distribuição.

Os Produtos resultantes do software não podem ser chamado de

"CodeIgniter" e conter o "CodeIgniter" em seu nome, sem a permissão prévia

por escrito da EllisLab, Inc.

22

Portanto, o CodeIgniter é uma alternativa para o programador que quer

desenvolver uma aplicação WEB de forma ágil, sem ter que se preocupar com o

desenvolvimento de funções de usos rotineiros, como as retratadas anteriormente.

Dessa maneira, o desenvolvedor focaliza na lógica da aplicação evitando a fadiga de

escrever funções usuais.

O CodeIgniter adota o modelo padrão MVC, a Figura 3 apresenta o fluxo

de dados MVC no framework. Nota-se que a camada controller é responsável por

receber, processar e retornar os dados para as views.

Quando um navegador faz uma requisição ao CodeIgniter, este por sua

vez, propaga a requisição para o arquivo “index.php”, que é responsável por

processá-las, em seguida o framework verificará se existe alguma rota

correspondente ao pedido. Se existir, ele disparará o requerimento para o controlador

correspondente, que por sua ver irá requisitar um model e por fim carregar a view.

No framework CodeIgniter é possível criar aplicações inteiras sem

utilizar os models, usando a classe Active Record, mas essa abordagem não é

recomendada, pois dessa maneira não estaria utilizado o padrão MVC.

Figura 3 - Fluxo de dados MVC com CodeIgniter

Fonte:(Gabardo, 2012)

23

Na figura 4 é possível visualizar a estrutura do CodeIgniter, o arquivo

“index.php” é responsável por receber as requisições HTTP e direciona-las. Na pasta

“system” se encontra o código responsável pelo funcionamento do framework, e na

pasta “application” é o local aonde será desenvolvida a nova aplicação.

Dentro da “application” (Figura 5) encontramos diversas pastas e

arquivos. As mais importantes para se iniciar o desenvolvimento, são:

A “config”, responsável pelos arquivos de configuração do

framework;

O “controllers”, contendo os códigos referentes aos

controladores;

O “models” é o local em que serão armazenados os modelos, com

as suas lógicas de negócio do sistema;

A “views” acomodará os arquivos referentes às visões da

aplicação.

Figura 4 - Estrutura do CodeIgniter

Figura 5 - Pasta Application do CodeIgniter

24

Durante a criação das classes do model, deve-se herdar a classe

“Ci_model”, é essa classe que é responsável por informar ao framework que a classe

é do tipo model. O controller tem o funcionamento muito parecido, mas a classe

herdada pelo controller é o “Ci_controller”, já nas visões não é necessário herdar

nenhum tipo de classe, até porque ele conterá poucos códigos em PHP, diferente das

outras duas classes, que contem somente códigos em PHP.

25

2 MATERIAIS, TÉCNICAS E MÉTODOS

A elaboração do SGPE foi dividida em duas etapas: a análise e o

desenvolvimento, durante essas etapas foi utilizado um computador com 4 GB de

memória RAM, com uma CPU Intel Core 2 Duo e um HD de 320GB. O sistema

operacional utilizado foi o Microsoft® Windows 7 Profissional de 64bits.

Antes de iniciar as etapas de produção do sistema, foi necessário estudar

o formulário utilizado pela SVS para gerenciar os seus planos executivos. O

formulário (Anexo 1) é dividido em diversos blocos, o bloco 1 faz referência ao

vinculo estratégico, a metodologia estratégica utilizada pela SES é a Balanced

Scorecard (BSC), a qual divide a estratégia por perspectivas, ou por dimensões. A

estratégia da SES é separada da SVS, isso ocorre, pois, as estratégias adotadas pela

SES estão relacionadas a todas as áreas pertencentes a ela, já as adotadas pela SVS

estão relacionadas somente com a área de vigilância em saúde. Para a SVS não sair

do foco da instituição, foi necessário fazer o relacionamento das estratégias adotadas

pelas duas.

O bloco 2 do formulário, está associado com as informações gerais de

todo o plano executivo, que inclui as etapas pertencentes a ele. O bloco 3 faz

referência a cada etapa de um projeto, nessa parte do formulário será especificado

detalhadamente cada uma das etapas, incluindo as sub etapas e seus resultados. O

último item do formulário, o bloco 4, faz ligação com a prioridade do plano

executivo. A prioridade é dividida em duas, a prioridade de impacto, a qual

estabelece a força de mudança na realidade da instituição, e a prioridade de

execução, que define a necessidade de colocar em ação.

Finalizado o estudo do formulário, iniciou-se a produção do software. O

objetivo da primeira etapa é a análise e documentação do sistema. Para isso, foi

utilizado na modelagem de caso de uso, o software Dia, já no levantamento de

requisitos o Microsoft® Office Word, para o diagrama de classe, de sequência e de

atividade, recorreu-se ao Microsoft® Visio, na elaboração do banco de dados, foi

produzida a modelagem entidade relacionamento, usando a aplicação DBWrench.

Para compor todas as modelagens e diagramas citados acima, foi

necessário conhecer os formulários utilizados para o gerenciamento do plano

26

executivo, e realizar entrevistas com superintendente, coordenadores e técnicos da

superintendência de vigilância em saúde.

Na etapa de desenvolvimento, foi empregado a linguagem de

programação PHP, juntamente com o framework CodeIgniter e o padrão de projeto

MVC. O motivo da escolha do CodeIgniter, foi determinada pela possibilidade de

tornar o desenvolvimento da aplicação menos fatigante. Já a opção que induziu a

utilização do MVC foi pela facilidade do reaproveitamento de códigos, e com isso

tornar a programação mais rápida.

Para auxiliar no desenvolvimento foi utilizado a IDE Netbeans 7.2.1 para

a programação em PHP.

Para a parte visual ou o layout das páginas, foi utilizado o HTML,

juntamente com a folha de estilos CSS e as funções em JavaScript.

No componente de folha de estilos e do JavaScript foi empregado uma

estrutura de front-end, chamada Bootstrap, que consiste de pacotes de estilos CSS e

funções JavaScript. Para utilizá-los, basta colocar o estilo no código HTML, isso

para o CSS, no caso do JavaScript, apenas chamar as funções.

Para o banco de dados, utilizou-se o SGBD MySQL, devido à facilidade

de integração com o PHP. Para o gerenciamento do banco de dados durante o

desenvolvimento, foi usado o software PhpMyAdmin, o qual é uma aplicação,

desenvolvida em PHP para fornecer uma interface gráfica, através de um navegador

web, para o MySQL.

Durante o desenvolvimento do sistema fez-se necessário verificar se o

software está retornando erro, se o sistema está trabalhando conforme o planejado, e

se a parte visual está legível e as funções em JavaScript estão funcionados

corretamente. Para isso foi feita a instalação do servidor Web Apache, no caso

específico a versão 2.2.22, com o interpretador PHP 5.4.3. Por conveniência foi

utilizado o WampServer, pois essa aplicação já dispunha de todos os aplicativos

citados anteriormente, mais o MySQL e o PhpMyAdmin, dessa maneira não seria

preciso instalar cada um deles separadamente.

Apesar de ter os servidores instalados, foi necessário utilizar um browser

para poder acessar o sistema. Durante o desenvolvimento foi utilizado três

navegadores, Firefox 19.0.2, Internet Explorer 9 e o Google Chrome versão 25.0.

27

3 RESULTADOS

Durante as reuniões com o superintendente foi apresentado os

formulários (Anexo 1), utilizados para a elaboração e acompanhamento dos planos

executivos na SVS. A partir desses documentos e das entrevistas realizadas, deu-se

início a análise do sistema.

3 .1 Levantamento de Requisitos

Na análise, foi necessário levantar requisitos funcionais e não funcionais,

para elencar os serviços que estarão presentes no SGPE, além de documentar

também os requisitos do sistema.

3.1.1 Requisitos Funcionais

Depois de um profundo estudo do formulário utilizado atualmente para o

gerenciamento de plano executivo, das diversas entrevistas feitas com os técnicos,

coordenadores e o superintendente, chegou-se aos seguintes requisitos funcionais:

Tabela 1 - Requisito funcional para cadastrar plano executivo

[RF_001] Deve cadastrar o plano executivo:

O cadastro do plano executivo deve ser feita de acordo com o bloco de

Informações Gerais Sobre a Ação, o bloco de Informações Específicas

sobre a ação e o bloco de Informação Orçamentária – Anexo 2 do

formulário do Plano Executivo.

Tabela 2 - Requisitos funcional cadastro de acompanhamento do plano executivo

[RF_002] Cadastrar o acompanhamento de execução do plano executivo:

O cadastro de acompanhamento da execução do plano executivo deve

ser feita de acordo com o Bloco de Resultado da Etapa – Anexo 3 do

28

formulário do Plano Executivo. O sistema deve também cadastrar os

detalhes de cada etapa, permitindo o anexo de documento para cada

etapa.

Tabela 3 - Requisito funcional para relatório simplificado do plano executivo

[RF_003] Apresentar um relatório simplificado:

O sistema deve representar um relatório simplificado dando destaques

para os planos de acordo com a data final de cada um. Por exemplo, se o

plano ultrapassar a data de fim de execução, ele deve aparecer em

vermelho, se estiver a 1 mês do fim do prazo deve aparecer como amarelo,

se estiver muito longe do prazo final, deve aparecer em verde e se a data

de prazo final não estiver definida deve aparecer em cinza.

Tabela 4 - Requisito funcional de níveis de usuário do SGPE

[RF_004] O sistema deve conter vários níveis de usuário:

O sistema deve conter 6 tipos de usuário:

Administrador – poderá ter controle total sobre o sistema, além

de gerenciar os usuários do sistema, visualizar logs e visualizar os

planos executivos “apagados”.

Superintendente – poderá ter controle total sobre o sistema.

Assistente – poderá somente visualizar todos os planos executivos

Coordenador – poderá ter o controle total de todos os planos

executivos que fazem parte daquela coordenadoria.

Auxiliar – poderá visualizar todos os planos executivos que fazem

parte da coordenadoria o qual o auxiliar pertence.

Técnicos – poderá ter controle total dos planos executivos a qual

tem responsabilidade.

Tabela 5 - Requisitos funcional do relatório detalhado de plano executivo

[RF_005] Deve permitir a visualização de um relatório detalhado:

O sistema deve permitir a visualização dos detalhes do plano executivo

selecionado.

29

Tabela 6 - Requisito funcional vinculo estratégico

[RF_006] O cadastro do vínculo estratégico de cada plano executivo:

O cadastro de vinculo estratégico deve ser feita de baseado no Bloco

Vinculo ao mapa estratégico – Anexo 4, adicionando o vínculo estratégico

indicador no formulário. O cadastro deve ser permitido apenas para os

superintendentes e coordenadores.

Tabela 7 - Requisito funcional da homologação do plano executivo

[RF_007] O sistema deve dar a opção de homologar:

O sistema deve permitir que o superintendente da SVS homologue o plano

executivo cadastrado, não permitindo assim que os outros tipos de

usuários modifique os dados gerais do plano executivo homologado.

Tabela 8 - Requisito funcional número do plano executivo

[RF_008] O sistema deve gerar o número do plano executivo:

O número deve ser gerado, após a homologação do mesmo, de acordo

com o ano de cadastro, o número da perspectiva, o número do objetivo, o

número da iniciativa, o número do problema/causa e um número crescente

de acordo com o número do plano criado naquele ano.

Tabela 9 - Requisitos funcional de gerar relatório em pdf

[RF_009] Gerar relatório detalhado no formato pdf do plano executivo:

O sistema tem que permitir a geração de relatório detalhado ou

simplificado e dos logs do sistema no formato pdf do plano executivo,

para que o usuário possa salvar ou imprimir.

Tabela 10 - Requisito funcional cadastro prioridade plano executivo

[RF_010] Deve cadastrar a indicação de prioridade do plano:

O sistema deve permitir o cadastro da indicação de prioridade do plano

executivo de acordo com o bloco de Indicação da Prioridade da Ação –

anexo 5. O cadastro da indicação de prioridade deve ser feita apenas pelo

superintendente e pelos coordenadores.

30

Tabela 11 - Requisito funcional visualização de anexo

[RF_011] Deve permitir a visualização dos anexos de cada etapa:

O sistema deve permitir, durante a visualização do relatório detalhado, a

opção dever os anexos de cada etapa.

Tabela 12 - Requisito funcional de autenticação de usuário

[RF_012] Deve autenticar os usuários antes de acessar o sistema:

O sistema deve autenticar o usuário através do login e da senha, antes de

permitir o acesso somente nas áreas do sistema permitido para aquele tipo

de usuário.

Tabela 13 - Requisito funcional da alteração do plano executivo

[RF_013] O sistema deve permitir a alteração do plano executivo:

O sistema deve permitir a alteração, antes da homologação, do bloco de

informações gerais, de Informações Especificas Sobre a Ação e o bloco de

Informações Orçamentária do plano executivo, anexo 2.

Tabela 14 - Requisito funcional acompanhamento do plano executivo

[RF_014] O sistema deve permitir a alteração do acompanhamento do plano

executivo:

O sistema deve permitir a alteração dos dados de execução do plano

executivo de acordo com o bloco de resultado da etapa do formulário do

Plano Executivo.

Tabela 15 - Requisito funcional da alteração do vínculo estratégico

[RF_015] O sistema deve permitir a alteração do vínculo estratégico:

O sistema deve permitir a alteração do vínculo estratégico de acordo com

o bloco Vínculo ao Mapa Estratégico do formulário do Plano Executivo,

anexo 4. As alterações só podem ser feitas pelos usuários do nível

superintendente e coordenador.

31

Tabela 16 - Requisito funcional da alteração da prioridade do plano executivo

[RF_016] O sistema deve permitir a alteração da indicação de prioridade do plano

executivo:

O sistema deve permitir a alteração da indicação de prioridade do plano

executivo de acordo com a Indicação da Prioridade da Ação do formulário

do Plano Executivo, anexo A. As alterações só podem ser feitas pelos

usuários do nível superintendente e coordenador.

Tabela 17 - Requisito funcional da exclusão de plano executivo

[RF_017] O sistema não irá permitir a exclusão de plano executivo:

O sistema não irá excluir os planos executivos, será permitida apenas a

omissão do mesmo. Os tipos de usuários que poderão usufruir dessa opção

serão os do tipo coordenador e superintendente.

Tabela 18 - Requisito funcional de cadastro de parceiro

[RF_018] O sistema permitirá o cadastro dos parceiros:

O sistema permitirá o cadastro dos nomes dos parceiros separadamente do

cadastro do plano executivo

Tabela 19 - Requisito funcional de exclusão de parceiros

[RF_019] O sistema permitirá a exclusão de parceiros:

O sistema permitirá a exclusão de parceiros desde que não esteja

cadastrado em nenhum plano executivo.

Tabela 20 - Requisito funcional de cadastro de tipos de resultados

[RF_020] O sistema permitirá o cadastro de tipos de resultado:

O sistema permitirá o cadastro dos tipos de resultado separadamente do


Tabela 21 - Requisito funcional de exclusão de tipos de resultado

[RF_021] O sistema permitirá a exclusão dos tipos de resultado:

O sistema permitirá a exclusão os tipos de resultado desde que não esteja


32

Tabela 22 - Requisito funcional de alteração de tipos de resultado

[RF_022] O sistema permitirá a alteração dos tipos de resultado:

O sistema permitirá a alteração dos tipos de resultado separadamente do


Tabela 23 - Requisito funcional de cadastro de destinação de resultado

[RF_023] O sistema permitirá o cadastro da destinação do resultado:

O sistema permitirá o cadastro de destinação do resultado separadamente

do cadastro do plano executivo

Tabela 24 - Requisito funcional de exclusão da destinação do resultado

[RF_024] O sistema permitirá a exclusão da destinação do resultado:

O sistema permitirá a exclusão da destinação do resultado desde que não

esteja cadastrado em nenhum plano executivo.

Tabela 25 - Requisito funcional de alteração da destinação do resultado

[RF_025] O sistema permitirá a alteração da destinação do resultado:

O sistema permitirá a alteração da destinação do resultado separadamente

do cadastro do plano executivo

Tabela 26 - Requisito funcional de cadastro da natureza da ação

[RF_026] O sistema permitirá o cadastro da natureza da ação:

O sistema permitirá o cadastro da natureza da ação separadamente do


Tabela 27 - Requisito funcional de exclusão da natureza da ação

[RF_027] O sistema permitirá a exclusão da natureza da ação:

O sistema permitirá a exclusão da natureza da ação desde que não esteja


33

Tabela 28 - Requisito funcional de alteração da natureza da ação

[RF_028] O sistema permitirá a alteração da natureza da ação:

O sistema permitirá a alteração da natureza da ação separadamente do


Tabela 29 - Requisito funcional de finalização do plano executivo

[RF_029] O sistema permitirá finalizar o plano executivo:

O sistema terá a opção de finalizar o plano executivo. Após a finalização,

não será permitido a alteração de qualquer informação referente ao plano

finalizado e será registrado a data da finalização.

Tabela 30 - Requisito funcional de cadastro de usuário

[RF_030] O sistema permitirá cadastro de usuários:

O sistema permitirá o cadastrar usuários apenas para os usuários de nível

administrador.

Tabela 31 - Requisito Funcional de alteração de dados do usuário

[RF_031] O sistema permitirá alterar dados de usuário:

O sistema permitirá o alterar os dados do usuário apenas para os usuários

de nível administrador.

Tabela 32 - Requisito funcional de desativação de usuário

[RF_032] O sistema permitirá a desativação de usuários:

O sistema permitirá a desativação dos usuários apenas para os usuários de

nível administrador. Os usuários desativados não poderão mais acessar o

SGPE.

Tabela 33 - Requisito funcional de gerar logs de acesso

[RF_033] O sistema irá gerar log de acesso:

O sistema irá gerar automaticamente os logs de acesso de todos os

usuários que acessarem o sistema

34

Tabela 34 - Requisito funcional de gerar logs de atividade

[RF_034] O sistema irá gerar logs de atividade:

O sistema irá gerar automaticamente os logs de atividades de todas

atividades realizadas por cada usuário

Tabela 35 - Requisito funcional de exibir logs

[RF_035] O sistema permitirá a exibição dos logs:

O sistema permitirá a exibição de todos os logs gerado pelo mesmo.

Tabela 36 - Requisito funcional de cadastro de setores

[RF_036] O sistema permitirá a o cadastro de setores:

O sistema permitirá o cadastrar de setores apenas para os usuários de nível

administrador.

Tabela 37 - Requisito funcional de alteração de setores

[RF_037] O sistema permitirá a o alteração de setores:

O sistema permitirá a alteração do nome do setor apenas pelo usuário do

tipo administrador

Tabela 38 - Requisito funcional de exclusão de setores

[RF_038] O sistema permitirá a exclusão de setores:

O sistema permitirá a exclusão do setor apenas pelo usuário do tipo

administrador e se não houver nenhum usuário pertencendo ao setor a ser

excluído.

Tabela 39 - Requisito funcional de cadastro de grupos responsáveis

[RF_039] O sistema permitirá a o cadastro dos grupos responsáveis:

O sistema permitirá a cadastro dos grupos somente pelos usuários

coordenador e superintendente

Tabela 40 - Requisitos funcionais de alteração de grupos responsáveis

[RF_040] O sistema permitirá a alteração dos grupos responsáveis:

O sistema permitirá a alteração dos grupos somente pelos usuários

35


Tabela 41 - Requisito funcional de exclusão de grupos responsáveis

[RF_041] O sistema permitirá a exclusão dos grupos responsáveis:

O sistema permitirá a exclusão dos grupos somente pelos usuários


Tabela 42 - Requisito funcional do cadastro de etapa

[RF_042] O sistema permitirá a o cadastro de etapas do plano executivo:

O sistema permitirá o cadastro de etapas do plano executivo pelos

usuários do tipo administrador, coordenador e técnico.

Tabela 43 - Requisito funcional da alteração da etapa

[RF_043] O sistema permitirá à alteração de etapas do plano executivo:

O sistema permitirá a alteração das etapas do plano executivo pelos


Tabela 44 - Requisito funcional da exclusão da etapa

[RF_044] O sistema permitirá à exclusão de etapas do plano executivo:

O sistema permitirá a exclusão das etapas do plano executivo pelos


Tabela 45 - Requisito funcional do cadastro de sub etapa

[RF_045] O sistema permitirá a o cadastro de sub etapas do plano executivo:

O sistema permitirá o cadastro de sub etapas do plano executivo pelos


Tabela 46 - Requisito funcional da alteração da sub etapa

[RF_046] O sistema permitirá à alteração de sub etapas do plano executivo:

O sistema permitirá a alteração das sub etapas do plano executivo pelos


36

Tabela 47 - Requisito funcional da exclusão da sub etapa

[RF_047] O sistema permitirá à exclusão de sub etapas do plano executivo:

O sistema permitirá a exclusão das sub etapas do plano executivo pelos


Tabela 48 - Requisitos funcionais de cadastro das estratégias adotadas

[RF_048] O sistema permitirá o cadastro das estratégias:

O sistema permitirá o cadastro das estratégias adotadas pela SES e pela

SVS separadamente. As estratégias são compostas de perspectiva,

objetivo, indicadores, metas, iniciativas e problema/causa. O tipo de

usuário responsável pelo cadastro é o superintendente.

Tabela 49 - Requisitos funcionais de edição das estratégias adotadas

[RF_049] O sistema permitirá o editar das estratégias:

O sistema permitirá o editar das estratégias adotadas pela SES e pela SVS

separadamente. O tipo de usuário responsável pela edição é o

superintendente

Tabela 50 - Requisitos funcionais de exclusão estratégias adotadas

[RF_050] O sistema permitirá a exclusão das estratégias:

O sistema permitirá as exclusões das estratégias adotadas pela SES e pela

SVS separadamente. O tipo de usuário responsável pela exclusão é o

superintendente

3.1.2 Requisitos Não Funcionais

Nessa seção serão apresentados os requisitos não funcionais do sistema:

Tabela 51 - Requisito não funcional servidor web

[RNF_001] Ter um servidor web:

O sistema precisará de um servidor web com o Apache, PHP e o MySql

instalados.

37

Tabela 52 - Requisito não funcional sistema de backup

[RNF_002] Ter um sistema de backup:

O servidor a qual estará a aplicação, deverá ter um sistema de backup para

o banco de dados do sistema.

Tabela 53 - Requisito não funcional conexão com a internet

[RNF_003] Ter conexão com a Internet:

O sistema precisará de uma conexão com a Internet.

Tabela 54 - Requisito não funcional interface amigável

[RNF_004] Ter uma interface amigável:

O sistema precisará de uma interface amigável, o qual a utilização do

sistema seja intuitiva.

38

3.2 Casos de Uso

O próximo passo foi os diagramas de caso de uso. Devido a uma grande

quantidade de casos de uso, foi separado por atores de acordo com o número de

atores especificado na Tabela 4.

O primeiro caso de uso a ser apresentado é o do administrador do

sistema, ele será responsável por gerenciar os usuários, o qual implica em cadastrar,

alterar e desativar usuários, conforme está demonstrado na tabela 30, 31 e 32. O

administrador também poderá visualizar os logs do sistema, conforme o requisito

funcional representado na tabela 35, e de todos os planos executivos, incluindo os

que foram escondidos pela aplicação. Conforme mostrado nas tabelas 36, 37 e 38,

além disso, ele será responsável por gerenciar os setores dos usuários, a Figura 06

ilustra o caso de uso do administrador do sistema.

Em seguida serão apresentados os casos de uso do assistente e do auxiliar

(Figura 07), o assistente, conforme a tabela 4 dos requisitos funcionais, terá acesso

Figura 6 - Caso de uso do administrador do sistema

39

apenas a visualização dos planos executivos. Já o auxiliar, é uma especialização do

assistente, ele poderá visualizar somente os planos executivos da coordenadoria a

qual pertence.

O caso de uso dos técnicos, é um pouco mais abrangente, pois eles serão

responsáveis pela criação e acompanhamento dos planos executivos, podendo

também gerar alguns relatórios referentes aos mesmos. A Figura 8 representa os

casos de uso.

Os coordenadores tem o caso de uso parecido com os dos técnicos, pois

eles também serão responsáveis por alimentar os planos executivos. A diferença está

apenas em alguns casos a mais que os coordenadores podem executar, como

gerenciar o vínculo estratégico do plano executivo, definir as suas prioridades e

gerenciar os grupos responsáveis, além disso, poderá também finalizar os planos

executivos. A Figura 9 ilustra o caso citado.

Figura 7 - Caso de uso do assistente e do auxiliar

40

Figura 8 - Caso de uso do técnico

Figura 9 - Caso de uso do coordenador

41

O último ator do sistema é o superintendente, o qual terá um maior controle sobre o

sistema, ele poderá gerenciar e conduzir os planos executivos, poderá também definir

e alterar o vínculo estratégico, a prioridade e os grupos responsáveis, além de

finalizar os planos executivos. Os casos de uso exclusivo do superintendente é o de

homologar o sistema, conforme a tabela 7, e de gerenciar as estratégias atribuídas a

SES e a SVS. A Figura 10 demonstra os casos de uso do superintendente.

3.3 Diagrama de Classe

Esse diagrama tem por objetivo identificar os objetos que fará parte do

sistema, e a partir dele poderemos ter uma perspectiva do aplicativo. A Figura 11

exibe uma visão geral do diagrama de classe do SGPE.

Figura 10 - Caso de uso do superintendente

42

Figura 11 - Visão Geral do diagrama de classe

43

Na Figura 12, exibe mais detalhadamente os objetos relacionados às

estratégias do plano executivo, pode-se observar que todas as classes contém um

atributo chamado local. Ele serve para demonstrar se o item estratégico pertence à

SES ou a SVS.

A Figura 13, está associada ao acompanhamento do plano executivo, nela

pode-se notar que cada etapa está relacionada com diversas sub etapas, e elas por sua

vez, tem apenas um resultado, as classes que fazem parte do controle financeiro são

as classes “ElementoDespesa”, referindo a qual tipo de orçamento, e a classe

“Orcamento”, fazendo referência ao orçamento de cada etapa.

Figura 12 - Diagrama de Classe estratégia do plano executivo

44

A Figura 14 demonstra o diagrama pertencente ao plano executivo, e sua

natureza, parceiros e grupos responsáveis, já a Figura 15, destaca as classes

responsáveis pelos logs, controle e gerenciamento de usuários, sendo que a classe

“Setor” faz referência ao setor em que o usuário está inserido.

Figura 13 - Diagrama de classe acompanhamento do plano executivo

45

Figura 15 - Diagrama de classe dos acessos e logs

Figura 14 - Diagrama de classe do plano executivo

46

3.4 Modelagem Entidade Relacionamento

Após o levantamento de requisitos, foi realizada a modelagem entidade

relacionamento do banco de dados, para se chegar ao fechamento do MER foi

necessário mais entrevistas e estudos do formulário. A Figura 16 mostra uma visão

geral do diagrama entidade relacionamento (DER).

Percebe-se na modelagem a existência de doze entidades parecidas, as

quais fazem parte da estratégia adotada pelas SES, Figura 17, e pela SVS, Figura 18.

As perspectivas estão relacionadas ao cenário da aplicação da ação, os

objetivos se referem ao propósito do plano executivo, os indicadores são guias para

que cada objetivo seja alcançado, as metas são responsáveis por determinar a

Figura 16 - Diagrama Entidade Relacionamento do SGPE

47

finalidade, as iniciativas ou atividade em que o plano executivo fará parte, e o

problema/causa que o plano executivo irá solver.

As entidades estão divididas entre as pertencentes à SES e a SVS, isso

ocorreu porque a estratégia adotada pela SVS é diferente da estratégia adotada pela

SES. A elaboração dessas entidades foi necessária, pois os planos executivos devem

estar de acordo com as estratégias adotadas pela SVS e também pela SES.

Figura 18 - DER associado à estratégia da SES

Figura 17 - DER associado à estratégia da SVS

48

A parte dos logs representando na Figura 19, foi dividida em duas

entidades, a “logs_acesso” responsável por registrar os dados de acesso de cada

usuário, e a “logs_atividade”, que é responsável por registrar as atividades feitas de

cada acesso e em qual plano executivo foram realizadas.

A Figura 20 está associada ao controle de acesso do sistema, o controle

será feito através dos usuários, que pertencem a um setor. As permissões serão feitas

através de níveis de acesso, os quais poderão ter ou não, a permissão de acessar

certos métodos do sistema.

Figura 19 - DER associado aos logs do sistema

Figura 20 - DER associado ao controle de acesso

49

A Figura 21, apresenta os dados gerais do plano executivo, na qual

podemos notar as diversas tabelas, entre elas: a “natureza” especificando a natureza

da ação, “parceiros”, fazendo referência aos membros externos da SVS que

participarão do projeto, “grupo_responsavel” correspondendo ao grupo de trabalho

responsável pelo plano executivo, e o “plano_executivo”, nessa entidade temos o

atributo “homologado”, indicando se o plano foi homologado ou não, há também o

campo “numPlano”, onde será armazenado o número do plano executivo gerado após

a homologação.

Na Figura 22, se encontra as informações referentes as etapas, como as

informações orçamentarias, que possui informações sobre os itens necessários para

executar o plano e seus respectivos custos, e para cada componente existe um tipo de

elemento de despesa, representado pela tabela “elementoDespesa”, as dos técnicos

responsáveis pela execução, e das sub etapas.

Cada sub etapa tem seu resultado, onde conterá uma descrição,

destinação e qual o tipo de elemento obtido.

Figura 21 - DER associado aos dados gerais do plano executivo

50

Figura 22 - DER associado às etapas do plano executivo

51

3.5 Diagrama de Sequência

O diagrama de sequência produzido no período do estágio foi a do

cadastro de novo plano executivo (Figura 23), ele serve para representar a sequência

dos processos durante a criação de um novo plano executivo.

Figura 23 - Diagrama de sequência de novo plano executivo

52

3.6 Diagrama de Atividade

Os diagramas de atividade produzidos durante o estágio foi a do cadastro

de um novo plano executivo e o seu acompanhamento. A Figura 24 representa o

diagrama de atividade do cadastro de um novo plano executivo.

Figura 24 - Diagrama de atividade de cadastro de um novo plano executivo

53

A Figura 25 corresponde ao digrama de atividade do acompanhamento

de um plano executivo.

Essa atividade de acompanhamento, visa conduzir as informações

referentes a cada plano executivo de maneira sistemática, para controle das ações

relativas ao mesmo.

Figura 25 - Diagrama de atividade de acompanhamento do plano executivo

54

3.7 Implementação

Os documentos gerados na análise foram utilizados como apoio para a

implementação. A utilização do framework e do MVC agilizaram o processo, mas

pelo curto prazo de tempo não foi possível a implementação de todo o aplicativo.

A primeira tela que o usuário terá acesso no aplicativo, será de um

formulário de login, pois, somente as pessoas cadastradas poderão acessar o sistema,

a Figura 26 apresenta a imagem da página inicial do sistema.

A área de gerenciamento dos usuários, demonstrado na Figura 27, pode-

se perceber que é possível criar, alterar e desativar um usuário, em concordância com

as tabelas 30, 31 e 32 dos requisitos funcionais.

Figura 26 - Tela de login

Figura 27 - Tela principal parte usuário

55

A etapa da estratégia, incluiu cadastrar, editar e excluir as perspectivas,

objetivos, indicadores, metas, iniciativas e problemas/causa.

As Figuras 28 e 29 exibem a tela aonde se deve selecionar o elemento

estratégico. Na Figura 28 os elementos fazem parte da estratégia da SVS e na Figura

29 fazem parte da estratégia da SES.

Figura 28 - Tela principal da estratégia da SVS

Figura 29 - Tela Principal da estratégia da SES

56

Na Figura 30, o item perspectiva é referente a Superintendência de

Vigilância em Saúde, conforme proposto pela tabela 48, 49 e 50 dos requisitos

funcionais. As telas dos demais itens serão parecidas com a Figura 30, pois elas

possuem os requisitos funcionais semelhantes.

O gerenciamento da natureza da ação, apresentado na Figura 31, está de

acordo com os requisitos funcionais relatados nas tabelas 26, 27 e 28.

Os logs de acesso e de atividade serão exibidos nas Figuras 32 e 33,

servindo para registrar os acessos realizados no sistema e as atividades efetuadas, o

registro do log de admissão será feito após a verificação do usuário e antes de

ingressar no sistema, já o log de atividade é produzido assim que uma função é

requisitada, juntamente com a verificação de permissão.

Figura 30 - Tela da perspectiva da SVS

Figura 31 - Tela da natureza do plano executivo

57

No apêndice 1 é apresentado o código do controlador “permissao”,

podemos observar que contém diversas funções e uma delas é o “index()”, todos os

controllers do CodeIgniter devem ter essa função, pois ela é default, na função

”novo()” existe uma requisição a um método do modelo “permissão_model”

(apêndice 2), o qual faz as conexões ao banco de dados e responde a solicitação para

o controlador, esse por sua vez seleciona uma view e envia os dados recebidos para

serem exibidos, no apêndice 3, temos um exemplo de código da visão “novo_view”,

que é um formulário de cadastro de permissões. Os demais códigos desenvolvidos

durante o estágio estão em um CD anexo ao relatório.

Figura 32 - Tela dos logs de acesso

Figura 33 - Tela dos logs de atividade

58

4 DIFICULDADES ENCONTRADAS

Durante o período de estágio foram encontradas diversas dificuldades na

área de análise e na fase de desenvolvimento do aplicativo, conforme exposto logo

abaixo.

Na análise, as dificuldades surgiram ao compreender o fluxograma e a

estrutura do plano executivo, que foi ocasionado pelo fato de não possuir um

conhecimento prévio na área de planejamento da SVS.

Para solucionar a situação, foram necessárias realizar diversas

entrevistas com o superintendente, técnicos e coordenadores, na tentativa de

possibilitar uma maior clareza de como funcionava a realidade institucional,

adquirindo assim, conhecimentos necessários para entender o fluxo e a estrutura de

um plano executivo.

Outro contratempo encontrado, foi a maneira de organizar o formulário

para exibição, pois os formulários de cadastro e alteração do plano executivo

continham um grande número de campos, o qual se tornaria cansativo para o usuário

o seu preenchimento. Assim sendo, foi imprescindível dividi-los de forma que o

cliente conseguisse preencher pequenas partes e salvá-las para poder continuar em

outro momento.

Na fase das entrevistas, ocorreram momentos em que o responsável pela

explicação do funcionamento do plano executivo, estava em reunião ou executando

ações pertinentes a SES. Por esse motivo houve uma certa morosidade para realizar

os encontros.

Na implementação, a primeira adversidade encontrada foi a de como

realizar o controle de usuário, depois de muitas pesquisas ficou evidente que seria

necessário cadastrar todas as classes e suas respectivas funções, após essa fase, foi

necessário criar grupos de acesso e permitir o ingresso do grupo em funções

especificas de acordo com as permissões pré-estabelecidas.

Com a utilização do CodeIgniter, o desafio posto, foi a de pouco

conhecimento de suas distintas ferramentas, e para suprir tal demanda foi

necessários, acessar e estudar o manual do usuário, disponível no site do

59

desenvolvedor do framework. A partir desse momento foi possível trazer as claras

quais métodos utilizar.

Já com a utilização do MySQL o obstáculo maior, foi referente a

gravação das acentuações no banco de dados, para resolver tal problema foi

necessário definir a codificação dos caracteres, ou colação, como utf8_unicode_ci,

evitando desta maneira a realização de conversões de codificação dos textos

recebidos através de formulários.

No layout da interface gráfica apresentado ao usuário houve uma objeção

quanto à organização das telas, para vencer essa dificuldade, as telas foram

remanejadas de maneira intuitiva e sem muitos objetos, possibilitando um campo

visual mais nítido, limpo e de fácil compreensão.

A dificuldade ocorrida com maior frequência foi a de encontrar pouco

conteúdo na língua portuguesa, a grande maioria está disponível apenas na língua

inglesa. Apesar de se ter um conhecimento mediano nessa língua, ocorreram algumas

dificuldades quanto a tradução e interpretação. Entretanto, a utilização de tradutores

online, dicionários e gramáticas especializadas facilitaram o entendimento.

Todas as diversidades encontradas, foram muito importantes para o

aprendizado, pois é um tipo de conhecimento que não é possível sem ter a execução

da prática e do comprometimento.

60

5 CONCLUSÕES

A realização do estágio, foi de extrema importância para adquirir

conhecimento e experiência no que tange as áreas práticas de análise e

desenvolvimento de software.

Durante o estudo dos formulários do plano executivo, foram realizadas

diversas entrevistas com os técnicos, coordenadores e o superintendente, os quais

foram importantes, pois, complementaram de maneira satisfatória as informações

sobre o formulário, o que possibilitou um melhor entendimento do fluxograma de

funcionamento do plano executivo. Essa etapa foi necessária, pois sem ela seria

impossível realizar a construção do sistema de acordo com as necessidades da SVS, a

partir dessa etapa se teve o fundamentação básica para realizar o projeto do sistema.

Após o entendimento do fluxograma do plano executivo, partiu-se para a

etapa de levantamento de requisitos funcionais e não funcionais do sistema. Foram

utilizados os conhecimentos adquiridos na fase anterior e realizadas mais algumas

entrevistas. Essa etapa influenciou nos demais processos de desenvolvimento, pois os

levantamentos de requisitos informam às necessidades que conterá no sistema.

Finalizado os levantamentos de requisitos, deu início à diagramação do

sistema, durante esse estágio todas as diagramações propostas foram finalizadas, e a

partir da modelagem entidade relacionamento, foi construído o banco de dados do

sistema. Essa fase proporcionou uma documentação e um melhor entendimento do

funcionamento do sistema, o diagrama de classe foi necessário para construir as

classes que fazem parte do modelo, pois é nele que se encontra a lógica de negócio

do sistema. O diagrama de atividade foi importante para compreender o passo a

passo do funcionamento do sistema. O diagrama de sequência proporcionou um

entendimento melhor de como e quando ocorrem às trocas de mensagens entre os

objetos do sistema.

Para a construção do banco de dados, o diagrama de entidade

relacionamento auxiliou na construção do script de criação do banco, sem a

construção do diagrama de entidade relacionamento, a construção do banco de dados

seria uma tarefa trabalhosa.

61

A utilização do framework CodeIgniter tornou a programação mais

acelerada, e a utilização de funções e bibliotecas evitou uma demanda maior de

escrita de códigos. O padrão MVC possibilitou o reaproveitamento de código

tornando eficiente a criação do software. O Apêndice 1 é o exemplo de um

controller, nele é possível observar que solicitou-se diversas vezes ao model para

realizar operações. Após receber os dados do modelo, o controller os envia para a

visão, esse por sua vez se responsabiliza em exibi-los ao usuário. O modelo é

retratado no apêndice 2, nele nota-se que não há nenhum tipo de referência ao

controller ou a view. No apêndice 3 é apresentado uma exemplo de código da view, o

qual é diferente dos demais, pois contém marcadores HTML, esses marcadores serão

interpretados pelo browser, que construirá a tela.

Apesar de utilizar ferramentas e métodos para acelerar o

desenvolvimento do programa, cabe ressaltar que a produção do sistema ainda está

em andamento.

Como proposta futura, a finalização do aplicativo possibilitará o teste e a

implantação do SGPE na SVS, e após a consolidação do sistema, se iniciará o

incremento da próxima versão, tendo em vista, estabelecer melhorias práticas no

gerenciamento dos planos executivos e suas respectivas auditorias.

62

6 REFERÊNCIAS BIBLIOGRÁFICAS

EllisLab, Inc. CodeIgniter User Guide. Disponível por www em

http://ellislab.com/codeigniter/user-guide/ (acessado em 15 de março de 2013).

FREEMAN, A., SANDERSON, S.; 2011. Pro ASP.NET MVC 3 Framework. 3

edição. Nova York: Apress.

GABARDO, Ademir Cristiano; 2012. PHP e MVC com CodeIgniter. 1ª edição. São

Paulo: Novatec.

GILMORE, Jason; 2010. Beginning PHP and MySQL: From Novice to Professional.

4ª edição. Nova York: Apress.

GUEDES, Gilleanes; 2011. UML2: uma abordagem prática. 2ª edição. São Paulo:

Novatec.

KABIR, Mohammed; 2002. Apache Server 2 Bible. 1ª edição. Nova York: Hungry

Minds.

NIEDERAUER, Juliano 2011. Desenvolvendo Websites com PHP. 2ª edição. São

Paulo: Novatec.

SAMMERVILLE, Ian; 2007. Engenharia de software. 8ª edição. São Paulo: Pearson.

SUEHRING, Steve; 2002. MySQL, a Bíblia. 1ª edição. Rio de Janeiro: Campus.

THOMSO, L., WELLING, L.; 2003. PHP e MySQL: Desenvolvimento Web. 2ª

edição. Rio de Janeiro: Campus.

VALADE, Janet; 2007. PHP & MySQL for Dummies. 3ª edição. Indianapolis: Wiley.

63

APÊNDICES E/OU ANEXOS

Anexo 1 – Formulário de Plano Executivo

64

65

66

67

Anexo 2 – Parte do formulário referente ao cadastro do Plano

Executivo

68

Anexo 3 – Parte do formulário referente ao acompanhamento

do Plano Executivo

69

Anexo 4 – Parte do formulário referente ao vinculo

estratégico

70

Anexo 5 – Parte do formulário referente à indicação de

prioridade

71

Apêndice 1 – Código do controller permissão.php

72

Apêndice 2 – Código do Model permissao_model.php

73

Apêndice 3 – Código da view novo_view.php

Documents

Análise e Desenvolvimento Do Sistema de Gerenciamento de Plano Executivo