sisedu – sistema educacional - módulo ano letivo

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

Afonso Alves Ribeiro 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.

Afonso Alves Ribeiro

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

../../Documents/sumario.xlsx#RANGE!_Toc310377518
























































































































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

Ano 2011 Defin

içã

o d

o P

rob

lem

a

Delim

itaçã

o d

o T

em

a

Pe

sq

uis

a B

iblio

grá

fica

Le

van

tam

en

to T

eó

rico

Defin

içã

o d

a m

eto

do

log

ia

Pla

ne

jam

en

to d

e A

çõ

es

Le

van

tam

en

to d

e R

eq

uis

ito

s

An

ális

e (

de

f. c

aso

s d

e u

so

)

Escre

ve

r a

mon

og

rafia

Ap

resen

taçã

o T

CC

I

ace

rto

s a

pós A

pre

se

nta

çã

o T

CC

I Pro

jeto

Cod

ific

açã

o

Ap

resen

taçã

o d

a m

on

og

rafia

Ace

rtos a

pó

s a

pre

se

nta

çã

o

En

tre

ga

fin

al

Imp

lem

en

taçã

o

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.

24

MÊS ETAPAS

Ano 2011 De

fin

içã

o d

o P

rob

lem

a

De

limitaçã

o d

o T

em

a

Pe

sq

uis

a B

iblio

grá

fica

Le

van

tam

en

to T

eó

rico

De

fin

içã

o d

a m

eto

do

log

ia

Pla

ne

jam

en

to d

e A

çõ

es

Le

van

tam

en

to d

e R

eq

uis

ito

s

An

ális

e (

de

f. c

aso

s d

e u

so

)

Escre

ve

r a

mon

og

rafia

Ap

resen

taçã

o T

CC

I

ace

rto

s a

pós A

pre

se

nta

çã

o T

CC

I

Pro

jeto

Co

dific

açã

o

Ap

resen

taçã

o d

a m

on

og

rafia

Ace

rtos a

pó

s a

pre

se

nta

çã

o

En

tre

ga

fin

al

Imp

lan

taçã

o

Julho 1a.

2a.

3a.

4a.

Agosto 1a.

2a.

3a.

4a.

5a.

Setembro 1a.

2a.

3a.

4a.

Outubro 1a.

2a.

3a.

4a.

Novembro 1a.

2a.

3a.

4a.

5a.

Dezembro 1a.

2a.

3a.

4a.

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.

http://pt.wikipedia.org/wiki/Cleanroom

http://pt.wikipedia.org/wiki/Desenvolvimento_ágil_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 Consumidos

Ano e semestre

Dados Produzidos

Período letivo

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]

Clica [ADICIONAR NOVO] Mostra campos a serem preenchidos e o botão [ADICIONAR]

Preenche campos com informação ano e Semestre letivo.

Clica em [ADICIONAR] Perguntar a confirmação da inserção dos dados e o botão [CONFIRMA]

Clica [CONFIRMA] Sistema grava informações cadastradas 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].

Clica [VOLTAR] Sistema retorna a pagina de cadastro na/semestre letivo.

Fluxo Alternativo 2

Pesquisar

Ator Sistema

Clica [PESQUISAR] Mostra campos ano e semestre letivo e o 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 [BUSCAR] Mostra “nenhum resultado encontrado” 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 obtido

Mostra campos a serem editados e o botão [ALTERAR]

Altera os campos necessários

Clica [ALTERAR] Sistema valida as informações inseridas Perguntar a confirmação da alteração e Botão [CONFIRMA]

Clica [CONFIRMA] Sistema grava informações alteradas no banco de dados

Sistema retorna a tela de resultado de pesquisa.

Fluxo Alternativo 5

Erro: Editar

Ator Sistema

Clica [EDITAR] ao lado do resultado obtido


Altera os campos necessários com dados Incompatíveis com o aceito pelo sistema

Sistema não valida as informações inseridas

Clica [ALTERAR] Sistema não valida as informações inseridas

Sistema retorna mensagem de erro apresenta frase: “dados inserido incorretamente” e o botão [VOLTAR]

Clica [VOLTAR] Sistema retorna a tela de resultado de pesquisa.

Fluxo Alternativo 6

Excluir

Ator Sistema

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

Clica [CONFIRMAR] Sistema grava informações alteradas no banco de dados

Retorna uma tela “dados excluído com sucesso” E o botão [OK]

50

Clica [OK] Sistema retorna a tela de resultado de 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 Consumidos

Arquivos de ementa

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

Mostra menu secundário com as opções: [INCLUIR] [PESQUISAR]

Clica [INCLUIR] Mostra campo para inclusão e botões: [LOCALIZAR ARQUIVO] [ENVIAR ARQUIVO]

Clica [LOCALIZAR ARQUIVO] e seleciona o arquivo PDF de sua estação de trabalho.

Clica [ENVIAR ARQUIVO] Sistema grava informações cadastradas 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

Clica [PESQUISAR] Mostra campos disciplina e o botão [BUSCAR]

Clica [BUSCAR] Em uma tela de pesquisa o sistema mostra resultados obtidos seguidos dos

51

botões [EXCLUIR] e no final da Pesquisa o Botão [VOLTAR]

Fluxo Alternativo 3

Pesquisar = 0

Ator Sistema




Fluxo Alternativo 4

Excluir

Ator Sistema





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 ano\semestre letivo

Atores Professor

Dados Consumidos

notas

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

Mostra menu secundário com as opções: [LANÇAR NOTAS] [EDITAR] [PESQUISAR]

52

Clica [LANÇAR NOTAS] Mostra campos a serem preenchidos: “ano/semestre letivo, turma, disciplina. E um botão [AVANÇAR]

Preenche campos com informação: ”ano/semestre letivo, turma, disciplina. E clica no botão [AVANÇAR]

Mostra relação de alunos matriculados no ano, Semestre turma e disciplinas respectivos, com Campos para lançamento das notas por aluno. e um botão [AVANÇAR].

Lança as notas e clica no botão [AVANÇAR] Perguntar a confirmação da inserção e um botão [CONFIRMAR]

Clica [CONFIRMAR] Sistema grava informações cadastradas 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]

Clica [VOLTAR] Sistema retorna a pagina de Avaliação do Aluno

Fluxo Alternativo 2

Pesquisar

Ator Sistema

Clica [PESQUISAR] Mostra campos ano/semestre letivo, turma, disciplina e o botão [BUSCAR]

Clica [BUSCAR]

Em uma tela de pesquisa o sistema 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




Fluxo Alternativo 4

Editar

53

Ator Sistema




Clica [ALTERAR] Sistema valida as informações inseridas Perguntar a confirmação da alteração e botão [CONFIRMA]



Fluxo Alternativo 5

Erro: Editar

Ator Sistema








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 Consumidos

Matrícula do Aluno

Dados Produzidos

Relatório constituindo o Histórico Escolar

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:

54

[CONSULTAR POR MATRÍCULA]

Informa o número da matrícula e clica [CONSULTAR POR MATRÍCULA]

