Sistema de Informação para Gestão Acadêmica

FACULDADE ALVORADA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO

Afonso Alves Ribeiro
Glauco Kendi Ribeiro Itai

SisEdu – Modulo Ano Letivo

Brasília-DF
2011

Glauco Kendi Ribeiro Itai

SisEdu – Modulo Ano Letivo

Monografia apresentada a Faculdade Alvorada
para a obtenção do título de Bacharel em
Sistemas de Informação.

Orientadores: Prof. Elias Freitas da Silva
Profa. Mestra Elizabeth d´Arrochella Teixeira

Brasília-DF
2011

AGRADECIMENTOS

Glauco Kendi Itai

Agradeço primeiramente a Deus por me proporcionar a oportunidade de
aprimorar meus conhecimentos através desta graduação. Aos meus pais Romeu
Kendi Itai e Alice Ribeiro, por me darem amor e carinho e me incentivarem a
escolher e trilhar meus próprios caminhos. A minha tia Berenice Itai (Tia Yuki), pois
sem a ajuda dela nada disso seria possível. A minha esposa Vanesa Castro Itai por
estar presente a cada momento galgando cada degrau dessa subida ao meu lado. E
também ao meu primo Roger Luiz Itai cuja vasta experiência na área norteou meu
caminho nessa longa jornada.


Agradeço aos Deuses e aos meus Ancestrais por todas as oportunidades, a
Oghma pela Iluminação, a Eochaid Ollathair por me ensinar a paciência, aos meus
pais, Júlio César Antunes Ribeiro e Jane Alves da Silva Antunes por oferecerem,
com suas vivências, o cerne forte sobre o qual fundamentei meu passado, à minha
avó, Iara Antunes Ribeiro, por tornar este trabalho possível, e a Jéssica Alves de
Vasconcelos, por ser a construtora auxiliar dos sonhos que me impulsionam para o
meu futuro.

RESUMO

Uma forma estruturada e padronizada para atender os discentes da
Faculdade ABC (empresa fictícia), preferencialmente por meios digitais, em termos
de solicitação de documentação, bem como disponibilização de certas informações
de interesse do discente, atualmente é uma necessidade claramente pronunciada.
Tanto para um maior controle do conteúdo das informações utilizadas dentro do
âmbito dos profissionais da Faculdade quanto para maior agilidade no
processamento das solicitações de serviços. Da forma como é realizado este fluxo
de trabalho atualmente, levando-se em consideração o volume de serviços que são
solicitados diariamente, a conclusão óbvia é uma solução acessível e confiável a ser
implementada em breve, se não imediatamente. A instituição de ensino necessita
que haja o controle da execução de serviços como emissão de documentos, dentre
tantas outras atribuições do Setor de Atendimento da Faculdade. Este trabalho se
propõe a criar um sistema de informação que cumpra este papel.

Palavras-chave: Sistema de Informação. Fluxo de Serviço e Agilidade.

ABSTRACT

A structured and standardized way to attend the students of ABC College
(fictional company), preferably by digital means, in terms of documentation requests,
as well as availability of certain information that concerns to the students, is currently
a clearly pronounced need. As well as for a better control over the content of the
information used inside the scope of the staff of the college, as for more agility in the
processing of service requests. The way this work flow is carried out now,
considering the amount of demands requested daily, the obvious conclusion is an
available and trustable tool to be created soon, if not immediately. The educational
institution needs to control over the performance of services as the issue of
documents, among many other assignments of the college’s Care Sector. The current
article proposes the creation of an information system that meets this role.

Keywords: Information System. Work Flow and Agility.

LISTA DE FIGURAS

Descrição Pag.
1 Organograma 23
2 Modelo Incremental – XP 31
3 Modelo Incremental – SCRUM 32
4 Fases do RUP 39
5 Diagrama de Caso de Uso 50
6 Diagrama de Classe 74
7 Modelo de Entidade e Relacionamento - Elizabeth d’Arrochella Teixeira 75
8 Árvore do Sistema 89
9 TELA DE LOGIN 90
10 TELA DE CONSULTA MATRÍCULA VAZIA 91
11 TELA DE CONSULTA MATRÍCULA CHEIA 91
12 TELA DE EDITAR MATRÍCULA 92
13 TELA MENU 92

LISTA DE TABELAS
Descrição Pag.
1 Planejamento do Projeto de Desenvolvimento 25
2 Casos de Uso 49
3 Caso de Uso UC01 – Manter Períodos 50
4 Caso de Uso UC02 – Manter Ementa 52
5 Caso de Uso UC03 – Manter Avaliação 54
6 Caso de Uso UC04 – Histórico Escolar 56
7 Caso de Uso UC05 – Manter Matrícula 57
8 Caso de Uso UC06 – Manter Turma 60
9 Caso de Uso UC06 – Manter Grade Horária 62
10 Caso de Uso UC08 – Manter Calendário 64
11 Caso de Uso UC09 – Manter Pauta 66
12 Caso de Uso UC10 – Manter matrícula/Disciplina 69
13 Caso de Uso UC11 – Enturmação 72
14 PERÍODO 76
15 MATRÍCULA 76
16 TURMAS 77
17 ENTURMAÇÃO 77
18 MATRÍCULA_DISCIPLINA 77
19 BANCO 78
20 BOLETO 80
21 CURSO 80
22 DISCIPLINA 81
23 DOCUMENTOS 81
24 GRADE CURRICULAR 81
25 HST_PESSOA 82
26 HST_USUÁRIO 83
27 INSCRIÇÃO_VESTIBULAR 83
28 INSCRIÇÃO_VESTIBULAR ALUNO 83
29 OBSERVAÇÃO 84
30 PAGAMENTO 84
31 PARAMETROS 84
32 PERFIL 85
33 PERÍODO 85
34 PESSOA 86
35 PLANO ENSINO 86
36 TIPO_BOLETO 87
37 TIPO_DOC 87
38 TIPO_END 87
39 UF 87
40 USUÁRIO 88
41 VESTIBULAR 88

LISTA DE ABREVIATURAS E SIGLAS

Descrição
AGI IRIX Sistema operacional baseado no Unix com o BSD
AIX Advanced Interactive eXecutive
ASP Active Server Pages
BD Banco de Dados
BSD Berkeley Software Distribution
GNU GNU is Not Unix (em português: GNU Não é Unix)
HP-UX Sistema operacional lançado pela empresa Hewlett-Packard
IBM International Business Machines
ITIL Information Technology Infrastructure Library
JAVA Linguagem de programação orientada a objeto
MAC OS Macintosh Operating System
MySQL My Structured Query Language
PHP Hypertext Preprocessor", originalmente Personal Home Page.
RUP Rational Unified Process (ou Processo Unificado Racional)
SGBD Sistema de Gerenciamento de Banco de Dados
SisEdu Sistema Acadêmico para faculdades
SOLARIS Sistema Operacional UNIX desenvolvido pela Sun Microsystems
SQL Structured Query Language
TI Tecnologia da Informação
TRU 64 Sistema operacional UNIX 64-bit
UML Unified Modeling Language
XP Programação extrema (do inglês eXtreme Programming)

10

Sumário

1 Introdução 14
1.1 Tema 14
1.2 Justificativa 15
1.3 Formulação do Problema 16
1.4 Objetivos 17
1.4.1 Objetivo Geral 17
1.4.2 Objetivos Específicos 17
1.5 Organização do Trabalho 18
2 Análise Institucional 19
2.1 A Empresa e seu Negócio 19
2.1.1 Organograma da Empresa 21
2.2 Descrição das Necessidades 22
3 Cronograma 26
4 Referencial Teórico 28
4.1 Engenharia de Software 28
4.1.1 Cleanroom 29
4.1.2 Métodos Ágeis 29
4.2 Arquitetura de Software 32
4.3 Linguagem de Programação 32
4.3.2 PHP 33
4.3.3 ASP 34
4.4 Banco de Dados 35
4.4.1 Oracle 37
4.4.2 PostgreSQL 37
4.4.3 MySQL 38
4.5 RUP (Rational Unified Process) 38
4.5.1 Desenvolvimento Iterativo 39
4.5.2 Fases do RUP 40
4.5.2.1 Concepção 40
4.5.2.2 Elaboração 41
4.5.2.3 Construção 41
4.5.2.4 Transição 41
4.6 UML (Unified Model Language) 42
4.7 Information Technology Infrastructure Library – ITIL 43
5 Proposta do Novo Sistema 44
5.3 Descrição do Sistema Proposto 44
5.4 Resultados Esperados 47
5.5 Restrições do sistema proposto 47
5.6 Relação Custo x Benefícios:
Análise de Viabilidade Econômica do Novo Sistema 48
5.7 Áreas Afetadas Pelo Novo Sistema 48
6 Documentação de Análise 49

