INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E

COMUNICAÇÃO

SISTEMA INFORMÁTICO DE AVALIAÇÃO DO DESEMPENHO

DO DOCENTE PARA INSTITUTO DE TECNOLOGIAS DE
INFORMAÇÃO E COMUNICAÇÃO – MÓDULO EXTENSÃO

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA.

AUTOR:
Mateus Ngunguvele Castro Abel 1629

Luanda, 2023
 INSTITUTO DE TECNOLOGIAS DE INFORMAÇÃO E
COMUNICAÇÃO

SISTEMA INFORMÁTICO DE AVALIAÇÃO DO DESEMPENHO

DO DOCENTE PARA INSTITUTO DE TECNOLOGIAS DE
INFORMAÇÃO E COMUNICAÇÃO – MÓDULO EXTENSÃO

TRABALHO DE FIM DE CURSO DE LICENCIATURA EM

ENGENHARIA INFORMÁTICA.

AUTOR:
Mateus Ngunguvele Castro Abel 1629
ORIENTADOR:

Campos Calenga Pataca, PhD

CO-ORIENTADOR

Engº Nzuzi Manuel

Luanda, 2023
 Agradecimento

Agradecemos a Deus pela vida e o dom da sabedoria, deu-nos folego para que o dia de
hoje fosse uma realidade e por estar sempre connosco ajudando-nos a ultrapassar
todos os obstáculos encontrados ao longo do percurso, Agradecemos ao nosso tutor
PhD Campos Calenga Pataca e co-tutor Nzuzi Manuel que incansavelmente deram do
seu precioso tempo para poder nos liderar para a concretização deste trabalho.
Aos nossos pais, irmãos e companheiras que sempre nos deram o apoio para minha
formação académica e me compreendiam quando ficávamos ausentes deles enquanto
nós nos dedicávamos na vida académica. Aos nossos amigos que nos incentivaram a
nos dedicar na formação académica e sempre tiveram o interesse. Aos meus docentes
pelos ensinamentos, correções que me ajudaram a crescer e obter um melhor
desempenho no processo da nossa formação académica.

III
 Resumo
A avaliação de desempenho docente possui implicações reais ao nível da atividade do
docente, dos salários, da progressão na carreira e da formação profissional, pelo que
florescem as investigações que analisam os sistemas de avaliação de desempenho em
vários contextos educacionais.

O presente estudo de natureza descritiva e analítica, contempla uma abordagem mista

transversal, configurado sob a forma de um estudo de caso, tem como objetivo principal
desenvolver um sistema interativo de avaliação do desempenho docente do Instituto de
Tecnologias de Informação e Comunicação (SIADD_INSTIC), baseado nos parâmetros
definidos no DP nº121/20 de 27 de abril, com ênfase no módulo extensão. Os sistemas
de avaliação de desempenho do docente existentes não cumprem com todos os
requisitos para tratar o problema a nível do ensino superior, a necessidade de melhorar
o nível de qualidade, segurança, acessibilidade e o controlo dos dados de eventos para
o processo avaliação do desempenho do docente do INSTIC e atender os objetivos do
INSTIC com qualidade, bom desempenho, eficiência rapidez.

Os Sistemas informáticos visam otimizar os processos realizados nas organizações,

contribuindo assim para o controle eficiente da informação nelas gerada. Nesta
pesquisa, um sistema informático de Avaliação do Desempenho do Docente foi
desenvolvido para o Instituto de Tecnologias de Informação e Comunicação.

Para o desenvolvimento do sistema, foi realizado um estudo sobre as metodologias,

ferramentas e tecnologias para o desenvolvimento do sistema. Após o desenvolvimento
do sistema, foram realizados testes para testar o mesmo.

Palavras-chave: Sistema informático, Avaliação do desempenho, Docente, carreira.

IV
 Abstract
Teacher performance evaluation has real implications in terms of teacher activity,
salaries, career progression and professional training, which is why researches that
analyze performance evaluation systems in various educational contexts flourish.

The present descriptive and analytical study, contemplates a cross-sectional mixed

approach, configured in the form of a case study, has as main objective to develop an
interactive system of evaluation of the teaching performance of the Institute of Information
and Communication Technologies (SIADD_INSTIC), based on the parameters defined in
DP nº121/20, with emphasis on the extension module. The existing systems in the area
of teacher performance evaluation do not meet all the requirements to deal with the
problem at higher education level, the need to improve the level of quality, security,
accessibility and the process of controlling event data for evaluation of the performance
of the INSTIC teacher and meet the objectives of the INSTIC with quality, good
performance, efficiency and speed.

Computer systems aim to optimize the processes carried out in organizations, thus
contributing to the efficient control of the information generated in them. In this research,
a computer system for Teacher Performance Assessment was developed for the Institute
of Information and Communication Technologies.

For system development, a study was carried out on methodologies, tools and
technologies for system development. After the development of the system, tests were
carried out to test it.

Keywords: Computer system, Performance evaluation, Teacher, career.

V
 Índice

INTRODUÇÃO.....................................................................................................................1
Situação Problemática da Investigação...........................................................................2
Problema de Investigação................................................................................................2
Objeto de Estudo..............................................................................................................2
Campo de Acção..............................................................................................................2
Objetivo Geral...................................................................................................................3
Objetivo Específico...........................................................................................................3
Ideia a Defender...............................................................................................................3
Tarefas de Investigação...................................................................................................3
CAPÍTULO 1 - FUNDAMENTAÇÃO TEÓRICA.................................................................4
1. Introdução...............................................................................................................4
1.1. Avaliação de desempenho.....................................................................................4
1.2. Soluções existentes..............................................................................................15
1.3. Funcionalidades que podem ser implementadas no sistema proposto...............17
1.4. Metodologia a usar para o Desenvolvimento da Solução....................................18
1.5. Ferramentas e tecnologias...................................................................................19
1.7. Proposta para a solução.......................................................................................28
1.8. Metodologias de Investigação Científica..............................................................29
Conclusão.......................................................................................................................30
CAPÍTULO 2 – CARACTERÍSTICA DO SISTEMA..........................................................31
2. Introdução.............................................................................................................31
2.1. Objecto de automação..........................................................................................31
2.2. Modelagem do negócio........................................................................................31
2.3. Modelagem do sistema.........................................................................................34
2.4. Padrões de arquitetura.........................................................................................41
2.5. Padrões de desenho.............................................................................................42
2.6. Diagrama de classes com estereotipo UML para Web........................................43
2.7. Normalização dos dados......................................................................................44
2.8. Modelo conceptual ou domínio.............................................................................46
Conclusão.......................................................................................................................47
CAPÍTULO 3 - DESENHO, IMPLEMENTAÇÃO E PROVAS DO SISTEMA...................48

VI
 3.1. Diagrama de componentes...................................................................................48
3.2. Modelo de despliegue (implantação)....................................................................49
3.3. Padrão de codificação..........................................................................................51
3.4. Processo de Provas..............................................................................................51
Conclusão..........................................................................................................................58
CONCLUSÃO....................................................................................................................59
RECOMENDAÇÕES.........................................................................................................60
BIBLIOGRAFIA.................................................................................................................61
GLOSSÁRIO......................................................................................................................65
ANEXO..............................................................................................................................67

VII
 Índice de Figuras

Figura 2.1 - Diagrama de casos de uso do negócio (elaboração própria)........................32

Figura 2.2 - Diagrama de casos de uso do sistema (elaboração própria).........................38
Figura 2.3 - Interface do caso de uso autenticar usuário..................................................39
Figura 2.4 - Padrão MVC. Fonte: ( (JOSUÉ, et al., 2011))................................................42
Figura 2.5 - Diagrama de classe com estereotipo web. Fonte: (Elaboração própria).......44
Figura 2.6- Modelo físico do banco de dados. Fonte: (Elaboração própria).....................45
Figura 2.7 - Modelo conceitual. Fonte: (Elaboração própria)............................................46
Figura 3.1- Diagrama de componentes Docente. Fonte: Elaboração própria...................49
Figura 3.2 - Modelo de despligue (implantação). Fonte: (Diocleciano, 2021)...................50
Figura 3.3 - Fragmento de código com aplicação do teste de caixa branca. Fonte:
(Elaboração própria)..........................................................................................................53
Figura 3.4 - Gráfico Fluxo Prova Caixa Branca Fonte: Elaboração própria......................53
Figura 3.5 - Teste de caixa preta em aplicação. Fonte: (Elaboração própria)..................55
Figura 3.6 - Teste de caixa preta aplicado e validado. Fonte: (Elaboração própria).........56
Figura 3.7 - Teste de caixa preta aplicado e inválido. Fonte: (Elaboração própria)..........56
Figura 3.8 - Gráfico de interação – Prova de Caixa Preta. Fonte: elaboração própria.....57

VIII
 Índice de tabelas

Tabela 1.1 - Parâmetros a serem avaliados em função dos módulos..............................10

Tabela 1.2 - Parâmetros produção normativa e curricular................................................12
Tabela 1.3 - Parâmetros prestação de serviços e consultoria...........................................13
Tabela 1.4 - Parâmetros interação com a comunidade.....................................................14
Tabela 1.5 – Parâmetros mobilização de agentes e recursos da comunidade para a
realização de atividades práticas no interior ou no exterior das Instituições de Ensino
Superior-IES.......................................................................................................................15
Tabela 1.6 - Comparação dos sistemas ADD de Portugal e de Angola............................16
Tabela 1.7 - Ciclo de vida do OpenUP...............................................................................19
Tabela 1.8 - Principais navegadores..................................................................................20
Tabela 1.9 - Principais linguagens de programação.........................................................21
Tabela 1.10 - Principais frameworks..................................................................................22
Tabela 1.11 - Principais aplicativos do NoSQL..................................................................23
Tabela 2.1 - Descrição do caso de uso para o negócio fazer avaliação...........................33
Tabela 2.2 - Requisitos funcionais existentes....................................................................35
Tabela 2.3 - Requisitos não funcionais..............................................................................37
Tabela 2.4 - Caso de uso cadastrar usuário......................................................................39
Tabela 2.5 - Caso de uso gerir docente.............................................................................40
Tabela 3.1 - Descrição do modelo de despliegue..............................................................50
Tabela 3.2 - Prova de caixa preta: registrar docente.........................................................55

IX
 Lista de abreviaturas e símbolo

AD – Avaliação Desempenho

ADD – Avaliação do Desempenho Docente

CAD – Comissão de Avaliação de Docente

CSV – Comma Separated Value

DCU – Diagrama de Caso de Uso

DP – Diário da República

ER - Entidade Relação

FTP - File Transfer Protocol (protocolo de transferência de arquivos)

GIF - Graphics Interchange Format (Formato para Intercâmbio de Gráficos)

GPL - General Public License (Licença Pública Geral)

GRASP – General Responsibility Asigment Software Patterns

GUI - (Graphical User Interface) Interface Gráfica do Utilizador

HTML - Hyper Text Markup Language (Linguagem de Marcação de Hipertexto)

HTTP - Hyper Text Transfer Protocol (Protocolo de Transferência de Hipertexto)

I&D – Investigação e Desempenho

INSTIC – Instituto de Tecnologias de Informação e Comunicação

JSON - JavaScript Object Notation

JVM - Java Virtual Machine (Máquina Virtual do Java)

MDS – Metodologia de Desenvolvimento de Software

MVC - Model View Controller (Modelo Vista Controlador)

NoSQL- Not Only Structured Query Language

OpenUP - Open Unified Process (Processo Unificado Aberto)

PHP - Hypertext Preprocessor (Processador de Hipertexto)

X
POP - Procedimento Operacional Padrão

RAM - Random Access Memory (Memória de Acesso Aleatório)

REST - Representational State Transfer (Transferência de Estado Representacional)

RF - Requisito Funcional

RNF - Requisito Não Funcional

RUP – Rational Unified Process

SGBD - Sistema Gerenciador de Banco de Dados

SI - Sistema de Informação

SIADD – Sistema Informático de Avaliação do Desempenho do Docente

SMTP - Simple Mail Transfer Protocol

SQL- Structured Query Language (Linguagem de Consulta Estruturada)

TCP/IP - Protocolo de Controle de Transmissão/Protocolo da Internet (Transmission

Control Protocol/Internet Protocol)

TICs - Tecnologia de Informação e Comuninação

UML - Unified Model Language (Linguagem de Modelagem Unificada)

XML - Extensible Markup Language

XP - Extreme Programming (Programação Extrema)

XI
INTRODUÇÃO

As tecnologias de informação e comunicação mudaram a forma de interação mundial

criando mais espaços para o crescimento tecnológico e as empresas foram se
familiarizando cada vez mais com as mudanças provocadas por estas tecnologias de
comunicação. O acesso à informação de qualidade bem como a informatização de
diversos serviços tornou-se uma realidade para os dias de hoje devido o crescimento
constante das tecnologias de informação comunicação a nível mundial e
particularmente em Angola.
Hoje se tornou possível utilizar as ferramentas de tecnologias de informação para fazer
a gestão de diversos serviços e oferecer melhor qualidade de armazenamento e
controle de Dados. As tecnologias de comunicação e as suas ferramentas são bastante
importantes para serviços de gestão académica, com o passar dos anos as empresas e
organizações tendem a se informatizar e a buscar soluções mais adequadas para
gerenciar seus produtos e serviços, e os sistemas de gestão baseada em Web tem sido
uma das soluções mais procurada por pequenas e médias empresas.
Globalmente, os docentes apresentam uma perceção sobre o processo de avaliação do
desempenho docente congruente com o estipulado nas normas legais, no que se refere
à forma como esta se processa, periodicidade, instrumentos e metodologia,
intervenientes e alvo de avaliação. Verifica-se, também, que as principais preocupações
passam pelo facto de a avaliação não refletir a qualidade de ensino/aprendizagem e
não haver conhecimento e/ou clarificação dos critérios a serem avaliados, não
apresentando qualquer impacto na melhoria da carreira docente, nos salários e
formação profissional, mas ao nível da promoção na carreira.

1
Situação Problemática da Investigação
Neste sentido, é por meio dessa ferramenta AD que os gestores conseguem identificar
quais são as habilidades e qualificações que têm à disposição e o que ainda deve ser
melhorada para alcançar os resultados esperados pela.
O INSTIC é uma instituição de ensino superior, que tem como propósito formar quadros
de qualidade tendo em conta a mais alta qualidade de ensino, para que isto se
concretiza é necessário que tenham docentes qualificados e realmente comprometidos
com a causa (formar quadros de qualidade), o INSTIC mede as qualificações dos
docentes de um modo tradicional ou seja de forma manual, levando em consideração
uma serie de processos e critérios para avaliar o docente, acarretando consigo uma
serie de desvantagens e insegurança dos dados do processo avaliativo.
Podemos perceber, então, a importância da qualidade nas análises de performance.
Impressões equivocadas podem levar o INSTIC a outro caminho, culminando em perda
de produtividade, queda na credibilidade e prejuízos à imagem do INSTIC.
Atendendo às dificuldades, desafios e constrangimentos que o processo de avaliação
de desempenho docente no INSTIC tem aportado, desde a gerência do processo
avaliativo envolvendo o cadastramento de pessoas para fiscalizar, gastos com
divulgação e pessoal, e, há a necessidade de prestar contas do processo seletivo,
inclusive com recibos, relatórios e outros. foi formulada a seguinte questão de
investigação:

Problema de Investigação
Como facilitar o processo de avaliação do desempenho do docente do Instituto de
Tecnologias de Informação e Comunicação?

Objeto de Estudo
Atendendo tudo o que foi identificado, temos definido como objeto de estudo o seguinte:
Sistema informático de Avaliação do Desempenho do Docente.

Campo de Acão
Para a presente investigação o campo de ação é: Sistema informático de Avaliação do
Desempenho do Docente no INSTIC.

2
Objetivo Geral
Desenvolver um sistema interativo de avaliação do desempenho docente do Instituto de
Tecnologias de Informação e Comunicação (SIADD_INSTIC), baseado nos parâmetros
definidos no DP nº121/20 de 27 de abril, com ênfase no módulo extensão.

Objetivo Específico
• Recopilar as bibliografias necessárias para o estudo do desenvolvimento do
sistema;
• Analisar os regulamentos e sistemas de avaliação do desempenho docente no
âmbito nacional e internacional;
• Analisar e selecionar as metodologias, ferramentas, tecnologias, linguagens para
o desenvolvimento do sistema;
• Desenvolver e implementar o SIADD-INSTIC.
• Efetuar provas do sistema com o propósito de validar a proposta;

Ideia a Defender
Com o desenvolvimento do SIADD-INSTIC deverá se melhorar o nível de qualidade,
acessibilidade e o processo de controlo dos dados de eventos para avaliação do
desempenho do docente do INSTIC.

Tarefas de Investigação
• Recopilação das bibliografias necessárias para o estudo do desenvolvimento do
sistema;
• Análise dos sistemas de avaliação do desempenho docente no âmbito nacional e
internacional;
• Análise e seleção das metodologias, ferramentas, tecnologias, linguagens para o
desenvolvimento do sistema;
• Descrição detalhada do comportamento do sistema;

• Desenho do sistema de acordo as metodologias e ferramentas previamente

selecionadas;
• Implementação do sistema.

• Aplicação das provas de sistema com função para validar a proposta de solução;

3
CAPÍTULO 1 - FUNDAMENTAÇÃO TEÓRICA

Neste capítulo fala-se dos conteúdos teóricos que serão essenciais para elaboração e
implementação do trabalho, especifica-se sobre os sistemas informáticos de avaliação e
desempenho docente existentes, tanto a nível nacional como a nível internacional.
Também se definem as ferramentas metodológicas e tecnológicas utilizadas durante a
elaboração do trabalho.

1. Introdução
O trabalho aborda o tema sistema informático de avaliação e desempenho docente. A
abordagem engloba o estudo do INSTIC como uma instituição onde o trabalho do
gestor geral do INSTIC tem papel diferenciado dos gestores de outras áreas. A ênfase
na gestão participativa, onde o corpo docente e a comunidade externa devem contribuir
com suas habilidades, é um espaço de articulação e de convergência de múltiplas
forças principais conceitos associados ao objeto de estudo.

1.1. Avaliação de desempenho

1.1.1. Avaliação de Desempenho: Conceito e Delimitação
A educação, por ser um exercício de contínuo aperfeiçoamento e de enorme
complexidade, exige uma qualificação de base e um processo de constante
requalificação. E é nesse processo de constantes requalificações que emerge a nossa
preocupação em elevar a qualidade do sistema de ensino e os resultados escolares dos
alunos. Estamos, assim, a suscitar questões referentes à eficácia e à eficiência dos
docentes, das escolas e da educação em geral, que constituem atualmente uma
exigência e, como tal, ganham maior destaque, tanto nos discursos políticos, como nos
pedagógicos. Esta necessidade de procurar melhorar a qualidade do sistema
educacional faz com que alguns educadores procurem inovar recursos e metodologias
de forma a melhorar a qualidade da prática de ensino e da aprendizagem dos alunos,
propiciando um contexto de verdadeiro crescimento para todos.
Nesta ótica, afirma-se que “a necessidade de elevar os padrões do ensino e de
melhorar a qualidade das aprendizagens dos alunos tem levado os governos a
introduzir reformas nas escolas e no trabalho dos docentes no sentido de uma maior
prestação de contas, entre as quais se destaca a avaliação dos docentes”. Acreditamos
que, para a maior eficácia e qualidade de ensino, é necessário ligar os novos projetos

4
educativos à formação inicial e contínua dos docentes. Assim como também fortalecer
as relações na comunidade educativa, com abrangência a valores, princípios,
autonomia e reflexão, permitindo a todos um desenvolvimento continuado.
Em prol de uma maior qualidade para o sistema educativo e seus colaboradores, a
pertinência da avaliação justifica-se pela necessidade repetida de melhorar as práticas
e elevar a qualidade dos resultados, justificando a sua finalidade e o seu impacto social,
face às constantes mudanças nos cenários educativos e sociais. Assim, falar da
avaliação de desempenho dos docentes implica debruçarmo-nos sobre um conjunto de
ideias que motivam a busca para uma melhor compreensão e enquadramento da
realidade em que nos encontramos inseridos e o conhecimento da perceção que sobre
ela têm os agentes educativos. Privilegiamos uma avaliação que dê resultados
significativos à prática educativa, numa dupla perspetiva: por um lado, diagnosticar
aspetos que permitam a todo o docente melhorar, proporcionando estratégias para o
seu desenvolvimento profissional. Por outro lado, uma orientação para a
responsabilidade e prestação de contas, com o intuito de se criar consciências críticas e
aprendentes. A relevância da avaliação do desempenho docente enquadra-se no plano
de melhoria educativa. Subjazem abordagens que sustentam ideias de que a qualidade
profissional, pessoal, a promoção das aprendizagens reside nos docentes que buscam
no seu dia-a-dia fazer diferença com relação a sua prática. Afigura-se o papel do
docente no processo de mudança, através de vários desempenhos, na qual a formação
ao longo da vida faz parte.
1.1.2. Objetivos da Avaliação de Desempenho
A ADD é um processo através do qual os docentes são avaliados. Este processo é
normalmente conduzido pela escola e envolve processos de autoavaliação, atividades
de desenvolvimento profissional, formação contínua e ainda observação de aulas. Este
sistema de ADD vai ao encontro dos resultados do trabalho docente no seu campo de
ação, não se cingindo à simples análise da qualidade do ensino ou das aprendizagens,
ou até mesmo das competências, mas sim permite incutir uma melhoria no sistema de
ensino em si mesmo e regular as qualidades do mesmo (Paxi, 2017).
Atendendo ao Preâmbulo desse Decreto Regulamentar, pretende-se um modelo de
avaliação mais simples do que os anteriores existentes, mas ao mesmo tempo exigente
e rigoroso, onde seja valorizada a atividade letiva e criadas as condições para que as
escolas e os docentes recentrem o essencial da sua atividade: o ensino e a

5
aprendizagem. Assim sendo e nesta linha de pensamento, o objetivo da ADD é
melhorar a qualidade do serviço educativo e das aprendizagens dos alunos, bem como
valorizar o desenvolvimento pessoal e profissional dos docentes mediante o
acompanhamento e supervisão da prática pedagógica, no quadro de um sistema de
reconhecimento do mérito e da excelência.
1.1.3. Erros na Avaliação de Desempenho
Quando se escolhe um método para implementar a AD tem que se ter em atenção os
pormenores associados a todo o processo, não se podendo descurar que a avaliação
se realiza por pessoas e para pessoas. Da mesma forma, qualquer que seja o sistema
de avaliação, este nunca é exato e, como tal, significa que o erro não está ausente. Por
esse motivo, importa que, tanto o avaliador como o avaliado, possuam conhecimentos
sobre o tipo de distorções que podem existir, na medida em que estas operam
negativamente sobre os julgamentos emitidos por ambos, condicionando a justiça do
processo avaliativo. Os erros de avaliação resultam, na sua maioria, de julgamentos
errados realizados pelo avaliador, o que pode ser observado quando o desempenho
real do avaliado é divergente do que é retratado nas observações. Por isso, os erros
devem ser evitados para que não haja falta de motivação, de empenhamento e um
conjunto de erros que são considerados como sendo os mais comuns e que a seguir se
apresentam (Paxi, 2017).
1.1.3.1. Efeito de Halo
Este erro surge quando o avaliador estende uma avaliação positiva (halo) ou negativa
(horn) de uma determinada pessoa. Por exemplo: se um determinado docente não
possui competências comunicacionais ajustadas, o avaliador infere que este docente
também não apresentará competências de relacionamento interpessoal, ou pelo
contrário, se ele apresenta excelentes competências comunicacionais também
apresentará excelentes competências relacionais (Paxi, 2017).
1.1.3.2. Erro de Tendência Central
Este erro surge quando há uma tendência para avaliar sempre no “meio termo”. O
avaliador opta por não dar pontuações muito elevadas ou muito baixas aos avaliados,
situando-se sempre em pontuações medianas (Paxi, 2017).

6
 1.1.3.3. Erro de Primazia e de Recência
O erro de primazia centra-se na primeira impressão enquanto o de recência na última
impressão. Assim, este erro ocorre quando o avaliador utiliza a sua memória recente ou
inicial para atribuir a sua avaliação. Por exemplo, o avaliador ter concedido uma
avaliação muito positiva a determinado docente numa avaliação inicial e não aceitar que
o seu desempenho tenha decaído ao longo do tempo. Ou, pelo contrário, o avaliador
considerar apenas os últimos acontecimentos da avaliação de determinado docente,
esquecendo-se de outros aspetos que tenham ocorrido anteriormente e que são
importantes na análise global do desempenho (Paxi, 2017).
1.1.3.4. Erro de Fadiga/Rotina
Este erro ocorre quando o avaliador se encontra com excesso de trabalho, levando-o a
esquecer determinados critérios de avaliação. Por exemplo, após um grande número de
avaliações diárias, as últimas, na ausência de um guião pré-estruturado, poderão não
responder necessariamente a todas as informações necessárias (Paxi, 2017).
1.1.3.5. Erro de Estereótipo
Este erro, também designado de erro de preconceito social, surge quando o avaliador
estabelece um estereótipo em relação ao desempenho do avaliado e esta situação não
se altera nem com o processo de AD, mesmo que o desempenho seja superior ou
inferior ao estereótipo estabelecido pelo avaliador. Este erro pode associar-se a
diferentes preceitos como a cor da pele, a religião do docente, sua orientação sexual,
entre outros (Paxi, 2017).
1.1.3.6. Erro de Precisão
Este erro é também designado de erro constante, e consiste na tendência para avaliar
os candidatos de forma muito rígida em qualquer situação ou ser muito complacente,
permitindo a persistência do seu erro. Por exemplo, um avaliador encontrar sempre
justificações plausíveis para os comportamentos menos adequados de determinado
docente ou estar sempre a encontrar justificações plausíveis que justifiquem
classificações excecionalmente más (Paxi, 2017).

7
 1.1.3.7. Erro da Profecia Auto verificada
Este erro consiste no facto de o avaliador gerar expetativas fracas sobre o avaliado
desde o início do processo de avaliação, as quais podem traduzir se num mau
desempenho. Por exemplo, um determinado avaliador nunca ter gerado elevadas
expectativas perante um determinado docente, sendo que quando aquele avaliar este
último, a sua avaliação poderá apresentar se condicionada às suas baixas expectativas
(Paxi, 2017).
1.1.3.8. Erro de Favoritismo
Este erro surge quando o avaliador privilegia algum avaliado em função do seu grau de
parentesco, de amizade, influência, interesse, entre outros. É o caso de um avaliador
tender a avaliar de forma positiva um docente que foi seu vizinho durante muito tempo e
com o qual mantém boas relações de amizade (Paxi, 2017).
1.1.3.9. Erro de Semelhança
Este erro surge quando o avaliador tende a avaliar em função de uma sintonia com os
avaliados. Por exemplo, o facto de um dos docentes avaliados apresentar um interesse
num determinado hobby poderá levar o avaliador a conferir-lhe uma avaliação positiva
pelo facto de se identificar, pessoalmente, com esse interesse (Paxi, 2017).
1.1.3.10. Efeito de Pigmalião
Este erro surge quando a mera expectativa de determinada ocorrência de um
comportamento, aumenta a probabilidade da sua ocorrência. Por exemplo, o avaliador
desenvolve expectativas sobre o comportamento de um determinado docente que irá
ser avaliado e transmite-lhe de forma indireta ou direta, essas mesmas expectativas.
É necessário utilizar-se diferentes avaliadores, dando-lhes formação e
consciencializando-os para os erros que um processo de avaliação pode ter, como
forma de redução destes erros. Uma outra forma de ultrapassar estes erros é realizar
uma sessão de feedback na qual o avaliador deve justificar a razão da atribuição de
determinada classificação, sendo que para isto é necessário existir confiança e à
vontade entre o avaliador e o avaliado (Paxi, 2017).

8
 1.1.4. O que Avaliar?
A ADD pode ser perspetivada como um processo burocrático e administrativo, que
consome tempo, esforço e dinheiro e com pouca ou nenhuma influência no
desempenho, na competência e na eficácia dos docentes e pode ser vista como um
processo ao serviço da melhoria da qualidade pedagógica e da qualidade de ensino dos
docentes, podendo gerar ambientes propícios à inovação, ao desenvolvimento
profissional e, consequentemente, à melhoria das aprendizagens dos alunos.
Defendermos uma ou outra perspetiva significa condicionar a perceção sobre avaliação,
processo de implementação e operacionalização (Paxi, 2017).
As sociedades atuais exigem da escola e dos docentes conhecimentos e competências
atualizadas, para que se possam adaptar às novas e constantes mudanças,
congregando os aspetos cognitivos, afetivos e relacionais, sendo o desenvolvimento
profissional dos docentes uma encruzilhada de caminhos e práticas educativas,
pedagógicas, escolares e de ensino.
Pelo facto de o sistema de ADD assentar numa diversidade de domínios e no sentido
de se harmonizar o entendimento sobre os elementos de referência da avaliação dos
docentes do subsistema de ensino superior, a Presidência da república procedeu à
publicação do regulamento avaliação de desempenho dos docentes do subsistema de
ensino superior (DP 121/20, 2020), através do DP 121/20 de 27Abril, que se apresenta
na tabela 1.1.

9
 Tabela 1.1 - Parâmetros a serem avaliados em função dos módulos.

Módulos Parâmetros
a) Materiais Pedagógicos
b) Orientação de Estudantes
c) Lecionação de Unidades
Ensino
Curriculares

d) Infraestruturas de Apoio ao Ensino

a) Produção Científica e Tecnológica

b) Projetos de Investigação Científica
Investigação c) Infraestrutura de Apoio à
Científica Investigação Científica
d) Reconhecimento pela Comunidade
Científica
a) Produção Normativa e Curricular
b) Prestação de Serviços e
Consultoria
Extensão c) Interação com a Comunidade

d) Mobilização de Agentes e
Recursos da Comunidade

a) Cargos em Órgãos da IES/Unidade