Mostra o nome do aluno, curso, semestre e turma e o botão [GERAR HISTÓRICO]

Clica em [GERAR HISTÓRICO]

Gera, em uma nova tela, um relatório com as informações de presença e notas das avaliações do aluno, consultadas na tabela Pauta e na tabela Avaliação

Fluxo Alternativo 1

Matrícula não encontrada

Ator Sistema

Após informada a matrícula do aluno, o sistema verifica se existe um registro com aquela matrícula no Banco de Dados

Caso não exista um aluno cadastrado com aquela matrícula, o sistema mostra erro “aluno não encontrado”, e um botão [VOLTAR].

Clica [VOLTAR] Sistema retorna a pagina de geração de histórico escolar.

UC05 – Manter Matrícula

Tabela 7 – Caso de Uso UC05 – Manter Matrícula

Nome UC05 – Manter

Objetivo Matricular alunos em uma turma

Atores Funcionário

Dados Consumidos

Ano, semestre, turma

Dados Produzidos

Período letivo

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo previamente cadastrado Turma previamente cadastrada Aluno estar em conformidade com a instituição de ensino

Pós-condições

Fluxo Principal

O UC01 tem início quando o Ator acessa a opção de menu matricular aluno

Ator Sistema

Mostra menu secundário com as opções: [MATRICULAR] [PESQUISAR]

Clica [MATRICULAR] Mostra campos matricula e nome e um Botão [BUSCAR]

Clica [BUSCAR] Busca na base de dados informação sobre aluno:

55

Se o aluno já for um veterano o sistema mostra Dados do semestre anterior

Mostra na pagina dados do aluno buscados na Base, além de campos: ano e semestre letivo, Turma a serem alterados. E o botão [ADICIONAR]

altera campos com informação ano e Semestre letivo e turma



Sistema retorna a pagina de matricular aluno

Fluxo Alternativo 1

Aluno novo (calouro)

Ator Sistema



Clica [BUSCAR]

Busca na base de dados informação sobre aluno: Se o aluno for um calouro o sistema mostra Dados ano e semestre letivo, Turma em branco.

Mostra na pagina dados do aluno buscados na Base, além de campos: ano e semestre letivo, Turma a serem alterados. E o botão [ADICIONAR]

Preenche campos com informação ano e Semestre letivo e turma




Fluxo Alternativo 2

Aluno já matriculado

Ator Sistema

Após digitado informações do aluno O sistema verifica se já existe no banco de dados

Caso já exista registro do aluno no semestre atual cadastrado

56

O sistema mostra erro “aluno já cadastrado”, e um botão [VOLTAR].


Fluxo Alternativo 2

Pesquisar

Ator Sistema

Clica [PESQUISAR] Mostra campos ano e semestre letivo matricula do aluno e nome do aluno e o botão [BUSCAR]

Clica [BUSCAR]


Fluxo Alternativo 3

Pesquisar = 0

Ator Sistema




Fluxo Alternativo 4

Editar

Ator Sistema





Clica [CONFIRMA] Sistema grava informações alteradas no Banco de dados


Fluxo Alternativo 5

Erro: Editar

Ator Sistema







57


Fluxo Alternativo 6

Excluir

Ator Sistema

Clica [EXCLUIR] ao lado do resultado obtido

Perguntar a confirmação da exclusão e o Botão [CONFIRMAR]

Clica [CONFIRMAR] Sistema grava informações alteradas no Banco de dados



UC06 – Manter Turma

Tabela 8 – Caso de Uso UC06 – Manter Turma

Nome UC06 – Manter Turma

Objetivo Manter dados de Turmas da instituição

Atores Coordenador

Dados Consumidos

Turmas

Dados Produzidos

Relação de turmas

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo cadastrado Disciplinas cadastradas Cursos cadastrados

Pós-condições

Fluxo Principal

O UC06 tem início quando o Ator acessa a opção de menu turmas

Ator Sistema

Mostra menu secundário com as opções: [NOVA TURMA] [EDITAR] [PESQUISAR]

Clica [NOVA TURMA] Mostra campos a serem preenchidos e o botão [ADICIONAR]

Preenche campos com informação: ano e Semestre letivo, curso, período e nome da turma pelas Siglas do curso, quantidades de Semestres Cursado e período (BSI 7º Noturno)



Sistema retorna a pagina turmas.

Fluxo Alternativo 1

58

Erros – turma já existe.

Ator Sistema

Após digitado informações do : ano e Semestre letivo, curso, período e nomeia turma pelas Siglas do curso, quantidades de semestres Cursado e período (BSI 7º Noturno) O sistema verifica se já existe no banco de dados

Caso já exista ano/semestre letivo Cadastrado o sistema mostra erro “Erros – turma já existe.”, e um botão [VOLTAR].


Fluxo Alternativo 2

Pesquisar

Ator Sistema

Clica [PESQUISAR] Mostra campos nome da turma e o botão [BUSCAR]

Clica [BUSCAR]


Fluxo Alternativo 3

Pesquisar = 0

Ator Sistema




Fluxo Alternativo 4

Editar

Ator Sistema

clica [EDITAR] ao lado do resultado obtido Mostra campos a serem editados e o botão [ALTERAR]





Fluxo Alternativo 5

Erro: Editar

Ator Sistema

Clica [EDITAR] ao lado do resultado Mostra campos a serem editados e o

59

obtido Botão [ALTERAR]






Fluxo Alternativo 6

Excluir

Ator Sistema





UC07 – Manter Grade Horária

Tabela 9 – Caso de Uso UC07 – Manter Grade Horária

Nome UC07 – Manter Grade Horária


Atores Coordenador

Dados Consumidos

Dados Produzidos

Grade horária do semestre

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo cadastrado Disciplinas cadastradas Cursos cadastrados Professores cadastrados

Pós-condições

Fluxo Principal

O UC07 tem início quando o Ator acessa a opção de menu grade horária

Ator Sistema

Mostra menu secundário com as opções: [NOVA GRADE] [EDITAR] [PESQUISAR]

Clica [NOVA GRADE] Mostra campos a serem preenchidos ano e

60

Semestre letivo, curso, período e turma e o botão [AVANÇAR]

Preenche campos com informação: ano e Semestre letivo, curso, período e turma e

Clica em [AVANÇAR]

Mostra planilha com os dados anteriormente preenchido bem como horário das aulas e dias da semana e campos a serem preenchidos como Professor e disciplina e botões, [ADICIONAR].

Preenche dados professor e disciplina

Clica [ADICIONAR] Perguntar a confirmação da inserção dos dados e o botão [CONFIRMA]



Fluxo Alternativo 1

Erros – Grade Horária já existe.

Ator Sistema

Após digitado informações do : ano e Semestre letivo, curso, período e turma e professor O sistema verifica se já existe no banco de dados

Caso já exista ano/semestre letivo Cadastrado o sistema mostra erro “Erros – Grade Horária já existe. e um botão [VOLTAR].


Fluxo Alternativo 2

Pesquisar

Ator Sistema


Clica [BUSCAR]