11

6.1 Visão Macro dos Atores 49
6.2 Identificação dos Atores 49
6.3 Listas de Casos de Uso 50
6.4 Diagrama de Caso de Uso 51
6.5 Descrição detalhada dos Casos de Uso 53
6.6 Diagramas de Classes 76
6.7 Modelo de Entidade-Relacionamento 77
6.8 Especificação das Tabelas 78
6.9 Árvore do Sistema 88
6.10 Especificação Técnica 89
6.10.1 Layout das Principais Telas da Aplicação 89
6.10.5 Segurança Física 93
7 Plano de Implantação 98
8 Conclusão 100
9 Referências Bibliográficas cv

12

1 Introdução
Segundo GUILLON (1994), uma instituição de ensino difere de empresas com
atuação em áreas diferentes em vários pontos. Deles, o mais facilmente observável
é a forma com que ela deve lidar com seu cliente. Essencialmente, uma Faculdade é
uma prestadora de serviço, sendo assim, a qualidade deste serviço, bem como uma
integração com seus contratantes é ponto crucial.
Promover um serviço informativo de qualidade significa interagir com os
clientes, neste caso os docentes, da forma mais ágil e simplificada possível.
(GUILLON, 1994)
Para diversos fins, o discente matriculado em uma faculdade necessita, vez por
outra, de certos documentos autenticados contendo informações sobre sua atuação
na instituição de ensino. A emissão e autenticação destes documentos não são, a
princípio, funções do Departamento de Atendimento, porém, ao solicitar tais
serviços, é a este departamento que o discente irá se dirigir. Sendo assim, o Fluxo
do Serviço interage diretamente com este setor, e deve ser definido de modo a
tornar a execução deste trabalho eficiente.

1.1 Tema
Ackoff (1999) defende que uma das muitas maneiras de perceber um sistema é
descobri-lo como um “todo que não pode ser dividido em partes independentes”. Seu
desempenho nunca é igual à soma das ações de suas partes, consideradas
separadamente: é uma função de suas interações. “Via de regra, os sistemas
interagem muito mais do que nossa capacidade de percepção.”

Encontra-se em elaboração uma proposta de um sistema unificado na
Faculdade ABC (empresa fictícia), que lide com as solicitações de serviços,
monitoramento de informações financeiras e acadêmicas por gestores e discentes
matriculados, dentre outras atribuições dentro da Instituição, este projeto é intitulado
SisEdu. O presente artigo será desenvolvido como um módulo integrante deste
sistema, responsável pela gestão das informações do Ano Letivo da Faculdade.

O Módulo de Ano letivo do SisEdu da Faculdade ABC será um sistema capaz
de receber solicitações de serviços da parte dos alunos, registrá-las e encaminhá-las

13

aos gestores destes serviços. Além disso, será capaz de disponibilizar certas
informações referentes ao ano letivo para Alunos e Professores, mediante um login.

Tomando como ponto de partida o cadastramento de informações como
disciplinas do semestre letivo, bem como as ementas destes cursos, além de
diversas outras informações que podem ser utilizadas pelo usuário no meio
acadêmico. Seguindo uma organização e apresentação destes dados os Docentes e
aos Discentes de modo a agilizar os fluxos de trabalho, com base nas demandas da
instituição bem como suas rotinas administrativas, a fim de trabalhar as áreas em
que a mesma possui falhas mais aparentes e necessidade da atenção por parte do
corpo administrativo da faculdade a fim de atender as necessidades do corpo
docente e discente de maneira rápida e agradável.

1.2 Justificativa
Para REZENDE (1999), modernamente, o software deve estar com o foco no
negócio empresarial e com o objetivo de auxiliar os processos de tomada de
decisões (estratégicas, táticas ou gerenciais e operacionais).

A metodologia utilizada atualmente pela Instituição é comum, composta por
diversos trâmites de documentos por meios físicos, com auxílio do sistema Cathedra
no cadastramento de informações de uso interno da Instituição, além do sistema
WebClass, voltado exclusivamente aos docentes para controle de frequência e notas
dos alunos. Estes softwares foram adquiridos pela instituição, mas não se aplicam
exclusivamente às suas necessidades, frequentemente apresentando uma
divergência de escopo que prejudica a otimização dos fluxos de serviço.

A Faculdade ABC necessita de uma forma automatizada de organizar as
informações de seus períodos letivos. Este processo atualmente é feito
manualmente por meio do uso de ferramentas como o Microsoft Excel.
SOMMERVILLE (2003) diz que os engenheiros de software devem pensar
sobre os serviços que o sistema fornece, as restrições dentro das quais o sistema
deve ser construído e operado e as interações do sistema com seu ambiente.

14

Sendo assim, o Módulo Ano Letivo do sistema unificado SisEdu deve
padronizar o cadastro de informações acerca do ano letivo da Faculdade, contando
com um banco de dados relacional bem organizado e exigindo coesão no conteúdo
das informações cadastradas. Além disso o módulo deve disponibilizar estas
informações aos estudantes via Web.

1.3 Formulação do Problema
É observável a necessidade de uma maior integração entre o corpo discente e
a Faculdade ABC. Cada serviço de informação de que o aluno necessite só é
atendido pela Instituição após a incursão em filas e a verificação das informações
solicitadas por parte de pessoal responsável no setor, processo este feito
manualmente.

Além disso, é necessária uma metodologia mais ágil no cadastramento das
informações referentes as demandas administrativas e acadêmicas da Faculdade,
de forma que o procedimento de, por exemplo, montar as grades curriculares dos
cursos deixe de ser um processo manual como é atualmente.

Havendo uma maior integração entre as informações, desde seu
cadastramento pelo Gestor da mesma, até sua utilização em um documento
porventura solicitado por um aluno, o funcionário responsável por atender à
demanda poderia contar com maiores agilidade e confiabilidade no processo.

Desta forma a necessidade identificada é a otimização destes fluxos de
trabalho, de forma a integrar melhor o aluno à Faculdade, e oferecer uma forma ágil
e segura de manter as informações curriculares atualizadas a cada período letivo.

1.4 Objetivos
Um objetivo pode ser definido como um propósito ou alvo que se pretende
atingir. Tudo aquilo que se deseja alcançar através de uma ação clara e explícita,
pode ser chamado de objetivos. (MARINHO, 2007)

15

Além disso, segundo NUNES (2002), os objetivos estão ligados à importância
do tema e relevo da pesquisa, e deve apontar os objetivos que esta pretende
alcançar.

Disponibilizar aos alunos da Faculdade ABC uma ferramenta confiável e
robusta para acessar suas informações de matrícula, notas, grades horárias, bem
como solicitar emissão de documentos para diversos fins, dentre outras
funcionalidades, é a proposta do presente artigo.

1.4.1 Objetivo Geral
Informatizar o processamento das informações dos períodos letivos da
Faculdade ABC em um ambiente WEB, tanto para proporcionar um armazenamento
otimizado destas informações, quanto para a organização destes em um documento
emitido para o aluno, mediante solicitação, que requeira apenas uma assinatura para
ser validado.

1.4.2 Objetivos Específicos

 Garantir o acesso ágil, por parte dos alunos, a informações sobre seu ano
letivo;
 Permitir a solicitação da emissão de certos documentos de que o discente
necessite;
 Cadastramento destas informações por professores ou demais responsáveis,
de modo a estarem sempre atualizadas e consistentes.

1.5 Organização do Trabalho
O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivos da
monografia em apresentação.
O segundo capítulo realiza a apresentação da Faculdade ABC e seu ramo de
negócio.

16

O terceiro capítulo apresenta o cronograma das atividades de
desenvolvimento dessa monografia, sinalizando os prazos para a finalização do
trabalho.
O quarto capítulo descreve o referencial teórico, todas as fontes de pesquisa
de ferramentas que serão utilizadas para o desenvolvimento do sistema e escrita da
monografia.
No quinto capítulo, é apresentada a proposta, a descrição, os resultados, as
restrições e as áreas afetadas pelo sistema que será desenvolvido.
No sexto capítulo é apresentada a descrição e identificação dos atores e
casos de uso do sistema. Como também, a apresentação das principais telas do
sistema e suas funcionalidades.
O sétimo capítulo descreve as atividades desempenhadas para a implantação
sistema na empresa.
Para o oitavo capítulo está registrada a conclusão do trabalho.
No nono e último capítulo estão descritas todas as referências bibliográficas
que dão sustentação e base ao desenvolvimento deste trabalho.

17