Orgânica
b) Cargos ao nível da Unidade
Orgânica/Departamento
Gestão
c) Cargos e Tarefas Temporários
d) Cargos em Órgãos
Externos/Comissões ad-hoc
Fonte: DP 121/20 de 27Abril.

Os padrões de avaliação de desempenho dos docentes do subsistema de ensino

superior estão definidos em quatro módulos de avaliação, que se assumem como
vertentes que caraterizam a ação profissional do docente, os domínios e indicadores,
que operacionalizam os módulos em planos mais restritos, e os níveis e descritores,
que descrevem, pormenorizadamente, o desempenho docente, clarificando o que deve
ser avaliado.

10
 1.1.5. Consequências da Avaliação de Desempenho Docente
A literatura apresenta os resultados de diversas investigações sobre as consequências
dos sistemas atuais de ADD, observando-se que estas podem ser positivas, mas, na
sua maioria, apresentam-se como negativas. A forma como estes sistemas de ADD têm
vindo a ser implementados, tem suscitado interpretações variadas por parte dos
avaliadores e dos avaliados, criando tensões de natureza diversa que aportam
consequências ao nível da adesão e das dificuldades que são encontradas.
1.1.6. Avaliação de Desempenho Docente em Angola: Desafios e
Oportunidades
A contextualização da Avaliação de Desempenho Docente (ADD) no sistema educativo
Angolano ocorreu ao abrigo do Decreto-Lei n.º 7/2008 de 23 de abril, encontrando-se
configurado na matriz do novo estatuto de carreira dos docentes do ensino primário,
secundário, técnicos pedagógicos e especialistas em administração da educação,
visando avaliar com maior objetividade a atividade docente e o exercício de
administração da educação nos estabelecimentos públicos de ensino e nas estruturas
públicas de administração da educação. Este Decreto-Lei apresentou novas alterações
ao modelo de ADD, pois até à data, a progressão na carreira docente efetuava-se
exclusivamente em função do tempo de serviço. O anterior diploma referia que a
mudança na categoria ocorria de cinco em cinco anos sem obrigação de ter um
resultado positivo no final de cada ano letivo. Com a implementação deste Decreto-Lei
a progressão nos escalões fica condicionada a uma duração temporal em cada um dos
escalões e também à avaliação de mérito (ou demérito), da experiência adquirida e da
frequência com aproveitamento no referido módulo da ADD.

11
 1.1.6.1. Parâmetros, Critérios da Avaliação definidos no DP nº121/20, para o
módulo extensão.
O artigo 26º. critérios de avaliação relativos ao parâmetro produção normativa e
curricular, enfatiza os seguintes aspetos:
1. A avaliação do desempenho no módulo extensão, parâmetro produção
normativa e curricular leva em conta a área disciplinar e baseia-se em critérios de
inovação, atualidade, diversidade, responsabilidade, contribuição para o avanço
do estado da arte, difusão e impacto profissional e social dos resultados.

2. A valorização quantitativa considera o tipo e o total de contribuições do avaliado

durante o período em avaliação, de acordo com a pontuação fixada na tabela 1.2.

Tabela 1.2 - Parâmetros produção normativa e curricular

Pontuaçã
# Tipo de Contribuição
o
Participação na elaboração de projeto legislativo
1 7
internacional
Participação na elaboração de norma técnica
2 6
internacional
Participação na elaboração de projeto legislativo
3 5
nacional
4 Participação na elaboração de norma técnica nacional 4
Participação na elaboração de projeto curricular de
5 curso de graduação ou de pós-graduação 3

Participação na elaboração de parte regulamento ao

6 nível das IES/Unidade Orgânica 2

Participação na elaboração de parte de um plano

7 curricular de curso de graduação ou de pós-graduação 2

Emissão de parecer científico sobre projetos de

8 diplomas legais ou projetos de tecnologia e inovação 2

Participação na elaboração de documentação

normativo orientador, relevante para o ensino-
9 1
aprendizagem (perfil, estágio, normas de qualidade,
avaliação, extensão)
Participação na elaboração de Estatuto ou
10 Regulamento Interno de estruturas ou processos 1
ligados ao ensino-aprendizagem
Fonte: DP 121/20 de 27Abril.

12
O artigo 27º. critérios de avaliação relativos ao parâmetro prestação de serviços e
consultoria, enfatiza os seguintes aspetos:
1. A avaliação do desempenho no módulo extensão, parâmetro prestação de
serviços e consultoria desenrola-se, tomando em conta a área disciplinar,
segundo critérios, tais como inovação, atualidade, responsabilidade, ética,
impacto, diversidade, âmbito territorial, entre outros.

2. A valorização quantitativa é obtida a partir do tipo e do número de acções

desenvolvidas pelo avaliado durante o período em avaliação, de acordo com a
pontuação fixada na tabela 1.3.
Tabela 1.3 - Parâmetros prestação de serviços e consultoria

# Tipo de Acção Pontuação

Incubação e formação de empresa de base
1 6
tecnológica
Recebimento de pagamento (Royalties) de
2 5
propriedade industrial (ex. vendas de patentes)
3 Direitos de Autor (ex. livros ou software) 4
Responsável por unidade interna prestadora de
4 3
serviços
Responsável por consultoria técnico-científica a
5 3
entidade externa
Responsável por projeto de curso de formação
6 contínua, de agregação pedagógica ou de extensão 2.5
científica, cultural ou artística
Responsável por formação profissional no âmbito de
7 2
protocolos de cooperação
8 Formador, no âmbito de protocolos de cooperação 1.5
Ministração de um módulo de curso avançado de
9 curta duração ou cursos no âmbito de jornadas 1.5
científicas
Participação em projeto, processo ou unidade de
10 1
prestação de serviços
Participação em consultoria técnico-científica, no
11 1
âmbito de uma parceria
Participação em acções educativas na comunidade
12 1
(alfabetização, capacitação)
Ministração de módulos de cursos de capacitação
13 docente ou científica noutras instituições, 1
devidamente autorizado
Membro de júri de elaboração e de correcção de
14 1
exames de acesso ao ensino superior
Responsável por divulgação científica nos meios de
15 0.5
comunicação social
Participante em formação profissional no âmbito de
16 0.5
protocolos de cooperação
Fonte: DP 121/20 de 27Abril.

13
O artigo 28º. critérios de avaliação relativos ao parâmetro interação com a comunidade,
enfatiza os seguintes aspetos:
1. A avaliação do desempenho no módulo extensão, parâmetro interação com a
comunidade é realizada, tendo em conta a área disciplinar, com base em critérios,
tais como ética, relevância, pertinência, diversidade, visibilidade, âmbito territorial,
impacto profissional e social.

A valorização é obtida a partir do tipo e número total de acções do avaliado, de acordo

com a pontuação fixada na tabela 1.4.

Tabela 1.4 - Parâmetros interação com a comunidade

# Tipo de Realização Pontuação

Realização de projetos de cariz social e de
1 desenvolvimento comunitário 5

Responsável por estrutura de coordenação da actividade

2 de extensão na Instituição de Ensino Superior 4
Responsável por estrutura de coordenação da atividade
3 3
de extensão na Unidade Orgânica
Realização de acções de animação de rua (desporto,
4 arte) com públicos diferenciados (crianças, jovens, 3
mulheres, idosos, deficientes)
Realização de atividades de divulgação da oferta
5 formativa em escolas secundárias 2

6 Organização de eventos culturais na instituição 2

7 Realização de atividades de voluntariado na comunidade 2
Realização de consultas gratuitas á comunidade (saúde,
8 direito, economia, contabilidade, marketing) 2
Realização de palestras educativas e ou de cursos de
9 1.5
extensão universitária
Organização de eventos culturais e/ou desportivos fora
10 da instituição 1.5
Participação em actividades dê vária natureza (Culturais,
11 desportivas) organizadas por entidades da comunidade e 1
fora da instituição
Integração em associações sociais de vária natureza, em
12 representação da instituição de ensino ou da Unidade 0.5
Orgânica
Fonte: DP 121/20 de 27Abril.

O artigo 29º. critérios de avaliação relativos ao parâmetro mobilização de agentes e

recursos da comunidade para a realização de atividades práticas no interior ou no
exterior das Instituições de Ensino Superior-IES, enfatiza os seguintes aspetos:

14
 1. A avaliação do desempenho no módulo extensão, parâmetro mobilização
de agentes e recursos da comunidade para a realização de atividades práticas no
interior ou no exterior das Instituições de Ensino Superior-IES é estabelecida,
tomando em conta a área disciplinar, com base em critérios, tais como ética,
relevância, pertinência, diversidade, liderança, âmbito territorial, difusão impacto
profissional e social.
2. A valorização quantitativa é obtida a partir do tipo e número total de acções
do avaliado, de acordo com a pontuação fixada na tabela 1.5.

Tabela 1.5 – Parâmetros mobilização de agentes e recursos da comunidade para a realização de atividades
práticas no interior ou no exterior das Instituições de Ensino Superior-IES

# Tipo de Acção Pontuação

1 Criação de condições para assinatura de protocolo
de parceria com entidade externa, para efeito de 4
práticas e estágios
2 Organização e acompanhamento de estagiários
3.5
em contextos de trabalho
3 Organização de acções de formação em
2.5
colaboração com parceiros sociais
4 Realização de visitas de estudo a contextos reais
2
em colaboração com entidades externas
5 Criação de mecanismos para utilização de infra-
estrutura e equipamentos sociais disponibilizados 1.5
por entidades parceiras
6 Preparação de condições para formalização de
uma parceria entre a instituição de ensino superior 1.5
e agentes externos
7 Mobilização de entidades para a organização
conjunta de certames académicos ou culturais 1
(férias, exposições, excursões, etc)
8 Mobilização de órgãos de comunicação social para
0.5
realização de programas de interesse científico
Fonte: DP 121/20 de 27Abril.

1.2. Soluções existentes

Nível Internacional e Nacional
No sentido de se poder compreender melhor os desafios e as oportunidades que se
colocam à ADD em Angola, a Tabela 1.6 mostra a comparação em alguns dos itens
entre o sistema de ADD português em vigor e o existente em Angola. Esta comparação
não espelha, no entanto, uma dominação de um sistema perante o outro, mas somente
assinala as similaridades e diferenças entre eles, sendo importante considerar na sua
análise, as idiossincrasias culturais, sociais e profissionais destes dois países.

15
 Tabela 1.6 - Comparação dos sistemas ADD de Portugal e de Angola