Fluxo Alternativo 3

Pesquisar = 0

Ator Sistema


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


Fluxo Alternativo 4

Editar

61

Ator Sistema




Clica [ALTERAR] Sistema valida as informações inseridas Perguntar a confirmação da alteração e botão [CONFIRMA]



Fluxo Alternativo 5

Erro: Editar

Ator Sistema








Fluxo Alternativo 6

Excluir

Ator Sistema





UC08 – Manter Calendário

Tabela 10 – Caso de Uso UC08 – Manter Calendário

Nome UC08 – Manter Calendário

Objetivo Realizar cadastro dos eventos acadêmicos no calendário

Atores Funcionário

Dados Consumidos

Evento

62

Dados Produzidos

Calendário Acadêmico

Prioridade Alta


Pós-condições

Fluxo Principal

O UC08 tem início quando o Ator acessa a opção de menu Calendário Acadêmico

Ator Sistema

Mostra calendário do período letivo atual com a opção [ADICIONAR EVENTO] em cada dia

Clica [ADICIONAR EVENTO]

Mostra campos a serem preenchidos e o botão

[ADICIONAR]

Preenche campos com informação do evento

Clica em [ADICIONAR]

Perguntar a confirmação da inserção dos dados

e o botão [CONFIRMA]

Clica [CONFIRMA]

Sistema grava informações cadastradas no banco

de dados

Sistema retorna para a tela com o calendário do período letivo atual, com os dias associados a eventos destacados

Fluxo Alternativo 1

Mais de um evento no mesmo dia

Ator Sistema

Após digitadas as informações do evento

O sistema verifica se já existe um evento associado àquele dia

Caso já exista um evento cadastrado

O sistema mostra erro “um evento já associado a este dia”, e um botão [VOLTAR].

Clica [VOLTAR] Sistema retorna para a tela com o calendário do período letivo atual, com os dias associados a eventos destacados

Fluxo Alternativo 2

Pesquisar Evento

63

Ator Sistema

Clica [PESQUISAR EVENTO]

Mostra campos nome e data do evento e o botão

[BUSCAR]

Clica [BUSCAR]

Em uma tela de pesquisa o sistema mostra

resultados obtidos seguidos dos botões

[EXCLUIR EVENTO] [EDITAR EVENTO] e no final da Pesquisa

o Botão [VOLTAR]

Clica [VOLTAR] Sistema retorna para a tela com o calendário do período letivo atual, com os dias associados a eventos destacados

UC09 – Manter Pauta

Tabela 11 – Caso de Uso UC09 – Manter Pauta

Nome UC09 – Pauta

Objetivo Manter dados dos diários de classe associado a turma, disciplina e Professor

Atores Professores

Dados Consumidos

Dados Produzidos

Relatórios e pautas

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo cadastrado Disciplinas cadastradas Cursos cadastrados Professores cadastrados Alunos cadastrados

Pós-condições

Fluxo Principal

O UC07 tem início quando o Ator acessa a opção de menu pauta

Ator Sistema

Mostra menu secundário com as opções: [NOVA PAUTA] [EDITAR] [PESQUISAR]

Clica [NOVA PAUTA]

Mostra uma tabela contendo os campos: turma, Disciplina, professor ano e semestre letivo (em Caixa de seleção), e o botão [AVANÇAR]

Selecionar campos com informação: turma, Disciplina, professor ano e s semestre letivo

Clica [AVANÇAR] Sistema apresenta planilha contendo as

64

Informações previamente cadastradas e com o nome dos alunos matriculados no curso por ordem alfabética seguidos de campos para registrar faltas e campo de anotações dos eventos da aula e botões [ADICIONAR] [ADICIONAR OBS.]

Insere faltas e anotações




Fluxo Alternativo 1

Erros – Grade Horária já existe.

Ator Sistema

Após digitado informações do : ano e Semestre letivo, curso, período e turma e Professor O sistema verifica se já existe no banco de dados

Caso já exista ano/semestre letivo Cadastrado o sistema mostra erro “Erros – Grade Horária já existe. e um botão [VOLTAR].


Fluxo Alternativo 2

Pesquisar

Ator Sistema


Clica [BUSCAR]


Fluxo Alternativo 3

Pesquisar = 0

Ator Sistema




Fluxo Alternativo 4

Editar

Ator Sistema

clica [EDITAR] ao lado do resultado obtido Mostra campos a serem editados e o botão [ALTERAR]


Clica [ALTERAR] Sistema valida as informações inseridas

65

Perguntar a confirmação da alteração e Botão [CONFIRMA]



Fluxo Alternativo 5

Erro: Editar

Ator Sistema




Sistema não valida as informações Inseridas

Clica [ALTERAR] Sistema não valida as informações Inseridas



Fluxo Alternativo 6

Excluir

Ator Sistema





UC10 – Manter Matrícula/Disciplina

Tabela 12 – Caso de Uso UC05 – Manter Matrícula/Disciplina

Nome UC05 – Manter Matrícula/Disciplina

Objetivo Matricular alunos em uma Disciplina

Atores Funcionário

Dados Consumidos

Ano, semestre, turma

66

Dados Produzidos

Período letivo

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo previamente cadastrado Turma previamente cadastrada Aluno estar em conformidade com a instituição de ensino

Pós-condições

Fluxo Principal

O UC01 tem início quando o Ator acessa a opção de menu matricular aluno

Ator Sistema



Clica [BUSCAR]

Busca na base de dados informação sobre aluno: Se o aluno já for um veterano o sistema mostra Dados do semestre anterior

Mostra na pagina dados do aluno buscados na Base, além dos 9 campos a serem alterados. E o botão [ADICIONAR]

altera campos com informação código da disciplina, carga horária e número do semestre.



Sistema retorna a pagina de matricular Aluno

Fluxo Alternativo 1

Aluno novo (calouro)

Ator Sistema


Clica [MATRICULAR] Mostra campos matricula, CPF e nome e um Botão [BUSCAR]

Clica [BUSCAR] Busca na base de dados informação sobre aluno: Se o aluno for um calouro o sistema

67

mostra Dados ano e semestre letivo, Disciplinas em branco.

Mostra na pagina dados do aluno buscados na Base, além de campos e Disciplinas a serem alterados. E o botão [ADICIONAR]





Fluxo Alternativo 2

Aluno já matriculado

Ator Sistema


Clica [MATRICULAR] Mostra campos matricula, CPF e nome e Um Botão [BUSCAR]

Clica [BUSCAR]

Busca na base de dados informação sobre aluno: Se o aluno for um calouro o sistema mostra Dados ano e semestre letivo, Disciplinas preenchidos com os dados do banco.

Mostra na pagina dados do aluno buscados na Base, além de campos e Disciplinas a serem alterados. E o botão [ADICIONAR]






Fluxo Alternativo 3

Pesquisar

Ator Sistema

Clica [PESQUISAR] Mostra campos matricula do aluno, CPF,

68

nome do aluno e o botão [BUSCAR]

Clica [BUSCAR]


Fluxo Alternativo 4