2 Análise Institucional
Como tudo que é instituído, instituíste ou em vias de institucionalização, a
análise institucional é um produto social-histórico. Trata-se da concepção de história
da empresa (GOMES, 2006).

Também é nossa responsabilidade compreender as necessidades dos usuários
e demais gestores, cujas vidas serão afetadas por nossa solução. (LEFFINGWELL,
2003).

A fim de obter um conhecimento mais aprofundado no que se refere aos fluxos
de serviços e informações dentro do âmbito da Faculdade ABC, foram realizadas
entrevistas com funcionários responsáveis pelo atendimento às demandas por
informação acerca do Ano Letivo da Faculdade e outros serviços disponíveis aos
docentes.

2.1 A Empresa e seu Negócio
Segundo SOMMERVILLE (2004), da mesma maneira que o ambiente físico, os
sistemas são também situados em um ambiente organizacional. Isso inclui políticas
e procedimentos que são, por sua vez, regidos por questões políticas, econômicas,
sociais e ambientais mais amplas.

A Faculdade ABC é uma instituição de ensino superior (fictícia) com filial
estabelecida em Brasília DF, classificada como de médio porte. Possui uma matriz
no estado do Paraná e alguns campi em outros estados brasileiros. Conta com
quadro de profissionais próprio, criado independentemente da avaliação da matriz. E
organiza sua grade curricular de forma “Fechada”.

Em um aspecto geral podemos dividir as necessidades em várias frentes de
atuação onde os problemas são visíveis e graves.

Quanto à infraestrutura, segundo levantamento efetuado nas dependências da
ABC, verificou-se que toda a estrutura possui falhas, todo o maquinário é
ultrapassado e poucos atendem as necessidades para qual vêm sendo usados. A

18

infraestrutura de rede mostra pontos fracos em sua organização e distribuição, e não
possui um projeto. É utilizada por docentes e alunos, apesar das dificuldades e
perda de banda.

Todo o complexo da ABC carece de um sistema de segurança para bloqueio de
invasões exceto o que é fornecido pela matriz situada em outro estado, bem como
todo o sistema de informação que é vinculado à matriz cujo sistema de envio e
recebimento de dados impossibilita ou dificulta a realização de certas tarefas pelo
sistema.

Com relação à estrutura de dados, verificou-se que toda a base de dados que o
sistema se utiliza está localizada na matriz, essa mesma base de dados possui
falhas graves, como redundâncias e conflitos com dados das filiais, o acesso à base
de dados é restrito somente a alta diretoria, ou seja, aos mantenedores da
faculdade.

O fator mais preocupante identificado pela análise realizada é o conflito entre
dados de bases diferentes. Como exemplo, há registros de alunos recém-
matriculados, iniciando seu curso, mas com registro de disciplinas já cursadas, pois
na base de dados há registros de alunos que possuem o mesmo nome, e se
encontram em vias de se formar.

Sobre o sistema atual, verificou-se que, atualmente, a ABC se utiliza de dois
sistemas informatizados, ao Cathedra e o Web Class. Ambos utilizados para
gerenciar a vertente acadêmica da faculdade. Contudo, não há nenhum sistema pra
gerenciar a parte administrativa da Instituição (Srh. Financeiro, almoxarifado, etc.).

A análise do negócio revelou que, em ambos os sistemas utilizados, as falhas
apresentadas na comunicação são graves, ou seja, eles quase não se comunicam
entre si. Grande parte das informações é redundante, fazendo com que boa parte
delas tenha que ser digitadas manualmente, e pelos seus operadores. Assim como
informações complementares, que deveriam ser extraídas do outro sistema também
tenha de ser inseridas manualmente.

19

Todo o sistema é suscetível a falhas humanas. Pouco ou nenhum modelo de
relatórios são emitidos. Nenhum dos utilizados atualmente possui um operador de
acompanhamento de protocolo. Estes foram alguns dos problemas encontrados pela
Análise dos sistemas em uso.

A organização dos períodos letivos da Faculdade ABC é feita em períodos
anuais, para fins financeiros. Já para fins acadêmicos, como a organização da grade
de disciplinas, a organização segue um padrão semestral, o que gera diversos
conflitos entre estas e aquelas informações.

Para REZENDE (1999), toda empresa, independente de seu negócio e meio de
atuação, possui cultura, filosofia e políticas, podendo ser definidas em formal ou
praticadas informalmente. Estes valores são introduzidos na empresa, fazendo parte
de suas atividades cotidianas.

2.1.1 Organograma da Empresa
Abaixo se verifica o organograma da Faculdade ABC de forma a apresentar
hierarquicamente os setores e departamentos que a compõem.

Este organograma mostra como estão dispostas unidades funcionais, a
hierarquia e as relações de comunicação existentes entre elas.

Também são unidades administrativas com funções bem definidas.

Aqui estamos representando apenas a faculdade ABC que é uma filial, pois o
sistema proposto afetará apenas a esta filial.

20

Figura 1 - Organograma da Empresa

2.2 Descrição das Necessidades
Segundo LEFFINGWELL (2003), os requisitos definem as capacidades que os
sistemas devem oferecer, em conformidade com um grupo de necessidades, que
normalmente definem o sucesso do projeto.

Já para SOMMERVILLE (2004), os problemas que os engenheiros de software
têm para solucionar são, muitas vezes, imensamente complexos. Compreender a
natureza dos problemas pode ser muito difícil, especialmente se o sistema for novo.

De acordo com o que se propõe o módulo Ano Letivo do SisEdu, são
observadas diversas necessidades que o projeto deve atender. São elas:

 Permitir o cadastramento de Diretores, Professores/Coordenadores,
Funcionários e Alunos da Faculdade ABC, com perfis diferentes, ao
sistema. Determinados perfis deverão permitir o cadastramento das
informações que serão consultadas pelo perfil Aluno;
 Disponibilizar, por meio de integração com outros módulos do SisEdu,
informações sobre a situação atual da matrícula do discente ao perfil

21

Aluno, de acordo com a identificação do usuário previamente cadastrado
no sistema;

 Manter, por meio de integração com os diários de classe, o histórico
escolar do aluno, de modo a disponibilizar para ele quando solicitado;

 Manter o diário de classe de cada turma. Esta operação será realizada
pelo Professor, mediante acesso ao sistema;

 Manter um registro, no histórico escolar do aluno, dos créditos
prestados anteriormente à matrícula por alunos transferidos de outras
instituições;

 Permitir o armazenamento, por parte dos Professores, de arquivos que
contenham a ementa de suas matérias para aquele período letivo;

 Manter informações acerca de turmas montadas de acordo com as
matrículas realizadas;

 Permitir a consulta a algumas das informações cadastradas por parte
do perfil Aluno;

2.3 Sistema de Informação Existente na Empresa
O software atualmente utilizado pela Faculdade ABC foi desenvolvido por
terceiros chamado Cathedra. Ele possui um banco de dados próprio atualmente em
MySQL segundo informações da mantenedora, o que faz com que a instituição se
adéque a ele, e não o contrário.

O Cathedra é um sistema utilizado para gerenciar e manter o controle de
alunos, como pré- matrícula e matrícula em curso e disciplina, vestibular, emissão de
boleto bancário, reajuste de mensalidade cálculo de atividades extracurriculares e
protocola pedidos como declarações diversas, contrato de monitorias e estágios,
contrato aluno / instituição, ou seja o Cathedra apenas mantém um número de

22

protocolos para os serviços, esses são gerados a partir de editores de texto e
editores de planilhas.

Webclass é um sistema proprietário web que por sua vez se utiliza de um
banco de dados próprio nos remetendo ao mesmo problema do Cathedra.

O WebClass é por sua vez utilizado para manter o que diz respeito a
funcionalidades acadêmicas da instituição, ou seja, é através dele que os
professores lançam notas de frequência dos alunos, que são feitas as consultas para
saber os aprovados do semestre, sendo também responsável pelo controle de turma
e disciplinas.

2.4 Normas de Funcionamento
Após análise, constata-se que, para o devido funcionamento de qualquer dos
dois sistemas, o usuário deve ter acesso a eles via login, após devido
cadastramento. No caso do Cathedra, é necessário que a aplicação esteja presente
na máquina, já para o WebClass, o funcionário deve ter acesso à rede interna da
Faculdade, além de ser um professor ou gestor de informações acadêmicas.

2.5 Ambiente Tecnológico Existente
O ambiente tecnológico é composto de: 100 computadores AMD Sempron,
1GB, HD 160GB, Gravador de DVD - Space BR, monitor 15.6, sistema operacional
Windows XP, todo o pacote Microsoft Office 2003, compondo quatro laboratórios.