Dimensões Portugal
Natureza Obrigatória
Periodicidade Bianual
Melhoria da qualidade das
aprendizagens e dos
resultados escolares dos
alunos
Objetivos finais Desenvolvimento pessoal e
profissional dos docentes,
num sistema de
reconhecimento do mérito e
da excelência
Avaliado
CCAD
Avaliadores: relator (docente
Intervenientes no processo da mesma área disciplinar
com posicionamento e grau
académico superior ao
avaliado e júri de avaliação
Vertente profissional social e
ética
Desenvolvimento do ensino e
da aprendizagem
Dimensões da avaliação Participação na escola e
relação com a comunidade
escolar
Desenvolvimento e formação
pessoal ao longo da vida
Expresso numa escala
graduada de 1 a 10 valores,
convertidos em menções
qualitativas de:
Classificação Excelente - ≥ 9
Muito Bom - ≥ 8
Bom - ≥ 6,5
Regular - ≥ 5 e < 6,5;
Insuficiente- < 5.
Entrevista individual Facultativa
Ingresso na carreira:
conversão da nomeação
provisória em nomeação
definitiva Progressão
horizontal: mudança de
Efeitos escalão e índice salarial
Promoção vertical: acesso à
categoria de docente titular.
Outros efeitos: renovação de
contrato; reconversão ou
reclassificação profissional;
Angola
Obrigatória
Bianual
Regular o sistema de
avaliação do desempenho
dos docentes, permitindo a
sua valorização pessoal e
profissional, a melhoria
permanente da sua atividade
e o incremento da reputação
científica, académica e social
das Instituições de Ensino
Superior;
Avaliado
Estudantes
CAD
Gestor da Unidade Orgânica
Docentes de categoria
superior à dos docentes
avaliados de categoria mais
elevada (DP 121/20, 2020).
Ensino
Investigação Científica
Extensão
Gestão
Excelente CF≥ 100;
Muito Bom 80≤CF<100;
Bom 50≤CF<80;
Suficiente 30≤CF<50;
Inadequado CF< 30.
Obrigatório
Promoção na carreira e
reavaliação do contrato;
Duas avaliações negativas
seguidas - disciplinar por
incompetência profissional;
Atribuição de avaliação
negativa - impede a
revalidação para o ano letivo
seguinte do contrato de
trabalho; rescisão do vínculo
laboral (DP 121/20, 2020).
16
 1.3. Funcionalidades que podem ser implementadas no sistema proposto
Regular o sistema de avaliação do desempenho dos docentes, permitindo a sua
valorização pessoal e profissional, a melhoria permanente da sua atividade e o
incremento da reputação científica, académica e social das Instituições de Ensino
Superior;
Definir os parâmetros e critérios de avaliação nos módulos de ensino, investigação
científica, extensão e gestão, estabelecendo as referências de desempenho sob a
forma de módulos, parâmetros, indicadores e critérios;
Estabelecer as regras e procedimentos do processo de avaliação do desempenho dos
docentes, assim como a metodologia para obtenção da classificação final;
Definir a constituição, competências e funcionamento da Comissão de Avaliação de
Docentes (CAD).
1.3.1. Metodologias de Desenvolvimento de Software
A Metodologia de Desenvolvimento de Software – MDS é um conjunto de boas práticas
em desenvolvimento de sistemas que são utilizadas pelas equipes de desenvolvimento
e manutenção de softwares.
A elaboração da metodologia é uma iniciativa da Coordenação de Tecnologia da
Informação, precedida de um estudo da evolução dos processos, artefactos e
orientações existentes. A utilização permitirá às equipes padronizar a forma de
desenvolver software, alinhando os processos de trabalho e criando a documentação
adequada. (José, et al., 2020)
1.3.1.1. Metodologia pesadas
É chamado de metodologia pesada, o modelo nos quais se descrevem os fluxos de
trabalho, as atividades e a inter-relação entre os componentes de um projeto,
permitindo a existência de diferentes maneiras de executar os processos de
desenvolvimento de acordo as condições do meio onde se ocorrem (Luís, 2020).

17
 1.3.1.2. Metodologias ágeis
Ágil é uma norma que visa oferecer leveza e rapidez no desenvolvimento de software.
Um dos principais motivos pelo grande aumento na demanda por agilidade é causado
pelo grande crescimento de Web sites e aplicações para dispositivos móveis.
Os requisitos de projeto de software são sempre congelados antes do desenvolvimento
do projeto e seu produto, no entanto esses últimos são passíveis de mudanças e requer
maior flexibilidade de adaptação. Isso é permitido aos desenvolvedores através da
metodologia que segue os princípios ágeis (COLNAGO, 2022).
Principais métodos ágeis
O grande foco dos métodos ágeis são simplicidade e rapidez. Alguns dos principais
métodos de desenvolvimento dessa categoria são:
• Scrum - conjunto de técnicas/processos de gerenciamento não linear de projetos
em equipe;

• OpenUP - Open Unified Process (Processo Unificado Aberto);

• Desenvolvimento Voltado a Funcionalidades;

• XP - Extreme Programming (Programação Extrema).

1.4. Metodologia a usar para o Desenvolvimento da Solução

OPENUP
O OpenUP é um processo unificado enxuto que aplica abordagens iterativas e
incrementais em um ciclo de vida estruturado. O OpenUP adota uma filosofia
pragmática e ágil que se concentra na natureza colaborativa do desenvolvimento de
software. É um processo independente de ferramentas e de baixa cerimônia que pode
ser estendido para atender a uma ampla variedade de tipos de projetos (COLNAGO,
2022).
A referida metodologia foi escolhida para o desenvolvimento do SIADD_INSTIC pois o
esforço pessoal em um projeto OpenUP é organizado em micro-incrementos. Eles
representam pequenas unidades de trabalho que produzem um ritmo constante e
mensurável de progresso do projeto (geralmente medido em horas ou alguns dias). O
processo aplica colaboração intensa à medida que o sistema é desenvolvido de forma
incremental por uma equipe comprometida e auto-organizada. Esses micro-incrementos
fornecem um loop de feedback extremamente curto que conduz decisões adaptativas
em cada iteração (COLNAGO, 2022).
18
O OpenUP estrutura o ciclo de vida do SIADD_INSTIC em quatro fases: início,
elaboração, construção e transição. O ciclo de vida do projeto fornece às partes
interessadas e aos membros da equipe visibilidade e pontos de decisão ao longo do
projeto. Um plano de projeto define o ciclo de vida e o resultado final é um projeto
acabado (JESUS, 2018).
Princípios Do OpenUp
Os princípios se baseiam no ciclo de vida do OpenUP, que pode ser estruturado em
quatro fases (JESUS, 2018):
Tabela 1.7 - Ciclo de vida do OpenUP

Levantamento de requisitos, os membros da equipe se juntam para determinar o

Iniciação
escopo do projeto assim como seus objetivos.
Elaboração Desenvolvimento da análise arquitetural da solução proposta.
Construção Detalhamento de requisitos, no design, na implementação e nos testes.
Onde o sistema vai ser implementado para a realidade no cliente, em outras
Transição
palavras o cliente vai enfim testá-lo e dar feedbacks a respeito.
Elaboração própria.

1.5. Ferramentas e tecnologias

Primeiramente, todos nós sabemos que os computadores não se comunicam do jeito
que as pessoas fazem. Em vez disso, os computadores exigem códigos ou direções,
chamados de códigos binários. E também comandos permitem que os computadores
processem as informações necessárias. A cada segundo, bilhões e bilhões de zeros e
uns são processados para fornecer as informações de que você precisa.
Os métodos pelos quais os computadores se comunicam através do uso de linguagens
de marcação e pacotes multimídia são conhecidos como tecnologia da web (Silva,
2022). Vejamos a seguir, algumas tecnologias da Web

19
Navegadores
Os navegadores são os intérpretes da web. Eles solicitam informações e, quando as
recebem, mostram-nos na página em um formato que podemos ver e entender, a tabela
1.8 ilustra os principais navegadores.

Tabela 1.8 - Principais navegadores

Versão
# Navegador Descrição Fonte
recomendada

Google Atualmente, o navegador mais popular

1 A partir da 79.0.3945
Chrome trazido pelo Google;

https://gs.statcounter.com/
2 Safari Navegador da web da Apple; A partir da 12.1.2

Navegador de código aberto suportado

3 Firefox A partir da 71.0
pela Fundação Mozilla;

É o mais atual navegador Web,

4 Edge desenvolvido pela Microsoft, para A partir da

substituir o IE. 44.18362

Elaboração própria.

HTML - Hypertext Markup Language é uma linguagem de marcação. Ela fornece a

estrutura de um site para que os navegadores da Web saibam o que mostrar.
CSS - Cascading Style Sheets é uma folha de estilo em cascata. CSS permite que os
webs designers mudem cores, fontes, animações e transições na web.
Eles fazem a web com bom aspecto.
LESS - um pré-compilador de CSS para facilitar o trabalho com CSS e adicionar
funcionalidade.
SASS - um pré-compilador de CSS para facilitar o trabalho com CSS e adicionar
funcionalidade.
Linguagens de Programação
Linguagens de programação são formas de se comunicar com computadores e dizer-
lhes o que fazer. Para isso, existem muitas linguagens de programação diferentes
(COLNAGO, 2022). Os desenvolvedores normalmente são apenas proficientes em um
canal, então eles promovem mais do que outros. Abaixo estão apenas algumas
linguagens de programação mais populares, a tabela 1.9 mostra as principais
linguagens de programação.

20
 Tabela 1.9 - Principais linguagens de programação

# Linguagem Descrição Ano criação Criado por

1 Atualmente mais utilizada para
PHP 1995 Rasmus Lerdorf
programação Web;
Podemos dizer que C é o pai das
linguagens de programação, diversas
outras linguagens foram escritas em

2 C C, assim como sistemas operacionais

1972 Dennis Ritchie
como o Linux/Unix e Windows.
É uma linguagem de programação
compilada, de propósito geral,
estruturada e imperativa;
Usado por todos os navegadores da

3 Javascript web e muitos outros frameworks.

1995 Brendan Eich
Arquivos .JS estão por toda a parte
nas páginas da web;
Projetada para desenvolvimento da
Web para produzir páginas da Web

4 ASP.NET dinâmicas. Foi desenvolvido pela

2002 Microsoft
Microsoft para permitir que os
programadores criem sites dinâmicos,
aplicativos da Web e serviços da Web;

5 Python Usado pelo framework Django e usado

1991 Guido van Rossum
em muitos cálculos matemáticos;

6 Ruby Yukihiro "Matz"

Usado pelo framework Ruby on Rails; 1990
Matsumoto

7 Go Linguagem mais recente, construída

2009 Google
para velocidade;

8 Objective-C A linguagem de programação por trás Tom Love and Brad

1984
do iOS; Cox

9 Swift A mais nova linguagem de

2014 Chris Lattner; Apple
programação da Apple;

10 Java Usado pelo Android e muitos Estadunidense Sun

1991
aplicativos de desktop. Microsystems
Elaboração própria.

21
 Frameworks
Estruturas são construídas para facilitar a construção e o trabalho com linguagens de
programação. Geralmente, as estruturas executam todas as tarefas difíceis e repetitivas
na configuração de um novo aplicativo da Web e as executam para você ou facilitam o
trabalho (LUIS, 2021), a tabela 1.10 ilustra as principais frameworks.
Tabela 1.10 - Principais frameworks

# Framework Descrição Fonte

1 Meteor Um framework javascript full-stack, para front e

https://www.meteor.com/
back end;
2 Node.js Um framework javascript do lado do servidor; https://nodejs.org/

3 Ruby on Rails Uma estrutura de pilha completa construída

https://rubyonrails.org/
usando ruby;

4 Django Uma estrutura de pilha completa construída

https://www.djangoproject.com/
usando python;
5 Ionic Um framework móvel; https://ionicframework.com/

Uma estrutura de interface do usuário

6 Bootstrap (interface com o usuário) para construir com https://getbootstrap.com/
HTML, CSS e Javascript;

7 Foundation Uma estrutura de interface do usuário para

https://foundation.app/
construir com HTML, CSS e Javascript;

8 WordPress Um CMS: sistema de gerenciamento de

https://wordpress.com/
conteúdo, baseado em PHP;
9 Drupal Um framework CMS construído usando PHP; https://www.drupal.org/

10 .NET Uma estrutura de pilha completa construída

https://g.co/kgs/Pd8pXu
pela Microsoft;
11 Angular.js Uma estrutura de javascript front-end; https://angularjs.org/

12 Ember.js Uma estrutura de javascript front-end; https://emberjs.com/

13 Backbone.js Uma estrutura de javascript front-end. https://backbonejs.org/

Elaboração própria.

22
 Bibliotecas
As bibliotecas são pedaços agrupado de código para habilitar uma grande quantidade
de funcionalidades sem precisar escrever tudo sozinho. As bibliotecas normalmente
também enfrentam o problema para garantir que o código seja eficiente e funcione bem
em navegadores e dispositivos (nem sempre é o caso, mas geralmente funcionam)
(Matheus, et al., 2021).
Bancos de dados
Bancos de dados são onde todos os dados são armazenados. É como um monte de
arquivos com pastas cheias de arquivos. Bancos de dados vêm principalmente em dois
tipos: SQL e NoSQL (Elaine, et al., 2019).
O SQL fornece mais estrutura, o que ajuda a garantir que todos os dados estejam
corretos e validados.
O NoSQL oferece muita flexibilidade para construir e manter aplicativos, a tabela 1.11
mostra os principais aplicativos do NoSQL.
Tabela 1.11 - Principais aplicativos do NoSQL

# Aplicativo Descrição Fonte

1 É um banco de dados NoSQL de
código aberto e atualmente é o
MongoDB https://www.mongodb.com/
único banco de dados suportado
pelo Meteor
2 É outro popular banco de dados
SQL de código aberto. O MySQL
MySQL https://www.mysql.com/
é usado em sites do WordPress
Usada no projecto
3 É um banco de dados mais novo,
MARIADB para substituir o MySQL, que foi https://mariadb.org/
adquirido pela Oracle
4 É um banco de dados SQL
Oracle https://www.oracle.com/database/
corporativo
5 https://www.impacta.com.br/blog/entenda-
É um gerenciador de servidor
SQL Server de-uma-vez-por-todas-o-banco-de-dados-
SQL criado pela Microsoft
sql-server/
6 É sistema gerenciador de banco
de dados objeto relacional,
PostgreSQL https://www.postgresql.org/
desenvolvido como projeto de
código aberto. Usada no projecto.
Elaboração própria.

23
 Cliente e servidor
Um cliente é um usuário de um aplicativo (Márcio, 2019). Os clientes podem ser
computadores desktop, tablets, ou dispositivos móveis. Geralmente, há vários clientes
interagindo com o mesmo aplicativo armazenado em um servidor.
Um servidor é onde o código do aplicativo é normalmente armazenado (Elaine, et al.,
2019). As solicitações são feitas ao servidor pelos clientes e o servidor reunirá as
informações apropriadas e responderá a essas solicitações.
Front-end
O front-end é composto por HTML, CSS e Javascript. É assim e onde o site é exibido
para os usuários (LUIS, 2021).
Back-end
O back-end é composto pelo seu servidor e banco de dados. É o local onde ocorrem
funções, métodos e manipulação de dados que você não deseja que os clientes vejam.
Protocolos
Os protocolos são instruções padronizadas sobre como passar informações entre
computadores e dispositivos.

 HTTP - Este protocolo é como cada site chega ao seu navegador. Sempre que
você digita um site, este protocolo solicita o site do servidor e, em seguida, recebe
uma resposta com o HTML, CSS e javascript do site.
 POP e SMTP - São protocolos usados para o recebimento e envio de emails
respetivamente.
 REST - é um protocolo usado principalmente para APIs. Ele possui métodos
padrão, como GET, POST e PUT, que permitem que as informações sejam
trocadas entre os aplicativos.

API
Uma API é uma interface de programação de aplicativos. Ele é criado pelo
desenvolvedor de um aplicativo para permitir que outros desenvolvedores usem
algumas das funcionalidades do aplicativo sem compartilhar código. Os
desenvolvedores expõem os "pontos finais", que são como entradas e saídas do
aplicativo. O uso de uma API pode controlar o acesso com chaves de API. Exemplos de
boas APIs são aquelas criadas pelo Facebook, Twitter e Google para seus serviços da
web. (Cléber, 2020).
24
  Formatos de dados.

Formatos de dados são a estrutura de como os dados são armazenados.

➢ JSON - está rapidamente se tornando o formato de dados mais popular

➢ XML - foi o principal formato de dados no início dos dias da web e

predominantemente usado por sistemas da Microsoft.

➢ CSV - são dados formatados por vírgulas. Dados do Excel normalmente são
formatados dessa maneira.

1.5.1. Ferramentas na qual se apoia para a solução

O desenvolvimento do sistema foi baseado em softwares livres porque estão
disponíveis gratuitamente na internet e são uma forma de manifestação de um software
em que, resumidamente, permite-se adaptações ou modificações no seu código de
forma espontânea, ou seja, sem que haja a necessidade de solicitar permissão ao seu
proprietário para modificá-lo.
1.5.2. As ferramentas utilizadas para o desenvolvimento do sistema
A nível de Front-end usamos a ferramentas e tecnologias abaixo:

Next.js é uma estrutura da web de desenvolvimento front-end React de código aberto

criada por Vercel que permite funcionalidades como renderização do lado do servidor e
geração de sites estáticos para aplicativos da web baseados em React. É uma estrutura
pronta para produção que permite que os desenvolvedores criem rapidamente sites
JAMstack estáticos e dinâmicos e é amplamente usada por muitas grandes empresas
(Mochammad, et al., 2022).

O Redux Toolkit é nosso conjunto de ferramentas oficial, opinativo e com baterias para
um desenvolvimento Redux eficiente. Destina-se a ser a maneira padrão de escrever a
lógica do Redux. Ele inclui várias funções de utilitário que simplificam os casos de uso
mais comuns do Redux, incluindo configuração de armazenamento, definição de
redutores, lógica de atualização imutável e até mesmo criação de "fatias" inteiras de
estado de uma só vez sem escrever nenhum criador de ação ou tipo de ação
manualmente (Toni, 2022).

25
O SweetAlert é uma API — Application Programming Interface — utilizada para estilizar
e adicionar funcionalidades às caixas de diálogos em aplicações web. Ele oferece uma
série de recursos que tornam a comunicação entre a página e a pessoa usuária muito
mais funcional e elegante (CAMPIONI, 2022).

JsPDF autotable é um plugin JavaScript que é usado para gerar pdfs contendo tabelas,
seja analisando tabelas HTML ou de JavaScript fornecendo os dados diretamente.
Quando usamos este plugin em nossa página, ele baixa automaticamente o pdf gerado
para nossa máquina local.

Tailwind ICSS é uma estrutura CSS de código aberto. A principal característica desta
biblioteca é que, ao contrário de outros frameworks CSS como Bootstrap, ela não
fornece uma série de classes predefinidas para elementos como botões ou tabelas. Em
vez disso, ele cria uma lista de classes CSS "utilitárias" que podem ser usadas para
estilizar cada elemento misturando e combinando.

Tailwind CSS é um framework CSS utilitário que fornece plugins oficiais para recursos
populares.
Tailwind CSS Forms é um plugin que melhora o estilo padrão dos elementos do
formulário e facilita a personalização deles usando classes de utilitários.

React Toastify As notificações são uma parte essencial do desenvolvimento de

aplicativos; você descobrirá isso rapidamente quando começar a desenvolver aplicativos
da Web ou móveis. A necessidade de notificar o usuário sobre o que está acontecendo
nos bastidores se tornará inevitável.

React Toastify é um excelente exemplo das poucas bibliotecas que resolvem totalmente
esse problema.

React Hook Form é uma biblioteca que auxilia na criação e validação dos formulários,
como já mencionado, além de reduzir a quantidade de código desenvolvido, fazendo
com que a captura de ações do formulário também seja mais objetiva. Outra facilidade
que ele traz é na melhora significativa de desempenho, já que a ação de renderização
também pode ser controlada. Dessa forma, apenas as alterações de entradas são
rerrenderizadas, não o formulário inteiro.

O React Icons é uma biblioteca que ajuda o desenvolvedor ou desenvolvedora na

inserção de ícones dentro das páginas em desenvolvimento. Bastante utilizado nas
26
aplicações, é um pacote que disponibiliza os ícones como componente, permitindo sua
estilização para deixá-los de acordo com o layout da sua aplicação.

Axios é um cliente HTTP baseado em Promises para fazer requisições. Pode ser
utilizado tanto no navegador quanto no Node.js ou qualquer serviço de API. Neste artigo
criaremos um projeto em React que realiza requisições HTTP a API do GitHub usando o
Axios.

Animações CSS tornam possível animar transições de um estilo CSS para outro.
Animações se consistem de dois componentes: um estilo descrevendo a animação e um
set de keyframes que indicam o estado final e inicial do estilo CSS da animação, bem
como possíveis waypoints intermediários ao longo do caminho.

O MomentJS é uma biblioteca JavaScript muito poderosa, que fornece todo tipo de
métodos e funções já prontinhas para lidar com o tempo em si. Seja ele disposto de
qualquer e toda forma possível, podendo ser usada a qualquer MOMENT.

Headless ui/react são Componentes de interface do usuário totalmente sem estilo e

totalmente acessíveis, projetados para se integrar perfeitamente ao Tailwind CSS.

A nível de Back-end usamos a ferramentas e tecnologias abaixo:

O Visual Studio Code é um editor de código-fonte desenvolvido pela Microsoft para

Windows, Linux e macOS. Ele inclui suporte para depuração, controle de versionamento
Git incorporado, realce de sintaxe, complementação inteligente de código, snippets e
refatoração de código. Ele é customizável, permitindo que os usuários possam mudar o
tema do editor, teclas de atalho e preferências. Ele é um software livre e de código
aberto.

XAMPP é um pacote com os principais servidores de código aberto do mercado,

incluindo FTP, banco de dados MySQL e Apache com suporte as linguagens PHP e Perl.
De plataforma, software livre, que consiste principalmente na base de dados MySQL, o
qual foi substituído pelo MariaDB (embora ainda seja utilizado MySQL em algumas
versões), o servidor web Apache e os interpretadores para linguagens de script: PHP e
Perl,além de um cliente FTP. O nome provem da abreviação de X (para qualquer dos
diferentes sistemas operativos), Apache, MariaDB, PHP, Perl. É um método que torna
extremamente fácil para os desenvolvedores a criar um servidor web local para fins de
teste.
27
GitHub é uma plataforma de hospedagem de código-fonte e arquivos com controle de
versão usando o Git. Ele permite que programadores, utilitários ou qualquer usuário
cadastrado na plataforma contribuam em projetos privados e/ou Open Source de
qualquer lugar do mundo.

PHP (um acrônimo recursivo para "PHP: Hypertext Preprocessor", originalmente

Personal Home Page) é uma linguagem interpretada livre, usada originalmente apenas
para o desenvolvimento de aplicações presentes e atuantes no lado do servidor,
capazes de gerar conteúdo dinâmico na World Wide Web.
Laravel é um framework PHP livre e open-source criado por Taylor B. Otwell para o
desenvolvimento de sistemas web que utilizam o padrão MVC (model, view, controller).
Algumas características proeminentes do Laravel são sua sintaxe simples e concisa, um
sistema modular com gerenciador de dependências dedicado, várias formas de acesso
a banco de dados relacionais e vários utilitários indispensáveis no auxílio ao
desenvolvimento e manutenção de sistemas.
De acordo com uma pesquisa feita em março de 2015 com desenvolvedores, o Laravel
foi listado como o framework PHP mais popular de 2015, seguido pelo Symfony2, Nette,
CodeIgniter, Yii2 e outros. Em agosto de 2015, o Laravel já era o principal framework de
projetos PHP no GitHub. Atualmente encontra-se na versão 9 (Andri, et al., 2019).
1.6. Vantagens que apresenta:
Tem uma interface muito intuitiva e é fácil de aprender.
Permite a geração automática de diagramas a partir da descrição de casos de uso.
Permite a descrição dos casos de uso que de uma variedade de modelos padrão que
permitem a personalização.

1.7. Proposta para a solução

A fim de dar solução aos problemas que o Instituto de Tecnologias de Informação e
Comunicação enfrenta serão utilizados os seguintes recursos: para o desenvolvimento
do mesmo a metodologia de desenvolvimento será OpenUp, as ferramentas e
tecnologias serão: Xamp, VSCode, Laravel, GitHub, Next JS, Redux Toolkit, Sweetalert,
JSpdf Autotable, Tailwind CSS, Tailwind CSS Forms, React Toastify, React Hook, React
Icons, Axios, Animações CSS, MomentJS, Headless UI/React.

28
 1.8. Metodologias de Investigação Científica
Para o cumprimento dos objetivos específicos proposto, foram usados diferentes
métodos e procedimentos teóricos e empíricos da investigação científica na busca e
processamento da informação. Dos métodos teóricos foram aplicados os seguintes:
Histórico-Lógico: Este método se utiliza para analisar como o desenvolvimento das
tecnologias está evolucionando os sistemas de avaliação e desempenho docente.
Analítico-Sintético: Se aplica para analisar a informação e a documentação relevantes
para o desenvolvimento do sistema de avaliação e desempenho docente, enfatizando
nos elementos mais importantes que se relacionam com o objeto de estudo.
Dos métodos empíricos foram aplicados os seguintes:
Entrevista: Realizaram-se várias entrevistas com o responsável da área, sobre como é
feita a gestão do processo completo de avaliação do desempenho do docente do
INSTIC, para compreender melhor a situação existente.

29
Conclusão
O mundo tem evoluído continuamente, é importante acompanhar esse dinamismo, os
sistemas informáticos são fundamentais para as organizações, auxiliam as
organizações na manipulação dos dados que são gerados e como ferramenta de
divulgação do seu negócio.
Por estes motivos será desenvolvido um novo sistema que cumpra com todos os
requisitos que o Instituto de Tecnologias de Informação e Comunicação necessita já
estabelecidos pelo DP nº121/20.
A metodologia a ser implementada será a OpenUp por ser adaptável às necessidades
do produto, o que facilita que não se adicione um trabalho excessivo pela quantidade de
papéis ou documentação que se gera com o uso das metodologias pesadas. OpenUp
permite detetar erros temporários através de um ciclo iterativo e como metodologia ágil
é idónea para realizar o sistema de gestão em questão.
.

30
CAPÍTULO 2 – CARACTERÍSTICA DO SISTEMA

2. Introdução
Neste capítulo é feita a apresentação da modelagem do negócio, descrição do negócio,
diagrama de caso de uso de negócio, descrição do caso de uso de negócio,
modelagem do sistema, especificação de requisitos do sistema, requisitos funcionais,
requisitos não funcionais, descrição do caso de uso do sistema, arquitetura do sistema,
padrão de desenho utilizado, diagrama de classes com estereótipos UML para Web,
padrões de desenho, análise e desenho do banco de dados, modelo lógico e físico de
dados, normalização dos dados.

2.1. Objecto de automação

Automatizar o processo de avaliação e desempenho do docente para o INSTIC, assim
como a facilidade no processo de armazenamento e busca de informação é o que
propõe o sistema a realizar. Será implementado a modelagem e análise do negócio
antes de se iniciar a desenvolver o sistema pois é necessário entender em qual domínio
de negócio o mesmo processo se consegue executar.

2.2. Modelagem do negócio

Para mostrar como o negócio funciona, determinar os atores e trabalhadores do negócio
e explicar detalhadamente o papel que desempenha no negócio, para tal se faz uma
modelagem de negócio, suscetível de mostrar os casos de uso de negócio e as suas
descrições. Também explica a lógica por meio da qual uma organização gerência, cria,
mantem e disponibiliza valores (Luís, 2020).

2.2.1. Descrição do negócio

A ADD assenta nos princípios da universidade, obrigatoriedade, objetividade, relevância,
transparência, imparcialidade, rigor e coerência. A ADD do ensino superior deve ser
aplicada a todos os docentes, abarcando as diferentes dimensões do seu desempenho,
ao longo do exercício da sua atividade profissional na instituição onde presta serviço,
todos os docentes estão obrigados a sujeitar-se ao processo de AD, de acordo aos
princípios, as regras, procedimentos e pressupostos estipulados no Regulamento e
demais legislação aplicável (DP 121/20, 2020).

31
A ADD deve identificar os aspetos mais importantes do desempenho docente sobre os
quais deve recair a avaliação, tendo em conta o objetivo de promover o desenvolvimento
pessoal e profissional, a ADD deve ser baseada em parâmetros e indicadores, sempre
que possível, mensuráveis e passiveis de comprovação com evidencias. Deve ser
previamente divulgada as regras, os critérios, os procedimentos, os parâmetros, os
indicadores e as escalas de valorização que sustentam o processo de ADD (DP 121/20,
2020).

2.2.2. Diagrama de caso de uso do negócio

Na Engenharia de Software, caso de uso de negócio é a sequência de ações realizadas
no negócio, que produzem um resultado de valor observável para certos atores de
negócio.

Um diagrama de caso de uso de negócio descreve os processos de um negócio

vinculados ao campo de ação e como se beneficiam e interagem os sócios e clientes
nestes processos (Luís, 2020). Assim sendo a seguir apresenta-se o diagrama de caso
de uso de negócio na figura 2.1.

Figura 2.1 - Diagrama de casos de uso do negócio (elaboração própria)

32
 2.2.3. Descrição de caso de uso do negócio

A tabela 2.1, mostra a descrição do caso de uso para o negócio fazer avaliação. No caso
de uso fazer avaliação, o actor docente e o trabalhador coordenação (CAD) interagem,
para realizar a ação de fazer avaliação, o que permite o docente solicitar a sua avaliação
na unidade orgânica sendo que a coordenação pode efetuar a avaliação do mesmo.
Tabela 2.12 - Descrição do caso de uso para o negócio fazer avaliação

Caso de Uso: Fazer avaliação de desempenho

Actor: Docente
Trabalhador: Coordenação (CAD)
Resumo: O caso de uso dá-se o início quando a coordenação anuncia abertura do ano de
avaliação de desempenho, o docente apresenta os requisitos necessários
(trabalhos e outros) e este efetua a avaliação do Docente.

Pré-condições Apresenta os documentos necessários

Pós-condições Docente avaliado com sucesso
1. Secção
Fluxo de evento normal
Acção do actor Resposta do negócio
1. Docente se informa sobre os requisitos para 2.Atende e solicita o documento ao docente.
avaliação.
3. Entregar documentos 4.Recebe os documentos necessários e verifica-
os
4.1. Entrega a ficha de avaliação ao docente.
1. 5. Recebe a ficha de avaliação e preenche 2.
e 6.Recebe a ficha de avaliação
entrega a coordenação com os respetivos 3. 6.1. Verifica se está bem preenchida
comprovantes em anexo.
4. 6.2. Assina a ficha de avaliação
5. 6.3. Adiciona docente na lista de avaliados naquele
referido período.
6. 6.4. Entrega e valida a nota da avaliação.
7. 7. Recebe comprovativo e sai da coordenação da
8.
Unidade Orgânica.
Fluxo de eventos alternativos
“Documentos em falta”
Acção do actor Resposta do negócio
9. 10. 1. Se os documentos não estão completos
11. 1.1. Informe ao docente e entrega-os os seus
documentos
12. 2. O docente recebe os documentos e retira-se da
13.
coordenação
“Ficha de avaliação mal preenchida”
Acção do actor Resposta do negócio

33
 14. 1. Se a ficha de avaliação está mal preenchida.
15. 2. Orientar o docente a correção, e entregar a
ficha.
3. Recebe a ficha e faz a correção 16. 4. Volta ao passo 6 do fluxo de eventos normal
Elaboração própria

2.3. Modelagem do sistema

É denominado por modelagem de sistemas, ao processo de desenvolvimento de
modelos abstratos de um sistema, de modos que cada modelo tenha uma apresentação
ou uma visão diferente do sistema. De forma geral representa o sistema com algum tipo
de notação gráfica, que se baseia em notações de UML. Também é possível
desenvolver modelos matemáticos formais de um sistema, na maioria das vezes como
uma especificação detalhada do sistema (Ricardo, et al., 2019).

A modelagem de sistemas permite ao analista compreender as suas funcionalidades, e

os modelos são usados para comunicação com os clientes ou empresas. Durante o
processo de engenharia os modelos normalmente são usados como requisitos para
ajudar na extração dos requisitos do sistema; ao passo que são usados para descrever o
sistema aos engenheiros que implementam durante o processo do projeto, e a posterior,
usados para documentar a operação e a estrutura do sistema.

Tais requisitos descrevem os serviços fornecidos pelo sistema e as suas restrições

operacionais. São a reflexão das necessidades dos clientes de um sistema que auxilia
na resolução de certos problemas, por exemplo, a localização ou solicitação de
informações (Luís, 2020).

2.3.1. Requisitos Funcionais

Os requisitos funcionais descrevem o que o sistema deve fazer, as suas funcionalidades
e serviços do sistema, especifica qual deverá ser a reação do sistema a entradas
específicas, a atividade de levantamento de requisitos corresponde à etapa de
compreensão do problema. O levantamento de requisitos fornece o mecanismo
adequado para entender o que o cliente deseja, analisando suas necessidades, e
determinando se elas são possíveis (André, et al., 2020). A Tabela 2.2, exibe os
requisitos funcionais existentes no software.

34
 Tabela 2.13 - Requisitos funcionais existentes

Categoria Requisitos funcionais Complexidade Prioridade

RF01: Autenticar usuário Alta Alta
RF02: Criar usuário Alta Alta
Gerir usuário RF03: Editar usuário Alta Média
RF04: Excluir usuário Baixa Média
RF05: Listar usuário Média Baixa
RF06: Inserir ano académico Alta Alta
Gerir ano RF07: Listar ano académico Alta Média
académico RF08: Atualizar ano académico Baixa Média
RF09: Excluir ano académico Média Média
RF07: Inserir ano lectivo Alta Alta
Gerir ano RF08: Listar ano lectivo Alta Média
lectivo RF09: Atualizar ano lectivo Baixa Média
RF10: Excluir ano lectivo Média Média
RF11: Inserir curso Alta Alta
RF12: Listar curso Alta Média
Gerir curso
RF13: Atualizar curso Baixa Média
RF14: Excluir curso Média Média
RF15: Preencher avaliação Alta Alta
RF16: Validar avaliação Média Alta
Gerir
RF17: Gerar pontuação da avaliação Média Alta
avaliação
RF18: Avaliar docente Alta Alta
RF19: Publicar resultado Alta Alta
RF11: Inserir turma Alta Alta
RF12: Listar turma Alta Média
Gerir turma
RF13: Atualizar turma Baixa Média
RF14: Excluir turma Média Média
RF15: Inserir disciplina Alta Alta
Gerir RF16: Listar disciplina Baixa Média
disciplina RF17: Atualizar disciplina Média Média
RF18: Excluir disciplina Baixa Média
RF19: Inserir unidade orgânica Alta Alta
Gerir
RF20: Listar unidade orgânica Baixa Média
unidade
RF21: Atualizar unidade orgânica Média Média
orgânica
RF22: Excluir unidade orgânica Baixa Média

35
 RF23: Inserir departamento Alta Alta
Gerir
RF24: Listar departamento Baixa Média
departament
RF25: Atualizar departamento Média Média
o
RF26: Excluir departamento Baixa Média
RF27: Inserir cargo Alta Alta
RF28: Listar cargo Alta Média
Gerir cargo
RF29: Atualizar cargo Baixa Média
RF30: Excluir cargo Média Média
RF31: Inserir membro CAD Alta Alta
Gerir
RF32: Listar membro CAD Alta Média
membro
RF33: Atualizar membro CAD Baixa Média
CAD
RF34: Excluir membro CAD Média Média
RF35: Inserir avaliadores Alta Alta
Gerir RF36: Listar avaliadores Alta Média
avaliadores RF37: Atualizar avaliadores Baixa Média
RF38: Excluir avaliadores Média Média
Elaboração própria.

2.3.2. Requisitos não funcionais

As restrições sobre as funções ou serviços garantidos pelo sistema são os requisitos não
funcionais. Os requisitos não funcionais incluem restrições sobre o processo de
desenvolvimento e padrões. Eles não se aplicam às características ou serviços
individuais do software, mas aplicam-se frequentemente, ao software, no geral, (André,
et al., 2020).

Na engenharia de software e de sistemas, um requerimento não funcional especifica os

critérios que podem ser aplicados para garantir o funcionamento de um sistema, em vez
de seus específicos comportamentos, uma vez que correspondam aos requisitos
funcionais.

No entanto, não descrevem as funções a serem executadas, mas sim referem- se a

todas as exigências para manter as informações. Tais requisitos fornecem o mecanismo
apropriado para entender aquilo que o cliente deseja, analisando as necessidades,
avaliando a viabilidade, negociando uma solução razoável, especificando à solução sem
ambiguidades (Cléber, 2020). A Tabela 2.3, exibe os requisitos não funcionais existentes
no software.

36
 Tabela 2.14 - Requisitos não funcionais

Confiabilidade
RNF1: Para não permitir entradas inapropriadas o sistema deve validar os dados.

Segurança
RNF2: O sistema deve permitir acesso somente a utilizadores registrados, mediante nome e senha.
RNF3: A senha para o acesso ao sistema deve ser forte, com uma longitude maior ou igual a 6
caracteres.
RNF4: O sistema deve garantir que haja uma opção de aviso, antes de executar a eliminação de
informações.

Interação
RNF5: O sistema deve validar os dados, de forma a impossibilitar a entrada de dados incorretos.

Compatibilidade
RNF6: Por se tratar de um aplicativo web deve ser Multiplataforma.
Usabilidade
RNF7: O sistema deve ser intuitivo e fácil de navegar, permitindo a que qualquer usuário com pouco
conhecimento de informática pode utiliza-lo.
RNF8: Nas interfaces gráficas deverá ter o uso de design responsivo.
RNF9: Para permitir a interpretação correta deverá garantir boa organização das informações.

Hardware

RNF10: Os requisitos mínimos para o computador que vai funcionar com o software devem ter as
seguintes características: Pentium 4 com 1 GB de RAM, 80 GB de disco rígido.

Software

RNF11: O sistema gerenciador de base de dados é o MySQL.

RNF12: Para aceder a aplicação se requer usar um Navegador Google Chrome ou Mozilla Firefox.

Elaboração própria

2.3.3. Diagrama de casos de uso do sistema

Diagrama de caso de uso do sistema é uma forma de representação gráfica utilizada
para a descrição dos requisitos funcionais do sistema. Resume os detalhes dos usuários
do sistema e as suas interações com o sistema, ajuda a equipa a representar e discutir
cenários em que o sistema interage com pessoas, organizações, ou sistemas externos e
as metas a atingir (Ricardo, et al., 2019).

37
A figura 2.2 se faz representar os casos de usos e os atores externos ao sistema. O caso
de uso do sistema representa uma sequência de ações realizadas pelo sistema, recebe
do ator que o utiliza, dados tangíveis de um tipo e formato, bem como o valor da
resposta da execução de um caso de uso já conhecidos.

Os atores do sistema desempenham o papel de uma entidade externa ao sistema como

um usuário, um hardware ou outro sistema que interaja com o sistema modelado, e
iniciam a comunicação com o sistema por intermédio do caso de uso (Silva, 2022). Na
figura 2.2, descreve os atores do sistema para este trabalho.

Figura 2.2 - Diagrama de casos de uso do sistema (elaboração própria)

2.3.4. Descrição de casos de uso do sistema

Descreve o comportamento do ator e as repostas do sistema. A seguir se mostra a
Tabela 2.4 do caso de uso autenticar usuário, e a respetiva figura de interface referente
ao mesmo caso de uso.

38
 Tabela 2.15 - Caso de uso cadastrar usuário

Caso de Uso: Autenticar usuário.

Atores: Usuário
Resumo: Este caso de uso serve para autenticar usuários no sistema.

Pré-Condição O usuário deve possuir login e senha cadastrada.

Pós-Condição O usuário deve acessar o sistema de acordo com o seu perfil.
Referência RF RF1.
Prioridade Alta.
Fluxo normal de eventos
Acção do ator Resposta do sistema
1. O caso de uso começa quando o usuário indica1. 2. O sistema apresenta a tela de login.
fazer login no sistema.
3. O usuário preenche os campos “Email‟ e “Senha‟2. 4. O sistema valida o email e senha, verifica o perfil
e clica no botão entrar. de usuário e redireciona o usuário a página principal.
Fluxos de Exceção
Fluxos de Exceção
3. Fluxos de Exceção:
4. E1: Usuário deixa campo “Email‟em branco:
5. 1. O sistema exibe a mensagem “O campo email é obrigatório!”.
6. 2. O caso de uso é reiniciado.
7. E2: Usuário deixa campo “Senha‟em branco:
8. 1. O sistema exibe a mensagem “O campo senha é obrigatório!”.
9. 2. O caso de uso é reiniciado.
10. E3: Usuário insere “Email‟ ou “Senha‟ inválidos:
11. 1. O sistema exibe a mensagem “Usuário ou senha incorreto!”.
12. 2. O caso de uso é reiniciado.
13.
Protótipo de Interface

Figura 2.3 - Interface do caso de uso autenticar usuário

Elaboração própria

39
 A figura 2.3 apresentada na Tabela 2.4 refere-se ao protótipo de interface do caso de
uso autenticar usuário, pode-se observar que esta permite o usuário logar-se no
sistema, devem ser preenchidos todos os campos obrigatórios e fazer o login. A seguir
se mostra a Tabela 2.5 que descreve o caso de uso gerir docente.

Tabela 2.16 - Caso de uso gerir docente

Caso de Uso: Gerir docente.

Atores: Administrador.
Resumo: Se especifica o processo de gerir docente.

Pré-Condição O administrador já deve ter sessão iniciada no sistema.

Pós-Condição Um novo docente deve estar cadastrado no sistema.
Referência RF RF02 à RF04.
Prioridade Alta.
Fluxo normal de eventos
Acção do ator Resposta do sistema
14. 2. Abre o painel do administrador com todas as suas
1. Uma vez cadastrado no sistema, autentica-se.
funções possíveis.
Evento. Inserir docente

Acção do ator Resposta do sistema

15. 1. Clica no item docente do menu. 16. 2. Abre a página onde estão listados os docentes
cadastrados no sistema.

3. 3. Clica em adicionar docente. 17. 4. Abre o formulário de inserção do docente.

5. Preenche o formulário com os respetivos dados18. 6. Valida as informações inseridas no formulário.

do docente e clica em salvar.
19. 7. Salva os dados e mostra uma mensagem de
sucesso. Termina o caso de uso.
Evento Excluir Docente

Acção do ator 20. Resposta do sistema

21. 1. Clica no item docente do menu. 22. 2. Abre a página onde estão listados os docentes
cadastrados no sistema.

3. Selecione um docente na lista e clica no ícone de23. 3. Uma caixa de diálogo será aberta para confirmação
excluir. da exclusão do docente selecionado.
4. Confirme a informação clicando em “Sim! Tenho24. 4. Docente excluído do sistema e mostra uma
certeza”. mensagem de sucesso. Termino do caso de uso.
Elaboração própria

40
 2.4. Padrões de arquitetura
Para o desenvolvimento do sistema a arquitetura a utilizar é o MVC, este padrão divide
a aplicação em três componentes ou partes que são: o model, view e controller.
2.4.1. Modelo Vista Controlador (MVC)
MVC é a abreviação de Model, View e Controller. MVC é uma forma popular de
organizar seu código. A grande ideia por trás do MVC é que cada seção do seu código
tem um propósito, e esses propósitos são diferentes. Parte do código contém os dados
do seu aplicativo, parte do código faz com que seu aplicativo tenha uma boa aparência
e parte do código controla o funcionamento do aplicativo. MVC é uma maneira de
organizar as funções centrais do seu código em suas próprias caixas bem organizadas.
Isso torna muito mais fácil e limpo pensar sobre seu aplicativo, revisitá-lo e compartilhá-
lo com outras pessoas (Barbosa, 2022).
Os três componentes fundamentais do MVC são:
Model: Inclui todos os dados e sua lógica relacionada.
View: apresenta dados ao usuário ou lida com a interação do usuário.
Controller: uma interface entre os componentes Model e View.
Acompanhe a descrição destes três componentes logo abaixo:
View
Uma visualização é a parte do aplicativo que representa a apresentação dos dados.
As visualizações são criadas pelos dados coletados dos dados do modelo. Uma
visualização solicita que o modelo forneça informações para que reenvie a
apresentação de saída ao usuário.
A view também representa os dados de bate-papos, diagramas e tabelas.
Controller
A Controller é a parte do aplicativo que lida com a interação do usuário. A controller
interpreta as entradas do mouse e do teclado do usuário, informando à model e a view
as alterações a serem efectuadas conforme apropriado.
Uma Controller envia comandos a model para actualizar seu estado (por exemplo,
salvando um documento específico). A controller também envia comandos para sua
view associada para alterar a apresentação da view (por exemplo, rolar um documento
específico).

41
 Model
O componente model armazena dados e sua lógica relacionada. Ele representa os
dados que estão sendo transferidos entre os componentes da controller ou qualquer
outra lógica de negócios relacionada. Por exemplo, um objeto Controller recuperará as
informações do cliente do banco de dados. Ele manipula os dados e os envia de volta
ao banco de dados ou os usa para renderizar os mesmos dados. Ele responde à
solicitação das views e também às instruções da controller para se actualizar. É
também o nível mais baixo do padrão responsável por manter os dados (Lucca, et al.,
2021). A figura 2.4 ilustra o resumo do MVC.

Figura 2.4 - Padrão MVC. Fonte: ( (JOSUÉ, et al., 2011))

2.5. Padrões de desenho

Padrão de desenho é uma solução geral para um problema que ocorre com frequência
dentro de um determinado contexto no projeto de software. Uma solução bem provada
para um problema comum que captura a experiência e as boas práticas de forma que
possa ser reutilizada. É uma representação abstrata que pode ser instanciada de várias
maneiras. Entre os padrões que se utilizam neste contexto encontra-se o padrão geral
de software para atribuição de responsabilidades general responsibility asigment
software patterns (GRASP) (Sommerville, 2011).
Os padrões GRASP englobam uma série de princípios baseados em conceitos de
orientação a objetos. Partindo de análises que procuram definir quais as obrigações dos

42
diferentes tipos de objetos em uma aplicação, estes patterns disponibilizam uma série
de recomendações que procuram favorecer a obtenção de sistemas melhor
estruturados. Partindo de práticas consagradas no desenvolvimento de sistemas
orientados a objetos, os padrões GRASP procuram fornecer diretrizes para a
construção de aplicações bem estruturadas e que possam ser facilmente adaptáveis
diante da necessidade de mudanças. A consequência direita das recomendações
propostas por estes patterns é um código melhor organizado, de fácil manutenção e
ainda, capaz de ser compreendido por diferentes desenvolvedores sem grandes
dificuldades (Devmedia, 2019).
Os utilizados no desenho do SIADD-INSTIC são os seguintes:
Controlador (Controller): quando aplicado atribui a responsabilidade por lidar com
eventos do sistema a uma classe que não esteja relacionada a interface com o usuário.
Na presente investigação este padrão pode ser observado no modelo views
(responsável pela criação de boa parte da regra de negócio do sistema).

Criador (Creator): este princípio determina qual classe deve ser responsável pela
criação de um certo objeto. O uso deste padrão pode ser observado entre a model
docente e a model contrato, onde a model docente possui informação necessária para a
inicialização da model contrato.

Especialista (Information Expert): propõe dar as responsabilidades as classes de

acordo a informação que contém as mesmas, cumprindo assim um princípio básico e
intuitivo da programação orientada a objetos. Dito padrão se pode observar na models
Pagamento, onde nela é necessário a criação do objeto contracto.

2.6. Diagrama de classes com estereotipo UML para Web

Em princípio, um diagrama de classes representa uma visão do modelo estrutural
estático, que pode ser entendido como a união de todos os diagramas de classe e de
objetos, da mesma maneira que pudesse projetar uma figura tridimensional em diversos
planos bidimensionais. Classes são descritores para um conjunto de objetos com
estrutura, comportamento e relacionamentos similares. Seu modelo diz respeito a
intensão de uma classe, ou seja, as regras que a definem enquanto uma classe (Júnior,
2020). A seguir se mostra a figura 2.5 que ilustra o diagrama de classe.

43
 Figura 2.5 - Diagrama de classe com estereotipo web. Fonte: (Elaboração própria).

2.7. Normalização dos dados

Sendo o processo de organização de dados em um banco de dados. Isso inclui a criação

de tabelas e o estabelecimento de relações entre essas tabelas de acordo com as regras
projetadas para proteger os dados e tornar o banco de dados mais flexível, eliminando a
redundância e a dependência inconsistente. Dados redundantes desperdiçam espaço
em disco e criam problemas de manutenção. Se os dados existentes em mais de um
local devem ser alterados, eles devem ser alterados exatamente da mesma maneira em
todos os locais. Uma alteração de endereço do cliente é muito mais fácil de implementar
se esses dados são armazenados apenas na tabela Clientes e em nenhum outro lugar
no banco de dados.

Há algumas regras para normalização do banco de dados. Cada regra é chamada de

"forma normal". Se a primeira regra for observada, diz-se que o banco de dados está na
"primeira forma normal ". Se as três primeiras regras forem observadas, o banco de
dados será considerado na "terceira forma normal". Embora outros níveis de
normalização sejam possíveis, a terceira forma normal é considerada o nível mais alto
necessário para a maioria dos aplicativos. Assim como muitas regras e especificações
formais, os cenários do mundo real nem sempre permitem a conformidade perfeita. Em
geral o SIADD-INSTIC baseia-se sobre as três primeiras regras.

44
 2.7.1. Modelo lógico de dados
Um modelo de banco de dados mostra a estrutura lógica de um banco de dados,
incluindo as relações e restrições que determinam como os dados podem ser
armazenados e acessados. Os modelos de dados individuais são projetados com base
nas regras e nos conceitos do modelo abrangente que os designers adotam. A maioria
dos modelos de dados podem ser representados por um diagrama de banco de dados
acompanhante.
Foi desenvolvido para facilitar o desígnio de base de dados que permite a especificação
de um esboço do universo de fala que representa a estrutura completa de um dado
básico. Em geral este modelo representa de forma abstrata a estrutura que possuirá a
base de dados da aplicação (Elmasri, 2011). A figura em anexo 1, exibe o modelo
lógico de banco de dados do SIADD-INSTIC.
2.7.2. Modelo físico da base de dados
Descrito, por meio de alguma linguagem, como será feita a armazenagem no banco.
Nesse nível se escolhe qual Sistema gerenciador de Banco de dados (SGBD) será
usado, levando em consideração o modelo lógico adotado. Para o SIADD_INSTIC foi
PostgreSQL e MySQL (Elmasri, 2011). A figura 2.7, exibe um trecho do modelo físico
de banco de dados do SIADD-INSTIC.

Figura 2.6- Modelo físico do banco de dados. Fonte: (Elaboração própria)

45
46
 2.8. Modelo conceptual ou domínio
De uma maneira geral, o modelo de domínio envolve o contexto onde o software será
aplicado, e sua compreensão, antes da introdução do sistema de software que se
pretende desenvolver. Assim, vemos que o modelo conceitual ilustra conceitos
significativos de um domínio aquilo que devemos estar cientes a respeito do domínio,
representando sempre coisas do mundo real não componentes de software (Jonnathan,
et al., 2020), assim sendo a figura 2.7 ilustra o modelo conceitual do SIADD-INSTIC.

Figura 2.7 - Modelo conceitual. Fonte: (Elaboração própria)

47
Conclusão
Neste capítulo fez-se um estudo sobre a modelagem do negócio como resultado da
modelagem do negócio e se identificaram os atores de negócio, também foram
identificados os principais caso de uso de negócio e de sistema onde foram projetados
38 requisitos funcionais, 12 requisitos não funcionais, apresentou-se a arquitetura do
sistema, o padrão de desenho utilizado, o diagrama de classes com estereótipos UML
para Web, a normalização dos dados, o modelo de dados, o modelo conceptual do
negócio bem como protótipos de interfaces com usuários, os quais foram
implementados e integrados com sucesso no SIADD-INSTIC.

48
CAPÍTULO 3 - DESENHO, IMPLEMENTAÇÃO E PROVAS DO

SISTEMA

3. Introdução
Neste capítulo é apresentado o diagrama de componentes, o modelo de implantação e
o padrão de codificação. Para a validação do sistema é feita a apresentação das
técnicas utilizadas para provar a garantia da confiabilidade e detetar possíveis falhas no
sistema.

3.1. Diagrama de componentes

O diagrama de componente dá uma visão de como o sistema foi implementado e quais
os componentes utilizados (Gudwin, 2010). Através deste diagrama, são identificados
os arquivos que compõem o sistema apresentando uma visão estática de como o
sistema está implementado e quais os seus módulos de software (componentes),
também está muito associado a linguagem de programação procurando associar
módulos, bibliotecas, formulários, arquivos, tabelas.
Um dos objetivos deste diagrama é modelar os componentes do código-fonte e
executável, Banco de dados físicos, destacar a função de cada módulo para facilitar a
reutilização, utilizar o processo de engenharia reversa por meio da organização dos
módulos do sistema e seus relacionamentos.
Qualquer parte de seu sistema pode ser representado em um diagrama de
componentes e são usados para explicar a lógica dos artefactos que são usados para
implementar as expressões lógicas do provecto do caso de uso e diagrama de classes
(Books, 2006). Componente pode ser uma página HTML, um arquivo txt, dll, jar e etc.
Um componente expõe suas interfaces (métodos públicos) para o mundo externo, para
representar isso é possível utilizar a notação de interface e estereotipá-la como um
componente. Um componente pode utilizar serviços ou depender de alguma outra
forma de outros componentes do sistema.
A seguir se mostra a figura 3.1 que representa o diagrama de componente do sistema.

49
 Figura 3.6- Diagrama de componentes Docente. Fonte: Elaboração própria

3.2. Modelo de despliegue (implantação)

É usado para representar a distribuição física (estática) dos componentes de software
nos diferentes nós físicos da rede. Geralmente é usado junto com o diagrama de
componentes (às vezes até com o diagrama de pacote) para que, juntos, eles forneçam
uma visão geral de como o sistema de informação será implantado. O diagrama de
componentes mostra quais componentes existem e como eles estão relacionados
enquanto o diagrama de implantação é usado para ver como esses componentes
lógicos estão localizados nos diferentes nós físicos. Como praticamente todos os
diagramas UML, ele pode ser usado para representar aspetos gerais ou muito
específicos, sendo mais comumente usado para aspetos gerais (DiagramasUML, 2017).
A figura 3.2, exibe o modelo de implantação.

50
 Figura 3.7 - Modelo de despligue (implantação). Fonte: (Diocleciano, 2021)

3.2.1. Descrição do modelo de implantação do sistema

A tabela 3.1, exibe a descrição modelo de implantação.

Tabela 3.17 - Descrição do modelo de despliegue.

Nós/Dispositivos Descrição
Acedem a aplicação através de um computador ou smartfone, onde é
PC/MOBILE cliente executada mediante um navegador disponível no computador/smartfone,
que tenha um sistema operativo.
Servidor de aplicação É onde a aplicação é mantida e executada, inclui a lógica de negócio da
web aplicação, e para este caso específico o servidor usado é o PostgreSQL.
Servidor de banco de É o local onde os dados poderão ser armazenados, ele usa um sistema
dados gerenciador de banco de dados para este caso o PostgreSQL.
Trata-se do protocolo utilizado pelos servidores web para a transferência e
HTTPs visualização de conteúdo web de forma segura para o cliente, neste caso
o navegador.
TCP/IP Protocolo para conectar o servidor de aplicação ao base de dados.
Impressora Os usuários do sistema podem fazer impressões de relatórios e afins.
Elaboração própria

51
 3.3. Padrão de codificação
O propósito dos estândares de codificação é organizar e estilizar consistentemente o
sistema com independência do autor de modo a facilitar e ajudar a entender a forma
como se programa. Tendo em conta que a proposta da solução se desenvolve
utilizando o framework django na sua versão 3 se define o uso do estândar PEP 8 –
Style Guide for Python code (Rossen, 2018). Python usa indentação para dar uma
indicação visual da estrutura do seu código. Adicionalmente tem-se um interpretador
interativo que provê uma representação do interpretador para objetos.
 Utilize quatro espaços para indentação
 Não se faz abertura de chaves para as classes ou funções.
 Use aspas simples para variáveis que recebem valor string.
 As palavras reservadas como as de estruturas de controle, devem ter espaço
entre elas.
 Ao indicar as relações entre as classes, deve-se seguir a ordem de precedência
certa.
 Utiliza import de conveniência quando possível. Exemplo (from django. views
import view).
 Nas views do Django, o primeiro parâmetro na função de uma view deve ser
chamado request.
 Os nomes dos campos, devem ser todos minúsculos, usando underscores ao
invês de camelCase.
 Utiliza-se uma linha em branco entre o último import e qualquer código a nível de
módulo, e duas linhas em branco acima da primeira função ou classe.

3.4. Processo de Provas

Teste de Software Seguindo a metodologia OpenUP. Uma série de testes foi realizada
no produto, sendo que a implementação foi concluída. Uma vez que é necessário
verificar a operação, a qualidade da mesma e garantir que ela atenda aos requisitos
estabelecidos pelos clientes e todos os possíveis erros sejam detetados e corrigidos
(Canalti , 2019).

52
 3.4.1. Estratégia de prova
Para iniciar os testes de um software, a primeira coisa é definir uma estratégia de teste
onde os níveis de teste a serem tratados são capturados, assim como os tipos de teste,
o método de teste e a técnica aplicada neste método. Uma estratégia de teste de
software integra métodos de projeto de caso de teste de software em uma série bem
planejada de etapas que levará à construção do software. Deve incorporar o
planejamento de testes, o desenho de casos de teste, a execução de testes e a coleta e
avaliação dos dados resultantes. Isso tem que ser flexível o suficiente para promover
uma abordagem personalizada. Ao mesmo tempo, deve ser suficientemente rígido para
promover o planejamento razoável e o monitoramento administrativo do progresso do
projeto (Portalgsti , 2019).

3.4.2. Prova de caixa branca

É baseado na estrutura interna do código das aplicações. Nos testes de caixa branca,
uma perspetiva interna do sistema, bem como as habilidades de programação, são
usadas para projetar casos de teste. Esse teste geralmente é feito no nível da unidade
(SM, 2018).

Vantagens da Prova de caixa branca, segundo o Ianswer4u (2019):

 O teste pode começar mesmo antes da GUI estar pronta.

 Como a funcionalidade interna é considerada, todas as condições possíveis são
consideradas e os casos de teste são gerados. Portanto, todas as funcionalidades
estão sendo testadas.
 Ele identifica a precisão do procedimento específico dentro do aplicativo.
 Ele verifica minuciosamente se o programa pode ser executado com sucesso com
outras partes do aplicativo.
 Ele identifica o erro no código oculto e, portanto, torna o processo de depuração
rápido.
 Ele remove linhas extras de código que não são necessárias no programa,
otimizando assim o programa e aumentando a eficiência.
 Como a codificação interna do aplicativo é considerada durante a preparação dos
casos de teste, torna-se muito fácil identificar a entrada e os dados de saída
esperados.
 Isso ajuda na avaliação de todas repetições (loops) e caminhos.
53
  Ele pode fornecer estabilidade e usabilidade dos casos de teste.
 A exaustividade alcançada no teste de caixa branca é muito mais do que o teste
de caixa preta.
 Vários defeitos ocultos se desenterram durante a realização da prova de caixa
clara.

Na figura 3.3, mostra o código de cadastro de docente no sistema, nome da função

adicionarDocente, que funciona da seguinte maneira, no primeiro verifica se o docente
por adicionar já existe no sistema, se não cria um novo registro do docente, salva na
base de dados e devolve a view com a mensagem de salvo “docente salvo com
sucesso” caso não houver erro nenhum ao salvar.

Mas caso houver uma falha ao salvar devolve a view com a mensagem de erro houve
um erro ao tentar registar um novo docente no sistema.

Figura 3.8 - Fragmento de código com aplicação do teste de caixa branca. Fonte: (Elaboração própria)

Na figura 3.4, mostra gráfico fluxo prova caixa branca, onde tem quatro arestas e quatro
de nós.

54
 Figura 3.9 - Gráfico Fluxo Prova Caixa Branca Fonte: Elaboração própria

O número máximo de casos de prova é calculado pela fórmula V ( G )= A−N +2 (1), onde A
é o número de arestas e N o número de nós do grafo.

V ( G )=9−8+2 (2),

Caminho: 1-2-3-4

Caso de prova: Cadastrar docente no sistema quando o docente não existe no sistema.

Entrada: O docente preenche o formulário de adicionar novo docente no sistema.

Resultado: O sistema apresenta uma mensagem de notificação (:” docente

cadastrado com sucesso”).

Caminho: 1-2-4-5-6-8

Caso de prova: Cadastrar docente no sistema quando o docente já existe no sistema.

Entrada: O usuário preenche o formulário de adicionar novo docente no sistema.

Resultado: O sistema apresenta uma mensagem de notificação (:” docente já existe

no sistema!”).
3.4.3. Provas de caixa preta

Os testes de caixa preta, também chamados de testes comportamentais, concentram-se

nos requisitos funcionais do software. Esse teste permite que o engenheiro de software
obtenha conjuntos de condições de entrada que exercitam totalmente todos os requisitos
funcionais de um programa. O teste de caixa preta tenta encontrar erros das seguintes
categorias:

 Funções incorretas ou ausentes.

 Erros de interface.
 Erros nas estruturas de dados ou acesso a bancos de dados externos.

55
  Erros de desempenho e erros de inicialização e finalização.

A técnica aplicada nesse método é a partição equivalente que divide o campo de entrada
de um programa em classes de dados das quais os casos de teste podem ser derivados.
A partição equivalente é direcionada para a definição de casos de teste que descobre
classes de erros, reduzindo assim o número total de casos de teste que devem ser
desenvolvidos (Reqtest , 2015). A tabela 3.2 ilustra a prova de caixa preta do caso
registrar docente.

Tabela 3.18 - Prova de caixa preta: registrar docente

Classes de equivalência
Condições de entrada Classes de equivalência válidas
inválidas
O campo nome do docente
Nome = ‘Jairo Santos’ Nome = “ ”
não pode estar vazio
O campo Nº mecanográfico
Nº mecanográfico = ‘1112’ Nº mecanográfico = “ ”
não pode estar vazio
O campo categoria
categoria profissional =
profissional não pode estar Categoria profissional = ‘’
‘Assistente estagiário’
vazio
O campo percent. contrato
percent. contrato = ‘60%’ Percent. contrato = “ ”
não pode estar vazio
O campo Departamento não
Departamento = ‘Académico’ Departamento = ‘’
pode estar vazio.
Resultados da prova válida: o Sistema redireciona o usuário para o registro de docente.

Teste valido do registro de docente:

Antes: preenchendo todos os campos, que são: nome do docente, nº mecanográfico,
categoria profissional, percentagem contrato e departamento. A figura 3.5 exibe o
formulário de cadastro de docente no SIADD-INSTIC.

56
 Figura 3.10 - Teste de caixa preta em aplicação. Fonte: (Elaboração própria)

Depois: preenchido todos os campos e clicando no botão cadastrar, o sistema emite

uma mensagem ‘Docente registrado com sucesso’ e de seguida abrir a página
Docentes registrados como mostra a figura 3.6.

Figura 3.11 - Teste de caixa preta aplicado e validado. Fonte: (Elaboração própria)

Teste inválido do registrar docente:

Quando não se preenche os dados o sistema mostra a seguinte mensagem: Preencha
os campos vazios, como se vê na Figura 3.7:

57
 Figura 3.12 - Teste de caixa preta aplicado e inválido. Fonte: (Elaboração própria)

As figuras acima mostram os resultados da prova de Caixa Preta, com intuito de validar
a funcionalidade de cadastrarDocente. Na Fase de teste, fez – se 4 (quatro) iterações
em 4 (quatro) cenários, onde na primeira iteração foram detetadas cerca de 4 (quatro)
não conformidades, foram corrigidas as 4 (quatros) não conformidades. Na segunda
iteração, foram detetadas 3 (três) não conformidades dentre estas 2 (duas) foram
corrigidas. Durante a terceira iteração, detetou-se 2 (duas) não conformidades, após o
decorrer da iteração foi possível resolver todas as não conformidades, o que permitiu a
resolução de todas as não conformidades na funcionalidade testada. Para que fosse
possível a certificação da conclusão desta prova realizou-se a 4 (quarta) iteração onde
demostrou-se que a funcionalidade foi aprovada, pois não foram detetadas não
conformidade durante as iterações.

Teste de caixa preta SIADD_INSTIC

4

0
1 2 3 4

Cenários Não conformidades Pontos corrigidos

Figura 3.13 - Gráfico de interação – Prova de Caixa Preta. Fonte: elaboração própria

58
59
Conclusão
Durante o desenvolvimento deste capítulo, abordou-se a compreensão do projeto por
meio de modelos, nos quais encontrou-se o diagrama de componentes que teve um
grande impacto sobre o sistema desenvolvido, pois deu a perceção relacionada as
partes a serem controladas pelo usuário final, dando assim um importante auxílio para o
padrão de codificação e modelo de implementação do sistema como um todo. Os
processos de provas de software realizadas serviram para comprovar o bom
funcionamento e avaliar a qualidade do software.

60
CONCLUSÃO
O presente trabalho teve como objetivo propor uma solução para o sistema de
avaliação do desempenho do docente do Instituto de Tecnologias de Informação e
Comunicação, por meio de um software voltado para web. Com base a execução dos
objetivos específicos e tarefas de investigação, concluiu-se o seguinte:
O estudo do marco teórico-metodológico da investigação e estudo dos sistemas
similares para o sistema de avaliação do desempenho do docente do Instituto de
Tecnologias de Informação e Comunicação, permitiu definir uma proposta que
facilitasse dar soluções as necessidades apresentadas pelo Instituto de Tecnologias de
Informação e Comunicação. O estudo de arte feito, enquadrado nos sistemas de
sistema de avaliação do desempenho do docente, mostrou que as soluções existentes
encontradas não cumprem na integra com as necessidades do sistema em causa.
Com base as metodologias, ferramentas e tecnologias usadas, o sistema foi
implementado seguindo a metodologia OpenUp e as demais ferramentas utilizadas
permitiram que o sistema fosse desenvolvido, alcançando assim os objetivos por este
oferecidos. Usou-se para o Back- Laravel, mysql e eloquent. Front-end React(Nextjs),
redux-toolkit, tailwindCss3. O levantamento de requisitos durante a investigação,
permitiram ter uma visão mais clara sobre as necessidades a serem implementadas e o
funcionamento do sistema proposto. O processo de modelagem do negócio e do
sistema executado resultou nos diagramas e artefactos necessários para orientar o
desenvolvimento do sistema de avaliação do desempenho do docente do Instituto de
Tecnologias de Informação e Comunicação.
A etapa de desenho e implementação da solução desenvolvida permitiram extrair os
elementos fundamentais para o funcionamento do sistema de avaliação do
desempenho do docente do Instituto de Tecnologias de Informação e Comunicação e
permitiu também cumprir na totalidade com os requisitos funcionais identificados.
As provas realizadas permitiram detetar falhas, e melhora-las possibilitando ter um
sistema seguro e com qualidade.

61
RECOMENDAÇÕES
Após a conclusão do trabalho, constatou-se que os objetivos pelos quais foi criado foram
alcançados, para a continuidade recomenda-se o seguinte:

 Usar o aplicativo como a principal ferramenta para avaliar o desempenho do

docente do INSTIC.
 Disponibilizar o aplicativo nas demais unidades orgânicas da Universidade de
Luanda que não usufruem de aplicativos para o auxílio do processo de avaliação
e desempenho do docente.
 Desenvolver uma versão do aplicativo exclusivamente para mobile.

62
BIBLIOGRAFIA

Alves, Maria Piedade, et al. 2018. Perceção dos professores sobre a avaliação do
desempenho docente. Portugal : Revista Portuguesa de Educação, 2018.
André, Fernando, Rollwagen e Joseane, Amaral. 2020. Software Educacional Para
Levantamento De Requisitos. Brasil : UniJuí, 2020.
Andri, Sunardia e Suharjito. 2019. MVC Architecture: A Comparative Study Between
Laravel Framework and Slim Framework in Freelancer Project Monitoring System Web
Based. Indonesia : 4th International Conference on Computer Science and
Computational Intelligence, 2019.
Barbosa, Adriley, Samuel, Ribeiro. 2022. Análise Comparativa Entre Os Padrões
Mvc, Mvp, Mvvm E Mvi Na Plataforma Android. Brasil : Instituto Federal Goiano, 2022.
CAMPIONI, Vanessa. 2022. Torgask: application for organization and task
management. França : Faculdade De Tecnologia De Franca “Dr. Thomaz Novelino” ,
2022.
Canalti . 2019. Teste de Software – Teste caixa-branca e caixa-preta. [Online] 2019.
[Citação: 2019 de Julho de 1.] https://www.canalti.com.br/teste-de-software/teste-de-
software-teste-caixa-branca-e-caixa-preta/.
Cangue, Justino. 2020. Universidade como organização educativa na qualificação dos
profissionais e crescimento económico de Angola. Belo Horizonte : Revista Docência
do Ensino, 2020. ISSN 2237-5864 .
Cléber, Ivo, de Oliveira. 2020. Reengenharia e Engenharia Reversa de Software. São
José do Rio Preto – SP – Brasil : Universidade Estadual Paulista “Júlio de Mesquita
Filho” (UNESP), 2020.
Colnago, Ana, Carolina. 2022. Metodologias Ágeis Na Gestão De Projetos: Um
Estudo De Caso Em Empresas De Software De Londrina. Paraná-Brasil : Universidade
Tecnológica Federal Do Paraná, 2022.
Devmedia. 2019. Devmedia. www.Devmedia.com.br . [Online] Devmedia, 24 de 11 de
2019. [Citação: 7 de 2 de 2020.]
http://www.devimedia.com.br/analisededados/definicao/1903.
DiagramasUML. 2017. Diagrama de despliegue. DiagramasUML. [Online] 2017.
Diocleciano, Joaquim, Donga. 2021. Sistema de Gestão de Fornecedores e
Professores Colaboradores do Instituto Superior para as Tecnologias de Informação e

63
Comunicação. Luanda : Instituto Superior para as Tecnologias de Informação e
Comunicação, 2021.
DP 121/20, de 27Abril. 2020. Regulamento de Avaliação de Desempenho do Docente
do Subsistema de Ensino Superior. Angola : Decreto Presidêncial, 2020.
Elaine, Calasans, de Souza e Marcus, Rogério, de Oliveira. 2019. Comparativo
Entre Os Bancos De Dados Mysql E Mongodb:. Sp-Brasil : Faculdade de Tecnologia de
Taquaritinga (FATEC), 2019. 10.31510/infa.v16i2.664.
Elmasri, Ramez. 2011. Fundamentals of Database Systems, 6th edition. 2011.
Gheno, Ediane Mari, et al. 2019. Sistema de avaliação da CAPES: indicadores e
procedimentos de monitoramento e avaliação de desempenho. Rio Grande do Sul-
Brasil : Em Questão Universidade Federal do Rio Grande do Sul, 2019. ISSN: 1807-
8893 1808-5245.
Ianswer4u . 2019. Advantages and Disadvantages of White box testing. [Online] 2019.
[Citação: 2 de Julho de 2019.] https://www.ianswer4u.com/2016/11/advantages-and-
disadvantages-of-white.html.
Jesus, Mirele Batista De. 2018. Vantagens E Desvantagens Das Metodologias Àgeis.
Goiás - Brasil : Instituto Federal De Educacão, Ciência E Tecnologia De Goiás Câmpos
Jata, 2018.
Jonnathan, Riquelmo, et al. 2020. Modelos Conceituais de Bancos de Dados
Relacionais. Av. Tiaraj ́u, 810 - Bairro Ibirapuit ̃a - Alegrete, RS : Laboratory of Empirical
Studies in Software Engineering (LESSE), 2020.
José, Lima, et al. 2020. Metodologias Ativas como forma de reduzir os desafios do
ensino em Engenharia de Software. Pernambuco : IX Congresso Brasileiro de
Informática na Educação (CBIE 2020); Anais do XXXI Simpósio Brasileiro de
Informática na Educação (SBIE 2020), 2020.
Josué, Luciano E Wallison, Joel, Barberá, Alves. 2011. Architectural Pattern Mvc:
Model-Viewcontroller. São Paulo : Centro Universitário UNIFAFIBE, 2011.
Júnior, Edwar, Saliba. 2020. Diagrama de classe e objeto. Triângulo Mineiro : Instituto
Federal de Educação, Ciência e Tecnologia, 2020.
Lucca, Sabbatini, Reid, Rodrigues e Gabriel, Bueno, dos Santos, Doria Oliveira.
2021. Estudos relativos ao uso do padr˜ao MVC para o desenvolvimento Web. Rio de
Janeiro : Projetos PEE PET-Tele, 2021.

64
Luís, Cavique. 2020. Modelação de Sistemas de Informação. Lisboa : Univ. Aberta,
2020.
—. 2020. Modelação de Sistemas de Informação. Lisboa : Univ. Aberta, 2020.
Luis, Henrique, Catunda, Rodrigues, Farias. 2021. Estudo Comparativo Da
Utilização De Design Patterns No Desenvolvimento De Aplicação Web Utilizando
Frameworks Front-End. Campus Crateús : Universidade Federal Do Ceará, Curso De
Graduação Em Sistemas De Informação, 2021.
Márcio, Andrey, Teixeira. 2019. Arquitetura cliente/servidor. SP-BRASIL : Instituto
Federal de São Paulo – Campus Catanduva , 2019.
Matheus, de Souza e Eduardo, Alves, da Silva. 2021. Estudo Comparativo de
Tecnologias de Desenvolvimento front-end para Web Angular, React e Vue. Itajaí, SC,
Brasil : Universidade do Vale do Itajaí, 2021.
Mochammad, Lazuardy e Dyah, Anggraini. 2022. Modern Front End Web
Architectures with React.Js and Next.Js. Indonesia : International Research Journal of
Advanced Engineering and Science, 2022. ISSN (Online): 2455-9024.
Paxi, Mataia. 2017. Avaliação de Desempenho Docente em Angola: Estudo de Caso
na Universidade Agostinho Neto. Covilhã : Universidade Da Beira Interior - Ciências
Sociais E Humanas, 2017.
Paxi, Mataia, Tana. 2017. Avaliação de Desempenho Docente em Angola: Estudo de
Caso na Universidade Agostinho Neto. Covilhã : Universidade Da Beira Interior
Ciências Sociais e Humanas, 2017.
Portalgsti . 2019. O que é Teste de Software? [Online] 2019. [Citação: 1 de Julho de
2019.] https://www.portalgsti.com.br/testes-de-software/sobre/.
Pressman. 2011. Engenharia de Software: Uma abordagem Profissional. 2011.
Pressman, Roger. 2011. Engenharia de software. Uma abordagem Profissional. São
Paulo : s.n., 2011.
Raphael, Soares. 2019. Comparação entre protocolos da camada de aplicação para
IoT. Recife : Universidade Federal Rural de Pernambuco – UFRPE, 2019.
Reqtest . 2015. Black Box vs White Box Testing Techniques – Understand the
Differences. [Online] 8th de Junho de 2015. [Citação: 2 de Julho de 2019.]
https://reqtest.com/testing-blog/black-box-testing-vs-white-box-testing/.
Ricardo, Ribeiro, Assink e Edson, Lessa. 2019. Modelagem de Software. Santa
Catarina : UniSul / anima Educação, 2019.

65
Rossen, Guido Van. 2018. Extending and embedding Python. 2018.
Silva, Antonio Carlos Pereira da. 2022. Ferramenta Web Para Auxiliar Na Aplicação
De Gamificação Em Sala De Aula. Macaíba, Rn : Unidade Acadêmica Especializada
Em Ciências Agrárias - Escola Agrícola De Jundiaí, 2022.
SM, Rajkumar . 2018. Black Box And White Box Testing | Definition And Types.
[Online] 30 de Julho de 2018. [Citação: 2 de Julho de 2019.]
https://www.softwaretestingmaterial.com/black-box-and-white-box-testing/#comments.
Sommervile, Ian. 2005. Ngeniería Del Software. Séptima edición. 2005.
Sommerville. 2011. Engenharia de Software. 2011.
Toni, Marković. 2022. Developing web applications using React and Redux libraries.
Croatia : Technical Sciences Computing, 2022.

66
GLOSSÁRIO

Apache: servidor web

Aplicação: é o software projetado para executar um grupo de funções, tarefas ou
atividades coordenadas para o benefício do usuário.
Blog: são páginas on-line, atualizadas com frequência, que podem ser diários
pessoais, periódicos ou empresariais, dessa forma, são formas de comunicação de
pessoas e de instituições com o mundo.
Código fonte: é o conjunto de palavras ou símbolos escritos de forma ordenada,
contendo instruções em uma das linguagens de programação existentes, de maneira
lógica.
Complexidade ciclomática: é uma métrica de software usada para indicar a
complexidade de um programa de computador, mede a quantidade de caminhos de
execução independentes a partir de um código fonte.
Framework: é um template com diversas funções que podem ser usadas pelo
desenvolvedor. Com ele, é desnecessário gastar tempo para reproduzir a mesma
função em diferentes projetos, auxiliando em um gerenciamento ágil de projetos.
Front-end: Interface de interação com o usuário
GitHub: é um sistema de gerenciamento de projetos e versões de códigos assim como
uma plataforma de rede social criada para desenvolvedores.
Hardware: É a parte física do computador, ou seja, peças e equipamentos que fazem o
computador funcionar.
Hipertexto: é um conceito associado às tecnologias da informação e que faz referência
à escrita eletrônica.
Internet: é um sistema global de redes de computadores interligadas que utilizam um
conjunto próprio de protocolos (Internet Protocol Suite ou TCP/IP) com o propósito de
servir progressivamente usuários no mundo inteiro.
Pagina Web: também conhecida por webpage, é uma página na world wide web,
geralmente em formato HTML e com ligações de hipertexto.
Site: conjunto de páginas web (documentos de hipertexto) armazenados em uma pasta
num servidor.
Software: é a soma total dos programas de computador, procedimentos e
documentação.

67
TIC: Tecnologia de Informação e Comunicação, consistem de todos os meios técnicos
usados para tratar a informação e auxiliar na comunicação, o que inclui o hardware de
computadores, rede, telemóveis, bem como todo software necessário.
UML: Linguagem de Modelagem Unificada (do inglês, UML - Unified Modeling
Language) é uma linguagem-padrão para a elaboração da estrutura de projetos de
software. Ela poderá ser empregada para a visualização, a especificação, a construção
e a documentação de artefactos que façam uso de sistemas complexos de software.
WWW: a sigla WWW se refere a World Wide Web ou, em português, rede de alcance
mundial. Trata-se de um sistema interligado de arquivos e informações executados na
internet.

68
ANEXO

69