Pesquisar = 0

Ator Sistema

Clica [PESQUISAR] Mostra campos matricula, CPF e nome [BUSCAR]



Fluxo Alternativo 5

Editar

Ator Sistema


Mostra campos das disciplinas a serem editados e o botão [ALTERAR]





Fluxo Alternativo 6

Erro: Editar

Ator Sistema


Mostra campos das disciplinas a serem editados e o botão [ALTERAR]



Sistema retorna mensagem de erro apresenta frase: “Atenção, dados incorretos. Repita a operação” e o botão [VOLTAR]


Fluxo Alternativo 7

Excluir

Ator Sistema

69





UC11 – Manter Enturmação

Tabela 13 – Caso de Uso UC11 – Manter Enturmação

Nome UC11 – Manter Enturmação


Atores Coordenador

Dados Consumidos

Identificação das Turmas

Dados Produzidos

Relação de Alunos em turmas

Prioridade Alta

Pré-condições

Possuir autorização e perfil de acesso Período letivo cadastrado Turmas cadastradas Cursos cadastrados

Pós-condições

Fluxo Principal

O UC06 tem início quando o Ator acessa a opção de menu Popular Turma

Ator Sistema

Mostra menu secundário com os campos Turma, Período e Curso e o botão: [PESQUISAR]

Clica [PESQUISAR] Mostra grid com lista de resultados. Cada resultado com a opção [EDITAR]

Clica em [EDITAR] no resultado Escolhido

Mostra uma tela com a identificação da turma no cabeçalho não editável, e com os 60 Campos para inserção dos alunos por número de matrícula, e o botão [SALVAR]

Preenche os campos, e clica em [SALVAR]

Sistema grava informações cadastradas no banco de dados


Fluxo Alternativo 1

70

Erro - Turma não existe.

Ator Sistema


Clica [PESQUISAR]

Caso não encontre registros, o sistema exibe a mensagem de erro “Nenhuma turma Encontrada” e o botão [VOLTAR]

Clica [VOLTAR] Sistema retorna a pagina de pesquisa de turmas.

Fluxo Alternativo 2

Turma já populada

Ator Sistema


Clica [PESQUISAR] Mostra grid com lista de resultados. Cada resultado com a opção [EDITAR]

Clica em [EDITAR] no resultado Escolhido

Mostra uma tela com a identificação da turma no cabeçalho não editável, e com os 60 Campos para inserção dos alunos por número de matrícula já preenchidos, e o botão [SALVAR]

Altera os campos, e clica em [SALVAR]

Sistema grava informações cadastradas no banco de dados


6.6 Diagramas de Classes

A Figura abaixo se refere ao diagrama de classes do Modulo Ano Letivo do

Sistema desenvolvido para faculdade ABC “SISEDU”, são apresentadas todas as

classes que compõem este modulo bem como seus relacionamentos.

71

Figura 06 – Diagrama de Classe

6.7 Modelo de Entidade-Relacionamento

O Modelo de Entidade-Relacionamento (MER) apresentado na Figura 07 traz

ilustração das tabelas e seus relacionamentos demonstrando a sua condição de

dependência do Modulo Ano Letivo do SISEDU sistema desenvolvido para

Faculdade ABC.

72

Figura 07 – Modelo de Entidade e Relacionamento – fonte: Prof. Mestra Elizabeth d’Arrochela Teixeira

73

6.8 Especificação das Tabelas

As tabelas apresentadas abaixo descrevem os campos do MER do Modulo

Ano Letivo do Sistema SISEDU desenvolvido para Faculdade ABC.

Esta tabela é utilizada para armazenar os dados de um novo cadastro de

período letivos.

Tabela 14 – PERIODOS

Campo Tipo Nulo PK FK

CD_ANO_LTV year(4) Não sim

CD_SEM char(1) Não NR_CUR int(11) Sim

TX_OBS char(100) Não

NR_SEM char(2) Sim

Esta tabela é utilizada para armazenar os dados cadastrais dos alunos da

faculdade ABC onde podem ser atualizadas e editadas.

Tabela 15 –MATRICULA

Campo Tipo de Dados Nulo PK FK

CD_MTR int(11) Não SIM

PESSOAS_NR_CPF_PESSOA decimal(11,0) Não SIM

CURSO_NR_CUR int(11) Não SIM

CD_TIP_MTR char(1) Sim

DT_MTR Date Sim

DT_INI_MTR Date Sim

NR_SEM char(2) Sim

DT_FIN_MTR Date Sim

CD_STT_MTR char(1) Sim

Esta tabela é utilizada para armazenar os dados cadastrais de uma nova

Turma na faculdade ABC em cursos por disciplinas.

74

Tabela 16 – TURMAS


CURSO_NR_CUR int(11) Não Sim

PERIODOS_CD_ANO_LTV year(4) Não sim

CD_TURMA int(11) Não sim

TX_DESC char(80) Sim

PERIODOS_CD_ANO_LTV1 year(4) Não

Esta tabela é utilizada para vincular alunos e turmas previamente cadastradas.

Tabela 17 – ENTURMAÇÃO


CD_ENT int(11) Não SIM

CD_DSC int(11) Não SIM

TURMAS_CURSO_NR_CUR int(11) Não SIM

TURMAS_PERIODOS_CD_ANO_LTV year(4) Não SIM

TURMAS_CD_TURMA int(11) Não SIM

TX_NOM_DSC varchar(45) Sim

CD_STT char(1) Não

DT_ENT date Não

DT_ULT_ALT date Sim

CD_MTR_ALN ocorre 60 vezes

CD_MTR_ALN_01 int(11) Sim

Esta tabela é utilizada para vincular as disciplinas disponíveis a uma aluno em

determinado curso.

Tabela 18 – DISCIPLINA_MATRICULA


MATRICULA_CD_MTR int(11) Não SIM

MATRICULA_PESSOAS_NR_CPF_PESSOA decimal(11,0) Não SIM

DISCIPLINAS ocorre 10 vezes

CD_DSC_01 int(11) Sim

QT_CRG_HOR_01 int(11) Sim

NR_SEM_01 char(2) Sim

Esta tabela é utilizada para armazenar os dados cadastrais dos Bancos que

disponibilizarão seus serviços a Faculdade ABC.

75

Tabela 19 – BANCO Campo Tipo Nulo PK FK

CD_BB char(3) Não SIM

TX_BB varchar(45) Sim

Esta tabela é utilizada para gerir e gerar boletos bancários de mensalidades bem como outras solicitações e demandas da Faculdade.

Tabela 20 – BOLETO Campo Tipo Nulo PK FK

NR_SEQ_BOL int(11) Não SIM

TIPO_BOLETOS_CD_TIP_BOL int(11) Não SIM



MATRICULA_CURSO_NR_CUR int(11) Não SIM

DT_VCT date Sim

NOSSO_NUMERO int(11) Sim

CD_SIT_PG tinyint(1) Sim

DT_PG date Sim

DT_GRC_BOL date Sim

VL_MNS float Sim

VL_DSC float Sim