Composto também dois computadores AMD Sempron, 1GB, HD 160GB,
Gravador de DVD - Space BR, monitor 15.6", sistema operacional Windows.

Além de 20 computadores AMD Sempron, 1GB, HD 160GB, Gravador de
DVD - Space BR, monitor 15.6, sistema operacional Windows XP, cinco impressoras
Lexmark T632 e, cinco scanner HP 5590 utilizados pelos setores administrativos da
instituição, sendo todos conectados por uma rede cabeada.

23

3 Cronograma

Desenvolver o cronograma significa determinar as datas de início e fim para
as atividades do projeto. Se as datas de início e fim não forem realísticas, é
improvável que o projeto termine como planejado.
Na tabela abaixo estão descritas o tempo medido em semanas de cada etapa
do projeto.

Tabela 1 - Planejamento do Projeto de Desenvolvimento

MÊS ETAPAS

acertos após Apresentação TCC

Apresentação da monografia
Levantamento de Requisitos

Acertos após apresentação
Análise (def. casos de uso)
Definição da metodologia

Planejamento de Ações
Definição do Problema

Escrever a monografia
Levantamento Teórico
Pesquisa Bibliográfica
Delimitação do Tema

Apresentação TCC I

Implementação
Entrega final
Codificação
Projeto
Ano 2011
I

Fevereiro 1a.
2a.
3a.
4a.
Março 1a.
2a.
3a.
4a.
5a.
Abril 1a.
2a.
3a.
4a.
Maio 1a.
2a.
3a.
4a.
5a.
Junho 1a.
2a.
3a.
4a.

Julho
MÊS

Agosto

Outubro
Ano 2011

Setembro

Dezembro
Novembro

4a.
3a.
2a.
1a.
5a.
4a.
3a.
2a.
1a.
4a.
3a.
2a.
1a.
4a.
3a.
2a.
1a.
5a.
4a.
3a.
2a.
1a.
4a.
3a.
2a.
1a.
Definição do Problema

Delimitação do Tema

Pesquisa Bibliográfica

Levantamento Teórico

Definição da metodologia

Planejamento de Ações

Levantamento de Requisitos
ETAPAS

Análise (def. casos de uso)

Escrever a monografia

Apresentação TCC I

acertos após Apresentação TCC I

Projeto

Codificação

Apresentação da monografia

Acertos após apresentação

Entrega final
24

Implantação

25

4 Referencial Teórico

Segundo NUNES (2002), a verificação prévia da existência do material
bibliográfico, da facilidade para seu manuseio, dentre outros fatores importantes, é
orientação necessária para todos os alunos, a partir da definição de qualquer tema.

Este capítulo objetiva apresentar as tecnologias e conhecimentos, bem como
conceitos adquiridos durante o curso. Além de uma avaliação de sua aplicabilidade
no projeto Módulo Ano Letivo do SisEdu.

Como afirma SALOMON (2001), documentar-se não é apenas uma das fases
da elaboração do trabalho científico: é um hábito do trabalhador intelectual e um tipo
de pesquisa também: a pesquisa documental.

4.1 Engenharia de Software
Segundo SOMMERVILLE (2003), a Engenharia de Software é uma
disciplina da engenharia que se ocupa de todos os aspectos da produção de
software, desde os estágios iniciais de especificação do sistema, até a manutenção
do mesmo.

Os Engenheiros de Software aplicam teorias, métodos e ferramentas nas
situações apropriadas, de modo seletivo, e sempre procuram descobrir soluções
para os problemas. Todos os aspectos da produção de software adotam uma
abordagem sistemática e organizada em seu trabalho, uma vez que essa é, com
frequência, a maneira mais eficaz de se produzir software.

Segundo afirma REZENDE (1999), Engenharia de Software é a
metodologia de desenvolvimento e manutenção de sistemas modulares, com as
características de adequação aos requisitos funcionais do negócio, efetivação de
padrões de qualidade e produtividade em suas atividades, fundamentação na
Tecnologia da Informação disponível, além de planejamento e gestão de atividades,
recursos e datas.

26

4.1.1 Cleanroom

Ainda segundo SOMMERVILLE (2003), o método Cleanroom é uma
filosofia de desenvolvimento que tem como base evitar defeitos de software pelo uso
de um rigoroso processo de inspeção. Seu nome deriva da analogia com as
unidades de fabricação de semicondutores. Nestas unidades os defeitos são
evitados por meio de uma atmosfera ultra limpa.

Este método possui cinco características principais:

 Especificação formal;

 Desenvolvimento Incremental;

 Programação estruturada;

 Verificação estática;

 Teste estatístico do sistema.

4.1.2 Métodos Ágeis

Segundo LEFFINGWELL (2003), nem sempre há uma disponibilidade
grande de tempo, de modo a permitir a estruturação de uma documentação
complexa e abrangente. Nesses casos, pode-se utilizar um método de
desenvolvimento ágil. Visando muito mais o acompanhamento e a evolução do
software, os métodos ágeis muitas vezes simplificam, ou mesmo se abstém de
alguns passos preliminares à codificação do projeto, otimizando seu
desenvolvimento por meio da constante interação com o usuário, além de diversas
metodologias de teste aplicadas.

4.1.3 XP – Extreme Programming

Segundo BECK (2004), Extreme Programming – XP, é uma metodologia
para desenvolvimento de software ágil, com qualidade e que atenda as
necessidades do cliente. Alguns praticantes definem a XP como a prática e a
perseguição da mais clara simplicidade, aplicado ao desenvolvimento de software.

27

Uma metodologia voltada para projetos cujos requisitos mudem com
frequência, utilizem desenvolvimento orientado a objetos, equipes de até 12
desenvolvedores e desenvolvimento incremental.

Figura 2 – Modelo de Processo Incremental – XP Fonte: infoescola.com

Já para TELES (2004), a XP é organizada em torno de um conjunto de
práticas e valores que atuam perfeitamente para assegurar um alto retorno do
investimento efetuado pelo cliente. A seguir serão apresentados os valores e em
seguida as práticas.

4.1.4 SCRUM

Segundo SCHWABER e SUTHERLAND (2010), Scrum vem sendo utilizado
para o desenvolvimento de produtos complexos desde o início dos anos 90, e é
fundamentado na teoria de controle de processos empíricos, empregando uma
abordagem iterativa e incremental para otimizar a previsibilidade e controlar riscos.

28

Figura 3 – Modelo Incremental - SCRUM Fonte: infoescola.com

Três pilares sustentam cada implementação de controle.

O primeiro pilar é a transparência, que visa garantir que aspectos do
processo que afetam o resultado devem ser visíveis para aqueles que gerenciam os
resultados.

O segundo pilar é a inspeção, afirmando que diversos aspectos do processo
devem ser inspecionados com uma frequência suficiente para que variações
inaceitáveis possam ser detectadas.

O terceiro pilar é a adaptação, que diz que, se o inspetor determinar, a partir
da inspeção, que um ou mais aspectos do processo estão fora dos limites aceitáveis
e que o produto resultante será inaceitável, ele deverá ajustar o processo ou o
material sendo processado.

4.2 Arquitetura de Software
Os grandes sistemas são sempre decompostos em subsistemas, que
fornecem algum conjunto de serviços relacionados. O processo inicial de projeto,
que consiste em identificar esses subsistemas e estabelecer um Framework para o
controle e a comunicação de subsistemas, é chamado de Projeto de Arquitetura, e a

29

saída desse processo de projeto é uma descrição da Arquitetura do Software.
(SOMMERVILLE, 2003)

Analisar e estabelecer formas de maximizar a eficiência de determinado
sistema em seu ambiente de implementação, este é o fundamento da Arquitetura de
Software, que se mostra imprescindível quando da união entre o Sistema e seu Meio
de Utilização. (REZENDE, 1999)

4.3 Linguagem de Programação
ANDRADRE (2007) afirma que a função das Linguagens de Programação
é servir de um meio de comunicação entre computadores e humanos.

Já para AMARIZ (2008) a linguagem de programação é uma forma de
determinarmos como um dispositivo deve trabalhar. É como se déssemos ordens
para esses dispositivos que podem ser simples, como por exemplo, um carregador
de pilhas ou mais complexos como um computador.

São veículos de comunicação entre os desenvolvedores de software,
devidamente munidos de seus conhecimentos e melhores práticas, e suas
máquinas. (REZENDE, 1999)

4.3.1 Java
Segundo PACIEVITCH (2011) Java é uma linguagem de programação
orientada a objetos que começou a ser criada em 1991, na Sun Microsystems. Teve
inicio com o Green Project, no qual os mentores foram Patrick Naughton, Mike
Sheridan, e James Gosling. Este projeto não tinha intenção de criar uma linguagem
de programação, mais sim de antecipar a “próxima onda” que aconteceria na área
da informática e programação.

