MONOGRAFIA_CONSTANTINO_GIL

Prévia do material em texto

INSTITUTO SUPERIOR DE CIÊNCIAS DA EDUCAÇÃO DA HUÍLA 
 ISCED-HUILA 
 
 
 
 
 
 
 
 
 
 
 
 
 
PROJECTO DE UM SISTEMA DE GESTÃO INTEGRADA DA ESCOLA 
SUPERIOR PEDAGÓGICA DA LUNDA NORTE - SGIESPLN. 
 
 
 
 
 
 
 
 
 
 
 
 
 
AUTOR: Constantino Nunes Canguya Gil 
 
 
 
 
LUBANGO 
2016 
 
 
 
 
INSTITUTO SUPERIOR DE CIÊNCIAS DA EDUCAÇÃO DA HUÍLA 
ISCED-HUILA 
 
 
 
 
 
 
 
 
 
 
 
 
PROJECTO DE UM SISTEMA DE GESTÃO INTEGRADA DA ESCOLA 
SUPERIOR PEDAGÓGICA DA LUNDA NORTE - SGIESPLN. 
 
 
 
 
 
 
Trabalho de fim de curso para obtenção do grau de 
licenciado em ensino de Informática Educativa 
 
 
 
 
 
 
AUTOR: Constantino Nunes Canguya Gil 
TUTOR: Dr. Jorge Dias Veloso 
 
 
 
 
 
LUBANGO 
2016
 I 
 
AGRADECIMENTOS 
Primeiramente a Deus Todo-Poderoso, porque sem Ele não teria chegado a 
lugar algum. Aos meus familiares e amigos. Também a toda família, que me 
acompanhou do começo ao fim deste trabalho. Especial gratidão e apreço ao 
Docente-Orientador, Dr. Jorge Dias Veloso, pela sua alta contribuição, 
dedicação, paciência com as minhas dificuldades e por conduzir-me para 
realizar o trabalho com perspicácia e a todos Docentes da RIED do 
ISCED/HUÍLA (2012-2015), muito obrigado pala vossa paciência e esforço 
empreendido. 
 
 II 
 
DEDICATÓRIA 
A minha família, por servir de motivação e por me dar todo apoio em tudo o 
que fiz, especialmente os meus Pais, Augusto Gil e Maria Chilicondjamba Gil, 
por serem sempre um pilar protector forte. 
 
 III 
 
RESUMO 
As instituições do ensino Superior em geral precisam manipular uma grande 
quantidade de informações armazenadas em diversos arquivos que, com o 
tempo, tornam o controlo da informação lento e incapaz de oferecer qualidade 
no atendimento aos estudantes. Algumas instituições preferem adquirir 
sistemas comerciais para o gerenciamento do directório de registos de 
informações. 
A ESPLN, com o propósito de adquirir um melhor desempenho, optou por 
desenvolver uma ferramenta adequada às suas necessidades. 
O Trabalho descreve o projecto do “Sistema Integrado de Gestão – 
SGIESPLN”, um sistema que pretende gerir todo a vida académica do 
estudante, processo de candidatura, selecção e matrícula de estudantes, 
recursos humanos, assuntos científicos. Tendo estas operações como os 
principais módulos do sistema, começa-se por apresentar uma breve 
introdução onde se inclui o contexto e motivação a para escolha do tema, os 
objectivos gerais e específicos, a metodologia que foi utilizada para a 
realização desse projecto, por fim, o enquadramento do trabalho. Em 
seguida, passa-se para a fundamentação teórica relativamente ao tema do 
projecto em estudo e depois procede-se a apresentação da proposta do 
sistema que é o ponto crucial deste trabalho, que passa pela fase da 
Especificação de todos os diagramas e seu respectivo resumo. 
Palavras-chave: Sistema Integrado de Gestão, Base de Dados, 
Informações, Engenharia de Software. 
 
 IV 
 
ÍNDICE 
0. INTRODUÇÃO ............................................................................................ 8 
0.1 Contextualização ......................................................................................... 9 
0.2 Descrição do Problema ............................................................................... 9 
0.3 Definição do Problema .............................................................................. 10 
0.4 Objectivo Geral .......................................................................................... 10 
0.5 Objectivos Específicos............................................................................... 10 
0.6 Tarefas da Investigação ............................................................................ 11 
0.7 Métodos de Colheitas de Dados ................................................................ 12 
0.8 Motivação .................................................................................................. 12 
CAPITULO 1. FUNDAMENTAÇÃO TEÓRICA ................................................. 13 
1.1 Introdução .......................................................................................... 13 
1.2 A Instituição do Ensino Superior (IES) como organização ................. 13 
1.3 Metodologia de Gestão da IES .......................................................... 14 
1.4 Engenharia de Software .................................................................... 14 
1.4.1 Definição ...................................................................................... 15 
1.4.2 Ciclo de Vida de Desenvolvimento ............................................... 15 
1.4.3 Processo Unificado da Rational ................................................... 17 
1.4.4 A Linguagem UML ........................................................................ 22 
1.4.5 Metodologias de Desenvolvimento de Software ........................... 27 
1.5 Técnicas de Orientação a Objectos – OO ......................................... 27 
1.5.1 Conceitos Fundamentais da OO .................................................. 28 
1.6 Sistema de Informação (SI) ............................................................... 29 
1.6.1 Processo de Desenvolvimento de SI ............................................ 29 
1.7 Sistema de gestão Base de Dados .................................................... 31 
CAPITULO 2. METODOLOGIA E ANÁLISE E TRATAMENTO DE DADOS.... 34 
2.1 Metodologia ....................................................................................... 34 
2.2 Análise de Dados ............................................................................... 34 
2.3 Análise e Tratamento de Dados ........................................................ 37 
2.3.1 O tratamento dos dados, inferência e interpretação ........................ 37 
CAPITULO 3. PROJECTO DE UM SISTEMA DE GESTÃO INTEGRADA DA 
ESCOLA SUPERIOR PEDAGÓGICA DA LUNDA-NORTE – SGIESPLN. ...... 52 
3.1 Diagrama Caso de Uso do SGIESPLN ..................................................... 52 
3.1.1 Especificação dos Casos de Uso de Administrador ..................... 52 
Em resumo: ............................................................................................... 62 
3.1.2 Especificação dos Casos de Uso de Estudante .............................. 63 
Em resumo: ............................................................................................... 69 
3.1.3 Especificação dos Casos de Uso do Docente ................................. 70 
Em resumo: ............................................................................................... 76 
3.1.4 Especificação dos Casos de Uso do DAAC..................................... 76 
Em resumo: ............................................................................................... 82 
3.1.5 Especificação dos Casos de Uso do DAC ....................................... 84 
 V 
 
Em resumo: ............................................................................................... 86 
3.1.6 Especificação dos Casos de Uso do Técnico do DRH .................... 87 
Em resumo: ............................................................................................... 88 
3.2 Outras funcionalidades a constar no Sistema .................................... 90 
CONCLUSÕES E RECOMENDAÇÕES .......................................................... 93 
CONCLUSÕES ............................................................................................. 93 
RECOMENDAÇÕES .................................................................................... 93 
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................. 94 
ANEXOS .......................................................................................................... 96 
ANEXO 1. OUTROS DIAGRAMAS PARA FACILITAREM A 
COMPRESSÃO NO PROCESSO DESENVOLVIMENTO DO SGIESPLN ..... 1 
ANEXO 2: Questionário paraEstudantes ..................................................... 19 
ANEXO 3: Questionário para Docentes ........................................................ 21 
ANEXO 4: Questionário para Funcionários Administrativos ......................... 23 
 
 
 VI 
 
ÍNDICE DE TABELAS 
Tabela 1: Quadro de Entrevistas ...................................................................... 36 
Tabela 2: Caso de uso Manutenção de Estudante .......................................... 54 
Tabela 3: Especificação do CSU Manutenção de Professor ............................ 55 
Tabela 4: Especificação do CSU Manutenção de Curso ................................. 56 
Tabela 5: Especificação do CSU de Gerir o Sistema ....................................... 57 
Tabela 6: Especificação do CSU de Consultar ................................................ 58 
Tabela 7: Especificação do CSU de Configurar ............................................... 60 
Tabela 8: Especificação do CSU de impressão ............................................... 60 
Tabela 9: Especificação do CSU de Upload .................................................... 62 
Tabela 10: Especificação do CSU de Estudante efectuar Matricula ................ 64 
Tabela 11: Especificação do CSU de Estudante da Consulta ......................... 66 
Tabela 12: Especificação do CSU de Estudante de Visualização.................... 67 
Tabela 13: Especificação do CSU de Estudante de impressão ....................... 68 
Tabela 14: Especificação do CSU de Estudante de Upload ............................ 69 
Tabela 15: Especificação do CSU de Docente Lançar Notas .......................... 71 
Tabela 16: Especificação do CSU de Docente de Consultas .......................... 72 
Tabela 17: Especificação do CSU de Docente de Visualização ...................... 74 
Tabela 18: Especificação do CSU de Docente de Impressão .......................... 74 
Tabela 19: Especificação do CSU de Docente de Upload ............................... 76 
Tabela 20: Especificação do CSU de DAAC de gestão de Comparticipação .. 77 
Tabela 21: Especificação do CSU de DAAC de Consultas .............................. 79 
Tabela 22: Especificação do CSU de DAAC de Scanner ................................ 80 
Tabela 23: Especificação do CSU de DAAC de Impressão ............................. 81 
Tabela 24: Especificação do CSU de DAAC de Upload .................................. 82 
Tabela 25: Especificação do CSU de DAC de Horários de Defesa ................. 85 
Tabela 26: Especificação do CSU de DAC de Gerir DAC ................................ 86 
Tabela 27: Especificação do CSU de DRH de Gerir DRH ............................... 88 
 
 
 VII 
 