VL_PG float Sim

Esta tabela é utilizada para gerir cursos que serão cadastrados e editados conforme as necessidades da instituição.

Tabela 21 – CURSO Campo Tipo Nulo PK FK

NR_CUR int(11) Não SIM

TX_NOM varchar(45) Não

CD_COO_CUR int(11) Não

TX_SGL char(3) Sim

CD_CUR char(1) Sim

CD_TRN char(1) Sim

QT_HOR_EST int(11) Sim

QT_CRG_HOR int(11) Sim

VL_MNS float Sim

CD_STT char(1) Sim

DT_REG_MEC date Sim

NR_REG_MEC char(20) Sim

QT_SEM char(2) Sim

Esta tabela é utilizada para gerir disciplinas em seus cursos que serão cadastrados e editados conforme as necessidades da instituição.

76

Tabela 22 – DISCIPLINA



CD_DSC int(11) Não SIM

TX_NOM varchar(45) Não

TX_SGL char(3) Sim

TX_DESC char(150) Sim

QT_CRG_HOR int(11) Sim

VL_DSC float Sim

TX_END_ARQ char(60) Sim

DT_ULT_ALT date Sim

Esta tabela é utilizada para registrar solicitações de documentos para a

Faculdade ABC.

Tabela 23 – DOCUMENTOS


TIP_DOC_CD_TIP_DOC char(2) Não SIM

PESSOA_NR_CPF_PESSOA decimal(11,0) Não SIM

TX_OBS char(200) Sim

TX_END_DOC char(150) Sim

TP_EXT_DOC char(5) Sim

Esta tabela é utilizada para inserir e manter dados bem como cadastrar uma

nova grade curricular no semestre letivo.

Tabela 24 – GRADE_CURRICULAR



NM_GRA_HOR char(5) Não SIM

NR_SEM char(2) Não

CD_TRN char(1) Não

CD_STT char(1) Não

DT_INI_GRA Date Não

DT_FIN_GRA Date Sim

77

Esta tabela é utilizada para armazenar os dados de pessoas cadastradas

cujos dados não serão mais utilizados em virtude de um possível desligamento do

quadro de funcionários professores ou alunos.

Tabela 25 – HST_PESSOA

Campo Tipo Nulo PK

NR_CPF_PESSOA decimal(11,0) Não SIM

DT_ULT_ATL timestamp Não SIM

TP_PESSOA char(2) Sim

TX_NOM char(60) Não

TX_NOM_PAI char(60) Sim

TX_NOM_MAE char(60) Não

DT_NSC date Não

CD_SEX char(1) Não

TX_EML char(60) Sim

NR_DDD_TEL_RES decimal(3,0) Sim

NR_TEL_RES decimal(9,0) Sim

NR_DDD_TEL_CEL decimal(3,0) Sim

NR_TEL_CEL decimal(9,0) Sim

NR_DDD_TEL_SRV decimal(3,0) Sim

NR_TEL_SRV decimal(9,0) Sim

TX_END_TIP decimal(2,0) Sim

TX_END_NOME char(40) Sim

TX_END_CPL char(15) Sim

TX_END_BRO char(30) Sim

TX_END_CDD char(45) Sim

TX_END_UF char(2) Sim

TX_END_CEP decimal(8,0) Sim

CD_STT char(1) Sim

TX_GRD_ESC char(2) Sim

NR_CPF_USU_ALT decimal(11,0) Não

Esta tabela é utilizada para armazenar os dados de usuários cadastrados cujos

dados não serão mais utilizados em virtude de um possível desligamento do quadro

de funcionários professores ou alunos

78

Tabela 26 – HST_USUARIO



DT_ULT_ALT Timestamp Não SIM

CD_PER int(11) Sim

TX_SNH char(8) Não

DT_INI Date Não

DT_ATL_USU Date Não

Esta tabela é utilizada para cadastrar candidatos a prova de vestibular da

instituição.

Tabela 27 – INSCRIÇÃO_VESTIBULAR



VESTIBULAR_PERIODOS_CD_ANO_LTV year(4) Não SIM

VESTIBULAR_NR_VST int(11) Não SIM

QT_INS_VST int(11) Sim

QT_APV_VST int(11) Sim

QT_RPV_VST int(11) Sim

Esta tabela é utilizada para cadastrar candidatos aprovados no vestibular da

instituição.

Tabela 28 – INSCRIÇÃO_VESTIBULAR_ALUNO

Campo Tipo Nulo Padrão Extra

COD_INS_VST_AL int(11) Não SIM


INSCRICAO_VESTIBULAR_CURSO_NR_CUR int(11) Não SIM

INSCRICAO_VESTIBULAR_VESTIBULAR_ PERIODOS_CD_ANO_LTV year(4) Não SIM

INSCRICAO_VESTIBULAR_VESTIBULAR_NR_VST int(11) Não SIM

DT_VST date Sim

VL_NOT_DSC_01 int(11) Sim





VL_MED_NOT_VST int(11) Sim

79

Esta tabela é utilizada para cadastrar observações sobre pessoas existentes na

base de dados.

Tabela 29 – OBSERVAÇÃO



DT_OBS Timestamp Não SIM

TX_OBS varchar(300) Sim

Esta tabela é utilizada para controlar pagamentos efetuados para a instituição.

Tabela 30 – PAGAMENTOS




MATRICULA_CURSO_NR_CUR int(11) Não SIM

DT_PG date Não SIM

VL_MNS float Sim

VL_DSC float Sim

VL_PG float Sim

CD_BB char(3) Sim

Esta tabela é utilizada para armazenar endereços eletrônicos.

Tabela 31 – PARAMETROS


TX_END_URL char(200) Não SIM

Esta tabela é utilizada para cadastrar perfis de usuários e controlar o acesso

ao sistema.

O módulo de Segurança deverá fazer extensa utilização desta tabela para fins

de autenticação de usuário.

80

Tabela 32 – PERFIL


CD_PER int(11) Não SIM

NM_PER char(20) Não

CD_UTZ_MOD_ALN_C char(1) Sim

CD_UTZ_MOD_ALN_R char(1) Sim

CD_UTZ_MOD_ALN_U char(1) Sim

CD_UTZ_MOD_ALN_D char(1) Sim

CD_UTZ_MOD_ANL_C char(1) Sim

CD_UTZ_MOD_ANL_R char(1) Sim

CD_UTZ_MOD_ANL_U char(1) Sim

CD_UTZ_MOD_ANL_D char(1) Sim

CD_UTZ_MOD_CUR_C char(1) Sim

CD_UTZ_MOD_CUR_R char(1) Sim

CD_UTZ_MOD_CUR_U char(1) Sim

CD_UTZ_MOD_CUR_D char(1) Sim

CD_UTZ_MOD_DSC_C char(1) Sim

CD_UTZ_MOD_DSC_R char(1) Sim

CD_UTZ_MOD_DSC_U char(1) Sim

CD_UTZ_MOD_DSC_D char(1) Sim

CD_UTZ_MOD_FNC_C char(1) Sim