Além da linguagem em si, Java possui uma rica biblioteca, que torna
possível escrever programas portáteis que podem driblar sistemas operacionais
proprietários. Contudo, você não pode esperar aprender tudo sobre Java em um
semestre. A linguagem contém um vasto conjunto de pacotes de biblioteca que são

30

necessários para se escrever programas úteis. Há pacotes para gráficos, projeto de
interfaces com o usuário, criptografia, redes, som, armazenamento de bancos de
dados e muitos outros propósitos. O ideal é se concentrar nos pacotes que serão
utilizados no projeto a ser desenvolvido. HORSTMANN (2005)

4.3.2 PHP
Segundo PACIEVITCH (2011), PHP tem código fonte disponível para
qualquer pessoa, sem custos. A licença de uso e edição é Open Source, ou seja,
ninguém pode comercializar qualquer versão modificada do PHP, e qualquer
modificação deve continuar com o código fonte aberto para os usuários explorarem e
modificarem. Este sistema de licença não traz lucro aos desenvolvedores, pois estes
disponibilizam tudo para o publico gratuitamente, e o publico, por sua vez, ajuda
reportando erros e ajudando a modificar o código fonte.

Muitas empresas apoiam os desenvolvedores do PHP, pois estes não
visam lucro ao criarem e desenvolverem o programa. O PHP é muito usado com o
Linux e o MySQL, dois outros programas Open Source.

Já segundo CONVERSE (2001), diferente de páginas de servidor Java ou
CGI baseado em C, o PHP não exige que você possua uma compreensão profunda
das mais importantes linguagens de programação antes de poder criar um banco de
dados trivial. Diferentemente do Perl, o PHP tem uma sintaxe fácil de analisar
sintaticamente e amigável a humanos. E, diferentemente do Active Server Pages -
ASP, o PHP não obriga você a aprender duas linguagens de programação diferentes
para ocasiões diferentes.

Além disso, muitas das mais úteis funções específicas, como abrir uma
conexão com um banco de dados, ou com um servidor de IMAP, são pré-definidas.
Para tornar-se proficiente em PHP, você precisa estar à vontade para editar HTML
manualmente, pois nem todos os editores de PHP são “arrastar e soltar”, muitas
vezes é necessário lidar com o código puro.

31

4.3.3 ASP
Segundo AMARIZ (2011), Active Server Pages (ASP) é uma linguagem
para geração de páginas HTML dinamicamente.

A partir de um Windows NT Server com o IIS3 ou IIS4 (Internet
Information Server) instalado, é possível rodar códigos que geram páginas HTML
dinamicamente, e então, mandá-las para o Browser. Assim sendo, sempre que uma
página ASP for requisitada pelo Browser, esta página será executada pelo servidor.

A linguagem ASP não serve apenas para consultas a banco de dados.
Serve também para envio e recebimento de correio eletrônico via páginas HTML,
para criação de rotinas de propaganda rotativa, para identificação e autenticação de
usuários, para leitura de arquivos texto e uma infinidade de outras aplicações.

Apesar destas vantagens, conclui-se que a utilização do ASP não seria
viável. Devido à definição de escopo do projeto, a integração entre módulos não
seria facilitada por esta linguagem.

4.4 Banco de Dados
Segundo AMARIZ (2010), para armazenar um dado, é necessário criar
tabelas, dentro das tabelas são criadas colunas, onde as informações são
armazenadas. Para os dados da base de dados ficarem organizados, devem ser
criadas tabelas que não misturem informações.

Os comandos utilizados para consultar as informações armazenadas
variam de um SGBD para o outro. Embora a linguagem utilizada, a SQL, seja a
mesma, comandos para declarar tipos de campo, consultar determinadas
informações com junções entre tabelas, dentre outros, varia entre os diferentes
SGBD's.

Superficialmente, pode-se dizer que Orientação a Objetos corresponde à
organização de sistemas como uma coleção de objetos que integram estruturas de

32

dados e comportamento. Além desta noção básica, a abordagem inclui certo número
de conceitos, princípios e mecanismos que a diferenciam das demais.

Abstração é a consideração apenas das propriedades comuns de um
conjunto de objetos, omitindo os detalhes, utilizada com frequência na definição de
valores similares e na formação de um tipo a partir de outro, em diferentes níveis de
abstração.

Os Objetos são abstrações de dados do mundo real, com uma interface
de nomes de operações e um estado local que permanece oculto. As abstrações da
representação e das operações são ambas suportadas no modelo de dados
orientado a objetos, ou seja, são incorporadas as noções de estruturas de dados e
de comportamento.

Identidade de Objeto conceitua que, num modelo com identidade de
objetos, estes têm existência independente de seus valores correntes e dos
endereços de armazenamento físico. A identidade do objeto é geralmente gerada
pelo sistema.

Os Objetos Complexos são formados por construtores (conjuntos, listas,
tuplas, registros, coleções, arrays) aplicados a objetos simples (inteiros, booleanos,
strings). Nos modelos orientados a objetos, os construtores são em geral ortogonais,
isto é, qualquer construtor pode ser aplicado a qualquer objeto.

O Encapsulamento possibilita a distinção entre a especificação e a
implementação das operações de um objeto, além de prover a modularidade que
permite uma melhor estruturação das aplicações ditas complexas, bem como a
segurança dentro do sistema.

Um Conjunto de Objetos que possui o mesmo tipo (atributos,
relacionamentos, operações) pode ser agrupado para formar uma classe. A noção
de classe é associada ao tempo de execução, podendo ser vista como uma
representação por extensão, enquanto que o tipo é uma representação intencional.

33

Herança é um mecanismo que permite ao usuário definir tipos de forma
incremental, por refinamento de outros já existentes, permitindo composição de tipos
em que as propriedades de um ou mais tipos são reutilizadas na definição de um
novo tipo. De fato, ela corresponde a transferência de propriedades estruturais e de
comportamento de uma classe para suas subclasses.

Em sistemas Polimórficos uma mesma operação pode se comportar de
diferentes formas em classes distintas. Como exemplo tem o operação “print” que
será implementada de forma diferente se o objeto correspondente for um texto ou
uma imagem: dependendo do objeto teremos um tipo de impressão. Tem-se também
polimorfismo quando ocorre a passagem de diferentes tios de objetos como
parâmetros enviados a outros objetos.

Segundo REZENDE (1999), existe dois tipos diferentes de registros
tratados por software: O registro lógico e o registro físico, que é o grupamento de
registros lógicos, economizando espaço e tempo de pesquisa, condensando a
gravação.

4.4.1 Oracle
Para PACIEVITCH (2000), Oracle é um sistema de banco de dados que
surgiu no final dos anos 70, criado por Larry Ellison. Visava desde o início ser um
banco de dados relacional, o que, na época ainda não havia sido feito por nenhuma
outra empresa de Bancos de Dados.

Um banco de dados relacional segue o Modelo Relacional de
comportamento, ou seja, a organização dos dados armazenados se baseia na
relação entre as tabelas que os contém. A arquitetura de um banco de dados
relacional pode ser descrita de maneira informal ou formal. Na descrição informal o
foco está em aspectos práticos da utilização e utilizam-se os termos TABELA, LINHA
e COLUNA. Já na descrição formal prioriza-se a semântica formal do modelo e os
termos utilizados são RELAÇÃO (tabela), TUPLA (linhas) e ATRIBUTO (coluna).

34

4.4.2 PostgreSQL
Segundo EISENTRAUT (2011), PostgreSQL é um sistema de bancos de
dados relacional poderoso e de código aberto. Ele possui mais de 15 anos de
desenvolvimento ativo e uma arquitetura que ganhou uma forte reputação e
confiabilidade e integridade dos dados.

Ele é suportado pela maioria dos sistemas operacionais, incluindo Linux,
UNIX (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64), e Windows. Possui
suporte completo para chaves estrangeiras, joins, visões, gatilhos, e procedimentos
armazenados (em multiplas linguagens).

Inclui a maior parte dos tipos de dados SQL:2008, incluindo INTEGER,
NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, E TIMESTAMP.

Também suporta o armazenamento de grandes objetos binários, incluindo
imagens, audio e video. Possui interfaces nativas para programação em C/C++,
Java, .Net, Perl, Python, Ruby, Tcl, ODBC, dentre outras, e uma documentação
excepcional.

4.4.3 MySQL
Para PACIEVITCH (2010), esse SGBD possui interface simples, e também
a capacidade de rodar em vários sistemas operacionais, o que são alguns dos
motivos para este programa ser tão usado atualmente.