ÍNDICE DE FIGURAS 
Figura 1: Ciclo de Vida do Desenvolvimento de software ................................ 15 
Figura 2: Ciclo de vida de desenvolvimento ..................................................... 17 
Figura 3: As duas dimensões do RUP ............................................................. 18 
Figura 4: As quatro fases do RUP .................................................................... 18 
Figura 5: Exemplo de diagrama de caso de uso .............................................. 23 
Figura 6: Exemplo de diagrama de sequência ................................................. 24 
Figura 7: Exemplo de diagrama de actividade ................................................. 24 
Figura 8: Exemplo de diagrama de Classe ...................................................... 25 
Figura 9: Exemplo de diagrama de Estado ...................................................... 26 
Figura 10: Exemplo de diagrama de Componente ........................................... 26 
Figura 11: Exemplo de diagrama de Utilização ................................................ 27 
 
8 
 
0. INTRODUÇÃO 
A Sociedade da Informação apresenta hoje novos desafios ao Ensino Superior, 
consubstanciados não apenas no ensino à distância e na aprendizagem interactiva, 
mas também no aspecto menos visível da aplicação tecnológica ao serviço da 
gestão das Instituições de Ensino Superior. Os sistemas de informação beneficiam 
as organizações, os utilizadores e qualquer indivíduo ou grupo que interagir com o 
sistema. De entre os benefícios que um sistema de informação deve trazer 
encontram-se os da segurança dos dados, melhoria do serviço, redução de erros 
de gestão, maior precisão, maior eficiência e eficácia e maior produtividade. 
Por todas essas razões, este é um aspecto crucial. As Instituições de Ensino 
Superior são sistemas organizacionais complexos, com regras e processos muito 
próprios. Nestas Instituições, a informação pode ser académica, administrativa, 
docente e financeira, entre outras, representando diversas unidades orgânicas com 
necessidades informacionais específicas. 
Porque a informação está em toda a parte e o conhecimento é a matéria-prima da 
gestão eficiente, uma das tarefas mais críticas do quotidiano de uma Instituição de 
Ensino Superior (IES) é, pois, assegurar que a comunidade académica (estudantes, 
docentes, pessoal administrativo e gestores) tenha acesso à informação 
necessária, correcta, em tempo útil e de forma segura e eficiente. 
Posto isso, é necessário que a IES tenha um Sistema de Gestão, evidenciando 
todas as áreas cruciais geradoras de informações necessárias no processo da 
gestão desde os processos administrativos, passando pela gestão de processos de 
candidatura para os diferentes níveis de cursos, efectivação de inscrições, 
matrículas, avaliações, controlo de pagamento de propinas, recursos humanos, 
assuntos científicos, etc. 
 
9 
 
0.1 Contextualização 
A todo momento as organizações precisam aceder a informação certa para 
responder atempada e adequadamente os desafios que lhe são colocados 
(Audy, 2005). Esta informação produzida com base em Sistemas de Informação 
(SI) e Tecnologias de Informação e Comunicação (TIC) é importante para ajudar 
no processo de tomada de decisão, rentabilizando mais a organização e 
facilitando a comunicação entre os diversos intervenientes na actividade. 
O uso das TIC nas organizações em todo mundo e no caso concreto de Angola 
tem vindo a evoluir de forma surpreendente, dado que maior parte delas já se 
deu conta das vantagens que se obtêm ao implementá-las nas suas instituições, 
assume-se pois que o seu uso minimiza a complexidade existente no 
processamento dos dados e ajuda no processo de tomada de decisões. 
A importância da informação para a tomada de decisões nas organizações tem 
impulsionado o desenvolvimento dos sistemas de processamento de 
informações. 
Deste modo, o presente trabalho se refere à implementação de um Sistema de 
Gestão integrada destinado a possibilitar e facilitar o processamento e 
manuseamento da informação da Escola Superior Pedagógica da Lunda Norte, 
que constituirá um factor decisivo na execução dos trabalhos académicos e 
científicos de forma rápida e eficiente. 
A Base de Dados terá informações do perfil de cada estudante, desde a sua 
admissão à instituição até ao fim do seu currículo e ainda informações do perfil 
de cada Docente e, também, fará a emissão de relatórios e consultas, registo 
de disciplina, cadastro de notas, registo de marcação das avaliações, horários 
lectivos, Calendários de Exames, pautas, registo de Pagamentos, actividades 
dos departamentos dos recursos humanos e Científico. 
0.2 Descrição do Problema 
A Escola Superior Pedagógica da Lunda-Norte tem dificuldades no processo de 
gestão da informação, o que faz com que haja muito atraso na resposta de 
10 
 
certas solicitações feitas à instituição e isso deve-se ao facto de não possuir 
uma base de dados que gere a informação na sua íntegra. 
0.3 Definição do Problema 
A implementação de um Sistema Integrado de Gestão melhora o processo de 
gestão da informação da Escola Superior Pedagógica da Lunda-Norte? 
0.4 Objectivo GeralEste trabalho tem como objectivo desenhar um sistema Integrado de Gestão da 
Escola Superior Pedagógica da Lunda-Norte 
0.5 Objectivos Específicos 
Ao nível tecnológico: 
Inovar os processos e rotinas de gestão da informação da ESPLN, usando 
modernas tecnologias e ferramentas de forma a: 
 Padronizar as informações da ESPLN; 
 Reduzir o tempo e custo de acesso à informação para todos os nossos 
utilizadores; 
 Reduzir o custo da informação; 
 Fornecer informação precisa sobre o assunto, para tomada de decisão; 
 Procurar integrar todas as informações pertinentes e dispersas numa 
única base de dados de interesse académico, científico e recursos 
humanos e colocá-la à disposição dos que a ela acedam através de uma 
interface comum de fácil utilização; 
 Oferecer uma comunicação activa entre os estudantes com eficiência e 
produtividade; 
 Fomentar uma cultura de partilha de informação e colaboração entre os 
funcionários. 
Ao nível de formação profissional: 
 Instituir com esta metodologia de trabalho um novo instrumento 
alternativo de treinamento para os estudantes, promovendo, na prática, 
11 
 
a elevação da capacidade criativa dos mesmos na utilização de sistemas 
de informações; 
 Instituir um mecanismo moderno para melhorar as condições de acesso 
à educação profissional usando como ferramenta principal a elaboração 
de mecanismos modernos de Gestão da informação. 
Ao nível da gestão e administração: 
 Descentralizar actividade e melhorar os serviços; 
 Elevar taxa de eficiência e eficácia; 
 Disponibilizar ferramentas que permitam a consulta de informações 
pelos próprios utilizadores do sistema. 
0.6 Tarefas da Investigação 
Para conduzir a investigação adoptamos as seguintes tarefas: 
1. Diagnosticar o processo de tratamento da informação da ESPLN e levantar 
o problema de investigação; 
2. Caracterizar o Sistema integrado de gestão de bases de dados para a 
ESPLN; 
3. Recolher dados e seu processá-los; 
4. Entrevistar os funcionários dos departamentos e estudantes da ESPLN, para 
verificar a necessidade da implementação do sistema; 
5. Redigir a versão preliminar do relatório; 
6. Rever e corrigir; 
7. Imprimir e apresentar o trabalho. 
12 
 
0.7 Métodos de Colheitas de Dados 
Neste estudo, foram utilizadas as pesquisas bibliográficas, e, para a “exploração 
do campo de pesquisa” foi elaborado um guião de entrevistas a alguns membros 
da direcção da ESPLN. 
0.8 Motivação 
A escolha do tema foi motivada pelo facto de que, em angola, as instituições das 
redes públicas e particulares, em geral, ainda encontram-se desprovidas de 
inovações tecnológicas, que hoje são ferramentas indispensáveis para se fazer 
frente ao mundo moderno. 
Actualmente, Instituições de Ensino Superior têm avançado bastante. Com isso 
elas precisam estruturar-se para orientar seus estudantes e docentes 
(TACHIZAWA & ANDRADE, 1999). 
Uma Instituição de ensino é um conjunto de pessoas se interagindo, que ao se 
relacionar com estudantes através do poder do ensino, consegue passar a ideia 
em mente e tentar garantir que os estudantes saiam dali com um pensamento 
feito (TACHIZAWA & ANDRADE, 1999). 
Portanto, torna-se necessário automatizar esta actividade, a fim de assegurar 
estes dados, a eficiência e a agilidade das tarefas desempenhadas pela 
Direcção da ESPLN, e não só. A solução proposta nesse projecto é desenvolver 
um software de banco de dados relacional para o sistema de Gestão Integrado, 
que possibilite a instituição acompanhar todas as actividades 
 
13 
 
CAPITULO 1. FUNDAMENTAÇÃO TEÓRICA 
1.1 Introdução 
A gestão é um factor estratégico de sucesso em qualquer tipo de 
empreendimento. O ensino superior não é excepção, pois do planeamento 
depende a implementação das estratégias que dão à instituição o seu diferencial 
no mercado. 
Empresas dos mais variados tipos investem actualmente em business 
inteligence, ou seja, em sistemas que permitem aos dirigentes ter acesso a 
mecanismos de monitoramento e avaliação do seu negócio, contribuindo para 
decisões bem fundamentadas. 
A inteligência do negócio em termos de sistema de gestão integrada, além de 
permitir a informatização dos processos administrativos, diminuindo os custos 
operacionais, facilita a organização das grades curriculares flexíveis e monitora 
continuamente o desempenho académico, científico e financeiro da instituição. 
1.2 A Instituição do Ensino Superior (IES) como organização 
A IES são organizações que desenvolvem uma lógica distinta de outras 
organizações económicas, pois a sua atenção principal está voltada para a 
formação e disseminação de conhecimento através de práticas educativas. No 
entanto, apresentam estruturas que exigem a definição de práticas de gestão que 
possam garantir o alcance de resultados esperados pela sua comunidade interna 
e demais grupos de interesse. 
Baldridge (1971) escreveu que organizações variam significativamente em 
aspectos como: Tipo de clientes, tecnologias, habilidades dos trabalhadores, 
estrutura e estilos de coordenação e relacionamento com seu ambiente externo. 
Existem muitos elementos comuns na operação das universidades, empresas, 
organizações governamentais, mas nunca duas organizações são iguais. Este 
autor afirma ainda que universidades são organizações singulares, diferindo na 
maioria dos seus aspectos das empresas industriais, empresas de serviços e 
organizações governamentais. 
14 
 