CD_UTZ_MOD_FNC_R char(1) Sim

CD_UTZ_MOD_FNC_U char(1) Sim

CD_UTZ_MOD_FNC_D char(1) Sim

CD_UTZ_MOD_PRF_C char(1) Sim

CD_UTZ_MOD_PRF_R char(1) Sim

CD_UTZ_MOD_PRF_U char(1) Sim

CD_UTZ_MOD_PRF_D char(1) Sim

CD_UTZ_MOD_USU_C char(1) Sim

CD_UTZ_MOD_USU_R char(1) Sim

CD_UTZ_MOD_USU_U char(1) Sim

CD_UTZ_MOD_USU_D char(1) Sim

CD_UTZ_MOD_VST_C char(1) Sim

CD_UTZ_MOD_VST_R char(1) Sim

CD_UTZ_MOD_VST_U char(1) Sim

CD_UTZ_MOD_VST_D char(1) Sim

Esta tabela é utilizada para criar e editar um período de semestre letivo.

81

Tabela 33 – PERIODO


CD_ANO_LTV year(4) Não SIM

CD_SEM char(1) Não

NR_CUR int(11) Sim

TX_OBS char(100) Não

NR_SEM char(2) Sim

Esta tabela é utilizada para cadastrar e editar pessoas, considerando

especificamente candidatos à vaga, aprovados no vestibular, funcionários e

professores além dos alunos ditos como veteranos na instituição na base de dados.

Tabela 34 – PESSOA



TP_PESSOA char(2) Sim

TX_NOM char(60) Não

TX_NOM_PAI char(60) Sim

TX_NOM_MAE char(60) Não

DT_NSC Date Não

CD_SEX char(1) Não

TX_EML char(60) Não

NR_DDD_TEL_RES decimal(3,0) Sim

NR_TEL_RES decimal(9,0) Sim

NR_DDD_TEL_CEL decimal(3,0) Sim

NR_TEL_CEL decimal(9,0) Sim

NR_DDD_TEL_SRV decimal(3,0) Sim

NR_TEL_SRV decimal(9,0) Sim

CD_TIP_END decimal(2,0) Sim

TX_NOM_END char(40) Sim

TX_CPL_END char(15) Sim

TX_BRO_END char(30) Sim

TX_CDD_END char(45) Sim

CD_UF_END char(2) Sim

TX_CEP_END decimal(8,0) Sim

CD_STT char(1) Sim

TX_GRD_ESC char(2) Sim

DT_ULT_ATL Date Sim

82

Esta tabela é utilizada para lançar planos de ensino na base de dados para

consulta.

Tabela 35 – PLANO_ENSINO


PERIODOS_CD_ANO_LTV year(4) Não SIM

DISCIPLINA_CURSO_NR_CUR int(11) Não

DISCIPLINA_CD_DSC int(11) Não

NR_PLN_ESN int(11) Não

TX_NOM_PRF char(60) Não

TX_END_ARQ char(60) Sim

DT_ULT_ALT Date Sim

Esta tabela é utilizada para determinar o tipo de boleto a ser utilizado

dependendo do pedido do usuário.

Tabela 36 – TIPO_BOLETO


CD_TIP_BOL int(11) Não SIM

NM_TIP_BOL varchar(45) Sim

TX_RGR Text Sim

Esta tabela é utilizada para editar documentos a serem fornecidos aos

solicitantes.

Tabela 37 – TIPO_DOC


CD_TIP_DOC char(2) Não SIM

TX_TIP_DOC char(30) Sim

Esta tabela é utilizada para gerir endereços baseados na base dos correios

ligando a consulta ao CEP.

Tabela 38 – TIPO_END


CD_TIP_END decimal(2,0) Não SIM

TX_TIP_END char(10) Sim

83

Esta tabela é utilizada para gerir unidades da federação baseados na base

dos correios ligando a consulta ao CEP.

Tabela 39 – UF


CD_UF char(2) Não SIM

TX_UF char(30) Sim

Esta tabela é utilizada para gerir acesso do usuário a sistema através de cadastros de usuários previamente determinados dependendo do seu perfil, aluno, professor ou funcionário.

Tabela 40 – USUARIO


PESSOA_NR_CPF_PESSOA decimal(11,0) Não SIM

PERFIL_CD_PER int(11) Não SIM

TX_SNH char(8) Não

DT_INI Date Não

DT_ULT_ATL Date Não

Esta tabela é utilizada para gerir provas de vestibulares da instituição bem como datas, prazos e períodos.

Tabela 41 – VESTIBULAR


NR_VST int(11) Não SIM

PERIODOS_CD_ANO_LTV year(4) Não SIM

DT_INI_INS Date Sim

DT_FIN_INS Date Sim

CD_STT char(1) Sim

Para entendimento dos nomes dos campos, utilizamos um Glossário (vide Anexo

I) com todos os termos utilizados nas Tabelas.

84

6.9 Árvore do Sistema

Na figura abaixo são relacionados em forma de arvore a estrutura do Módulo

Ano Letivo do Sistema SISEDU desenvolvido para atender as necessidades da

Faculdade ABC.

Figura 08 – Árvore do Sistema.

6.10 Especificação Técnica

Abaixo estão descritas as principais funcionalidades técnicas do SisEdu.

A maior parte delas em caráter conceitual, os Casos de Uso “Manter

Matrícula” com sua extensão “Matrícula/Disciplina” e “Manter Turma” com sua

extensão “Enturmação”, do módulo Ano Letivo foram desenvolvidas em caráter

prototipal, significando que as funcionalidades de Inclusão, Alteração, Exclusão e

Consulta foram criadas em nível conceitual e serão apresentadas em anexo ao

presente trabalho.

85

6.10.1 Layout das Principais Telas da Aplicação

Na figura 09 é apresentada a tela de login do sistema, o usuário deverá estar

previamente cadastrado para conseguir executar essa operação.

Figura 09 – Tela de login

6.10.2 Consultar Matricula

Na figura 10 é mostrada a tela de matricula em branco onde é permitido

efetuar uma busca do aluno que consta na base de dados na tabela Pessoa pelos

campos CPF, Nome ou Matricula.

Na figura 11 é mostrada uma consulta realizada, onde o resultado é exibido

em uma “grid” logo abaixo da consulta, onde no canto esquerdo são mostrados

86

botões para exclusão do aluno, edição de seus dados e inclusão de disciplina a

serem cursadas nos semestre letivo vigente.

Figura 10 – Tela de consulta matricula vazia

Figura 11 – Tela de consulta matricula cheia

87

6.10.3 Editar Matricula

Na figura 12 é apresentada a tela de Editar Matricula do sistema, o usuário

deverá estar previamente logado para conseguir executar essa operação.

Nessa tela será realizada a edição dos dados do aluno.

Figura 12 – Tela de editar matricula

6.10.4 Navegação

Na figura 13 é apresentada a tela de navegação (menu) do sistema, o usuário

poderá acessar qualquer funcionalidade por ela, cada menu contara com sub menus

que facilitaram o acesso.

88

Figura 13 – Tela menu