O MySQL é protegido por uma licença de software livre, desenvolvida pela
GNU. É também um dos programas que vem geralmente instalado com o
GNU/Linux.

O banco de dados MySQL se tornou a base de dados mundial de código
aberto mais popular por causa de seu alto desempenho, alta confiabilidade e
facilidade de uso

35

O MySQL funciona em mais de 20 plataformas, incluindo Linux, Windows,
Mac, Solaris, HP-UX, IBM AIX, dando-lhe o tipo de flexibilidade que coloca você no
controle. Se você é novo na tecnologia de banco de dados ou um desenvolvedor
experiente ou DBA, MySQL oferece uma gama abrangente de ferramentas de banco
de dados, suporte, treinamento e serviços de consultoria para fazer sucesso.

Já segundo CONVERSE (2001), o MySQL não disponibiliza a maioria dos
recursos sofisticados oferecidos pela PostgreSQL ou Oracle, contudo, para
aplicações de menor porte e mais simples ele é simplesmente ideal, principalmente
se utilizado juntamente ao PHP e a plataforma Linux.

4.5 RUP (Rational Unified Process)
Para MARTINEZ (2010), o Processo Unificado da Rational conhecido
como RUP (Rational Unified Process), é um processo de engenharia de software
criado para apoiar o desenvolvimento orientado a objetos, fornecendo uma forma
sistemática para se obter vantagens no uso da UML. Foi criado pela Rational
Software Corporation e adquirido em fevereiro de 2003 pela IBM.

O principal objetivo do RUP é atender às necessidades dos usuários
garantindo uma produção de software de alta qualidade que cumpra um cronograma
e um orçamento previsíveis. Assim, o RUP mostra como o sistema será construído
na fase de implementação, gerando o modelo do projeto e, opcionalmente, o modelo
de análise que é utilizado para garantir a robustez. O RUP define perfeitamente
quem é responsável pelo que, como as coisas deverão ser feitas e quando devem
ser realizadas, descrevendo todas as metas de desenvolvimento especificamente
para que sejam alcançadas.

36

Figura 4 – Fases do RUP Fonte: infoescola.com

4.5.1 Desenvolvimento Iterativo
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que
consiste em várias iterações, atribuindo a ele um caráter evolucionário. Desta forma
deve haver diversas interações com o cliente, ou usuário final, posto que este deve
validar cada uma das iterações, garantindo que o projeto esteja atendendo suas
necessidades e se aplicando ao seu negócio.

No desenvolvimento Iterativo a documentação do projeto não é o foco
principal da equipe, tendo em vista importância da agilidade em seu
desenvolvimento.

4.5.2 Fases do RUP
MARTINEZ (2010), explica que o RUP organiza o desenvolvimento de
software em quatro fases, onde são tratadas questões sobre planejamento,
levantamento de requisitos, análise, implementação, teste e implantação do
software. Cada fase tem um papel fundamental para que o objetivo seja cumprido,

37

distribuídos entre vários profissionais como o Analista de sistema, Projetista,
Projetista de testes, entre outros.

4.5.2.1 Concepção
Ainda segundo MARTINEZ (2010), a fase de Concepção abrange as
tarefas de comunicação com o cliente e planejamento. São feito um plano de projeto
avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as
prioridades, levantamento dos requisitos do sistema e preliminarmente analisá-lo.

Assim, haverá uma anuência das partes interessadas na definição do
escopo do projeto, onde são examinados os objetivos para se decidir sobre a
continuidade do desenvolvimento.

4.5.2.2 Elaboração
MARTINEZ (2010) segue esclarecendo que esta fase abrange a
Modelagem do modelo genérico do processo. O objetivo desta fase é analisar de
forma mais detalhada a análise do domínio do problema, revisando os riscos que o
projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica.
Indagações como “O plano do projeto é confiável?”, “Os custos são admissíveis?”
são esclarecidas nesta etapa.

4.5.2.3 Construção

Esta fase desenvolve ou Adquire os componentes de Software. O principal
objetivo desta fase é a construção do sistema de software, com foco no
desenvolvimento de componentes e outros recursos do sistema. É na fase de
Construção que a maior parte de codificação ocorre.

4.5.2.4 Transição

MARTINEZ (2010) finaliza mostrando que esta fase abrange a entrega do
software ao usuário e a fase de testes. O objetivo desta fase é disponibilizar o
sistema, tornando-o disponível e compreendido pelo usuário final. As atividades

38

desta fase incluem o treinamento dos usuários finais e também a realização de
testes da versão beta do sistema visando garantir que o mesmo possua o nível
adequado de qualidade.

4.6 UML (Unified Model Language)

Conforme SOMMERVILLE (2003) a Linguagem Unificada de Modelagem é
uma linguagem padrão para modelagem orientada a objetos. Tem como papel
auxiliar a visualizar o desenho e a comunicação entre objetos.

Ela permite que desenvolvedores visualizem os produtos de seu trabalho
em diagramas padronizados, e é utilizada para criar modelos de sistemas de
software.

Utiliza-se de um conjunto de técnicas de notação gráfica para criar
modelos visuais de software de sistemas intensivos, combinando as melhores
técnicas de modelagem de dados, negócios, objetos e componentes.

É uma linguagem de modelagem única, comum e amplamente utilizável no
atual paradigma de Orientação a Objetos, que tem substituído gradualmente a
metodologia Estruturada..

A UML possui dois tipos de diagramas. São eles:

1. Diagramas Estruturais:

 De Classe;

 De Objeto;

 De Componentes;

 De Implantação;

 De Pacotes;

 De Estrutura;

39

2. Diagramas Comportamentais

 De Casos de Uso;

 De Máquina de Estados;

 De Atividades;

 De Interação;

4.7 Information Technology Infrastructure Library – ITIL

Segundo MARTINEZ (2010) ITIL é a abordagem mais amplamente
adotada para Gerência de Serviços em TI no Mundo. Ela proporciona uma
plataforma prática e intuitiva para identificar, planejar, entregar e manter serviços de
TI para o Negócio.

ITIL assume que serviços de TI devem estar alinhados às necessidades
do negócio, e deve estar ligada ao núcleo dos processos do Negócio.

Oferece guias para organizações sobre como utilizar a TI como uma
ferramenta para facilitar a mudança, a transformação e o crescimento do Negócio.

As Melhores Práticas da ITIL são detalhadas em cinco publicações
principais, que permitem uma abordagem sistemática e profissional à gerência de
serviços em TI. Estas cinco publicações mapeiam o Ciclo de Vida do serviço ITIL,
começando pela identificação das necessidades do cliente e requerimentos de TI,
passando pelo Design e implementação do serviço para a operação, até finalmente
às fases de Monitoramento e Melhoria do serviço.

40

5 Proposta do Novo Sistema

A utilização das capacitações técnicas e gerenciais que resultem em
inovações de processo, produto, organização da produção e novas formas de
comercialização influenciarão toda a cadeia produtiva e permitirá à empresa
sustentar sua posição no mercado (MARIANO e DIAS, 1996).

Com base nas palavras de Mariano e Dias trabalhamos o SISEDU de forma a
maximizar estes aspectos, sendo assim, unificaremos a base de dados a fim de
reduzir toda, ou em sua maioria, a redundância de dados. Trabalharemos o sistema
de forma a atender aos três níveis: operacional, nível do conhecimento e nível
gerencial.

Todo o sistema deverá se comunicar com esses níveis propostos, de forma
que, para cada nível, se destacam funcionalidades distintas.

5.1 Descrição do Sistema Proposto
A proposta do presente trabalho é criar um sistema informatizado baseado na
web que trabalhe em três frentes.

A intranet funcionará da seguinte forma: todo e qualquer processo, e assume-
se como processo qualquer ação efetuada pelo usuário no sistema, deverá ser feito
posteriormente a uma identificação do usuário, ou seja, login e senha.

O acesso será local e restrito às dependências físicas da instituição. O
usuário só poderá acessar as funcionalidades da intranet se estiver logado na rede
física da faculdade ABC.

A intranet conterá a maioria das funcionalidades do sistema, visto que por
motivo de segurança a maioria dos processos deverá ser feita dentro de uma rede
segura.

41

Nessa frente teremos a classificação por perfis, ou seja, cada usuário deverá
ter um perfil que possibilitará o acesso apenas às funcionalidades que lhe sejam
relevantes. Esses perfis serão baseados nos papéis: aluno, professor, funcionário e
seus níveis, coordenador e gerência e seus níveis. Deve-se observar que os perfis
poderão ser ampliados à medida que houver necessidade para tal.