Enquanto organização complexa, a universidade apresenta cinco 
características específicas, as quais são descritas por Baldridge (1971) como: 
ambiguidade das metas, cliente service, tecnologia problemática, 
profissionalismo e vulnerabilidade ambiental. 
1.3 Metodologia de Gestão da IES 
Machado e Silveira (1998) consideram que, ao longo dos séculos, as instituições 
de ensino foram estruturadas para mudar lentamente, como forma de perenizar 
suas actividades. 
Segundo Buarque (1994), seja qual for o caminho da humanidade, ela passa 
pela universidade, que terá que consigo assustar-se e promover as 
transformações que a dotem da agilidade e flexibilidade requeridas para uma 
actuação mais efectiva, como forma de vislumbrar soluções alternativas a fim 
de superar os sustos e a perplexidade deste final de século. 
1.4 Engenharia de Software 
Um factor essencial para a conclusão de um projecto de desenvolvimento de 
software é a adopção de uma metodologia, que pode ser entendida como um 
conjunto de regras e padrões que orientam as abordagens utilizadas em todas 
as tarefas associadas com o ciclo de desenvolvimento de sistemas. A existência 
de uma metodologia padronizada de desenvolvimento de sistema garante a 
consistência das especificações para toda a empresa. 
Existem diversas técnicas de análise e modelagem, porém as mais dominantes 
são o desenvolvimento estruturado e o orientado a objecto. 
Segundo (PRESSMAN, 2011), o desenvolvimento estruturado é uma actividade 
de construção de modelo, que utilizando uma notação própria, cria modelos que 
retractam o fluxo e o conteúdo da informação. Os sistemas são divididos em 
partições funcionais e comportamentais que descrevem a essência do produto 
a ser construído. 
Nesta seção, apresenta-se a definição sobre Engenharia de Software, Ciclo de 
15 
 
Vida de um software e Processo Unificado da Rational. 
1.4.1 Definição 
Engenharia de Software é uma das grandes áreas da computação, que envolve 
a criação, a construção, a análise, o desenvolvimento e a manutenção do 
software. Este tipo de tratamento pode proporcionar ao desenvolvedor a 
produção de um software com qualidade e resultado desejado. 
(SOMMERVILLE, 2011). 
1.4.2 Ciclo de Vida de Desenvolvimento 
Para alguns sistemas o ciclo de vida não é longo, entretanto é necessário 
entender que um software nunca estará totalmente acabado; ele pode estar 
pronto para uso, mas sempre sofrerá implementações e melhorias(REZENDE, 
2005). 
Este ciclo abrange algumas etapas: a análise, o projecto, a implementação, os 
testes e a manutenção. O modelo cascata, mais conhecido como modelo de 
ciclo de vida, tem essas cinco fases denominadas de uma forma diferente, como 
mostra a Figura 1 (SOMMERVILLE, 2011). 
 
Figura 1: Ciclo de Vida do Desenvolvimento de software 
Para melhor especificação do sistema, é necessário recolher todos os requisitos 
e finalidades do sistema na primeira fase: Definição de Requisitos. Na segunda, 
é definida a arquitectura, tanto no aspecto software, os requisitos funcionais, 
quanto no aspecto hardware, os requisitos não funcionais. 
16 
 
Na terceira fase, Implementação e Teste de Unidade, o software começa a ser 
implementado e testado, de maneira a verificar se está atendendo a sua 
finalidade. Para verificar se todos os requisitos atendem as expectativas, na fase 
de Integração e Teste de Sistema, o software é testado como um todo. E por 
último, na fase de Operação e Manutenção, após a entrega do software, ele é 
requer novas alterações, relacionadas a erros não detectados nos testes 
(SOMMERVILLE, 2011). O ciclo de vida de um software também está 
representado na Figura 2. Como já dito, um software sempre estará em 
desenvolvimento, pois no decorrer de seu uso haverá sempre a necessidade de 
modificações (BROOKSHEAR, 2003). 
A fase de Manutenção concentra-se em: 
 Correcções: Mudanças que estão associadas à correcção de defeitos 
(Manutenção Correctiva); 
 Adaptações: são exigidas à medida que o ambiente do sistema evolui 
(Manutenção Adaptativa); 
 Melhoramento Funcional produzidas por exigências variáveis do cliente 
(Manutenção perfectiva). 
 Prevenção: O software de computador deteriora-se devido a 
modificações; 
 Surge a manutenção preventiva, que é frequentemente chamada de 
reengenharia de software, em essência, a manutenção preventiva faz 
modificações nos programas de computador, de modo que eles possam 
ser mais facilmente corrigidos, adaptados e melhorados; 
17 
 
 
Figura 2: Ciclo de vida de desenvolvimento 
1.4.3 Processo Unificado da Rational 
O Rational Unified Process (RUP) que traduzido para o português significa 
Processo Unificado da Rational, é um processo de engenharia de software. Com 
o objectivo de garantir a qualidade de um software que, dentro de um 
cronograma e um orçamento previsível, atendam às necessidades dos seus 
usuários finais, o RUP fornece uma abordagem disciplinada para a atribuição de 
tarefas e responsabilidades na organização do desenvolvimento. Utiliza a 
linguagem UML no desenvolvimento dos casos de uso e a orientação a Objectos 
(KRUCHTEN, 2003). 
1.4.3.1 Arquitectura do RUP 
Nesta seção será apresentada a arquitectura do RUP composta por dimensões 
e fases. 
1.4.3.1.1 Dimensões 
O RUP apresenta duas dimensões, a dinâmica e a estática, como mostra a 
figura a seguir: 
18 
 
 
Figura 3: As duas dimensões do RUP 
A dimensão horizontal representa o aspecto dinâmico do processo, o ciclo de 
vida. Essa dimensão faz com que o projecto do software seja elaborado com 
uma sequência de iterações incrementais. A dimensão vertical representa o 
aspecto estático, descrito em termos de componentes do processo: actividades, 
disciplinas, artefactos e papéis do processo (KRUCHTEN, 2003). 
1.4.3.1.2 Dimensão Dinâmica 
A arquitectura do RUP apresenta quatro fases no aspecto dinâmico: concepção, 
elaboração, construção e transição, como apresenta a figura 4. Essas fases 
podem conter várias iterações (KRUCHTEN, 2003). 
 
Figura 4: As quatro fases do RUP 
19 
 
A Concepção é a fase da criação do escopo do projecto; nela é realizada a 
avaliação de risco, uma estimativa dos recursos necessários e o cronograma 
dos marcos temporais mais importantes. Todos os actores envolvidos na 
iteração do sistema também são identificados nesta fase. Nesta fase são 
desenvolvidos, também, os seguintes artefactos: 
 Caso de negócio inicial; 
 Formulação do documento de visão geral dos requisitos do projecto; 
 Relatório inicial de avaliação de risco; 
 Estimativa de recursos; 
 Cronograma inicial; 
 Protótipos iniciais. 
A elaboração é a especificação e eliminação dos pontos de maior risco. Nesta 
fase são desenvolvidos os seguintes requerimentos: 
 Modelo de casos de uso 
 Análise e projecto do sistema; 
 Relatórios de Riscos; 
 Plano de gerenciamento; 
 Alocação da equipe; 
 Planeamento das fases, mostrando suas iterações e conteúdos. 
 Realiza-se a análise do domínio do problema e projecta uma arquitectura 
para o sistema. 
A construção é o início do desenvolvimento do sistema, ao final de cada ciclo, 
pode surgir uma versão utilizável do processo. Nesta fase, são desenvolvidos 
os seguintes requisitos: 
 Sistema de software funcionando e documentação associada pronta 
para ser liberada aos usuários; 
 Casos de testes baseados em cenários e resultados de testes; 
Por último, a transição: implantação do software e transferência do software 
para o usuário do sistema (KRUCHTEN, 2003). 
20 
 
1.4.3.1.3 Dimensão Estática 
A dimensão estática possui quatro conceitos chaves que definem quem faz o 
quê, como e quando? 
 Workers (trabalhadores) - quem; 
 Actividades - como; 
 Objectos - o quê; 
 Fluxos de trabalho (workflows) - quando. 
O RUP possui também, nove disciplinas, as quais estão detalhadas a seguir: 
Modelagem do negócio - Esta disciplina visa o entendimento da estrutura e a 
dinâmica da organização; o entendimento dos problemas e; a identificação das 
melhorias. 
Requisitos - Nesta disciplina é possível estabelecer uma concordância entre os 
envolvidos no projecto sobre os requisitos do sistema, bem como os limites do 
sistema, estimar o tempo e custo de desenvolvimento. 
Análise e Projecto - Esta disciplina visa transformar os requisitos em projecto; 
construir uma arquitectura para o sistema e; adaptar o projecto ao ambiente. 
Implementação - Visa estruturar o código, bem como implementar classes e 
Objectos; testar e integrar as unidades. 
Testes - Nesta disciplina é testado o sistema para a identificação de erros, que 
posteriormente são identificados e documentados; é possível validar o sistema 
de acordo com o que foi especificado e validar se o sistema foi desenvolvido de 
acordo com o projectado. 
Implantação - Esta disciplina visa a certificação da entrega do sistema ao 
usuário final. 
Gerência de Configuração e Mudança - Nesta disciplina é controlado os 
artefactos produzidos no desenvolvimento do projecto. 
Gerenciamento e Planeamento - Esta disciplina controla o gerenciamento de 
21 
 