6.10.5 Segurança Física

Segundo COCKBURN (1997), segurança física é extremamente importante

para manter a integridade, confidencialidade e disponibilidade das informações da

instituição.

Os conceitos principais da segurança aqui recomendados são: Controles de

acesso, Ponto fundamental para a segurança do Prédio onde estarão localizados os

servidores e a forma como é feito o controle de acesso de pessoas. É importante

que o pessoal da segurança saiba quem entrou e saiu de suas dependências,

horários identificados, o que veio fazer no prédio, se é aluno, Professor, funcionário

ou visitante que veio prestar um serviço.

Controle de Acesso de Pessoas Cadastradas e Autorizadas é incumbência da

portaria, ao gerenciar e autorizar a entrada no prédio somente mediante

apresentação do registro dos mesmos. Crachá para os professores e funcionários e

carteirinha estudantil para os alunos.

Essas pessoas, que constantemente passam pelo controle de acesso

efetuado pela portaria, devem ter a entrada facilitada, para tanto, um dos requisitos

para a segurança física é a implementação de catracas eletrônicas.

Controle de Acesso de Pessoas Não Cadastradas (desconhecidos, visitantes

ocasionais, prestadores de serviço, policiais, fiscais, oficiais de justiça, pedintes,

vendedores etc.), ou seja, as pessoas que não se incluem na lista de Pessoas

89

Cadastradas e Autorizadas acima descrita, necessitam de autorização expressa do

gestor podendo ser ele o chefe da segurança, um representante da administração da

instituição ou o próprio diretor, para entrar nas áreas de uso restrito do edifício.

É sugerido que a triagem seja feita de maneira minuciosa e criteriosa e para

tanto se faz necessário que o segurança execute procedimentos básicos no controle

de acesso a fim de impedir a entrada de pessoas suspeitas e indesejáveis nas

dependências da instituição.

Quanto à segurança física do Datacenter e às instalações da empresa é

sugerido contar com uma sala cofre para o armazenamento das máquinas-

servidoras e do Datacenter. O acesso a esta sala cofre deve ser controlado e

monitorado.

Outros fatores fundamentais no que diz respeito a segurança física é manter

registro de todo o pessoal que entra e sai, manter controle de entrada e saída de

dispositivos de armazenamento do Datacenter, além de a entrada somente de

pessoal que trabalha na sala, a mesma deverá ser trancada ao sair.

O conteúdo da sala, preferencialmente, recomenda-se que não esteja visível

externamente, além de estar protegido contra vandalismo, fogo, interferências

eletromagnéticas, fumaça, gases corrosivos e poeira.

Os dados armazenados pelo sistema devem estar seguros contra danos

físicos, para tal aconselha-se que afim de que a disponibilidade destes dados esteja

garantida, é necessário protegê-los de incêndios, infiltrações hidráulicas e extravio

em físico, bem como a substituição de parte do equipamento em geral os

equipamentos com maior tempo de uso a fim de evitar a entropia do sistema físico

da empresa.

90

È proposto também que os usuários do sistema passem por treinamentos,

tanto de operação do sistema de informação quanto em relação às medidas de

segurança a serem adotadas em sua rotina de trabalho.

Mesmo que o sistema conte com proteção contra ataques diretos aos dados,

os usuários ainda podem, por falha humana, criar falhas de segurança com

comportamento inadequado ou tratamento indevido das informações com que lida.

Sabendo que são comuns falhas de hardware, causadas por acidentes ou

fadiga de componentes mecânicos e eletrônicos propõe-se um mecanismo

importante para tolerar falhas e redundância.

– redundância de servidores

– redundância de fonte de alimentação

– redundância de discos (RAID)

– redundância de equipamentos

– redundância de ventilação

– redundância de interfaces de rede

Para garantir a disponibilidade da informação é preciso garantir o

fornecimento constante de energia e que ela esteja dentro da tensão recomendada

para isso podem-se utilizar dispositivos como filtros de linha, estabilizador de tensão

e “No Breaks”.

Utilizam-se Backups como recurso no caso de perda de informações, o

Backup preferencialmente será armazenado em discos e arquivados fora do

ambiente do Datacenter.

91

Visando como ultima recomendação de segurança física, eliminar

gradativamente os dados armazenados em papel destruindo os que já estiverem

duplicados na base de dados.

6.10.6 Segurança Lógica

Sugere-se que a segurança lógica adotada para o sistema conte com o fato

de que cada usuário do sistema a ter acesso ao departamento deverá possuir um

perfil específico que definirá quais informações estarão disponíveis para ele.

A vinculação de perfis se faz necessária devido ao risco de fornecer acesso a

informações indevidas para determinados usuários.

Visando manter a consistência dos dados do sistema, o perfil de Diretor não

tem certos privilégios que o Administrador por sua vez possui.

Cada usuário deverá cadastrar uma senha pessoal e intransferível para

acesso ao sistema. O sistema solicita a atualização da senha a cada espaço de

tempo determinado.

Tendo em vista que ele ficará disponível em uma rede, a medida de

segurança se faz necessária para evitar o acesso ao sistema por usuários não

cadastrados.

Sugere-se também a implantação, por parte do CPD, de firewall que realize

monitoramento interno e externo do sistema web visando minimizar o risco de

invasões.

92

O CPD também deve fornecer acesso remoto aos equipamentos através de

redes virtuais privadas VPN (Virtual Private Networks), por ser uma forma barata de

interligar duas redes privadas através da Internet.

A VPN nesse caso se aplicará para a ligação entre dois servidores e para

interligar duas redes inteiras também para ligação entre uma estação na Internet.

É incumbência do CPD manter a infra-estrutura operacional tanto física

como lógica da instituição, através de Antivírus, AntiSpam, e bloqueio de

funcionalidades como BIOS através de senha, sites suspeitos, funções

administrativas do S.O e manutenção do hardware.

93

7 Plano de Implantação

Os testes estão previstos para ser a fase subseqüente à codificação. O

SisEdu foi idealizado sob medida para a Faculdade ABC, desta forma esperam-se

incompatibilidades mínimas.

O treinamento dos funcionários na utilização do novo sistema, de modo a

adaptar os fluxos de trabalho à nova metodologia seria o passo seguinte. Como foi

mencionado, atualmente os serviços são executados manualmente com utilização

de ferramentas genéricas como editores de texto e planilhas, em virtude dessa

cultura já bastante utilizada na instituição faz-se necessário desenvolver nos

funcionários novos hábitos, onde vai se trabalhar com os dados diretamente no meio

onde serão tratados, e não por meio de trâmites de documentos entre gestores e

responsáveis diversos, de forma a reduzir a burocracia como um todo no ambiente

de trabalho, o que pode se mostrar uma tarefa mais demorada, porém que trará um

grande ganho futuro.

7.1 Atividades Futuras

O SisEdu está sendo entregue juntamente com este Trabalho de conclusão

de curso em nível de protótipo. Nem todas as funcionalidades aqui descritas foram

desenvolvidas, de modo que o sistema necessita da aprovação do Projeto por parte