Quanto a exemplos dos processos que poderão ser demandados a partir da
Intranet do SISEDU, os próximos capítulos mostram-nos em detalhes.

Módulo Ano Letivo:
 Manter cadastro de Ano Letivo / semestre
 Manter matrícula aluno (com tipo de Contrato)
 Manter histórico escolar aluno
 Manter pauta
 Manter ementa da Disciplina
 Manter presença de alunos
 Manter turmas

A Extranet é a segunda frente na qual o SISEDU poderia atuar, neste
ambiente serão trabalhadas as funcionalidades para as quais o usuário não terá
necessidade de estar logado na rede física, mas apenas no sistema, para operar.

A extranet do SISEDU sugere trabalhar basicamente com processos de
consulta e solicitações, e se volta principalmente para as funcionalidades que dizem
respeito os perfis de Professor e, em alguns casos, Coordenador.

Quanto aos processos passíveis de serem demandados a partir da extranet
do SISEDU, citam-se capítulos seguintes.

Módulo Ano Letivo:
 Lançamento de notas remotamente;
 Lançamento de Diários de Classe;

42

A página do SISEDU na internet poderá disponibilizar informações sobre a
instituição, além de divulgar os serviços oferecidos pela faculdade ABC. De forma
breve, se comportaria como uma Home Page para as demais frentes de trabalho, é
através dela que seriam efetuados os “login”.

A página da faculdade ABC conterá todo o conteúdo informativo da faculdade
e estará disponível para toda forma de consulta.

5.2 Resultados Esperados
O sistema utilizará a intranet da empresa na maioria das suas
funcionalidades. Estará disponível em todos os terminais, facilitando o acesso por
parte dos docentes. Em outra forma se utilizará da extranet com finalidade de
consultas e solicitações e contará com uma pagina para divulgação e como acesso
principal. É esperado que o sistema consiga desempenhar os diversos processos e
funcionalidades propostas, bem como manter uma base solida e confiável. O
controle de acessos será feito por login e perfis pré definidos.

5.3 Restrições do sistema proposto
Ao final do projeto, o sistema estará disponível em sua versão beta, o que
indica que deverá haver mudanças em sua estrutura. De forma que tais alterações
não interfiram nas regras propostas.

O sistema será preparado para futuramente vir a contemplar um portal web,
mas para tal deverá haver estudos de viabilidade.

5.4 Relação Custo x Benefícios: Análise de Viabilidade Econômica do
Novo Sistema
O custo para o desenvolvimento desse projeto será, a princípio, viável, pois o
sistema será completamente desenvolvido pelos acadêmicos em parceria com o
corpo docente da faculdade ABC.

43

5.5 Áreas Afetadas Pelo Novo Sistema

Toda a faculdade ABC será afetada diretamente, uma vez que o sistema tem
como proposta unificar todos os processos acadêmicos, administrativos e financeiros
da instituição. As áreas mais afetadas quando da ativação desse sistema serão:
departamento Administrativo; departamento Financeiro; departamento de
Informática; além de toda a área acadêmica e gerência.

44

6 Documentação de Análise

“O engenheiro de software amador está sempre à procura da mágica, de
algum método sensacional ou ferramenta cuja aplicação promete tornar
trivial o desenvolvimento de software. É uma característica do engenheiro
de software profissional saber que tal panacéia não existe” - Grady Booch

6.1 Visão Macro dos Atores

O ator representa qualquer entidade que interage com o sistema durante sua
execução essa interação se dá através de comunicações, ou seja solicitações
consultam execuções de processos. Um ator pode ser uma pessoa (gestor,
secretaria, aluno, professor...), um dispositivo (impressora, máquina...), hardware
(placa de modem, scaner...), softwares (sistema de BD, aplicativos...), etc. Algumas
de suas características são: ator não é parte do sistema. Representa os papéis que
o usuário do sistema pode desempenhar; ator pode interagir ativamente com o
sistema; ator pode ser um receptor passivo de informação e, ator pode representar
um ser humano, uma máquina ou outro sistema (MACORATTI, 2010).

Para o trabalho desenvolvido, serão propostos seis atores: Administrador,
diretor, coordenador, funcionário, professor e alunos.

6.2 Identificação dos Atores

A lista de ator – objeto é o ponto inicial da negociação entre o usuário
representativo, o responsável financeiro e o grupo de desenvolvimento.
(COCKBURN, 2005)

A lista enumera todos os objetivos que o sistema irá suportar, mostrando o
conteúdo funcional do sistema. (COCKBURN, 2005)

Dentre os quais citamos como atores:

45

1. Administrador
2. Diretor
3. Coordenador
4. Funcionário
5. Professor
6. Aluno

Administrador, responsável por controle geral do sistema. Esse ator terá
acesso a todos os processos e procedimentos da empresa.

Diretor, responsável por controlar todas as liberações de perfis e acessos.

Coordenador, responsável pela administrar funcionalidades e processos de
todo o setor acadêmico do sistema.

Funcionário, perfil de funcionalidades equivalentes ao do coordenador com
funcionalidades destinadas as suas áreas.

Professor, funcionalidades pré definidas somente as funcionalidades que
dizem respeito ao controles de turmas disciplinas e cursos.

Alunos, funcionalidade restrita a consultas e solicitações.

6.3 Listas de Casos de Uso

Um caso de uso descreve um objetivo que um ator externo ao sistema tem
com o sistema. Um ator pode ser um elemento humano ou não que interage com o
sistema. O ator se encontra fora do escopo de atuação do sistema, enquanto o
conjunto de casos de uso forma o escopo do sistema. A linha que separa os atores
dos casos de uso é a fronteira do sistema (SILVA , 2007).

Escrever casos de uso como um meio de capturar os requisitos
comportamentais de sistemas de software e processos organizacionais é uma

46

prática que está ganhando popularidade rapidamente. Casos de uso é um auxílio
importante no planejamento de projeto porque mostram claramente como as
pessoas, no final das contas, usarão o sistema que está sendo
desenvolvido.(COCKBURN, 2005)

No trabalho descrito foram utilizados nove casos de uso conforme descrito na
tabela 2:
Tabela 2 – Casos de Uso

UC01 Manter Cadastro do Períodos

UC02 Manter Ementa

UC03 Manter Avaliação

UC04 Manter Histórico Escolar Aluno

UC05 Manter Matrícula

UC06 Manter Turma

UC07 Manter Grade Horária

UC08 Manter Calendário

UC09 Manter Pauta

UC10 Enturmação

UC11 Manter Matricula Disciplina

6.4 Diagrama de Caso de Uso

Segundo JACOBSON, podemos dizer que um Caso de Uso é um "documento
narrativo que descreve a sequência de eventos de um ator que usa um sistema para
completar um processo". Um Caso de Uso representa uma unidade discreta da
interação entre um usuário (humano ou máquina) e o sistema. Um Caso de Uso é
uma unidade de um trabalho significante.

Cada Caso de Uso tem uma descrição da funcionalidade que irá ser
construída no sistema proposto. Um Caso de Uso pode "usar" outra funcionalidade
de Caso de Uso ou "estender" outro Caso de Uso com seu próprio comportamento.

47

Casos de Uso são tipicamente relacionados a "atores". Um ator é um humano
ou entidade máquina que interage com o sistema para executar um significante
trabalho.

Na figura 5, está a representação do diagrama de caso de uso do módulo
descrito no presente Trabalho de Conclusão de Curso.

Figura 5 – Diagrama de Caso de Uso

48

6.5 Descrição detalhada dos Casos de Uso

UC01 – Manter Períodos

Tabela 3 – Caso de Uso UC01 – Manter Períodos
Nome UC01 – Manter Períodos
Objetivo Realizar cadastro do Períodos
Atores Funcionário
Dados
Ano e semestre
Consumidos
Dados
Período letivo
Produzidos
Prioridade Alta
Pré-condições Possuir autorização e perfil de acesso
Pós-condições
Fluxo Principal
O UC01 tem início quando o Ator acessa a opção de menu Períodos
Ator Sistema
Mostra menu secundário com as opções:
[ADICIONAR NOVO] [PESQUISAR]
Mostra campos a serem preenchidos e o
Clica [ADICIONAR NOVO]
botão [ADICIONAR]
Preenche campos com informação
ano e
Semestre letivo.
Perguntar a confirmação da inserção dos
Clica em [ADICIONAR]
dados e o botão [CONFIRMA]
Sistema grava informações cadastradas
Clica [CONFIRMA]
no banco de dados
Fluxo Alternativo 1
Ano/Semestre letivo já existe
Ator Sistema
Após digitado informações do
ano/semestre letivo
O sistema verifica se já existe no banco
de dados
Caso já exista ano/semestre letivo
cadastrado
O sistema mostra erro “ano/semestre
letivo já cadastrado”, e um botão
[VOLTAR].
Sistema retorna a pagina de cadastro
Clica [VOLTAR]
na/semestre letivo.
Fluxo Alternativo 2
Pesquisar
Ator Sistema
Mostra campos ano e semestre letivo e o
Clica [PESQUISAR]
botão [BUSCAR]
Clica [BUSCAR] Em uma tela de pesquisa o sistema