riscos. Além de disponibilizar guias para planear, executar, acompanhar e 
monitorar o projecto. 
Ambiente - Visa focar nas actividades relacionadas à adaptação do processo 
organizacional do projecto (KRUCHTEN, 2003). 
1.4.3.2 Melhores Práticas 
As melhores práticas apresentadas no RUP descrevem como implantar um bom 
desenvolvimento de software para equipas desenvolvedoras. São elas: 
1.4.3.2.1 Desenvolver Software Iterativamente 
O RUP sugere que o desenvolvedor adopte uma abordagem iterativa, pois nela 
é necessário uma maior compreensão do problema através de melhorias 
sucessivas, para gerar gradativamente uma solução eficaz a cada iteração. A 
abordagem iterativa no desenvolvimento verifica os itens de maior risco em cada 
etapa do ciclo de vida, reduzindo significativamente o perfil de um projecto de 
risco (IBMa, 1998). 
Pois cada iteração termina com uma versão executável, o desenvolvedor 
permanece focado em produzir resultados e a verificação de estados frequentes 
ajudam a garantir que o projecto permaneça dentro do cronograma. Uma 
abordagem iterativa também tornam mais fáceis as mudanças tácticas nos 
requisitos, nas funcionalidades e/ou no cronograma (IBMa, 1998). 
1.4.3.2.2 Gerenciamento de Requisitos 
O RUP sugere ao desenvolvedoruma excelente maneira de capturar os 
requisitos funcionais. Essa prática apresenta como obter, organizar o 
documento de funcionalidade e restrições; como acompanhar e documentar 
compromissos e decisões; e facilmente como capturar os requisitos de negócio 
(IBMb, 2011). 
1.4.3.2.3 Uso de Arquitectura Baseada em Componentes 
O processo concentra-se no desenvolvimento inicial de uma arquitectura 
22 
 
robusta executável. Ele descreve como projectar uma arquitectura flexível, 
acomoda as mudanças, é intuitivamente compreensível e promove a 
reutilização de software mais eficiente. O RUP apoia o desenvolvimento de 
software baseado em componentes (IBMb, 2011). 
1.4.3.2.4 Modelagem Visual de Software 
As abstracções visuais ajudam o desenvolvedor a se comunicar com os 
diferentes aspectos software; a ver como elementos do sistema se encaixam; 
manter a coerência entre um projecto e sua execução; e promover a 
comunicação inequívoca (IBMb, 2011). 
1.4.3.2.5 Verificar Qualidade de Software 
Actualmente o fraco desempenho de aplicativos e a pouca confiabilidade são 
factores comuns que impedem drasticamente a aceitação dos pedidos de 
software. Assim, a qualidade deve ser focada no que diz respeito aos requisitos 
baseados em confiabilidade, funcionalidade, desempenho da aplicação e 
desempenho do sistema. Esta prática auxilia no planeamento do projecto, na 
implementação, na execução e na avaliação dos testes (IBMb, 2011). 
1.4.3.2.6 Gestão de Alterações no Software 
Em todo software há mudanças, em alguns casos, estas mudanças são 
inevitáveis, por isso a capacidade de gerir a mudança e de ser capaz de 
acompanhar as mudanças é essencial. Esta prática descreve como controlar, 
acompanhar e monitorar as mudanças para permitir o desenvolvimento iterativo 
sucesso (IBMb, 2011). 
1.4.4 A Linguagem UML 
A Unified Modeling Language ™ - UML® é uma especificação da Object 
Management Group - OMG® (OMG, 1997-2011). É uma linguagem gráfica de 
modelagem para visualizar, especificar, construir e documentar os artefactos de 
sistemas de Objectos distribuídos. 
A UML possui treze modelos gráficos que estão divididos em duas categorias, 
23 
 
os diagramas de aplicações estáticas que representam a estrutura e os 
diagramas de comportamentos, no entanto dentro desta última categoria, existe 
uma subcategoria que compõe os diagramas de interacção (SILVA, 2007). 
A categoria de diagramas de Estrutura inclui e diagrama de utilização diagrama 
de classe, diagrama de objecto, diagrama de componentes, diagrama de 
estrutura composta, diagrama de pacote (SILVA, 2007). 
Os diagramas de Comportamento são: diagrama de caso de uso, diagrama de 
máquina de estados e diagrama de actividades. Em sua subcategoria Interacção 
estão inclusos os diagramas de sequência, comunicação, visão geral de 
interacção e por ultimo, porém não menos importante o de temporização 
(SILVA, 2007). 
1.4.4.1 Principais Diagramas UML 
Os diagramas UML abordados neste trabalho são: Caso de Uso, Sequência, 
Actividade, Classe, Estado e Utilização. 
1.4.4.1.1 Diagrama de Caso de Uso 
O diagrama de caso de uso está relacionado à modelagem dinâmica do sistema. 
Ele é composto por elementos sintácticos denominados “atores” e relações que 
envolvem esses elementos (SILVA, 2007). A figura 5 apresenta um exemplo de 
um diagrama de caso de uso. 
 
Figura 5: Exemplo de diagrama de caso de uso 
24 
 
1.4.4.1.2 Diagrama de Sequência 
O diagrama de sequência também está relacionado à modelagem dinâmica do 
sistema. E representa a interacção entre os Objectos na troca de mensagens na 
ordem temporal em que elas acontecem. A leitura das mensagens que são 
enviadas de Objectos para outros Objectos é feita de cima para baixo (SILVA, 
2007). A figura 6 apresenta um exemplo de um diagrama de sequência. 
 
Figura 6: Exemplo de diagrama de sequência 
1.4.4.1.3 Diagrama de Actividade 
O diagrama de actividades é composto por actividades, vista como um conjunto 
de actividades ou de acções. Este diagrama representa uma actividade 
correspondente ao sistema. Conforme mostrado na figura 7. 
 
Figura 7: Exemplo de diagrama de actividade 
25 
 
1.4.4.1.4 Diagrama de Classe 
O diagrama de classes representa a estrutura e os relacionamentos das classes. 
No entanto, as classes e os relacionamentos cedidos a elas são os elementos 
sintácticos básicos do diagrama de classes (SILVA, 2007). A figura 8 apresenta 
um exemplo de um diagrama de classe. 
 
Figura 8: Exemplo de diagrama de Classe 
1.4.4.1.5 Diagrama de Estado 
O diagrama de estado representa o estado em que um objecto se encontra no 
sistema. Com isso, os elementos principais desse diagrama são os estados e 
as transições. Um objecto muda de estado com o auxílio de uma transição 
(SILVA, 2007). A figura 9 apresenta um exemplo de um diagrama de estado. 
26 
 
 
Figura 9: Exemplo de diagrama de Estado 
1.4.4.1.6 Diagrama de Componente 
Este diagrama demonstra os componentes do sistema e a relação entre esses 
componentes. Assim o diagrama representa a classe organizada, especificando 
a qual classe pertence cada um dos componentes. Conforme a figura 10. 
 
Figura 10: Exemplo de diagrama de Componente 
1.4.4.1.7 Diagrama de Utilização 
O diagrama de utilização, mais conhecido como diagrama de implantação 
representa os elementos do sistema necessários para a execução. 
Representando assim, a modelagem estrutural do sistema, através de nodos ou 
27 
 
instâncias de nodos. Conforme a figura 11. 
 