da Faculdade ABC. Por meio da leitura desta documentação, e visualizando a

aplicabilidade no meio acadêmico, os responsáveis por parte da Instituição

verificarão a viabilidade do Projeto. A lógica de armazenagem dos dados no banco

deve ser foco de implementações futuras.

94

Caso seja aprovado, o desenvolvimento do sistema como um todo será o

passo seguinte. Levando-se em conta que todos os módulos estarão documentados

então, a codificação dos Casos de Uso de cada módulo será o foco da segunda

Fase do trabalho.

O prazo para a codificação, incluindo ajustes prováveis no Banco de Dados,

se dará conforme a realização de reuniões com as gerencia da Faculdade ABC.

Depois de codificado, o sistema pode ser implementado na Faculdade ABC,

seguindo-se a esta fase o treinamento do pessoal na utilização do sistema.

95

8 Conclusã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 editores de texto e planilhas.

Sendo assim, o sistema unificado SisEdu deve padronizar o sistema

administrativo e acadêmico da instituição, e o Modulo Ano Letivo em si contribuirá de

forma a agilizar o cadastro de informações acerca do ano letivo, contando com um

banco de dados relacional bem organizado e exigindo coesão no conteúdo das

informações cadastradas. Além disso, o SisEdu pode disponibilizar estas

informações aos estudantes via Web.

De certo modo conceituamos uma maneira pratica, e um tanto quanto

conservadora, mas ainda assim com algumas contribuições inovadoras afim de

proporcionar uma melhor pratica no que diz respeito aos aspectos administrativos e

acadêmicos da Faculdade ABC, visando melhorias e agilidade em suas demandas.

96

9 Referências Bibliográficas

ALEXANDER, C., ISHIKAWA, S., SILVERSTEIN, M., LACOBSON M.,

FIKSDAHL-KING, I., AND ANGEL, S., A Pattern Language. Oxford

University Press, New York, 1977.

AMARIZ, Luiz Carlos. “Linguagem de Programação de Alto Nível”

Disponível em: < http://www.infoescola.com/engenharia-de-

software/linguagem-de-programacao-de-alto-nivel/> Acessado em 30 de

maio de 2011.

ANDRADE, Gabriel. “O Que São Linguagens de Programação”

Disponível em: < http://www.infoescola.com/informatica/o-que-sao-

linguagens-de-programacao/> Acessado em 30 de maio de 2011.

ASTUDILLO Herman, STUART Hammer; “Understanding the Architect’s

Job”, Software Architecture Workshop of OOPSLA’98, 1998.

BECK, Kent. “Programação extrema (XP) explicada: acolha as

mudanças”. Porto Alegre RS: Bookman, 2004.

BOOCH, Grady; RUMBAUGH, James; JACOBSON Ivar. “UML GUIA DO

USUÁRIO”, 2 Edição. Editora Campus

COCKBURN, Alistair. “Escrevendo Casos de Uso Eficazes Um guia

prático para desenvolvedores de software.” Porto Alegre –RS:

Bookman, 2005.

CONVERSE, Tim. “PHP4, a Bíblia” Rio de Janeiro: Campus, 2001.

EISENTRAUT, Peter. “PostgreSQL”

Disponível em: < http://www.postgresql.org/community/contributors/>

Acessado em 30 de maio de 2011.

97

GUILLON, Antonio Bias Bueno, e MIRSHAWKA, Victor. “Reeducação.”

São Paulo: Makron, 1994.

HORSTMANN, Cay. “Conceitos de Computação Com o Essencial de

Java”. Porto Alegre: Bookman, 2005.

MARTINEZ, Marina. “RUP”

Disponível em: < http://www.infoescola.com/engenharia-de-software/rup/>


NUNES, Rizzatto. “Manual da Monografia” São Paulo: Saraiva, 2002.

PACIEVITCH, Yuri. “História do Java”

Disponível em: < http://www.infoescola.com/informatica/historia-do-java/>


REZENDE, Denis Alcides. “Engenharia de Software e sistemas de

Informação”. Rio de Janeiro: Basport, 1999.

SALOMON, Délcio Vieira. “Como fazer uma Monografia”. São Paulo:

Martins Fontes, 2001

SCHWABER, Ken, e SUTHERLAND, Jeff. “Scrum Guide”

Disponível em:</http://www.scrum.org/storage/scrumguides/Scrum/>

Acessado em 02 de junho de 2011.

SOMMERVILLE, Ian. “Engenharia de Software”. São Paulo: Addison

Wesley, 2003.

TELES, Vinícius Manhães. “Extreme Programming: Aprenda como

encantar seus usuários desenvolvendo software com agilidade e alta

qualidade”. São Paulo - SP: Novatec Editora Ltda, 2004.

98

Anexo I - DICIONÁRIO DE DADOS DO SISEDU

Exemplo: CD_TIP_ACAO_OPR

COD DESCRIÇÃO

CD CODIGO

DT DATA

HR HORA

IN INDICE

NM NOME

NR NUMERO

QT QUANTIDADE

TS TIMESTEMP

TX TEXTO

VL VALOR

COD DESCRIÇÃO

2EP 2a. Época

AG Agência

ALN Aluno

ANO Ano

ANT Anterior

APR Apresentação

APV Aprovado

ARQ Arquivo

ATL Atual-Atualização

AUTZ Autorizado

B1 Bimestre 1

B2 Bimestre 2

BB Código do Banco

BOL Boleto

BRO Bairro

CAD Cadastro

CC Conta Corrente

CDD Cidade

99

CEL Celular

CEP Código Postal

COO Coordenador

CPL Complemento

CRG Carga

CTR Controle

CUR Curso

DCP Disciplina

DD Dias

DESC Descrição

DOC Documentação

DSC Disciplina

EML e_mail

EMM Ementa

END Endereço

ENT Enturmação

ENS Ensino

ESC Escolaridade

EST Estágio

FILI Filiação

FIN Final

FLT Faltas

FRM Formatura

FUC Funcionário

GRA Grade

GRC Geração

GRD Grau

HOR Horário/Hora

INCL Inclusão

INI Inicial

INS Inscrição

LIM Limite

LTV Letivo

MTR Matricula

MEC Min. Educação

MED Média

100

MNS Mensalidade

MOD Módulo

MSG Mensagem

MVT Movimento

NOM Nome

NOT Nota

NSC Nascimento

OBS Observação

PFN Prova Final

PAG Pago

PER Perfil

PLN Plano

PRD Período

PRF Professor

REG Regularização

RES Residencial

RGR Regra

RLZ Realização

RPV Reprovado

RSP Responsável

SAL Sala

SDO Saldo

SEM Semestre

SEQ Sequencial

SEX Sexo

SGL Sigla

SIT Situação

SMN Semana

SNH Senha

SRV Serviço

STT Status

TEL Telefone

TIP Tipo

TOT Totais

TRM Turma

TRN Turno

101

UF Unid.Federativa

ULT Última

USU Usuário

UTZ Utilização

VCT Vencimento

VST Vestibular