49

mostra resultados obtidos seguidos dos
botões [EXCLUIR] [EDITAR] e no final
da Pesquisa o Botão [VOLTAR]
Fluxo Alternativo 3
Pesquisar = 0
Ator Sistema
Clica [PESQUISAR]
botão [BUSCAR]
Mostra “nenhum resultado encontrado”
Clica [BUSCAR]
e no final da Pesquisa o Botão [VOLTAR]
Clica resultado [VOLTAR] Sistema retorna a tela de pesquisa.
Fluxo Alternativo 4
Editar
Ator Sistema
clica [EDITAR] ao lado do resultado Mostra campos a serem editados e o
obtido botão [ALTERAR]
Altera os campos necessários
Sistema valida as informações inseridas
Clica [ALTERAR] Perguntar a confirmação da alteração e
Botão [CONFIRMA]
Sistema grava informações alteradas no
Clica [CONFIRMA]
banco de dados
Sistema retorna a tela de resultado de
pesquisa.
Fluxo Alternativo 5
Erro: Editar
Ator Sistema
Clica [EDITAR] ao lado do resultado Mostra campos a serem editados e o
Altera os campos necessários com
Sistema não valida as informações
dados Incompatíveis com o aceito
inseridas
pelo sistema
Clica [ALTERAR]
inseridas
Sistema retorna mensagem de erro
apresenta frase: “dados inserido
incorretamente” e o botão
[VOLTAR]
Clica [VOLTAR]
pesquisa.
Fluxo Alternativo 6
Excluir
Ator Sistema
Perguntar a confirmação da exclusão e o
Clica [EXCLUIR] ao lado do resultado obtido
botão [CONFIRMAR]
Sistema grava informações alteradas no
Clica [CONFIRMAR]
banco de dados
Retorna uma tela “dados excluído com
sucesso” E o botão [OK]

50

Clica [OK]
pesquisa.

UC02 – Manter Ementa

Tabela 4 – Caso de Uso UC02 – Manter Ementa
Nome UC02 – Manter Ementa
Objetivo Realizar inserção de ementa de disciplina no banco de dados.
Atores Coordenador
Dados
Arquivos de ementa
Consumidos
Dados
Produzidos
Prioridade Média
Pós-condições
Fluxo Principal
O UC02 tem início quando o Ator acessa a opção de menu Ementa
Ator Sistema
[INCLUIR] [PESQUISAR]
Mostra campo para inclusão e botões:
Clica [INCLUIR] [LOCALIZAR ARQUIVO]
[ENVIAR ARQUIVO]
Clica [LOCALIZAR ARQUIVO] e
seleciona o arquivo PDF de sua
estação de trabalho.
Clica [ENVIAR ARQUIVO]
no banco de dados
Sistema retorna a pagina de Ementa.
Fluxo Alternativo 1
Arquivo já existe
Ator Sistema
Após confirmado envio do arquivo o
sistema verifica se já existe arquivo com
mesmo nome no banco de dados
Caso já exista o sistema mostra erro
“arquivo já cadastrado”, e um botão
[VOLTAR]
Clica [VOLTAR] Sistema retorna a pagina de Ementa.
Fluxo Alternativo 2
Pesquisar
Ator Sistema
Mostra campos disciplina e o botão
Clica [PESQUISAR]
[BUSCAR]
Em uma tela de pesquisa o sistema
Clica [BUSCAR]

51

botões [EXCLUIR] e no final da Pesquisa
o Botão [VOLTAR]
Fluxo Alternativo 3
Pesquisar = 0
Ator Sistema
Clica [PESQUISAR]
botão [BUSCAR]

Mostra “nenhum resultado encontrado” e
Clica [BUSCAR]
no final da Pesquisa o Botão [VOLTAR]


Fluxo Alternativo 4
Excluir
Ator Sistema

Perguntar a confirmação da exclusão e o botão
Clica [EXCLUIR] ao lado do resultado obtido
[CONFIRMAR]

Sistema grava informações alteradas no banco
Clica [CONFIRMAR]
de dados
Retorna uma tela “dados excluído com
sucesso” E o botão [OK]
Clica [OK]
pesquisa.

UC03 – Manter Avaliação

Tabela 5 – Caso de Uso UC03 – Manter Avaliação
Nome UC03 – Manter Avaliação
Objetivo Lançar notas da Avaliação do anosemestre letivo
Atores Professor
Dados
notas
Consumidos
Dados
Produzidos
Prioridade Alta
Pós-condições
Fluxo Principal
O ator inicia selecionando a opção lançar notas no menu Avaliação do Aluno
Ator Sistema
[LANÇAR NOTAS] [EDITAR]
[PESQUISAR]

52

Mostra campos a serem preenchidos:
Clica [LANÇAR NOTAS] “ano/semestre letivo, turma, disciplina.
E um botão [AVANÇAR]
Mostra relação de alunos matriculados
Preenche campos com informação: no ano, Semestre turma e disciplinas
”ano/semestre letivo, turma, disciplina. respectivos, com Campos para
E clica no botão [AVANÇAR] lançamento das notas por aluno.
e um botão [AVANÇAR].
Perguntar a confirmação da inserção e
Lança as notas e clica no botão [AVANÇAR]
um botão [CONFIRMAR]
Clica [CONFIRMAR]
no banco de dados.
Sistema retorna a pagina de Avaliação do
Aluno
Fluxo Alternativo 1
Dados de notas já lançados
Ator Sistema
Após digitado informações “ano/semestre
letivo, turma, disciplina
O sistema verifica se já existe no banco de
dados
Caso já exista notas relacionadas a
“ano/semestre letivo, turma, disciplina
digitados
O sistema mostra erro “notas já
cadastradas”, e botões [VOLTAR]
[EDITAR]
Sistema retorna a pagina de Avaliação do
Clica [VOLTAR]
Aluno
Fluxo Alternativo 2
Pesquisar
Ator Sistema
Mostra campos ano/semestre letivo,
Clica [PESQUISAR]
turma, disciplina e o botão [BUSCAR]
Em uma tela de pesquisa o sistema
Clica [BUSCAR]
botões [EXCLUIR] [EDITAR] e no final da
Pesquisa o Botão [VOLTAR]
Fluxo Alternativo 3
Pesquisar = 0
Ator Sistema
Clica [PESQUISAR] botão
[BUSCAR]
Mostra “nenhum resultado encontrado”
Clica [BUSCAR]
e no final da Pesquisa o Botão [VOLTAR]
Fluxo Alternativo 4
Editar

53

Ator Sistema
clica [EDITAR] ao lado do resultado Mostra campos a serem editados e o
Altera os campos necessários
Sistema valida as informações inseridas
Clica [ALTERAR] Perguntar a confirmação da alteração e
botão [CONFIRMA]
Sistema grava informações alteradas no banco
Clica [CONFIRMA]
de dados
pesquisa.
Fluxo Alternativo 5
Erro: Editar
Ator Sistema
Clica [EDITAR] ao lado do resultado Mostra campos a serem editados e o
Altera os campos necessários com
dados Incompatíveis com o aceito pelo
inseridas
sistema
Clica [ALTERAR]
inseridas
Sistema retorna mensagem de erro
apresenta frase: “dados inserido
incorretamente” e o botão [VOLTAR]
Clica [VOLTAR]
pesquisa.

UC04 – Manter Histórico Escolar
Tabela 6 – Caso de Uso UC04 – Histórico Escolar
Nome UC04 – Histórico Escolar
Objetivo Emitir o Histórico Escolar
Atores Funcionário
Dados
Matrícula do Aluno
Consumidos
Dados
Relatório constituindo o Histórico Escolar
Produzidos
Prioridade Alta
Pós-condições
Fluxo Principal
O UC04 tem início quando o Ator acessa a opção de menu Histórico Escolar
Ator Sistema
Mostra menu secundário com a opção:

Sistema de Informação para Gestão Acadêmica

Sistema de Informação para Gestão Acadêmica

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (8)

Similaire à Sistema de Informação para Gestão Acadêmica

Similaire à Sistema de Informação para Gestão Acadêmica (20)

Plus de UNIEURO

Plus de UNIEURO (12)

Sistema de Informação para Gestão Acadêmica