Figura 11: Exemplo de diagrama de Utilização 
1.4.5 Metodologias de Desenvolvimento de Software 
O software será desenvolvido por meio do processo de engenharia de software 
Rational Unified Process® - RUP, utilizado de forma configurada, utilizando 
assim, parte do processo RUP, pois ele é um processo muito complexo. 
O RUP apresenta seis das melhores práticas para um bom desenvolvimento de 
como desenvolver o software iterativamente, gerar requisitos, usar arquitecturas 
baseadas em componentes, modelar software visualmente, verificar a qualidade 
do software, controlar as mudanças do software (IBMb, 2011). 
A modelagem do software será realizada com a utilização das ferramentas 
Microsoft® Oficce Visio® (12.0.4518.1014) MSO (12.0.4518.1014, A linguagem 
que será usada para a implementação será Xhtml e na plataforma de 
desenvolvimento NetBeansIDE e foi seleccionado um Sistema Gerenciador de 
Base de Dados livre, o MySQL. 
1.5 Técnicas de Orientação a Objectos – OO 
Segundo Martin e Odell (1996), as técnicas OO mudam a visão que os analistas 
têm do mundo. Em vez de pensarem em processos e na sua decomposição, 
eles pensam em objectos e no comportamento destes. O objecto internamente 
pode ser complexo, porém o analista não precisa entender esta complexidade 
28 
 
e sim, saber como se comporta tal objecto e como utilizá-lo. Segundo Rumbaugh 
(1994), a modelagem e o projecto baseado em objectos são um novo modo de 
estudar problemas com utilização de modelos fundamentados em conceitos do 
mundo real. A estrutura básica é o objecto, que combina a estrutura e o 
comportamento dos dados em uma única entidade. Os modelos baseados em 
objectos são úteis para a compreensão de problemas, para a comunicação com 
os peritos em aplicações, para modelar empresas, preparar documentação e 
projecta programas e bancos de dados. 
As vantagens da OO são: 
 Maior facilidade para reutilização de códigos e por consequência do 
projecto; 
 Utilização de um padrão único durante todo o processo de criação do 
software; 
 Maior adequação à arquitectura cliente /servidor; 
 Ciclo de vida mais longo para os sistemas; 
 Menor custo para o desenvolvimento e manutenção de sistemas. 
1.5.1 Conceitos Fundamentais da OO 
Alguns conceitos que diferenciam a OO dos outros métodos são mostrados 
abaixo: 
Abstracção - Segundo Cood (1991), é o princípio que leva a ignoraros aspectos de 
um assunto não relevante para o propósito em questão, tornando possível uma 
concentração maior nos assuntos principais. Consiste na selecção que o analista 
faz de alguns aspectos, ignorando outros. As formas de abstracção existentes são: 
procedimentos e dados; 
 Encapsulamento - Segundo Furlan (1998), significa omitir informações 
pelo princípio de que uma determinada entidade esconde informações 
as quais são necessárias apenas à mesma. É fundamental que o objecto 
proteja seus dados, não permitindo que o usuário do objecto os acesse 
directamente, mas sim através de métodos; 
29 
 
 Herança – É um mecanismo que permite a propagação das 
responsabilidades de um objecto para o outro (PRESSMAN, 2011); 
 Polimorfismo - Conceito usado em Programação OO para denotar a 
característica segundo a qual linguagem suporta a utilização do mesmo 
identificador (o mesmo nome) para métodos de classes diferentes. A 
rigor, o polimorfismo aparece quando se usa o mesmo nome para tarefas 
similares em classes diferentes. É uma característica que reduz o 
esforço necessário para aumentar o sistema existente (Pressman, 
2011). 
1.6 Sistema de Informação (SI) 
Com o avanço da tecnologia de informação, as organizações passaram a utilizar 
sistemas de informações (SI) para as apoiar suas actividades, sendo 
desenvolvidos vários sistemas para atender aos requisitos específicos das 
diversas unidades ou sectores de actividades. O Sistema de Informação 
Um sistema de informação (SI) é um tipo especializado de sistema e pode ser 
definido de diversas formas distintas. Segundo Stair e Reynolds (2006), um SI 
é um conjunto de componentes inter-relacionados que recolham, manipulam e 
disseminam dados e informações para proporcionar um mecanismo de 
realimentação para atingir um objectivo. 
1.6.1 Processo de Desenvolvimento de SI 
O Desenvolvimento de um sistema de informação, independentemente do 
modelo de ciclo de vida utilizado, abrange basicamente 4 estágios: 
 Problema inicial, que pode ser um erro em um sistema/software existente 
ou a necessidade da criação de um software para automatizar um 
processo; 
 Definição e análise do problema que deverá ser resolvido; 
 Desenvolvimento técnico ou codificação que resolverá o problema 
através da aplicação de alguma tecnologia; 
 Implantação da solução, ou seja, o sistema é entregue ao Utilizador final. 
30 
 
Os modelos de ciclo de vida de desenvolvimento de S.I. seguem alguns 
padrões: 
 Depende da natureza do sistema que será desenvolvido; 
 Representam tentativas de solucionar um problema caótico; 
 Ajuda no gerenciamento de um processo de desenvolvimento de S.I. 
Modelo em cascata - No modelo em cascata, as actividades de análise, de 
projecto e de implementação são executadas sequencialmente, isto é, uma 
após a outra, sem haver interacção entre as fases. O modelo em cascata é 
composto pelas seguintes fases: 
Modelagem do sistema: é a fase onde se especificam os requisitos do 
sistema, os incluindo de informação e negócios, ao qual o programa está 
sendo executado; 
Análise de requisitos: é a fase ao qual são modelados os requisitos de 
informação, os requisitos funcionais, comportamentais, de desempenho e de 
interface do software; 
Projecto: onde são projectadas as estruturas de dados e onde é mapeado em 
procedimentos, a arquitectura e o comportamento do sistema; 
Codificação: nesta fase o projecto é transformado numa linguagem 
compreendida pelo computador; 
Testes: onde se verifica e valida o software; 
Manutenção: onde se garante a usabilidade do software, ou seja, onde se 
garante os utilizadores a facilidade e satisfação do uso do software. 
O modelo em cascata apresenta uma vantagem que é a de, no decorrer do 
desenvolvimento do sistema, só se avança para a próxima fase quando o cliente 
valida e aceita os produtos finais (documentos, modelos, programas) da tarefa 
actual. 
No entanto, esse modelo apresenta uma inconveniência - caso o sistema não 
obtiver os resultados originalmente esperados pelo cliente, este fique 
31 
 
desapontado assim levar ao desperdício de tempo e de recursos indevidamente 
(Silva & Videira, 2005). 
Prototipagem - Segundo Laudon [1998], a prototipagem consiste na construção 
de um sistema experimental, de forma rápida e barata para avaliação dos 
Utilizadores finais. Interagindo com o protótipo, os Utilizadores podem ter uma 
melhor ideia das informações requeridas. O protótipo validado pelos Utilizadores 
pode ser usado como um modelo para a criação do sistema final. 
A prototipagem como paradigma pode ser problemática por muitas razões. 
Muitas vezes faz concessões de implementação a fim de colocar um protótipo 
em funcionamento rapidamente. 
Com o passar do tempo, as funções do sistema acabam se tornando familiares 
e o projectista acaba se esquecendo de todas as razões pelas quais elas eram 
inadequadas, tornando desta forma, a opção menos ideal parte como integrante 
do sistema. 
1.7 Sistema de gestão Base de Dados 
Nas diversas áreas de conhecimento surge frequentemente a necessidade de 
recolher e processar dados que possuem um volume significativo e que se 
encontram inter-relacionados. Nestes casos é necessário gerir esses dados de 
um modo eficaz, de tal forma que não existam perdas de informação, que a 
organização dos dados permita a sua fácil compreensão e que o seu 
processamento por meios informáticos seja possível com eficiência. Durante a 
década de 70 eram já muitas as deficiências sentidas em diversas áreas como 
resultado da organização dos dados em simples ficheiros. Contudo, a tecnologia 
informática da época apenas permitiu que grandes organizações (como os 
Bancos, por exemplo) recorressem a um software específico, denominado 
sistema gestor de bases de dados (SGBD), bem diferente dos que existem 
actualmente, para suprir algumas dessas deficiências. 
Nos últimos anos, o desenvolvimento da informática, quer no que respeita o 
hardware como a software, conjuntamente com a enorme baixa dos seus custos 
financeiros, permitiu que a utilização dos SGBD para criação, manutenção e 
32 
 
processamento de bases de dados se banalizasse e que estes sistemas se 
tornassem auxiliares indispensáveis nos problemas que envolvem dados de 
vários tipos. A capacidade, que muitos SGBD possuem, de permitir acessos de 
utilizadores em rede e de suportar dados distribuídos por vários computadores 
a funcionarem em rede, contribui também para a crescente utilização dos 
SGBD. 
Uma base de dados é um conjunto de dados relacionados que é utilizado 
recorrendo a um sistema gestor de Bases de Dados (SGBD). Uma Base de 
Dados representa uma parte da realidade que é relevante para a resolução de 
um determinado conjunto de problemas. Presentemente, existem no mercado 
diversos SGBD, os mais utilizados são os SGBD relacionais que permitem criar 
bases de dados relacionais. Os conceitos de Base de Dados relacional foram 
apresentados em 1970 e desde então vários fornecedores de Informática têm 
vindo a desenvolver SGBD relacionais. O Mysql inclui-se nesta categoria de 
SGBD e destina-se a ser utilizado em computadores com sistema operativo 
Windows. ORACLE e Informix, Microsoft Access e Sql Server constituem 
exemplos de outros SGBD relacionais que actualmente são muito utilizados em 
computadores com sistema operativo Windows ou UNIX. Neste trabalho, foi 
usado o sistema de gestão de base de dados (SGBD) MySQL, por considerar 
que o seu servidor de base de dados é extremamente rápido, seguro e fácil de 
usar, além das outras funções de conectividade, velocidade e a segurança que 
torna este sistema adaptável em ambiente de Internet para aceder a Base de 
Dados. 
Uma das razões para o uso deste SGBD é que o seu motor de base de dados 
MySQL proporciona um armazenamento seguro e fiável tanto para os dados 
relacionais, como estruturados, permitindo deste modoa criar e gerir aplicações 
de dados de elevada disponibilidade e desempenho (Davidson, 2006). 
Contrariamente a outros tipos de SGBD utilizados sobretudo entre 1970 e 1985, 
os SGBD relacionais não surgiram na sequência do aperfeiçoamento das 
técnicas de processamento de ficheiros, mas sim, a partir de um conjunto de 
conceitos teóricos apresentados em 1970 por E. F. Codd. Os conceitos que 
33 
 
Codd introduziu foram, posteriormente, desenvolvidos por outros autores e 
actualmente são adoptados pelos SGBD mais utilizados. 
As tecnologias de bases de dados vêm contribuir de forma significativa, para a 
viabilização dos requisitos de correcção e actualização dos dados, fornecendo 
meios e ferramentas para a extracção da informação relevante na altura em que 
é necessária e com o formato adequado. Dentre elas (as tecnologias de bases 
de dados), cita-se a persistência dos dados, integridade, segurança e um 
aumento da eficiência, pois com o uso de um SGBD, as informações podem ser 
extraídas e alteradas de modo mais prático e eficaz. (Silberschatz, 1999). 
A principal vantagem é a utilização de SGBDs Relacionais disponíveis no 
mercado. Porém, tem-se como dificuldade a questão de criação das consultas 
ao sistema, pois, deve-se percorrer duas estruturas distintas para disponibilizar 
o resultado esperado (Câmara, 1995). 
Outra opção é a utilização de extensões espaciais desenvolvidas sobre SGBDs 
Objectos – Relacional (SGBDOR), que definem funcionalidades e 
procedimentos capazes de armazenar, aceder e analisar dados espaciais 
(Ferreira, 2003). As vantagens dos SGBD relacionais devem-se essencialmente 
a três factores: 
 Simplicidade dos conceitos que utilizam; 
 Existência de definições formais para os conceitos que permitiram uma 
rápida divulgação e a adesão de diversos fabricantes de software; 
Adequação à representação de muitos dos aspectos que constituem a 
realidade. 
 
34 
 
CAPITULO 2. METODOLOGIA E ANÁLISE E TRATAMENTO DE DADOS. 
2.1 Metodologia 
A metodologia de pesquisa para a finalização do estudo foi à pesquisa de campo 
utilizando a distribuição de questionários para os professores, estudantes e 
funcionários administrativos. O questionário teve como base uma pesquisa 
bibliográfica retirada de livros, apostilas, artigos de revista e internet. A escolha 
do questionário tem como objectivos de saber qual é a opinião a cerca da 
criação de sistema de gestão integrada para facilitar no processo de gestão da 
informação. 
Deste estudo foi feito uma análise preliminar, baseado em pesquisa de carácter 
exploratória, recolha de dados e informações previamente analisadas, com o 
objectivo de avaliar a viabilidade da pesquisa anunciada, e da qual resultou a 
opção aos seguintes procedimentos metodológicos: 
Descritivo: A pesquisa realizada pode ser considerada como uma investigação 
do tipo descritivo, e teve como objectivos específicos a descrição de como é 
actualmente feito o armazenamento da informação. Foram seleccionadas uma 
série de questões, que foram incluídas em questionários dirigidos a uma 
amostra casual constituída por professores, estudantes e funcionários 
administrativos. 
2.2 Análise de Dados 
Nesta etapa foi feita a análise qualitativa de dados, que é um conjunto de 
técnicas de análise das comunicações visando obter, por procedimentos, 
sistemáticos e objectivos de descrição de conteúdo das mensagens, indicadores 
que permitam a inferência de conhecimentos relativos às condições de 
produção/concepção (variáveis inferidas) destas mensagens (Galton & Hood, 
2004), sendo que em alguns casos foi feita uma análise quantitativa dos dados. 
Este processo de análise teve três etapas nomeadamente: 
1. A pré-análise; 
2. A exploração do material; 
35 
 
3. O tratamento dos dados, inferência e interpretação. 
Pré-análise 
A Pré-análise consistiu na escolha dos documentos bem como triagem das 
entrevistas efectuadas, a formulação dos objectivos e por fim a identificação dos 
indicadores que irão fundamentar a interpretação final. 
Exploração do material 
Nesta etapa, primeiro foi feita a codificação, que é “o processo pelo qual os 
dados brutos são transformados sistematicamente e agregados em unidades, 
os quais permitem uma descrição exacta das características pertinentes ao 
conteúdo”. (Galton & Hood, 2004). 
Em seguida, fez-se a categorização que é a operação de classificação dos 
elementos constitutivos de um conjunto, por diferenciação, seguidamente, por 
agrupamento (Galton & Hood, 2004). A categorização não introduz desvios, mas 
dá a conhecer índices invisíveis ao nível dos dados brutos. Por fim, realizou-se 
o tratamento e interpretação dos dados. 
Em resumo, para a realização deste trabalho, foram usadas entrevistas, as 
observações, e a revisão de documentação para a recolha de dados e 
compreensão do funcionamento da ESPLN, também foi feita a análise 
qualitativa dos dados recolhidos. 
Nesta pesquisa foi feita a recolha, observação, registo, análise e interpretação 
dos factos sem manipularmos. Portanto pretendeu-se buscar com a máxima 
precisão possível do nível de dificuldades no armazenamento da informação na 
ESPLN. 
Neste estudo, foram utilizadas as pesquisas bibliográficas, e, para a “exploração 
do campo de pesquisa” foi elaborado entrevistas a alguns membros da direcção 
da ESPLN. 
36 
 
Nº Local Entrevist
ados 
Objectivo 
 
Resultado Duração & 
Data 
realização 
 
1 ESPLN Decano 
da ESPLN 
Perceber o 
funcionament
o e as 
actividades 
realizadas na 
ESPLN 
Visão Geral 
da ESPLN, 
percepção 
dos 
processos 
nela 
efectuada. 
25 Minutos 
23/03/2016 
2 ESPLN Vice 
Decano 
para 
Assuntos 
Académic
os 
Perceber que 
actividades 
são levadas a 
cabo, bem 
como as 
dificuldades 
encaradas no 
processo de 
gestão 
académica; 
 
Percepção 
das 
actividades 
realizadas no 
DAAC da 
ESPLN 
40 Minutos 
23/03/2016 
3 ESPLN Vice 
Decano 
para os 
Assuntos 
científicos 
Perceber que 
actividades 
são levadas a 
cabo, bem 
como as 
dificuldades 
encaradas no 
processo de 
gestão 
científica; 
 
Percepção de 
como é feita a 
selecção de 
trabalhos 
científicos 
20 Minutos 
24/03/16 
4 ESPLN Chefe do 
DAAC da 
ESPLN 
Perceber que 
actividades 
são levadas a 
cabo, bem 
como as 
dificuldades 
encaradas no 
processo de 
gestão do 
DAAC; 
 
Como 
funciona o 
processo da 
gestão das 
informações 
nesta área. 
25 Minutos 
24/03/16 
Tabela 1: Quadro de Entrevistas 
As entrevistas tiveram como principal objectivo identificar os problemas 
existentes na ESPLN relativamente aos procedimentos relacionados com os 
37 
 
estudantes e descrever o que pensam os entrevistados sobre a metodologia de 
trabalho até então empregada na ESPLN. 
O entrevistado Dr. Jorge Dias Veloso possui vasto conhecimento sobre Sistema 
de Informação, teoricamente tem ideias sólidas e bem fundamentadas do que 
poderia ser um sistema adequado à realidade da ESPLN.O entrevistado Dr. 
Domingos Veríssimo possui noções de informática e já teve contacto directo 
prático com sistemas de informação escolar informatizados. 
2.3 Análise e Tratamento de Dados 
Nesta etapa foi feita a análise qualitativa de dados, que é um conjunto de 
técnicas de análise das comunicações visando obter, por procedimentos 
sistemáticos e objectivos de descrição de conteúdo das mensagens, indicadores 
que permitam a inferência de conhecimentos relativos às condições de 
produção/concepção (variáveis inferidas) destas mensagens (Galton & Hood, 
2004), sendo que em alguns casos foi feita uma análise quantitativa dos dados. 
2.3.1 O tratamento dos dados, inferência e interpretação 
 
Nesta etapa, fez-se a análise dos dados obtidos por meios dos questionários 
aplicados a um total de 36 indivíduos, dos quais 12 docentes, 12 funcionários 
administrativos e 12 estudantes. 
Resultado dos questionários dirigidos aos estudantes 
1. Dados do estudante 
Sexo 
Masculino Feminino8 4 
66,66% 33,33% 
 
38 
 
 
Gráfico 1: Dados de estudantes 
2. Já ouviu falar de sistema de gestão académico? 
Sim Não 
9 3 
75% 25% 
 
 
Gráfico 2: Dados referentes a questão 1 do questionário aplicado aos estudantes para o 
diagnóstico da situação 
Com respeito a Pergunta 1 Já ouviu falar de sistema de gestão académico? 
Resultou 9 Sim fazendo 75% e 3 Não fazendo 25% 
3. Onde ouviu de sistema integrado de gestão? 
 
 
 
66,66%
33,33%
0%
10%
20%
30%
40%
50%
60%
70%
Estudantes
Sexo Masculino
Sexo Feminino
75%
25%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Estudantes
Sim
Não
39 
 
Televisão Revista Internet Rádio Escola 
7 1 1 0 0 
77,77% 11,11% 11,11% 0% 0% 
 
 
 
Gráfico 3: Dados referentes a questão 2 do questionário aplicado aos estudantes para o 
diagnóstico da situação 
Com respeito a pergunta 2 Onde ouviu de sistema integrado de gestão? 
Resultou 7 ouviram na Televisão fazendo 77,77%, 1em revista fazendo 11,11% 
e 1 na Internet fazendo 11,11%. 
4. Fez o uso de um sistema de gestão académico? 
Sim Não 
0 12 
0% 100% 
 
11,11%
77,77%
11,11%
0% 0% 0%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
Estudantes
Revista
Televisão
Internet
Rádio
Escola
Outros
40 
 
 
Gráfico 4: Dados referentes a questão 3 do questionário aplicado aos estudantes para o 
diagnóstico da situação 
Com respeito a pergunta 3 Fez o uso de um sistema de gestão académico? 
Resultou que nenhum Sim fazendo 0% e 12 Sim fazendo 100%. 
 
5. Acredita que a criação de Sistema de Gestão Académica, contendo toda 
informação académica, onde os estudantes podem consultar (notas, datas 
de provas, calendário, pagamento de emolumentos e outras informações), 
facilitaria o processo de obtenção de informações? 
 
Sim Não 
12 0 
100% 0% 
 
 
0%
100%
0%
20%
40%
60%
80%
100%
120%
Estudantes
Sim
Não
41 
 
 
Gráfico 5: Dados referentes a questão 4 do questionário aplicado aos estudantes para o 
diagnóstico da situação 
Com respeito a Pergunta 4 Acredita que a criação de Sistema de Gestão 
Académica, contendo toda informação académica, onde os estudantes 
podem consultar (notas, datas de provas, calendário, pagamento de 
emolumentos e outras informações), facilitaria o processo de obtenção de 
informações? Resultou em 12 Sim que faz 100% e 0 Não fazendo 0% 
5.1 Justifique a opção escolhida? 
Facilita o acesso a informação a partir do 
sistema 
5 41,66% 
Reduz o tempo gasto 4 33,33% 
Eficiência na informação 3 25% 
 
100%
0%
0%
20%
40%
60%
80%
100%
120%
Estudantes
Sim
Não
42 
 
 
Gráfico 6:Dados referentes a questão 4.1 do questionário aplicado aos estudantes para 
o diagnóstico da situação 
No que diz respeito a pergunta 4.1 Justifique a opção escolhida? Resultou 5 
Facilita o acesso a informação a partir do sistema fazendo 41,66%, 4 Reduz o 
tempo gasto fazendo 33,33% e 3 Eficiência na informação fazendo 25% 
6. Que dificuldade tem encontrado no acesso a informação? 
Consulta de notas 4 33,33% 
Entrada e Entrega de declaração 3 25% 
Consulta dos horários e calendários de 
prova 
3 25% 
Pagamento de emolumentos 2 16,66% 
 
 
Gráfico 7: Dados referentes a questão 5 do questionário aplicado aos estudantes para o 
diagnóstico da situação 
41,66%
33,33%
25%
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
Estudantes
Facilita o acesso a
informação a partir do
sistema
Reduz o tempo gasto
Eficiência na informação
33,33%
25% 25%
16,66%
0%
5%
10%
15%
20%
25%
30%
35%
Estudantes
Consulta de notas
Entrada e Entrega de
declaração
Consulta dos horários e
calendários de prova
Pagamento de
emolumentos
43 
 
Quanto a pergunta 5 Que dificuldade tem encontrado no acesso a 
informação? Resultou 4 em Consulta de notas fazendo 33,33%, 3 em Entrada 
e Entrega de declaração fazendo 25%, 3 em Consulta dos horários e 
calendários de prova fazendo 25% e 2 em Pagamento de emolumentos fazendo 
16,66. 
Resultado dos questionários dirigido aos docentes 
1. Dados dos docentes 
Área de formação 
Matemática Pedagogia Língua 
Portuguesa 
Biologia 
M F M F M F M F 
2 1 4 2 1 1 0 1 
16,67% 8,33% 33,33% 16,67% 8,33% 8,33% 0% 8,33% 
 
 
 
2. Como tem gerido os dados académicos dos alunos? 
Papel Computador Outros 
3 9 0 
25% 75% 0% 
 
16,67%
33,33%
8,33%
0%
8,33%
16,67%
8,33% 8,33%
0%
5%
10%
15%
20%
25%
30%
35%
Matemática Pedagogia Língua
Portuguesa
Biologia
Sexo Masculino
Sexo Feminino
Gráfico 8: Dados dos Docentes 
44 
 
 
Com respeito a Pergunta 1 Como tem gerido os dados académicos dos 
alunos? Resultou 3 em Papel fazendo 25%, 9 em Computador e 0 em Outros 
fazendo 0%. 
3. Que dificuldade principal observou no processamento da informação na 
ESPLN? 
Atraso no 
processamento 
Indisponibilidade 
de informação 
Informação 
deturpada 
Outras 
7 4 1 0 
58,33% 33,33% 8,33% 0% 
 
 
Gráfico 10: Dados referentes a questão 2 do questionário aplicado aos Docentes para o 
diagnóstico da situação 
Com respeito a pergunta 2 Que dificuldade principal observou no 
processamento da informação na ESPLN? Resultou que 7 em Atraso no 
58,33%
33,33%
8,33%
0%
0%
10%
20%
30%
40%
50%
60%
70%
Docentes
Atraso no processamento
Indisponibilidade de
informação
Informação deturpadaprova
Outras
25%
75%
0%
0%
10%
20%
30%
40%
50%
60%
70%
80%
Docentes
Papel
Computador
Outros
Gráfico 9: Dados referentes a questão 1 do questionário aplicado aos Docentes para o 
diagnóstico da situação 
45 
 
processamento fazendo 58,33, 4 em Indisponibilidade de informação fazendo 
33,33%, 1 em Informação deturpada fazendo 8,33% e 0 em outras fazendo 0%. 
4. Já utilizou um Sistema Integrado de Gestão? 
Sim Não 
1 11 
8,33% 91,67% 
 
 
Gráfico 11: Dados referentes a questão 3 do questionário aplicado aos Docentes para o 
diagnóstico da situação 
Com respeito a pergunta 3 Já utilizou um Sistema Integrado de Gestão? 
Resultou em 1 Sim fazendo 8,33% e 11 Não fazendo 91,67%. 
 
5. Achas necessário a implementação de um Sistema integrado de gestão para 
a ESPLN? 
Sim Não 
12 0 
100% 0% 
 
 
8,33%
91,67%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Docentes
Sim
Não
46 
 
 
Gráfico 12: Dados referentes a questão 5 do questionário aplicado aos Docentes para o 
diagnóstico da situação 
Com respeito a pergunta 5 Achas necessário a implementação de um 
Sistema integrado de gestão para a ESPLN? Resultou em 12 Sim fazendo 
100% e 0 Não fazendo 0%. 
 
6. Após a implementação do Sistema o quê que espera que aconteça? 
Acessibilidade da informação 3 25% 
Rapidez no processamento da informação 2 16,67% 
Melhoria do processo actual 3 25% 
Facilidade na obtenção da Informação 4 33,33% 
 
100%
0%
0%
20%
40%
60%
80%
100%
120%
Docentes
Sim
Não
47 
 
 
Gráfico 13: Dados referentes a questão 5 do questionário aplicado aos Docentes para o 
diagnóstico da situação 
Com respeito a pergunta 5 Após a implementação do Sistema o quê que 
espera que aconteça? Resultou que 3 em Acessibilidade da informação 
fazendo 25%, 2 em Rapidez no processamento da informação fazendo 16,67%, 
3 em Melhoria do processo actual fazendo 25% e 4 em Facilidade na obtenção 
da Informação fazendo 33,33%. 
 
Resultado dos questionários dirigidos aos Administrativos 
1. Dados do Administrativos 
Sexo 
Masculino Feminino 
5 7 
41.66 % 58,33% 
 
25%
16,67%
25%
33,33%
0%
5%
10%
15%
20%
25%
30%
35%
Docentes
Acessibilidade da
informação
Rapidez no processamento
da informação
Melhoria do processo actual
Facilidade na obtenção da
Informação
48 
 
 
Gráfico 14: Dados de funcionários Administrativos 
2. Como é feito o tratamento da informação actualmente na sua área de 
serviço? 
Papel Computador Outros 
1 11 0 
8.33% 91.66% 0% 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
41,66%
58,33%
0%
10%
20%
30%
40%
50%
60%
70%
Administrativos
Sexo Masculino
Sexo Feminino
8,33%
91,66%
0%
0%
10%
20%30%
40%
50%
60%
70%
80%
90%
100%
Administrativos
Papel
Computador
Outros
Gráfico 15: Dados referentes a questão 1 do questionário aplicado aos Administrativos para o 
diagnóstico da situação 
49 
 
Com respeito a pergunta 1 Como é feito o tratamento da informação 
actualmente na sua área de serviço? Resultou que 1 em papel fazendo 
8,33%, 11 em computador fazendo 91,66% e 0 em Outros fazendo 0%. 
 
3. Que dificuldade principal observou no processamento da informação na 
ESPLN? 
Falta de 
segurança 
Excesso de 
dados 
Atraso 
na 
resposta 
Outras 
5 4 3 0 
41,66% 33,33% 25% 0% 
 
 
Gráfico 16: Dados referentes a questão 2 do questionário aplicado aos Administrativos 
para o diagnóstico da situação 
Com respeito a pergunta 2 Que dificuldade principal observou no 
processamento da informação na ESPLN? Resultou que 5 em Falta de 
segurança fazendo 41,66%, 4 em Excesso de dados fazendo 33,33%, 3 em 
Atraso na resposta fazendo 25% e o em Outras fazendo 0%. 
4. Já utilizou um Sistema Integrado de Gestão? 
 
Sim Não 
0 12 
0% 100% 
 
41,66%
33,33%
25%
0%
0%
5%
10%
15%
20%
25%
30%
35%
40%
45%
Administrativos
Falta de Segurança
Excesso de Dados
Atraso na Resposta
Outras
50 
 
 
Gráfico 17: Dados referentes a questão 3 do questionário aplicado aos Administrativos 
para o diagnóstico da situação 
Com respeito a pergunta 3 Já utilizou um Sistema Integrado de Gestão? 
Resultou em 0 Sim fazendo 0% e 12 Não fazendo 100%. 
5. Achas necessário a implementação de um Sistema integrado de gestão 
para a ESPLN? 
 
Sim Não 
12 0 
100% 0% 
 
Gráfico 18: Dados referentes a questão 5 do questionário aplicado aos Administrativos 
para o diagnóstico da situação 
Com respeito a pergunta 5 Achas necessário a implementação de um 
Sistema integrado de gestão para a ESPLN? Resultou em 12 Sim fazendo 
100% e 0 Não fazendo 0%. 
0%
100%
0%
20%
40%
60%
80%
100%
120%
Administrativos
Sim
Não
100%
0%
0%
20%
40%
60%
80%
100%
120%
Administrativos
Sim
Não
51 
 
 
6. Após a implementação do Sistema quais são os resultados que esperas? 
Acessibilidade da informação 4 33.33% 
Rapidez no processamento da informação 2 16.66% 
Melhoria do processo actual 2 16.66% 
Facilidade no armazenamento da Informação 4 33,33% 
 
 
Gráfico 19: Dados referentes a questão 5 do questionário aplicado aos Administrativos 
para o diagnóstico da situação 
Com respeito a pergunta 5 Após a implementação do Sistema quais são os 
resultados que esperas? Resultou que 4 em Acessibilidade da informação 
fazendo 33,33%, 2 em Rapidez no processamento da informação fazendo 
16,66%, 2 em Melhoria do processo actual fazendo 16,66% e 4 em Facilidade 
no armazenamento da Informação fazendo 33,33%. 
 
33,33%
16,66% 16,66%
33,33%
0%
5%
10%
15%
20%
25%
30%
35%
Administrativos
Acessibilidade da
informação
Rapidez no processamento
da informação
Melhoria do processo actual
Facilidade no
armazenamento da
Informação
52 
 
CAPITULO 3. PROJECTO DE UM SISTEMA DE GESTÃO INTEGRADA DA 
ESCOLA SUPERIOR PEDAGÓGICA DA LUNDA-NORTE – SGIESPLN. 
Nesta fase do trabalho apresentaremos o projecto de um sistema de gestão que 
vai basear-se em tabelas de especificações do diagrama de caso de uso do 
sistema, para que o programador não tenha dificuldade nenhuma para vir a 
desenvolver o sistema posteriormente. 
3.1 Diagrama Caso de Uso do SGIESPLN 
3.1.1 Especificação dos Casos de Uso de Administrador 
Para uma melhor compreensão de cada funcionalidade do sistema, detalha-se 
a seguir a análise realizada de cada caso de uso do Administrador. 
Efectuar Matricula
Consultar
Visualizar
Upload
Consultar
Lançar Notas
Imprimir
Visualizar
Gerir Comparticipação
Consultar
Imprimir
Upload
Scannear
Estudante
Professor
C
DAC
Administrador
Imprimir
Gerir o Sistema
Consultar
Configurar
Upload
Upload
Imprimir
Manutenção de 
Estudante
Manutenção de Curso
Manutenção de 
Professor
Horários de 
Defesas
C
DAAC
Gerir DAC
Técnico do DRH
C
Gerir DRH
53 
 
Manutenção de 
Estudante
Administrador
 
No diagrama de caso de uso, é descrito o processo de manutenção de 
estudantes. Para uma correcta manutenção, é necessária a informação dos 
campos solicitados. 
Nome Manutenção de Estudante CSU01 
Sumário O administrador realiza a manutenção de um estudante 
Actor primário: Administrador 
Pré-Condição: O administrador com permissões para esta opção estar 
logado. 
Pós Condição: As informações do estudante são alteradas. 
Cenário Principal 
1. O administrador selecciona Manutenção de estudante. 
2. O sistema exibe opções Novo, Pesquisa e Alteração. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a manutenção e o caso de uso é encerrado. 
Cenário Opcional [1]: Inclusão de estudante 
1. Caso o administrador seleccione Inclusão, deverá informar os dados 
solicitados pelo sistema. 
2. O sistema valida a fotografia. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Busca e Alteração de estudante 
1. Caso o administrador seleccione Alteração, deverá informar o 
estudante a ser alterado e alterar os dados desejados. 
2. O sistema valida a fotografia. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção [1]: Dados necessários não informados 
54 
 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Cenário Excepção [2]: Estudante não encontrado na base de dados 
1. Caso não seja encontrado o estudante pesquisado o sistema exibe uma 
mensagem de erro. O caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 2: Caso de uso Manutenção de Estudante 
Manutenção de 
Professor
Administrador
 
No diagrama de caso de uso, é descrito o processo de manutenção de docentes. 
Para uma correcta manutenção, é necessária a informação dos campos 
solicitados. 
Nome Manutenção de Docente CSU02 
Sumário O Utilizador realiza a manutenção de um Docente 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: As informações do Docente são alteradas. 
Cenário Principal 
1. O administrador selecciona Manutenção de Docente. 
2. O sistema exibe opções Novo, Pesquisa e Alteração. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a manutenção e o caso de uso é encerrado. 
Cenário Opcional [1]: Inclusão de Docente 
1. Caso o administrador seleccione Inclusão, deverá informar os dados 
solicitados pelo sistema. 
2. O sistema valida a fotografia, grau académico e número do documento 
de identificação. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
55 
 
Cenário Opcional [2]: Busca e Alteração de Docente 
1. Caso o administrador seleccione Alteração, deverá informar o Docente 
a ser alterado e alterar os dados desejados. 
2. O sistema valida a fotografia grau académico e número do documento 
de identificação. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção [1]: Dados necessários não informados 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Cenário Excepção [2]: Docente não encontrado na base de dados 
1. Caso não seja encontrado o Docente pesquisado o sistema exibe uma 
mensagem de erro. O caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 3: Especificação do CSU Manutenção de Professor 
Manutenção de 
Curso
Administrador
 
No diagrama de caso de uso, é descrito o processo de manutenção de Cursos. 
Para uma correcta manutenção, é necessária a informação dos campos 
solicitados. 
Nome Manutenção Curso CSU03 
Sumário O Administrador realiza a manutenção de um Curso 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição:As informações do Curso são alteradas. 
Cenário Principal 
1. O administrador selecciona Manutenção de Curso. 
2. O sistema exibe opções Novo, Pesquisa e Alteração. 
3. O administrador selecciona a opção desejada. 
56 
 
4. O sistema executa a manutenção e o caso de uso é encerrado. 
Cenário Opcional [1]: Inclusão de Curso 
1. Caso o administrador seleccione Inclusão, deverá informar os dados 
solicitados pelo sistema. 
2. O sistema valida o Docente responsável pelo curso. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Busca e Alteração de Curso 
1. Caso o administrador seleccione Alteração, deverá informar o Docente 
a ser alterado e alterar os dados desejados. 
2. O sistema Solicita o Docente responsável pelo curso e a quantidade de 
estudantes. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção [1]: Dados necessários não informados 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Cenário Excepção [2]: Curso não encontrado no banco de dados 
1. Caso não seja encontrado o Docente pesquisado o sistema exibe uma 
mensagem de erro. O caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 4: Especificação do CSU Manutenção de Curso 
Gerir o Sistema
Administrador
 
No diagrama de caso de uso, é descrito o processo de gestão do sistema. 
Nome Gerir o Sistema CSU04 
Sumário O Administrador realiza a gestão do sistema 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: Verificar todas as operações efectuadas no Sistema 
57 
 
Cenário Principal 
1. O administrador selecciona Gerir Sistema. 
2. O sistema exibe opções Estudantes, Docentes e Actividades gerais. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a tarefa desejada e o caso de uso é encerrado. 
Cenário Opcional [1]: Actividades de Estudantes 
1. Caso o administrador seleccione Actividades. 
 2. O sistema deverá informar todas actividades realizadas pelos 
estudantes. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Actividades de Docentes 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas pelos docentes 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [3]: Actividades gerais 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas no sistema. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção: Nenhuma actividade encontrada 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 5: Especificação do CSU de Gerir o Sistema 
Cunsultar
Administrador
 
No diagrama de caso de uso, é descrito o processo de consultas. 
Nome Consultar CSU05 
Sumário O Administrador realiza consultas do sistema 
Actor primário: administrador 
58 
 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: Verificar todas as operações efectuadas no Sistema 
Cenário Principal 
1. O administrador selecciona Gerir Sistema. 
2. O sistema exibe opções Estudantes, Docentes e Actividades gerais. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a tarefa desejada e o caso de uso é encerrado. 
Cenário Opcional [1]: Actividades de Estudantes 
1. Caso o administrador seleccione Actividades. 
 2. O sistema deverá informar todas actividades realizadas pelos 
estudantes. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Actividades de Docentes 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas pelos docentes 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [3]: Actividades gerais 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas no sistema. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção: Nenhuma actividade encontrada 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 6: Especificação do CSU de Consultar 
 
59 
 
 
Configurar
Administrador
 
No diagrama de caso de uso, é descrito o processo de configuração. 
Nome Configurar CSU06 
Sumário O Administrador realiza a configurações no sistema 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: O administrador efectua as diferentes configurações no 
Sistema 
Cenário Principal 
1. O administrador selecciona Configurações. 
2. O sistema exibe opções Estudantes, Docentes e configurações gerais. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a tarefa desejada e o caso de uso é encerrado. 
Cenário Opcional [1]: configuração de Estudantes 
1. Caso o administrador seleccione configurações. 
 2. O sistema deverá configurar estudantes. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Actividades de Docentes 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas pelos docentes 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [3]: Actividades gerais 
1. Caso o administrador seleccione Actividades. 
2. O sistema deverá informar todas actividades realizadas no sistema. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
60 
 
Cenário Excepção: Nenhuma actividade encontrada 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 7: Especificação do CSU de Configurar 
 
Imprimir
Administrador
 
No diagrama de caso de uso, é descrito o processo de impressão. 
Nome Imprimir CSU08 
Sumário O Administrador realiza impressão de documentos 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: Impressão de qualquer documento. 
Cenário Principal 
1. O administrador selecciona Imprimir. 
2. O sistema exibe opções Relatórios. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a tarefa desejada e o caso de uso é encerrado. 
Cenário Alternativo: Impressão de Relatórios 
1. Caso o administrador seleccione o Relatório. 
 2. O sistema deverá imprimir o Relatório solicitado. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Excepção: Nenhum relatório encontrado 
1. Caso os dados solicitados não sejam informados, o sistema exibe uma 
mensagem de erro, o caso de uso retorna ao passo 3 (Cenário Principal). 
Tabela 8: Especificação do CSU de impressão 
61 
 
Upload
Administrador
 
No diagrama de caso de uso, é descrito o processo de Carregamento de 
ficheiros. 
Nome Upload CSU09 
Sumário O Administrador realiza o carregamento de ficheiros 
Actor primário: administrador 
Pré-Condição: O administrador tem permissões para esta opção e deve 
estar logado. 
Pós Condição: carregar ficheiros no sistema. 
Cenário Principal 
1. O administrador selecciona Upload. 
2. O sistema exibe opções Ficheiros comuns, Documentos oficiais e 
Pesquisa. 
3. O administrador selecciona a opção desejada. 
4. O sistema executa a tarefa desejada e o caso de uso é encerrado. 
Cenário Opcional [1]: Ficheiros comuns 
1. Caso o administrador seleccionar carregar. 
 2. O sistema deverá carregar o ficheiro. 
3. O caso de uso retorna ao passo 4 (Cenário Principal). 
Cenário Opcional [2]: Documentos oficiais 
1. Caso o administrador seleccionar carregar. 
2. O sistema deverá carregar o documento. 
3. O