monitorizac¸ao do desempenho curricular˜ do aluno ... · monitorizac¸ao do desempenho...
TRANSCRIPT
Monitorizacao do Desempenho Curriculardo Aluno Universitario
Ricardo Filipe Pateiro Marcao
Dissertacao para obtencao do Grau de Mestre em
Engenharia Informatica e de Computadores
Orientador: Prof. Gabriel Cesar Ferreira Pestana
Juri
Presidente: Prof. Mario Jorge Costa Gaspar da SilvaOrientador: Prof. Gabriel Cesar Ferreira Pestana
Vogal: Prof. Jose Carlos Martins Delgado
Maio 2014
Agradecimentos
O sucesso da realizacao desta dissertacao so foi possıvel com o apoio de determinadas pessoas e entidades,
as quais nao podia deixar de manifestar o meu sincero agradecimento. Comeco por agradecer ao Instituto
Superior Tecnico e ao INOV (INESC Inovacao), organismos onde surgiu este trabalho final de mestrado, a
Direcao dos Servicos de Informatica (DSI) do Instituto Superior Tecnico, unidade onde desenvolvi parte do
projeto, e a Capgemini Portugal, empresa onde sou consultor, pela possibilidade de integracao do Projeto
Fenix, projeto esse que me veio a proporcionar o tema em estudo. Como nao me poderia esquecer, agradeco
ao Engenheiro Luıs Cruz, ao Professor Luıs Guerra e Silva e ao Professor Fernando Mira da Silva, funcionario
e docentes agregados a DSI, que contribuiram para o sucesso deste trabalho e que me facilitaram o acesso aos
dados de teste, no meu caso de estudo; aos engenheiros Andre Morais Costa e Paulo Rosa Pereira, por todo
o apoio que me deram enquanto colegas de projeto, em contexto empresarial; ao Engenheiro Filipe Brito e a
Dr.a Olga Torrao, por toda a forca que solicitaram para terminar o meu mestrado, na Capgemini Portugal;
ao chefe do projeto, onde me insiro de momento, na Capgemini, o Engenheiro Dinis Campos Ferreira, pela
facilitacao da ginastica horaria, durante o perıodo laboral, para a participacao nas reunioes de orientacao da
minha tese; e ao Professor Gabriel Pestana, pela sugestao do tema e por todo o apoio e compreensao que
obtive durante a orientacao da dissertacao.
Um especial agradecimento aos meus pais, pois sem eles este documento nao seria possıvel; a Catarina Mira
Saltao, por toda a dedicacao, apoio e compreensao, que ajudaram, sem duvida, a concretizar este trabalho; ao
meu irmao e avos, por toda a forca investida para que este trabalho se concretizasse; e aos meus amigos, que
se esforcaram para providenciar alguns momentos de descontracao, mesmo que em tempo limitado. Gostaria
ainda de ceder uma palavra de cortesia, com especial apreco, a todos aqueles que contribuıram para as
revisoes tecnicas e ortograficas deste trabalho.
Este documento e dedicado a D. Ilda Fialho Caldeira Pateiro, minha avo materna.
i
Abstract
With the economic crisis in which we live, it becomes urgent to capture the high development of an enter-
prise, being academic or industrial profile. In an academic context, the practice of dashboards turns to the
management and/or performance monitoring of the users, while university students that may hold positions
in the senior executives of a company of any industry, when in an industrial context; or as teachers and/or
researchers in the portuguese public university education. This work aims to create a specification for the
development of a dashboard for monitoring the student’s educational performance, in this case, from Insti-
tuto Superior Tecnico (University of Lisbon), an educational institution where the tests were designed and
projected for the proposed solution. The same language was designed in ArchiMate 2.1 and UML 2.0 and
includes all modeling of the technological architecture, domain model, context diagrams, use cases (including
the various existing views) and activities, and the modeling of some test scenarios, with examples of appli-
cation of the solution, in which the drawn mockups are included, as well as the screens of a static testing
dashboard. To this end, we followed the guidelines of the Design Science Research methodology, due to the
production of artifacts, in the validating of the work.
Keywords
Actor, Dashboard, Key Indicator, Modeling, Monitoring, Performance.
iii
Resumo
Com a crise economica em que se vive, torna-se urgente a captacao do alto desenvolvimento de uma empresa,
seja esta de perfil academico ou industrial. Num contexto academico, a pratica de dashboards vira-se para a
gestao e/ou monitorizacao do desempenho dos utilizadores, enquanto alunos universitarios, que poderao vir a
exercer cargos nos altos quadros de uma empresa, de uma qualquer industria, quando em contexto industrial;
ou ainda enquanto docentes e/ou investigadores do ensino superior universitario publico portugues. Este
trabalho tem como objetivo a criacao de uma especificacao para o desenvolvimento de um dashboard para a
monitorizacao do desempenho pedagogico do aluno, neste caso, do Instituto Superior Tecnico (Universidade
de Lisboa), estabelecimento de ensino onde foram projetados os testes da solucao proposta. O mesmo foi
projetado nas linguagens ArchiMate 2.1 e UML 2.0 e inclui toda modelacao da arquitetura tecnologica, do
modelo de domınio, dos diagramas de contexto, de casos de uso (incluindo as varias vistas existentes) e de
atividades, e a modelacao de alguns cenarios de teste, com exemplos de aplicacao da solucao, no qual os
mockups desenhados se incluem, assim como os ecras de um dashboard estatico de teste. Para tal, seguimos
as diretrizes da metodologia Design Science Research, para a producao dos devidos artefactos, na validacao
do trabalho.
Palavras-chave
Ator, Dashboard, Desempenho, Indicador, Modelacao, Monitorizacao. cap
iv
Indice
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
Lista de Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
1 Introducao 1
1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Trabalho Relacionado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Principais Desafios e Definicao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 Principais Contributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2 Estado da Arte 16
2.1 Perspetiva Historica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Mercado de Dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Projetos e Estudos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3.1 Sistema de Detecao de Faltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.2 Monitorizacao do Desempenho do Negocio . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.3 Ferramenta de Monitorizacao do Progresso do Aluno . . . . . . . . . . . . . . . . . . . 25
2.3.4 Gestao do Desempenho do Negocio em Tempo Real . . . . . . . . . . . . . . . . . . . 28
2.3.5 Monitorizacao do Desempenho nos Cuidados de Saude . . . . . . . . . . . . . . . . . . 30
2.4 Metodologias e Linguagens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Desenvolvimento Conceptual de uma Ferramenta de Monitorizacao do Desempenho 34
3.1 Recolha de dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.2 Definicao e Identificacao dos Indicadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3 Framework de Zachman . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
v
3.4 A Envolvente do Dashboard Academico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5 Modelo Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.5.1 Levantamento do Modelo Conceptual Atual, do FenixEDU . . . . . . . . . . . . . . . 43
3.5.2 Modelo Conceptual Proposto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4 Caso de Estudo: FenixEDU 56
4.1 Aplicacao da metodologia Design Science Research . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2 Cenarios de Aplicacao da Solucao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.1 Cenario 1 - O Portal do Coordenador do Mestrado em Engenharia Informatica e de
Computadores (Taguspark) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.2 Cenario 2 - O Portal do Aluno do Mestrado em Engenharia Informatica e de Computa-
dores (Taguspark) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5 Conclusoes e Trabalho Futuro 68
5.1 Metodologia de Avaliacao do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.2 Perguntas de Investigacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.2.1 Artefactos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Referencias 73
Anexos 76
A. Questionario Realizado aos Alunos do Instituto Superior Tecnico . . . . . . . . . . . . . . . . . 76
B. Diagramas de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
C. Mockups Propostos para o Dashboard do Docente . . . . . . . . . . . . . . . . . . . . . . . . . . 81
D. Mockups Propostos para o Dashboard do Alumni . . . . . . . . . . . . . . . . . . . . . . . . . . 83
E. Mockups Propostos para o Dashboard do Tutor . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
vi
Lista de Tabelas
1.1 Relacao entre os varios projetos (e/ou estudos) e os conceitos abordados no documento . . . 13
2.1 Analise comparativa dos diferentes tipos de dashboards [10] . . . . . . . . . . . . . . . . . . . 21
3.1 Respostas a questao Q1: ”Acharia interessante o facto de ter uma aplicacao no seu telemovel,
que monitorizasse o seu percurso academico ao longo de um semestre, em determinada cadeira?” 35
3.2 Respostas a questao Q2: ”Gostaria de se poder comparar com os outros alunos, em todos os
elementos de avaliacao de determinada disciplina, de forma a manter a sua rentabilidade?” . 35
3.3 Respostas a questao Q3: ”Se o sistema ERP (Enterprise Resource Planning) que gere a sua
faculdade, instituto, universidade ou escola superior, como por exemplo o Sistema Fenix,
tivesse um sistema de alarmıstica associado, que tipo de mensagem (por SMS e/ou E-Mail)
gostaria de receber com as devidas notificacoes?” . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Respostas a questao Q4: ”Se o mesmo sistema ERP, referido na questao anterior, permitisse
o envio de uma justificacao de uma falta, por SMS ou E-Mail, no caso de a falta poder ser
justificada, aquando da rececao de uma notificacao com a falta dada, usaria tal funcionalidade?” 37
3.5 Respostas a questao Q5: ”Gostaria que o mesmo sistema ERP, referido anteriormente, lhe
gerasse um planeamento personalizado, mediante o seu desempenho atual, sendo este atual-
izado em tempo util?” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.6 Respostas a questao Q6: ”Que tipo de comparacoes, relativamente a anos anteriores, gostaria
de poder fazer no sistema?” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.7 Aplicacao da framework de Zachman ao planeamento do trabalho . . . . . . . . . . . . . . . . 41
3.8 Descricao das atividades associadas ao Aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.9 Descricao das atividades associadas ao Docente . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.10 Descricao das atividades associadas ao Coordenador . . . . . . . . . . . . . . . . . . . . . . . 45
3.11 Descricao das atividades associadas ao Tutor . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.12 Descricao das atividades associadas ao Alumni . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.1 Relacao entre os artefactos e as perguntas de investigacao . . . . . . . . . . . . . . . . . . . . 72
vii
Lista de Figuras
1.1 Exemplo de um mockup do prototipo em determinado cenario . . . . . . . . . . . . . . . . . . 3
1.2 Framework de Pesquisa em Sistemas de Informacao [5] . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Metamodelo da Extensao do Modelo de Competencias do ArchiMate [6] . . . . . . . . . . . . 5
1.4 Integracao da Extensao do Modelo de Competencias no Metamodelo do ArchiMate [6] . . . . 6
1.5 Framework de Zachman 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.6 Processo de tomada de decisao colaborativo do Buzz [11] . . . . . . . . . . . . . . . . . . . . . 9
1.7 Overview da framework de monitorizacao e analise [3] . . . . . . . . . . . . . . . . . . . . . . 9
1.8 Ciclo de vida do BPM, no ambito da integracao do BAM com um PPMM [13] . . . . . . . . 10
1.9 Estrutura do PPMM [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.10 Hierarquia do PPMM [13] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.11 Framework de desenho do sistema BAM integrado com o PPMM [13] . . . . . . . . . . . . . 12
2.1 Evolucao temporal dos dashboards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Dashboard da TAP com as operacoes dos seus voos 2 . . . . . . . . . . . . . . . . . . . . . . . 18
2.3 Dashboard da VISA com o desempenho da organizacao 3 . . . . . . . . . . . . . . . . . . . . . 19
2.4 Dashboard da Editora Abril com o relatorio mensal do desempenho da empresa 4 . . . . . . . 21
2.5 Fluxograma do processo de controlo proposto, com as estatısticas oferecidas pelo algoritmo
LOF [16] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Sistema de Gestao do Desempenho do Negocio, providenciando eventos em tempo real, atraves
de aplicacoes de planeamento empresariais [27] . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.7 Mecanismo de adaptacao de eventos do negocio - Formacao do KPI [27] . . . . . . . . . . . . 25
2.8 Mecanismo de adaptacao de eventos do negocio - Captura dos dos dados do negocio [27] . . . 25
2.9 Servidor de Gestao do Desempenho do Negocio - Calculo do KPI atraves de diferentes fontes
de dados [27] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.10 Desempenho do aluno num array com apenas uma dimensao, visualizada na ferramenta de-
senvolvida [14] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.11 Estrutura do sistema de informacao empresarial da empresa em questao [18] . . . . . . . . . . 29
2.12 Procedimento de desenho do sistema BAM [18] . . . . . . . . . . . . . . . . . . . . . . . . . . 29
viii
2.13 Estrutura do dashboard da empresa em questao, com o estado dos recursos dispersos geografi-
camente [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.14 Desenho do dashboard para o problema de gestao [18] . . . . . . . . . . . . . . . . . . . . . . 30
2.15 Dashboard para os recursos disponıveis por regiao [18] . . . . . . . . . . . . . . . . . . . . . . 31
2.16 Dashboard para o problema de gestao [18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.17 Diagrama UML de casos de uso 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.18 Gestao dos issues, por parte do TOGAF [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1 Distribuicao de respostas na questao Q1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2 Distribuicao de respostas na questao Q2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.3 Frequencia de respostas a questao Q3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.4 Distribuicao de respostas nas questoes Q4 e Q5 . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.5 Frequencia de respostas a questao Q6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6 Mapa Conceptual do Dashboard Academico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.7 Diagrama de casos de uso atual, relativos ao ator Aluno . . . . . . . . . . . . . . . . . . . . . 43
3.8 Diagrama de casos de uso atual, relativos ao ator Docente . . . . . . . . . . . . . . . . . . . . 44
3.9 Diagrama de casos de uso atual, relativos ao ator Coordenador . . . . . . . . . . . . . . . . . 44
3.10 Diagrama de casos de uso atual, relativos ao ator Tutor . . . . . . . . . . . . . . . . . . . . . 44
3.11 Diagrama de casos de uso atual, relativos ao ator Alumni . . . . . . . . . . . . . . . . . . . . 44
3.12 Exemplo de uma analise por ano curricular, no Portal do Coordenador, retirado do sistema
FenixEdu, implementado no Instituto Superior Tecnico . . . . . . . . . . . . . . . . . . . . . 46
3.13 Exemplo de uma analise por disciplina, no Portal do Coordenador, retirado do sistema FenixEdu,
implementado no Instituto Superior Tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.14 Exemplo de estatısticas de tutorandos e outros alunos, na tab do Tutor, retirado do sistema
FenixEdu, implementado no Instituto Superior Tecnico . . . . . . . . . . . . . . . . . . . . . 47
3.15 Exemplo de uma grelha de desempenho, na tab do Tutor, retirado do sistema FenixEdu,
implementado no Instituto Superior Tecnico . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.16 Arquitetura Tecnologica do Dashboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.17 Modelo de Domınio do Dashboard de Monitorizacao Academica . . . . . . . . . . . . . . . . . 50
3.18 Modelo do Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.19 Diagrama de casos de uso proposto para o Aluno . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.20 Diagrama de casos de uso proposto para o Docente . . . . . . . . . . . . . . . . . . . . . . . . 52
3.21 Diagrama de casos de uso proposto para o Coordenador . . . . . . . . . . . . . . . . . . . . . 52
3.22 Diagrama de casos de uso proposto para o Tutor . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.23 Diagrama de casos de uso proposto para o Alumni . . . . . . . . . . . . . . . . . . . . . . . . 53
3.24 Vista de Casos de Uso - Analise Curricular . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.25 Vista de Casos de Uso - Taxa de Empregabilidade . . . . . . . . . . . . . . . . . . . . . . . . 54
ix
3.26 Vista de Casos de Uso - Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.27 Vista de Casos de Uso - Assiduidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.28 Vista de Casos de Uso - Planeamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.1 Analise do ano letivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Personalizacao da escolha das disciplinas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Relatorio resultante da aplicacao dos questionarios da QUC . . . . . . . . . . . . . . . . . . . 57
4.4 Estatısticas do Aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.5 Diagrama de atividades referente ao ator Coordenador, relativo ao Cenario 1 . . . . . . . . . 61
4.6 Dashboard do Coordenador - Escolha do curso . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.7 Dashboard do Coordenador - Analise curricular . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.8 Dashboard do Coordenador - Media dos componentes de avaliacao e de assiduidade . . . . . . 62
4.9 Dashboard do Coordenador - Relacao entre media e quantidade de alunos . . . . . . . . . . . 63
4.10 Dashboard do Coordenador - Avaliacao qualitativa . . . . . . . . . . . . . . . . . . . . . . . . 63
4.11 Diagrama de atividades referente ao ator Aluno, relativo ao Cenario 2 . . . . . . . . . . . . . 64
4.12 Dashboard do Aluno - Escolha do ano letivo, do semestre e da disciplina . . . . . . . . . . . . 65
4.13 Dashboard do Aluno - Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.14 Dashboard do Aluno - Analise personalizada por ano letivo . . . . . . . . . . . . . . . . . . . 66
4.15 Dashboard do Aluno - Historico do curso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.16 Dashboard do Aluno - Historico da disciplina . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.17 Dashboard do Aluno - Taxa de empregabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.1 Modelacao do contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
B.1 Diagrama de Atividades do Aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.2 Diagrama de Atividades do Docente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.3 Diagrama de Atividades do Coordenador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.4 Diagrama de Atividades do Tutor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.5 Diagrama de Atividades do Alumni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
C.1 Dashboard do Docente - Escolha da disciplina . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
C.2 Dashboard do Docente - Analise por cadeira . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
C.3 Dashboard do Docente - Faltas do aluno aos tipos de aula . . . . . . . . . . . . . . . . . . . . 82
C.4 Dashboard do Docente - Analise do aluno, na cadeira escolhida . . . . . . . . . . . . . . . . . 82
C.5 Dashboard do Docente - Currıculo do aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
C.6 Dashboard do Docente - Plano de estudo do aluno . . . . . . . . . . . . . . . . . . . . . . . . 83
D.1 Dashboard do Alumni - Currıculo do ex-aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
D.2 Dashboard do Alumni - Taxa de empregabilidade . . . . . . . . . . . . . . . . . . . . . . . . . 84
E.1 Dashboard do Tutor - Listagem de tutorandos . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
x
E.2 Dashboard do Tutor - Analise de todas as cadeiras . . . . . . . . . . . . . . . . . . . . . . . . 85
E.3 Dashboard do Tutor - Analise de uma cadeira em particular . . . . . . . . . . . . . . . . . . . 85
E.4 Dashboard do Tutor - Currıculo do aluno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
E.5 Dashboard do Tutor - Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
xi
Lista de Abreviaturas
ADT Alternating Decision Tree
BAM Business Activity Monitoring
BI Business Intelligence
BPM Business Process Management
CBE Common Business Events
CEI Common Event Infrastructure
CMDB Configuration Management Data Base
CUSUM Cumulative Sum Chart
DSR Design Science Research
DW Data Warehouse
ECA Event Condition Actiomn
ERP Enterprise Resource Planning
ETL Extract, Transform and Load
ICA Independent Component Analysis
IT Information Technology
ITIL IT Infrastructure Library
KCI Key Control Indicator
KPI Key Performance Indicator
KRI Key Risk Indicator
LOF Local Outlier Factor
MSPC Processo de Controlo Estatıstico Multivariado
OCL Object Constraint Language
OLAP Online Analytical Processing
OLK Nıvel KPI Operacional
OMG Object Management Group
PMDM Process Metrics Definition Model
PPM Process Performance Metrics
PPMM Process-based Performance Measurement Model
xii
QoS Question of Service
QUC Qualidade das Unidades Curriculares
SLK Nıvel KPI Estratetigo
TAFIM Technical Architecture Framework for Information Management
TE Tenessee Eastman
TLK Nıvel KPI Tatico
TOGAF The Open Group Architecture Framework
UML Unified Modelling Language
WfMC Workflow Management Coalition
xiii
Capıtulo 1
Introducao
Este trabalho pretende apresentar uma solucao para a monitorizacao de uma plataforma academica, tendo
o sistema Fenix como caso de estudo. A solucao a apresentar parte de uma recolha de dados, tratados
estatisticamente, com a opiniao dos varios tipos de utilizadores; seguindo para a definicao de indicadores de
controlo, de desempenho e de risco; passando pelo desenho do modelo da arquitetura tecnologica, do modelo
de domınio, dos diagramas de casos de uso (e respetivas vistas) e de atividades; de mockups (frontends tipo
de cada cenario); e terminando com um exemplo de um dashboard operacional, desenvolvido em folhas de
calculo do Microsoft Excel, simulando o prototipo a desenvolver para a base de dados do sistema em questao.
O presente capıtulo encontra-se estruturado da seguinte forma:
1. Contexto – Apresentacao do contexto onde o trabalho se insere;
2. Trabalho Relacionado – Apresentacao do trabalho relacionado mais relevante no ambito desta dis-
sertacao, o que envolve metodologias, ferramentas, projetos e linguagens;
3. Principais desafios e definicao do problema – Avaliacao das principais complicacoes, detetadas no ambito
do trabalho, e definicao do problema que visamos solucionar;
4. Principais Contributos – Definicao dos principais contributos que o trabalho pretende oferecer, rela-
cionados com o problema definido no ponto anterior;
5. Estrutura do documento – Apresentacao geral da estrutura do documento.
1.1 Contexto
Por vezes, o desempenho curricular de um aluno do ensino superior (universitario publico) nao corresponde
aos objetivos inicialmente pretendidos pelo proprio, pela propria faculdade, ou ainda pelo corpo docente de
determinada cadeira a que aluno se encontra inscrito. Pretende-se, por isso, desenvolver um trabalho de
investigacao nesta vertente, o qual envolve a projecao e o desenvolvimento de uma ferramenta de dashboards,
1
para monitorizar tal desempenho, atraves de indicadores de analise (KPI’s – key performance indicators,
KRI’s – key risk indicators e KCI’s – key control indicators), recorrendo ao conceito de Business Activity
Monitoring (BAM), conceito que sera detalhado na proxima seccao [1]. Deste modo, focamos o trabalho na
monitorizacao em tempo util e na analise do desempenho das atividades envolvidas, no contexto do negocio.
A plataforma academica escolhida foi o sistema FenixEDU, um sistema integrado de gestao academica
e de apoio ao ensino, desenvolvido pelo Instituto Superior Tecnico (Universidade de Lisboa), usado nao so
neste instituto, mas tambem noutras faculdades, como o Instituto Superior de Ciencias do Trabalho e da
Empresa (Instituto Universitario de Lisboa), o Instituto Superior de Economia e Gestao (Universidade de
Lisboa), o Instituto Superior de Agronomia (Universidade de Lisboa). . .
A projecao e o desenvolvimento deste projeto envolveram a modelacao de todo o negocio que esta por
detras do desempenho curricular academico do aluno, em geral, baseando-nos nos pontos de avaliacao das
ferramentas analıticas, existentes no portal do coordenador (como podemos ver no capıtulo 4), e dos ques-
tionarios da Qualidade das Unidades Curriculares (QUC), do Instituto Superior Tecnico (Anexo A). Os
questionarios da QUC sao questionarios anonimos, realizados semestralmente, por via eletronica, na conta
pessoal de cada aluno, no Fenix. Aqui e tida em conta a avaliacao de determinados pontos, como a frequencia
aos varios tipos de aula de cada disciplina e o intervalo de notas, em que a nota final do aluno, na disciplina
em questao, se situa. Em tal modelacao, serao incluıdos todos os diagramas de casos de uso (e respetivas
atividades), descritos na linguagem UML 2, que o sistema atualmente reporta, o que corresponde ao lev-
antamento do atual estado do sistema, assim como os diagramas do sistema projetado com a aplicacao a
desenvolver, o que corresponde ao modelo conceptual proposto.
Como proposta de dashboard a implementar, foi desenhado um conjunto de mockups (ver exemplo na
figura 1.1), recorrendo ao Balsamiq 1.6.69, de forma a representar as varias interfaces contempladas e as fun-
cionalidades requeridas. Para modelar todo o negocio, descrito no paragrafo anterior, utilizamos a ferramenta
Enterprise Architect 10, tendo sido este projetado com recurso a metodologia Design Science Research, para
a criacao dos devidos artefactos. Hoje em dia, um dashboard nao so e uma ferramenta visual, que utiliza
a tecnologia de business intelligence para gerir processos de negocio (business process management), como
tambem e uma ponderosa ferramenta interativa e de diagnostico, a qual mostra um overview da empresa
relacionada, de forma a que os objetivos desta possam ser atingidos mais facilmente [2].
O conceito de business process management (BPM), referente a gestao de processos de negocio, em
portugues, engloba um conjunto de metodos e ferramentas para modelar, executar e analisar os processos
de negocio de uma organizacao [3]; processos esses que correspondem aos varios objetivos a atingir pelos
varios atores da organizacao escolhida, no projeto desenvolvido. Para alimentar este sistema de gestao, sao
utilizados sistemas de monitorizacao, que sao desenhados com data warehouses tradicionais e lotes ETL
(extract, transform and load), o que suporta o conceito de business intelligence, ja referido no paragrafo
anterior [4].
2
Figura 1.1: Exemplo de um mockup do prototipo em determinado cenario
1.2 Trabalho Relacionado
Para a Realizacao deste trabalho, foram utilizadas essencialmente ferramentas de modelacao, desenho e
planeamento, como o Balsamiq, uma ferramenta de desenho de mockups; o Enterprise Architect, uma fer-
ramenta de modelacao, que usa a linguagem UML 2, entre outras; e o Microsoft Office, para producao de
questionarios, tratamento de dados e simulacao do funcionamento do dashboard prototipado. O Enterprise
Architect permite a criacao de especificacoes e modelos conceptuais, como diagramas de casos de uso, diagra-
mas de atividades, modelos de domınio. . . , o que permite modelar o sistema atual e um sistema prototipado
proposto.
No seio dos sistemas de informacao, e desenvolvida uma framework que suporta a pesquisa nesta area, tal
como podemos ver na figura 1.2, para comparar o paradigma da ciencia do comportamento, com o paradigma
da ciencia do desenho.
Podemos observar, ainda na figura 1.2, o environment (ambiente), a IS research (pesquisa no ambito
dos sistemas de informacao) e o knowledge base (base de conhecimento). O ambiente define a envolvente do
problema, onde e despoletado o interesse da investigacao. Na pesquisa, intervem as pessoas, a organizacao,
onde reside o negocio, e a tecnologia envolvidas. A base de conhecimento fornece o sustento a pesquisa, de
forma a que esta possa utilizar metodologias e criar o fundamento necessario para que se torne credıvel [5].
E nesta perspetiva que entra a metodologia Design Science Research, a qual se baseia no conhecimento (e
no entendimento), atraves do knowledge base fornecida pela framework da figura 1.2, de um problema e na
projecao da sua solucao, mediante a producao de artefactos que a suportem:
1. Desenho como um artefacto. A DSR tem que produzir um artefacto viavel (um modelo, um metodo,
uma instanciacao e/ou um construtor).
2. Relevancia do problema. O objetivo desta metodologia e desenvolver solucoes tecnologicas para os
problemas importantes, ao nıvel do negocio.
3
3. Avaliacao do desenho. A utilidade, a qualidade e a eficacia do desenho de um artefacto tem que ser
rigorosamente demonstrado, atraves de metodos de avaliacao bem executados.
4. Contributos da pesquisa. A eficacia da metodologia tem que providenciar contributos verificaveis nas
areas do desenho do artefacto, dos fundamentos do desenho e/ou do desenho das metodologias.
5. Rigor da pesquisa. A DSR depende da aplicacao de metodos rigorosos na construcao e na avaliacao do
desenho do artefacto.
6. Desenho de um processo de pesquisa. A pesquisa por um artefacto efetivo requer a utilizacao dos meios
disponıveis para alcancar os fins desejados na envolvente do problema.
7. Comunicacao da pesquisa. A metodologia tem que ser efetivamente apresentada, tanto numa vertente
orientada a tecnologia, como numa vertente orientada a gestao [5].
Figura 1.2: Framework de Pesquisa em Sistemas de Informacao [5]
Como exemplo da aplicacao desta metodologia, temos a extensao do metamodelo do ArchiMate, para
que o artefacto “competencia” pudesse ser modelado, estando esse associado a um ator, que podera ser
o utilizador de determinado sistema, trabalho proposto por uma tese de mestrado, intitulada de “Gestao
de Competencias Organizacionais”. O autor da dissertacao sugere ainda uma metodologia para construcao
do Processo de Gestao de Competencias Organizacionais, elaborado em cinco passos, concluıda atraves da
aplicacao da Design Science Research:
1. Construcao de uma biblioteca de competencias, em que e feito um levantamento e uma analise de todas
as competencias das funcoes existentes numa organizacao;
2. Construcao de um inventario de competencias de todos os papeis e atores da organizacao, podendo
efetuar a sua gestao, informacao de custo, validade da mesma competencia ou ainda do desempenho
do seu funcionario;
4
3. Verificacao da qualidade das respetivas informacoes armazenadas, nas bases de dados envolvidas, por
parte de uma empresa externa, mediante servicos de outsourcing ; para nao se correr o risco de existirem
lacunas na seguranca ou redundancia de dados;
4. Criacao de um mecanismo de revalidacao de competencias que seja necessario, garantindo assim que
nenhuma competencia fique invalida em determinado intervalo de tempo;
5. Criacao de uma aplicacao que detete lacunas nas competencias existentes na organizacao.
Ainda referente ao trabalho do paragrafo anterior, o projeto desenvolvido foi baseado em interacoes
evolutivas, nas linguagens UML 2 e no ArchiMate, tendo sido apresentado o modulo proposto, como podemos
ver na figura 1.3, ficando assim integrado no metamodelo canonico do ArchiMate (figura 1.4). O seu resultado
final nao provoca alteracoes profundas no desempenho ou no funcionamento da propria linguagem, ou ainda
na sua implementacao, sendo que o foco da resolucao do problema e a associacao de um papel ou ator a um
processo de negocio, caso exista uma conexao de “satisfacao” entre as varias competencias organizacionais e
os requisitos do processo de negocio, associados a entidade (ou ator) que executa essas competencias.
Figura 1.3: Metamodelo da Extensao do Modelo de Competencias do ArchiMate [6]
A Framework de Zachman, inicialmente designada por “Framework para Arquiteturas de Sistemas de
Informacao”, e usada desde ha vinte e cinco anos, para desenhar artefactos, no desenho de processos. Esses
artefactos irao permitir relacionar os papeis, no desenho de processos, e as abstracoes do produto, tal como
podemos ver na figura 1.5.
Os papeis principais, na framework, sao o owner, o designer e o builder, que se referem ao dono, a quem
desenha e a quem cria o processo, respetivamente; embora haja outros. Neste caso, falamos do planner e do
subcontractor, que se referem a quem planeia e a quem implementa, respetivamente.
Nas colunas da matriz, podemos ver as abstracoes do produto, tais como what (o que), how (como),
where (onde), who (quem), when (quando) e why (porque), que dizem respeito a propria questao que cada
5
uma implica, requerendo respostas relativas a dados, a funcao, a rede, a pessoas, ao tempo e a motivacao,
respetivamente.
Figura 1.4: Integracao da Extensao do Modelo de Competencias no Metamodelo do ArchiMate [6]
Figura 1.5: Framework de Zachman 1
6
Embora a Framework de Zachman possa, por vezes, ser “impraticavel”, devido ao vasto numero de
celulas, permite enderecar toda a empresa com uma so tabela, independentemente das metodologias ou das
ferramentas utilizadas, ou a utilizar. E por esta razao que o seu trabalho continua a ser seguido, por Zachman
ser considerado o “pai” das frameworks de arquiteturas empresariais [7]. Vamos usar esta framework para
descrever o modelo conceptual que desenvolvemos, como se podera ver no capıtulo tres.
Existem muitos projetos relatando a aplicabilidade de dashboards a diferentes tipos de sistemas e/ou
diferentes tipos de negocio. Como exemplo da aplicabilidade a determinado negocio, temos um dashboard
dinamico, que permite uma introspecao crıtica dos dados do GPS da frota comercial de uma empresa, atraves
de metricas de desempenho indicativas, tal como o numero de veıculos em uso, o excesso de gastos e o tempo
gasto em cada local. Isto permite o estabelecimento de criterios para a frota, como uma monitorizacao rapida,
a localizacao e os possıveis inconvenientes que a sua operacao possa ter. Este dashboard oferece uma interface
flexıvel, que permite a selecao de metricas que se queiram incluir; providencia rapidamente uma vista rapida
de alto nıvel da frota; mostra rapidamente o desempenho sobre um codigo de cores facilmente identificavel;
apresenta as metricas de desempenho detalhadas para veıculos especıficos e para diferentes intervalos de
tempo; permite a operacao de drill down, mediante a aplicacao dos valores de KPI, desde a frota ate simples
veıculos; utiliza graficos de barras para mostrar a informacao; e oferece a funcionalidades de representacao
de momentos de quebra, sobre a informacao que nos e mostrada no grafico. Este dashboard dinamico pode
ser customizado para gerir e rastrear a frota, assim como para fazer a gestao do proprio negocio, tendo as
seguintes metricas de desempenho: atual e historico. As metricas do tipo “atual” providenciam informacao
em tempo real, enquanto que as do tipo “historico” nos mostram os dados de forma historica, sob a forma
de um grafico de barras [8].
Paralelamente aos tipos de dashboards descritos no paragrafo anterior, temos os dashboards inteligentes,
que servem essencialmente para mostrar resultados proativos do negocio em questao. Neste tipo de dashboards,
temos tres funcionalidades basicas, designadas por look outside, look ahead e look inside. A primeira permite
uma melhor visualizacao do risco, pois permite ver o “mercado”. A segunda permite uma visao de cima, algo
que o tradicional dashboard nao permite, pois e possıvel criar modelos preditivos, utilizando data mining, o
que nos conduzira a uma melhor tomada de decisao. A ultima foca os objetivos, tendo em conta os KPI’s
identificados [9].
Um dos projetos relacionados com o tema e a implementacao de um dashboard no REPOX, uma ferramenta
desenvolvida pelo INESC-ID para gerir processos em transferencias de dados, nas bibliotecas digitais. Com o
aumento da quantidade de informacao manuseada pelos gestores, o uso de dashboards e muito util, na tomada
de decisoes, tornando-se util, por consequencia, o uso de business intelligence. Trata-se da implementacao de
conceitos de um repositorio de metadatos, cujas principais funcionalidades funcionais do dashboard incluem
a flexibilidade na apresentacao do formato, alertas e notificacao em tempo real, capacidade de drill down,
1http://manurenaux.wp.mines-telecom.fr/2012/09/27/framework-darchitecture-dentreprise-zachman-l-gamassia-q-maurice-
d-thomas/ acedido dia 09/02/2013, autor: E. Renaux, ano: 2012
7
analise de cenarios e benchmarking externo. Segundo o autor, apos a definicao dos indicadores de desempenho,
indicados em seguida, descreve de forma rapida e sucinta a implementacao do dashboard, devendo o seu
desenho ser muito simples, e o tamanho ser de apenas um ecra. Este deve conter varios tipos de objetos
de visualizacao, como mapas, graficos circulares, de barras e de linhas, assim como graficos piramidais. A
implementacao de um dashboard deve incluir mecanismos de drill down, analise de cenarios e apresentacao
flexıvel. Alguns dos seus KPI’s identificados foram os seguintes:
• KPI 1 - Fonte de dados num fornecedor;
• KPI 2 - Registos numa fonte de dados;
• KPI 3 - Fornecedor de dados num paıs [10].
No que diz respeito a tomada de decisao colaborativa, podemos ver o exemplo do Buzz, a antiga rede
social da Google, cujo fluxograma pode ser visualizado na figura 1.6. Por vezes, uma decisao e tao simples
como saber onde ir almocar, embora noutras vezes possa ser um processo muito complexo de decisao, como
decidir onde, em qualquer ponto do mundo, podera ser a proxima reuniao presencial, no contexto de uma
organizacao distribuıda mundialmente. Foi neste contexto que o Buzz foi estudado [11].
Por ultimo, temos os projetos de Business Activity Monitoring (descritos nos proximos paragrafos), uma
metodologia que permite resolver o que o IT esconde, pois so costumamos ver a ponta do iceberg. O BAM
permite ver a forma como os eventos afetam o progresso do negocio, ou das suas transacoes, ver as transacoes
em tempo real e a tomada de decisoes em tempo real, em resposta a eventos. Esta tecnologia traduz-se
essencialmente num dashboard colorido, onde podemos ver a incidencia dos diferentes tipos de eventos, onde
podemos analisar as estatısticas do desempenho de um processo de negocio, podendo configurar notificacoes
automaticas de determinados eventos ou de determinadas infracoes a lei [12].
Na Universidade de Estugarda, na Alemanha, e na Universidade de Tecnologia de Vienna, na Austria,
um grupo de seis investigadores estudou os fatores de influencia que afetariam o desempenho dos processos
de negocio, atraves do BAM, de forma a obterem uma observacao contınua dos indicadores de desempenho
(KPI’s). Escolheram tal observacao porque, quando os KPI’s nao atingem os valores-alvo requeridos, a analise
do negocio tem em conta os fatores que provocam esse desvio. O seu trabalho assentou no desenvolvimento
de uma framework para a monitorizacao e analise desses fatores, dispersando-a em tres diferentes camadas,
sendo elas a analise, a monitorizacao e a execucao do processo de negocio em questao, como podemos ver na
figura 1.7. Na camada de monitorizacao, temos a informacao acerca dos processos de negocio que estao a
decorrer e dos servicos que interagem com a informacao recolhida, com o objetivo de monitorizar os KPI’s e
as metricas QoS (Question of Service); assumindo que o utilizador tem definido um conjunto de potenciais
fatores influentes, que e necessario monitorizar, para um KPI que se pretende analizar mais tarde, ao qual
corresponde a metrica em questao. Os KPI’s e os seus potenciais fatores influentes consistem em ambas as
PPM’s (Process Performance Metrics) e nas metricas QoS, sendo estas modeladas como parte do PMDM
(Process Metrics Definition Model). Com esta framework, alem de serem fornecidas informacoes atualizadas
8
do dashboard, acerca do desempenho do processo atual, e possıvel fazer a chamada analise de referencia, uma
analise aos principais fatores que influenciam o processo de negocio e que impedem o alcance do desempenho
pretendido, sendo o resultado mapeado numa arvore de decisao [3].
Figura 1.6: Processo de tomada de decisao colaborativo do Buzz [11]
Figura 1.7: Overview da framework de monitorizacao e analise [3]
9
Na Coreia, Han, Choi, Kang e Lee proposeram uma framework de desenho de um sistema BAM, integrado
com um PPMM (Process-based Performance Measurement Model), em que os indicadores de desempenho
sao relacionados com os processos de negocio e compostos por outros indicadores, mas de baixo nıvel. Para
suportar os pressupostos envolvidos, os investigadores concluem que, se as medidas de desempenho nao forem
geridas de forma independente dos processos de negocio, o sistema BAM precisa de monitorizar as metricas
de desempenho, em termos de processos de negocio, focando assim o ciclo do BPM. Este e composto pelo
processo de diagnostico, pelo processo de desenho e pelo processo de execucao. Na fase de diagnostico, e difıcil
decidir quais os processos que devem ser melhorados para atingir um objetivo especıfico de desempenho, ou
qual o ındice de desempenho que e influenciado, quando um processo de negocio especıfico e executado com
sucesso. Na fase do processo de desenho, os processos propostos sao novamente desenhados e a avaliacao
do desempenho e conduzida. Na fase de execucao, as atividades de negocio sao monitorizadas, coordenadas
e controladas continuamente para um melhor desempenho, como podemos ver na figura 1.8. O PPMM
proposto consiste em tres sub-modelos, como e mostrado na figura 1.9: KPI modelo, processo modelo e K-P
modelo. Primeiro, os KPI’s sao classificados hierarquicamente em tres nıveis, no KPI modelo, de acordo com
o seguinte nıvel de decisao de gestao:
• Nıvel KPI Estrategico (SLK);
• Nıvel KPI Tatico (TLK);
• Nıvel KPI Operacional (OLK).
Segundo, os processos de negocio sao classificados em tres nıveis no processo modelo, de acordo com o
tamanho do intervalo do controlo do processo, da seguinte forma:
• Nıvel Empresarial;
• Nıvel de Processo;
• Nıvel de Sub-Processo.
Figura 1.8: Ciclo de vida do BPM, no ambito da integracao do BAM com um PPMM [13]
10
Cada sub-processo tem uma rede composta por atividades unitarias, como e mostrado na figura 1.9.
A definicao de processo, sub-processo e atividade e feita de acordo com a definicao de WfMC (workflow
management coalition). Finalmente, o K-P modelo representa a relacao entre o KPI e o processo de negocio.
Os nıveis empresarial, de processo e de sub-processo correspondem, respetivamente, ao SLK, ao TLK e ao
OLK, no KPI modelo. Durante a fase de execucao do BPM, podemos concluir o resultado da analise das
atividades de monitorizacao, sendo refletido nas operacoes do processo de negocio, atraves da integracao
deste PPMM com o sistema BAM desenhado. Para desenhar este sistema BAM, temos entao a framework
desenvolvida, cujo processo decorre em duas fases, como podemos ver na figura 1.11:
• Levantamento preliminar de sistemas de informacao empresariais existentes;
• Desenho do sistema BAM.
Figura 1.9: Estrutura do PPMM [13]
Figura 1.10: Hierarquia do PPMM [13]
11
Figura 1.11: Framework de desenho do sistema BAM integrado com o PPMM [13]
E de notar que para testar o sistema BAM, desenhado com esta framework, os eventos que devem ser
monitorizados para seguir o estado da tendencia dos KPI’s selecionados ou dos processos de negocio no
dashboard sao definidos e categorizados; sendo um evento definido como “um registo de uma atividade
especıfica num sistema” 2e os eventos sao categorizados como business events ou technical events. Se o
processo de negocio e executado sem o sistema BPM e o KPI calculado atraves da manipulacao de dados na
propria base de dados, esta manipulacao e definida como um technical event.
Na sua generalidade, os projetos e/ou estudos (identificados pelas respetivas referencias) relacionados com
o tema encontram-se mapeados na tabela 1.1.
1.3 Principais Desafios e Definicao do Problema
Os principais desafios a atingir com o desenvolvimento deste trabalho sao:
• Apoio a monitorizacao do desempenho pedagogico do aluno do ensino superior universitario publico;
• Identificacao de um conjunto de indicadores de analise do progresso pedagogico do aluno e categorizacao
dos mesmos;
• Definicao de fluxos de notificacao para um ambiente colaborativo (por exemplo, entre um docente e um
aluno);
• Analise comparativa do desempenho singular do aluno com a envolvente, seja esta o conjunto de alunos
de uma determinada cadeira (cuja variavel temporal pode ser personalizada), seja o conjunto de alunos
de todo o curso;
• Funcionalidade de reporting anonimo, diferenciado por aluno ou docente, quando um aluno se encontra
em situacao de perigo ou cujo resultado em determinada componente de avaliacao seja discrepante do
esperado.
2Luckham, D., The power of events: an introduction to complex event processing in distributed enterprise systems, Addison-
Wesley, 2002, p. 88
12
Conceitos Projetos / Estudos
Alternating Decision Tree Referencia [14]
Balanced Scorecard Referencias [2] e [13]
Business Activity Monitoring Referencias [3], [13], [15], [16], [17] e [18]
Business Intelligence Referencia [19]
Business Process Management Referencias [3], [4], [6], [10], [13], [17] e [18]
Collaborative Decision Making Referencia [11]
Data Warehouses Referencias [4], [18] e [19]
Dashboard Referencias [2], [4], [10], [17], [18], [20] e [21]
Desempenho Referencias [2], [3], [4], [13], [17], [18], [20], [21] e [22]
Design Science Research Referencia [5]
Framework de Zachman Referencia [23]
Indicadores Referencias [2], [3], [4], [10], [13], [17], [18], [20], [21] e [22]
ITIL Referencia [6]
Monitorizacao Referencias [2], [3], [4], [13], [14], [17], [18], [20], [21] e [22]
Online Analytical Processing Referencias [4] e [18]
Process-Based Performance Measurement Model Referencia [13]
Processo ETL (Extract-Transform-Load) Referencias [4] e [19]
Processo Tenessee Eastman Referencia [16]
Real-Time Reporting Referencia [17]
Regras ECA (Event-Condition-Action) Referencia [12]
Simple Event Processing Referencia [12]
Machine Learning Referencia [14]
Sistema Enterprise Resource Planning Referencia [18]
Tabela 1.1: Relacao entre os varios projetos (e/ou estudos) e os conceitos abordados no documento
O problema que este trabalho pretende resolver e a melhoria do desempenho curricular academico do
aluno do ensino superior universitario publico, face ao plano de estudo definido por cada disciplina, em que o
mesmo se encontra inscrito. Nesta perspetiva, sera possıvel uma analise comparativa do progresso do aluno,
face ao contexto do curso, nao so no ano atual, mas tambem em relacao aos anos anteriores. Em consequencia,
na perspetiva do docente, do tutor e/ou do coordenador de curso, sera possıvel fazer um acompanhamento
pedagogico do aluno, no geral.
Para apoiar a definicao do problema cientıfico, seguem-se algumas perguntas de investigacao, a que esta
dissertacao pretende responder:
1. Como projetar um dashboard de monitorizacao academica?
13
2. Como definir o codigo de cores a utilizar no dashboard?
3. Como identificar as funcionalidades a implementar num dashboard?
4. Como levantar as acoes passıveis de serem executadas nos dashboards de cada ator?
5. Como representar os fluxos de informacao entre cada dashboard e entre cada drill down?
6. Como criar um modelo preditivo para a geracao de um plano de estudo automatizado e personalizado
para cada aluno?
7. Quais sao os atores intervenientes no processo de projecao do dashboard?
1.4 Principais Contributos
O principal contributo deste trabalho e a criacao de uma especificacao para o desenvolvimento de uma ferra-
menta de dashboards, integrado num sistema ERP, para monitorizacao do desempenho curricular academico
do aluno, do ensino superior universitario publico. Com esta ferramenta, sera possıvel monitorizar o desem-
penho do aluno em tempo util, nao so atraves do proprio dashboard, mas tambem atraves de um sistema de
alarmıstica associado, que ira permitir o despertar do aluno para o seu mau desempenho.
Para o desenho da especificacao, apoiamo-nos na Design Science Research, uma metodologia que visa o
desenvolvimento de solucoes “baseadas na tecnologia, para problemas de negocio relevantes” 3, atraves de
artefactos, como um processo de investigacao.
1.5 Estrutura do Documento
Este documento e composto por cinco capıtulos, sendo que o primeiro diz respeito a presente Introducao. Nos
seguintes, podemos encontrar o estado da arte (capıtulo dois), o processo de desenvolvimento conceptual de
uma ferramenta de monitorizacao do desempenho do aluno, do ensino superior universitario (capıtulo tres),
o caso de estudo (capıtulo quatro) e as conclusoes a que chegamos (capıtulo cinco).
No estado da arte, serao descritas as tendencias do mercado, no que diz respeito a ferramentas de moni-
torizacao, e alguns projetos relacionados com o tema, para alem de situarmos os dashboard numa perspetiva
historica.
O capıtulo tres descreve todo o trabalho de modelacao efetuado, como a identificacao dos indicadores,
o modelo de arquitetura tecnologica proposto, o modelo de domınio, o diagrama de contexto, os diagra-
mas de casos de uso associados (e respetivas vistas), os mockups desenvolvidos e os artefactos a ter em
conta, seguindo estes ultimos a metodologia Design Science Research. Serao tambem incluıdos elementos
como mapas conceptuais e como a publicacao de um questionario para identificacao dos indicadores acima
mencionados, juntamente com o seu tratamento, para a definicao das devidas funcionalidades no dashboard.
3Mota, P., Gestao de Competencias Internacionais, Master’s thesis, Instituto Superior Tecnico, 2011
14
No capıtulo respeitante ao caso de estudo, serao identificadas as operacoes que sao permitidas pelo sis-
tema FenixEDU, assim como as interfaces existentes, sendo tambem mostrado um mockup de um sistema
FenixEDU que incorpore a proposta desenvolvida. Para alem do mockup, serao tambem apresentados algu-
mas imagens do prototipo implementado, numa versao rudimentar, de teste, desenvolvido no Microsoft Excel,
acedendo a uma base de dados mascarada do FenixEDU do Instituto Superior Tecnico, disponibilizada pela
Direcao dos Servicos de Informatica do mesmo instituto.
Fora estes cinco capıtulos, sera ainda apresentada uma seccao de acronimos, para uma mais facil percecao
das notacoes usadas; uma seccao de lista de tabelas e de figuras; as referencias bibliograficas e um capıtulo
de anexos.
15
Capıtulo 2
Estado da Arte
A monitorizacao do desempenho e uma das funcionalidades associadas aos dashboards. Estes nao sao mais do
que ferramentas de diagnostico, projetadas para obter uma vista rapida sobre as atividades de uma empresa,
onde o desempenho e algo que pode estar saliente. Para tal, e necessario a definicao de determinados
indicadores [2]. Nas proximas subseccoes iremos abordar os dashboards segundo uma perspetiva historica,
assim como do ponto de vista das tendencias e da sua disponibilidade no mercado, para alem de alguns
projetos, metodologias e conceitos relacionados com o tema.
2.1 Perspetiva Historica
O conceito de dashboard surge no inıcio do seculo XX, em Franca, no mercado automovel, como computadores
de bordo. Nao e a toa que os carros franceses de hoje em dia sao os primeiros da gama media-baixa a
apresentar alta tecnologia ao volante.
Os primeiros dashboards na area do negocio surgiram em 1980, semelhantes a sistemas de informacao
simplesmente executivos. Durante uma decada nao se voltou a ouvir falar de dashboards sequer, tornando de
novo ao mercado quando as data warehouses e os sistemas OLAP se tornam famosos [10].
Hoje em dia, os dashboards sao ferramentas de diagnostico com um grande potencial, pois permitem a
utilizacao de business intelligence e constitui uma boa parte do conceito de business process management, pelo
facto de permitir a monitorizacao das atividades de uma empresa [10]. Como tal, tem tambem requisitos,
como o alinhamento entre os processos de negocio e a informacao devidamente atualizada, a visualizacao
intuitiva para a entrega de informacao aos utilizadores mais ocupados (com menos tempo disponıvel para
perder em analises de dados) e suportar navegacao audıvel, para uma melhor contextualizacao do utilizador
[21].
Embora o objetivo da utilizacao de dashboards possa variar, nao foge a determinados propositos, como
a monitorizacao, a consistencia, o planeamento e a comunicacao. A sua principal funcao e a avaliacao, em
funcao das metricas a usar para a acao proposta, garantindo o alinhamento entre as varias medidas utilizadas
16
nos diferentes departamentos. Para tal, sao disponibilizados cenarios, para os quais sao mostrados os devidos
resultados, tendo em conta as metricas escolhidas. Estas metricas sao indicadores definidos em diferentes
contextos e em diferentes dashboards. Um dashboard e uma ferramenta capaz de analisar diferentes cenarios
com um formato flexıvel na sua apresentacao, oferecendo a capacidade de drill down nos diferentes tipos de
amostragem apresentados [2].
Na figura 2.1, podemos ver os anos mais marcantes dos dashboards, referentes aos paragrafos anteriores,
sendo que atualmente existe alguma controversia entre a utilizacao dos dashboard e dos scorecards. Para este
ultimo, o proposito nao e um conjunto de medidas de desempenho, mas graficos de progresso, mostrando
os resultados periodicamente e nao em tempo util. Esses graficos, na sua generalidade, rastreiam objetivos
estrategicos mensalmente, semanalmente ou diariamente, de forma a mostrar a devida informacao aos gestores
envolvidos. Tal como os dashboards, os scorecards tambem sao ferramentas visuais, que utilizam graficos para
indicar o estado do desempenho, as tendencias e toda a envolvente dos objetivos a concretizar, ou a atingir.
Adicionalmente, os scorecards devem apresentar comentarios de interpretacao dos resultados, descrevendo a
acao tomada e providenciando algumas previsoes para o futuro [24].
Figura 2.1: Evolucao temporal dos dashboards
17
2.2 Mercado de Dashboards
Embora haja muito pouca informacao acerca de dashboards, com excecao do ponto de vista academico,
foquem-mo-nos em dois tipos de empresas: as que desenvolvem dashboards e as que usam dashboards para a
monitorizacao e/ou gestao da sua atividade empresarial [10].
Para o primeiro tipo de empresas, referidas no paragrafo anterior, temos marcas como a Pentaho, a
SpagoBI, a Palo, a JasperSoft, a iDashboards, a Microsoft e a MicroStrategy, entre outras. Segundo a
MicroStrategy, uma ferramenta de dashboards e algo que deve ser desenvolvido com o objetivo de ser user
friendly, de ter uma interface de facil percecao, tanto para a area do negocio, como para a area das tecnologias
de informacao, de forma a permitir o crescimento da organizacao cliente.
Figura 2.2: Dashboard da TAP com as operacoes dos seus voos 1
A mesma marca salienta ainda que os dashboards desenvolvidos devem alavancar todos os nıveis do
negocio, de forma a garantir o alinhamento da organizacao, o que facilita a tomada de decisao conjunta.
De forma a garantir o aumento do desempenho e uma maior escalabilidade, tanto os operadores como os
lıderes executivos, partilham os mesmos indicadores de desempenho, permitindo que todos os workflows
sejam embebidos no proprio dashboard [25]. A TAP, a VISA e a Editora Abril sao alguns dos clientes da
MicroStrategy, alguns dos utilizadores de dashboards ao nıvel do negocio, com o objetivo de monitorizar
as operacoes dos voos (figura 2.2), de monitorizar o desempenho na organizacao (figura 2.3) e de fazer um
1http://www.microstrategy.com/DashboardGallery/Dashboards/Customers/TAP/ acedido dia 31/05/2013, autor: MicroS-
trategy Inc., ano: 2010
18
relatorio mensal do desempenho da empresa (figura 2.4), respetivamente. [26]
Figura 2.3: Dashboard da VISA com o desempenho da organizacao 2
2.3 Projetos e Estudos Relacionados
Um dos estudos existentes sobre gestao do desempenho, atraves de dashboards envolve a posicao dos ge-
stores comerciais, sendo que os unicos benefıcios dos dashboards provem de publicacoes mensais. Segundo
este, realizado por Ogan Yigitbasioglu e por Oana Velcu, dois investigadores da Queensland University of
Technology (Australia) e da Aalto University (Finlandia), respetivamente, os gestores e os diretores comer-
ciais utilizam dashboards com propositos muito restritos, como e o caso da monitorizacao, da resolucao de
problemas, da racionalizacao de custos, do alinhamento dos seus negocios com a missao da empresa e da
garantia de consistencia ao nıvel do negocio. Uma vez que a qualidade infere no conteudo dos dados, ha uma
necessidade maior de estes serem utilizados em empresas com um maior numero de funcionarios, ou com um
maior volume de negocios. Yigitbasioglu e Velcu consideram que os dashboards sao optimas ferramentas de
gestao do desempenho, nao se restringindo a monitorizacao, pois atraves do estudo realizado, pode-se veri-
ficar uma forte relacao entre os dashboards e a produtividade do utilizador [2]. Entre varias funcionalidades,
as suas chaves acabam por nao ser apenas a apresentacao de informacao com um bom aspeto, mas sim as
notificacoes em tempo util, os varios tipos de informacao dispersos pelo dashboard com varias camadas, com
a presenca da funcionalidade de drill down, as analises de cenarios e uma analise do benchmarking externo
2http://www.microstrategy.com/DashboardGallery/Dashboards/customers/visa/ acedido dia 31/05/2013, autor: MicroS-
trategy, ano: 2010
19
[2] [20]. Contudo, as funcionalidades mais usadas foram a comunicacao e a monitorizacao do desempenho,
concluindo o estudo em como um optimo ponto de partida para uma investigacao futura seria o valor do
negocio, na gestao do desempenho [2], ponto esse que sera focado no desenvolvimento deste trabalho.
Com o objetivo de implementar um dashboard, numa ferramenta de transferencias de dados em bibliotecas
digitais, para fazer a gestao de processos, foi realizada uma tese de mestrado no ambito. Aqui, e dado algum
foco a definicao de indicadores de desempenho, salientando que e essencial para a gestao do desenvolvimento
dos funcionarios. Embora haja muito pouca informacao acerca de dashboards, nao ha duvida que estes
facilitam a criacao de relatorios. E um facto que essa funcionalidade nem sempre ajuda a tomar as melhores
decisoes, principalmente se tiver uma apresentacao muito pobre, por desviar a atencao dos encarregados,
mas facilita o controlo da organizacao. Sendo os dashboards ferramentas multicamada, para a monitorizacao
e gestao de uma atividade do negocio, usando medidas nao exclusivamente financeiras, deverao conter uma
camada com a informacao grafica de mais alto nıvel, uma camada com a informacao mais especıfica, resultante
da navegacao do utilizador, e uma camada com a informacao mais singular, mais individualizada, como
relatorios mais operacionais ou tecnicos.
Geralmente, os dashboards dividem-se em tres tipos: operacionais, taticos e estrategicos, os quais analis-
aremos na tabela 2.1, em relacao ao objetivo, ao tipo de informacao, a frequencia de atualizacao e ao aspeto
grafico.
Nao e so o tipo de dashboard que varia, mas tambem o tipo de informacao representada, devendo ser
respeitados os diferentes propositos dos diferentes tipos de representacao. A representacao grafica implica
um tipo de informacao espacial e a representacao tabular implica um tipo de informacao simbolico. Como
resultado do estudo efetuado, conclui-se que as funcionalidades dos dashboards podem ser do tipo funcional
ou visual, pois um tamanho pequeno pode resultar num conjunto de decisoes subotimas e um visual fraco
pode levar a confusao e a distracao do utilizador. Por essa razao, um dashboard deve conter paginas simples,
deve ser colorido, quanto baste, deve ter diferentes racios de cores nos diferentes dados e poderao ainda ser
usadas grelhas nos graficos tridimensionais.
O Business Intelligence (BI) refere-se a tecnologias, ferramentas e praticas para agrupar, integrar, analisar
e apresentar grandes volumes de informacao, de forma a providenciar uma melhor tomada de decisao. A
arquitetura tıpica de um sistema de BI consiste numa data warehouse (DW), com um ou varios data marts,
que consolida bases de dados e serve interfaces de ferramentas de querying, reporting e inferencia analıtica,
como os dashboards. Quando estes sistemas sao offline, o tradicional pipeline de integracao de dados e feito
num unico sentido, semelhante a um processamento em lotes, implementado normalmente por ferramentas
do tipo Extract – Transform – Load (ETL). Deste modo, as metricas a reter sao a confianca, a manutencao,
a recuperacao, a escalabilidade, a disponibilidade, a flexibilidade, a robustez, a acessibilidade, a consistencia,
a rastreabilidade e a auditabilidade [19]. Para o caso online, existe outro tipo de esquemas de funcionamento
e analise.
20
Operacional Tatico Estrategico
Objetivo Monitorizacao Analise Colaboracao
Informacao Detalhada Resumida Sumariada
Atualizacao Constante Diaria / SemanalMensal /
Trimestral
Aspeto Grafico DashboardPortal de Business
IntelligenceBalanced Scorecard
Tabela 2.1: Analise comparativa dos diferentes tipos de dashboards [10]
Figura 2.4: Dashboard da Editora Abril com o relatorio mensal do desempenho da empresa 3
Nas proximas seccoes, iremos analisar de forma mais pormenorizada alguns dos projetos relacionados com
o tema.
3http://www.microstrategy.com/DashboardGallery/dashboards/customers/editora1/ acedido dia 31/05/2013, autor: Mi-
croStrategy Inc., ano: 2010
21
2.3.1 Sistema de Detecao de Faltas
Um projeto realizado em 2009 na Coreia do Sul resultou na proposta de um metodo de monitorizacao
online para detecao de faltas, com o objetivo de melhorar o desempenho de uma fabrica. Este baseia-se
no processo de controlo estatıstico multivariado (MSPC), o que permite calcular o valor da monitorizacao
estatıstica, atraves da observacao em determinados intervalos de tempo. Consideremos dois estados do
processo: Controlado e Descontrolado. O estado controlado e atribuıdo quando o valor estatıstico esta
dentro dos limites, sendo o descontrolado atribuıdo quando o mesmo excede esse valor. O processo de
controlo estatıstico utiliza dois algoritmos de controlo: o LOF (Local Outlier Factor) e o ICA (Independent
Component Analysis); que permitem detetar faltas discrepantes ou antagonicas. Podemos ver a estrutura
do fluxograma proposto para o processo de controlo na figura 2.5, onde tomamos t como o ındice de tempo,
d(t) como a funcao de monitorizacao observada, obtida em tempo real, e s(t)={normal, falta} como a funcao
de estado do processo, sendo que o objetivo da monitorizacao e considerar o estado do processo atual s(t)
corretamente. Paralelamente a este esquema, existe um processo de monitorizacao, proposto por Downs e por
Vogel, utilizado em otimizacao, controlo preditivo, processo de diagnostico..., o qual foi usado como processo
de monitorizacao de teste para o esquema proposto anteriormente (Processo Tenessee Eastman), que nao
e mais que um conjunto de regras ECA (Event Condition Action), com a categorizacao do tipo de faltas
possıveis no processo de manufaturacao. [16]
2.3.2 Monitorizacao do Desempenho do Negocio
Um grupo de investigadores de um centro de investigacao da IBM, nos Estados Unidos da America, em
Nova Iorque, desenvolveu um mecanismo inteligente de adaptacao de eventos, para capturar e transformar
aplicacoes dependentes da camada tecnologica em eventos do tipo CBE (Common Business Events), para
que a execucao de operacoes ao nıvel do negocio pudesse ser controlada. Estes sao propagados ate uma
infraestrutura do tipo CEI (Common Event Infrastructure), para serem consumidos por um sistema de
gestao de desempenho do negocio. Para facilitar a extracao em tempo real, da fonte, o grupo optou por
utilizar diretamente a informacao da fonte, utilizando um sistema SAP, como exemplo de fonte de transacao
de eventos.
A gestao do desempenho do negocio permite as organizacoes monitorizar e responder as alteracoes no
ambiente do negocio, de forma a otimizar o desempenho do negocio, relacionando-o com os objetivos do
mesmo. O desempenho do negocio e medido atraves de KPI’s, para refletir o retorno das atividades do
mesmo, sob a camada tecnologica. Aqui, um indicador e definido segundo uma perspetiva de alto nıvel,
no que diz respeito ao negocio, e e calculado e extraıdo da fonte sob a camada tecnologica. Qualquer
atividade transacional, na camada tecnologica, afeta potencialmente o resultado dos KPI’s, tendo estes que
ser adaptados e propagados ate ao sistema de gestao do desempenho do negocio, para uma possıvel analise.
Um sistema de gestao do desempenho do negocio precisa de obter um completo e correlacionado conjunto
de eventos de dados, em ordem a deduzir o indicador correspondente. Para fazer a ponte entre os KPI’s e os
22
eventos ao nıvel do IT, existe a necessidade de ter um mecanismo na camada intermedia, que disponibiliza
as tarefas de adaptacao e de transformacao.
Figura 2.5: Fluxograma do processo de controlo proposto, com as estatısticas oferecidas pelo algoritmo
LOF [16]
Como constituicao do cenario de teste do grupo de investigacao, foi sugerido um call center de um de-
23
terminado negocio, em que os representantes dos vendedores usam tipicamente as aplicacoes de encomenda
empresarial e de cadeia de valor, para processarem os pedidos dos clientes. Um sistema de gestao de de-
sempenho do negocio contem, normalmente um dashboard para monitorizar a atividade do negocio, uma
infraestrutura de captura e processamento, como o CEI, e um ambiente de operacoes do dito sistema de
gestao, como podemos ver na figura 2.6. O sistema de processamento de eventos manuseia os eventos rela-
cionados com as operacoes. As operacoes do ambiente do sistema de gestao monitoriza os processos das
operacoes mais crıticas em termos temporais, atraves da correlacao de eventos do CEI e reporta o estado
ao dashboard. O dashboard mostra o estado dos processos de negocio, em termos de KPI’s, e despoleta um
alerta aos utilizadores finais.
Figura 2.6: Sistema de Gestao do Desempenho do Negocio, providenciando eventos em tempo real, atraves
de aplicacoes de planeamento empresariais [27]
Numa aplicacao tıpica de abordagem a adaptacao, o adaptador captura os eventos do IT e reencaminha-os
para a aplicacao objetivo com o formato simples de uma conversacao. O sistema de gestao do desempenho
do negocio trata da filtragem, da ordenacao e da correlacao desses eventos de baixo nıvel, de acordo com as
regras de negocio pre-definidas. Tal tem que captar os dados objetivos correspondentes, varias vezes, atraves
do adaptador, para formar o KPI, tal como e mostrado na figura 2.7.
O adaptador de eventos precisa de incorporar um mecanismo de adaptacao de eventos que capture, analize,
enriqueca e transforme os eventos, estando os dados do negocio em questao apresentados na figura 2.8.
24
Figura 2.7: Mecanismo de adaptacao de eventos do negocio - Formacao do KPI [27]
Figura 2.8: Mecanismo de adaptacao de eventos do negocio - Captura dos dos dados do negocio [27]
No adaptador proposto, temos quatro modulos funcionais: Gestor de Eventos, Motor de Pesquisa de
Dados, Modulo de Regras do Negocio e Transformacao de Dados. O gestor de eventos e responsavel por
capturar e analizar os eventos, invocando o motor de pesquisa de dados para obter os dados do negocio, de
acordo com o modulo das regras do negocio. Isto utiliza o modulo de transformacao de dados para formar
os eventos do negocio, para que possam ser reencaminhados para o servidor de gestao do desempenho do
negocio.
O calculo do KPI requer informacao de diferentes aplicacoes e fontes de dados, como e mostrado na figura
2.9. Os eventos ao nıvel do IT permitem que, em funcao das regras de negocio, os KPI sejam lidos e sejam
devolvidas mensagens relativas ao negocio para o servidor de gestao do desempenho do negocio. Por essa
razao, foi utilizado um IBM WBI middleware adapter, para processar os eventos e um SAP business event
adapter, para providenciar os KPI’s relacionados em tempo real, para proceder a transformacao, sendo estes
dados como input do mecanismo projetado [27].
2.3.3 Ferramenta de Monitorizacao do Progresso do Aluno
Foi projetada e desenvolvida, na Middle Tennessee State University, em Murfreesboro, nos Estados Unidos da
America, em 2006, uma ferramenta de monitorizacao do progresso dos alunos da mesma instituicao, atraves
da utilizacao dos conceitos de treeview. O seu objetivo era permitir que estudantes e professores pudessem
25
encontrar problemas no entendimento dos conceitos aprendidos por parte dos alunos da universidade, disponi-
bilizando algo interativo, como um simples dashboard, utilizando arvores ADT’s (Alternating Decision Trees),
um conceito de classificacao, baseado em machine learning.
Figura 2.9: Servidor de Gestao do Desempenho do Negocio - Calculo do KPI atraves de diferentes fontes de
dados [27]
Com a intencao de gerar um plano de estudo pessoal para cada estudante, a ferramenta de monitorizacao
grafica nao era mais que um sistema tutorial online, que analisava o trabalho dos estudantes em cada labo-
ratorio e apresentava os resultados ao professor, para a sua aprendizagem ser monitorizada numa estrutura,
de forma sistematica. Uma vez que o desempenho dos estudantes nao e a unica area em que este tipo de
visualizacao e util, a projecao do dashboard contemplou a sua aplicacao a outros objetivos que pudessem ser
medidos quantitativamente.
No desenvolvimento do projeto em questao, foram tidos em conta dois tipos de desenho: o do sistema e o
da interface. Os objetivos do desenho do sistema assentaram em algumas diretrizes, descritas seguidamente:
• O sistema deve providenciar uma ferramenta de levantamento que capture as atividades dos estudantes,
durante uma sessao tutorial;
• O sistema deve providenciar uma ferramenta de visualizacao que ajude o professor e/ou o estudante a
monitorizar o progresso do aluno;
• O sistema deve providenciar uma ferramenta de visualizacao que ajude o professor a monitorizar o
26
progresso de uma turma.
Para o desenho da interface, apenas foram tidas em conta as heurısticas de Nielsen, uma vez que se trata de
um dashboard de simples visualizacao e utilizacao.
Em termos de funcionamento do sistema de machine learning, a primeira decisao a ser tida em conta foi
perceber como organizar os conceitos base utilizados para ligar a questao e os componentes de avaliacao do
sistema. Como em qualquer outro assunto, os topicos em informatica sao, normalmente, hierarquicos, em que
um conceito e composto por sub-conceitos, que por sua vez sao tambem compostos por outros sub-conceitos.
Desta forma, a ferramenta seria usada para colocar questoes nos planos de estudo dos estudantes e para ver
os resultados das questoes. E usado o treeview para criar uma representacao visual e navegavel dos conceitos
em arvore, no browser do utilizador, como podemos ver na figura 2.10. Atendendo a esse facto, um professor,
ou um estudante, pode encontrar alguma anormalidade atraves da localizacao do no de nıvel superior, que
nao esta a verde, podendo ver a arvore num qualquer nıvel, atraves do colapso ou da expansao dos nos nas
respetivas arvores filhas [14].
Figura 2.10: Desempenho do aluno num array com apenas uma dimensao, visualizada na ferramenta
desenvolvida [14]
27
2.3.4 Gestao do Desempenho do Negocio em Tempo Real
Para um melhor desempenho no negocio ou para um processo de melhoria contınua de uma empresa, o
essencial e o conjunto formado pela medida efetiva e pela analise do desempenho das atividades de gestao da
mesma. E o que defendem dois investigadores da Gyeongnam National University, da Coreia do Sul. Para
apoiar tal afirmacao, Jin Kang e Kwan Han afirmam que um sistema BAM pode ser utilizado para a gestao
do desempenho em tempo real, para uma empresa monitorizar as suas atividades e responder em tempo real.
Uma vez que um sistema deste genero monitoriza varios sistemas empresariais, simultaneamente, e mostra
situacoes excecionais num dashboard, no caso de os sintomas do problema serem identificados por regras
pre-definidas, os investigadores do Engineering Research Institute desenvolveram um procedimento para o
desenho de um sistema deste genero e comentam os resultados da sua implementacao.
A empresa referida nesta pesquisa e uma empresa da industria automovel na Coreia, que esta presente em
varias zonas e tem varios escritorios. A monitorizacao em tempo real para uma melhoria do desempenho no
negocio de todos os escritorios e mais que essencial, devido a rapida globalizacao e as alteracoes envolventes
do negocio. Uma vez que era difıcil monitorizar e analizar os business events, de uma forma integrada e
compreensiva, devido a localizacao e a fonte dos sistemas de informacao para as medidas do desempenho, o
sistema BAM foi proposto com a solucao mais promissora para completar todas as necessidades, tendo sido
conduzido um projeto piloto.
No desenvolvimento da BAM System Design Framework, foi definida a devida estrutura do sistema de
informacao a monitorizar, podendo estes ser classificados em duas categorias: sistemas de processamento de
transacoes e sistemas de processamento analıtico. Um sistema de processamento de transacoes contem um
grupo de sistemas empresariais que processam uma grande quantidade de transacoes para operacoes diarias
da empresa. Normalmente, as transacoes sao processadas em tempo real e numa base contınua, estando
relacionadas com varias aplicacoes e bases de dados. Um sistema de processamento analıtico inclui um
grupo de sistemas que recolhem e analizam dados para a tomada de decisao. Por outras palavras, o sistema
de processamento de transacoes, para proteger o desempenho pre-definido do sistema de processamento de
transacoes, dos efeitos do sistema de processamento analıtico, que requer mais recursos. As data warehouses e
os sistemas OLAP sao representantes do sistema de processamento analıtico. Um sistema BAM e classificado
como um sistema de processamento analıtico. A figura 2.11 mostra-nos a estrutura do sistema de informacao
empresarial da empresa referida anteriormente, cujo sistema de processamento inclui o sistema BPM e o
sistema ERP. O sistema de processamento analıtico inclui o sistema BAM, que contem uma base de dados
separada e um dashboard.
Na mesma framework, e apresentado o procedimento desenvolvido para o desenho do sistema BAM, o
qual e seguido de acordo com a figura 2.12, em que sao definidos os objetos a monitorizar, e feito o desenho
do dashboard, sao definidos os eventos a monitorizar e sao entao apresentadas as regras de negocio para a
monitorizacao pretendida; e o desenho conceptual do dashboard. Para este ultimo, a estrutura e o formato da
apresentacao sao desenhados esquematicamente para apresentar, propriamente, o estado e a tendencia dos
28
indicadores de desempenho ou dos processos de negocio. Normalmente, graficos de barras, linhas, circulares
e listas sao os tipos de representacoes utilizados. No caso desta empresa, o dashboard de apresentacao do
estado dos recursos, por regiao, e desenhado esquematicamente, como podemos ver na figura 2.13. Aqui, o
grafico de barras vertical e utilizado para indicar o estado dos recursos e o nıvel do inventario. O dashboard
para apresentar o estado do processo de gestao do equipamento e organizado na forma que podemos ver na
figura 2.14. O grafico circular e usado para mostrar o numero de problemas ocorridos, por funcao. Os graficos
de barras sao usados para o numero de problemas de equipamento por fabrica/departamento e o atraso das
atividades ou os processos de alerta sao listados no devido formato.
Figura 2.11: Estrutura do sistema de informacao empresarial da empresa em questao [18]
Figura 2.12: Procedimento de desenho do sistema BAM [18]
Na fase de definicao dos eventos a monitorizar, sao definidos os eventos que devem ser monitorizados
para seguir o estado e rastrear os KPI’s selecionados ou os processos de negocio no dashboard. Um evento e
definido como ”um registo numa atividade especıfica, no sistema” 4e e categorizado, assim como os restantes
eventos, como um evento ao nıvel do negocio ou como um evento tecnico. Se o processo em questao for
29
conduzido sem um sistema de BPM e o indicador for calculado atraves da manipulacao da base de dados,
tal e definida como um evento tecnico. Desta forma, chegamos ao dashboard desenvolvido, para o estado dos
recursos disponıveis por regiao, o qual pode ser visto na figura 2.15, e ao dashboard para o estado do processo
de gestao envolvido (ver figura 2.16 [18]).
Figura 2.13: Estrutura do dashboard da empresa em questao, com o estado dos recursos dispersos
geograficamente [18]
Figura 2.14: Desenho do dashboard para o problema de gestao [18]
2.3.5 Monitorizacao do Desempenho nos Cuidados de Saude
Um projeto desenvolvido por Luc Noyez, da Radboud University Nijmegen, em Nijmegen, na Holanda, pre-
tendeu rever os metodos mais usados no controlo de qualidade nos cuidados de saude, especialmente em
cirurgias cardıacas. Embora a sua area seja a cardiologia e nao a gestao ou a informatica, o investigador
pretendeu estudar a utilidade de certos tipos de graficos, utilizados em dashboards, para monitorizar o desem-
penho dos cuidados de saude, como e o caso dos graficos de controlo, graficos do tipo CUSUM (Cumulative
4Luckham, D., The power of events: an introduction to complex event processing in distributed enterprise systems, Addison-
Wesley, 2002, p. 88
30
Sum Charts) e funnel plots. Como conclusao do estudo e da aplicacao do dashboard desenvolvido, a analise
dos CUSUM’s foi claramente a mais aceitavel para a avaliacao e para a monitorizacao dos processos medicos
em questao [28]. E de salientar que o aprofundamento do trabalho neste ponto nao se compara a um estudo
relativo a eficacia e/ou a eficiencia de um dashboard convencional, pelo que nao deve ser avaliado da mesma
forma.
Figura 2.15: Dashboard para os recursos disponıveis por regiao [18]
Figura 2.16: Dashboard para o problema de gestao [18]
2.4 Metodologias e Linguagens
O UML (Unified Modelling Language) e a linguagem de modelacao ideal para o desenho de artefactos de
software. Foi desenvolvida pela OMG (Object Management Group) e e considerado o produto resultante de
tres notacoes: Booch, OMT e Objectory. Embora a linguagem tenha sido desenvolvida para modelar produtos
de programacao orientada aos objetos, foi estendida para outros ambitos, como e o caso da modelacao de
31
arquiteturas, de forma a captar diferentes domınios, como e o caso da estrutura, do comportamento e da
organizacao. Estes ultimos dizem respeito as diferentes categorias dos diagramas da linguagem, passıveis de
serem construıdos. A estrutura pode ser mapeada atraves de diagramas de pacotes, diagramas de classes,
diagramas de objetos e modelos de domınio. O comportamento pode ser mapeado por diagramas de casos
de uso, como podemos ver no exemplo da figura 2.17 (que iremos utilizar para descrever as funcionalidades
propostas por este trabalho), por diagramas de estados, por diagramas temporais, por diagramas de comu-
nicacao, por diagramas de atividades e por diagramas de interacao. Finalmente, a categoria de nıvel mais
baixo, a implementacao, e mapeada por diagramas de componentes e por diagramas de implementacao. A
linguagem UML vem agregadas outras linguagens, como a OCL (Object Constraint Language), por exemplo,
que fornece uma extensao do UML numa vertente mais textual, para apoiar a componente grafica. Com a
OCL, e introduzido o conceito de stereotype, tagged value e profiles, tres tipos de mecanismos que podem ser
agregados a objetos [7].
Figura 2.17: Diagrama UML de casos de uso 5
O BAM e definido como um sistema que providencia o acesso aos KPI’s do negocio, para alem de devolver
a informacao necessaria para que as operacoes ao nıvel do negocio se tornem mais efetivas. Um dos estudos
realizados na area fornece um processo de controlo de qualidade em tempo real, atraves do BAM, estimando
o nıvel de risco e os seus intervalos de confianca, de um processo em curso. Atraves do acesso aos seus
dados historicos, e possıvel prever os proximos problemas, nao esquecendo a monitorizacao do atual estado
do processo em questao. Para garantir a monitorizacao e a resposta em tempo real, os nıveis de risco
(medidos em percentagem) e os intervalos de confianca sao estimados a cada instante monitorizado, baseado
na informacao parcialmente observada durante o processo em execucao. Como resultado deste estudo, temos
que o metodo proposto providencia medidas mais conclusivas, que refletem o progresso em tempo real do
controlo de qualidade do processo em curso, assim como sao despoletados mais avisos, em relacao ao estado
5http://www.homebasedweb.net/index.php/2009/05/27/software-development-life-cycle/ acedido dia 15/03/2013, autores:
Mike Baron, ano: 2009
32
dos nıveis de risco e dos intervalos de confianca, durante os perıodos de observacao. Neste trabalho, iremos
utilizar as nocoes oferecidas pelo BAM, para estabelecer as regras para o despoletar dos avisos entre os varios
atores (interlocutores) [15].
O TOGAF e uma framework disponibilizada pelo Open Group, aplicada a arquiteturas de sistemas de
informacao, como o proprio nome indica: The Open Group Architecture Framework. Esta existe desde 1995,
descendendo da TAFIM (Technical Architecture Framework for Information Management), uma framework
desenvolvida pelo Departamento da Defesa dos Estados Unidos da America (DoD), com foco na gestao de
sistemas de informacao [23]. O TOGAF nao define apenas um conjunto de metricas para a implementacao e
definicao de uma nova arquitetura de sistemas de informacao, mas tambem uma taxonomia para os servicos
envolvidos, num ponto de vista tecnologico [23]. Embora a framework nao se foque em arquiteturas organi-
zacionais [23], a criacao de novos servicos e requisitos de negocio e realizada com consistencia [29]. Segundo
a taxonomia de servicos, definida pela mesma, num ponto de vista tecnologico, os servicos distinguem-se
por diferentes tipos, tais como os de intercambio de dados, os de gestao de dados, os graficos e de imagem,
os de localizacao e de diretorio, os de rede, os dos sistemas operativos, os de engenharia de software, os de
processamento de transacoes, os de seguranca e os de gestao de rede e administracao de sistemas. Estes sao
ainda categorizados, relativamente a qualidade, sendo distinguidos pela disponibilidade, seguranca, usabili-
dade e adaptabilidade [23]. Deste modo e como podemos ver na figura 2.18, toda a gestao da data warehouse
(CMDB – Configuration Management Data Base) envolve uma quantidade de issues, desde os incidentes a
configuracao, posicionando-se o TOGAF na criacao de novos produtos do negocio, que no nosso caso e um
dashboard, sendo apoiado pelo ITIL 2.0 na gestao da mudanca. O ITIL (IT Infrastructure Library) e um
dos maiores servicos de gestao, como abordagem ao IT, sendo este construıdo a volta do processo-modelo
baseado na vista de controlo e na gestao de operacoes [29].
Figura 2.18: Gestao dos issues, por parte do TOGAF [29]
33
Capıtulo 3
Desenvolvimento Conceptual de uma
Ferramenta de Monitorizacao do
Desempenho
Este capıtulo descreve o desenvolvimento conceptual de uma ferramenta de monitorizacao do desempenho
curricular academico do aluno, do ensino superior universitario publico (portugues). Para tal, e definido
o conceito de indicador e sao identificados os varios tipos de indicadores para a ferramenta, baseados no
desenvolvimento, na aplicacao e no tratamento dos dados de um questionario, realizado a varios alunos do
Instituto Superior Tecnico, assim como de outras faculdades que utilizam a plataforma academica FenixEDU.
E entao utilizada a framework de Zachman, para definir o sistema a desenhar, sendo ainda desenhado todo o
modelo conceptual e concretizado o metodo de avaliacao do trabalho, baseado na metodologia Design Science
Research. Para alem destes pontos, sera ainda apresentado um mapa conceptual com o conceito de dashboard,
aplicado ao ambiente em estudo, e uma serie de mockups da ferramenta projetada.
3.1 Recolha de dados
Para concluir a definicao de alguns indicadores de desempenho, de risco e de controlo, foi realizado um
questionario (ver Anexo A), cuja analise, relativamente as questoes, podemos ver em seguida. O mesmo foi
aplicado a cento e vinte e quatro estudantes do ensino superior publico portugues. Nem todos sao alunos do
Instituto Superior Tecnico (Universidade de Lisboa), tendo sido tambem inquiridos alguns alunos do Instituto
Superior de Ciencias do Trabalho e da Empresa (Instituto Universitario de Lisboa), do Instituto Superior
de Economia e de Gestao (Universidade de Lisboa) e do Instituto Superior de Agronomia (Universidade de
Lisboa), estabelecimentos de ensino que utilizam tambem a plataforma em estudo.
Segundo a analise do questionario, como podemos ver na tabela 3.1 e 3.2, mais de cinquenta por cento
34
dos alunos acha interessante o facto de ter uma aplicacao no seu telemovel, que monitorize o seu percurso
academico, ao longo do semestre, em cada disciplina, assim como gostaria de se poder comparar com outros
alunos de uma disciplina que estao a frequentar, com o objetivo de manter a sua rentabilidade. As figuras 3.1 e
3.2 indicam-nos as percentagens das frequencias das respostas, associadas as tabelas 3.1 e 3.2, respetivamente.
Frequencia Distribuicao
Sim 100 81%
Nao 24 19%
Tabela 3.1: Respostas a questao Q1: ”Acharia interessante o facto de ter uma aplicacao no seu telemovel,
que monitorizasse o seu percurso academico ao longo de um semestre, em determinada cadeira?”
Frequencia Distribuicao
Sim 74 60%
Nao 50 19%
Tabela 3.2: Respostas a questao Q2: ”Gostaria de se poder comparar com os outros alunos, em todos os
elementos de avaliacao de determinada disciplina, de forma a manter a sua rentabilidade?”
Para apurar algumas das funcionalidades, em que os potenciais utilizadores poderiam ter interesse, numa
ferramenta do genero de um dashboard, a considerar que fossem incluıdas, e para detetar alguns dos indicadores
associados, inquiriram-se os alunos a respeito da sua preferencia. Tentou-se entao saber o que preferiam estes,
entre receber uma notificacao com o risco de reprovacao, a aproximacao da data de entrega de um projeto
ou de um teste, a nota mınima necessaria na avaliacao seguinte e a quantidade de faltas que o aluno ainda
poderia dar a disciplina a que acabou de faltar, distribuicao que podemos verificar na tabela 3.3. Verificamos
entao que a maior incidencia sob a preocupacao dos alunos e a detecao da aproximacao da data de entrega
de um projeto e da data de um teste, como podemos ver no grafico 3.3. Para uma mais facil interpretacao
dos mesmos, consideremos a seguinte legendagem:
O1 - Risco de reprovacao;
O2 - Aproximacao da data de entrega de um projeto;
O3 - Aproximacao da data de um teste;
O4 - Nota mınima necessaria na avaliacao seguinte;
O5 - Quantidade de faltas que o aluno pode ainda dar a disciplina a que acabou de faltar.
A necessidade de interatividade do sistema de gestao academica para o aluno e tanta que, a excecao
de 18 alunos, todos gostariam de poder enviar por e-mail ou SMS algo tao simples como a justificacao
de uma falta dada, assim como gostariam que o sistema ERP lhes gerasse um plano de melhoria do seu
35
rendimento academico, em tempo util, razao fulcral para os objetivos de gestao de um dashboard, para alem
da monitorizacao. Podemos ver os dados correspondente a estas duas questoes nas tabelas 3.4 e 3.5 e a
distribuicao das frequencias na figura 3.4. Uma vez que, em ambas as questoes aqui colocadas, foram obtidos
os mesmos resultados, apenas e apresentado um grafico de cada tipo.
Como o processo de comparacao entre os alunos e um dos pontos fortes na competicao e, consequente-
mente, na melhoria do desempenho de cada qual, em muitos dos casos, colocou-se uma questao sobre a
preferencia dos mesmos, com varias opcoes de escolha multipla, cuja identificacao e a seguinte:
O1 - Comparar notas finais de disciplinas a que se esta inscrito com notas de anos anteriores, da mesma
disciplina;
O2 - Comparar notas de projetos, testes, fichas e/ou laboratorios de uma disciplina que se esta a frequen-
tar, com notas de outros alunos, de outros anos letivos;
O3 - Comparar notas de projetos, testes, fichas e/ou laboratorios de uma disciplina que se esta a frequen-
tar, com as suas notas anteriores, no caso de prescricao;
O4 - Comparar medias do ano curricular atual com as dos anos anteriores;
O5 - Comparar as medias finais de curso, relacionadas com a empregabilidade dos alunos;
O6 - Comparar numero de disciplinas feitas por aluno, por ano letivo.
Podemos analisar as respostas dadas pelos inquiridos na tabela 3.6 e ver as frequencias no grafico da
figura 3.5. Tal como podemos verificar, o maior ponto de interesse e a melhoria da media de cada qual, com
incidencia nos resultados ao nıvel da empregabilidade.
SimNão
Figura 3.1: Distribuicao de respostas na questao Q1
SimNão
Figura 3.2: Distribuicao de respostas na questao Q2
36
Frequencia Distribuicao
Risco de reprovacao 55 60%
Aproximacao da data de entrega de um projeto 110 26%
Aproximacao da data de um teste 108 25%
Nota mınima necessaria na avaliacao seguinte 83 20%
Quantidade de faltas que o aluno pode ainda dar a disciplina a que
acabou de faltar
69 16%
Tabela 3.3: Respostas a questao Q3: ”Se o sistema ERP (Enterprise Resource Planning) que gere a sua
faculdade, instituto, universidade ou escola superior, como por exemplo o Sistema Fenix, tivesse um sistema
de alarmıstica associado, que tipo de mensagem (por SMS e/ou E-Mail) gostaria de receber com as devidas
notificacoes?”
O1 O2 O3 O4 O50
50
100
150
Opções
Frequência
Figura 3.3: Frequencia de respostas a questao Q3
Frequencia Distribuicao
Sim 106 85%
Nao 18 16%
Tabela 3.4: Respostas a questao Q4: ”Se o mesmo sistema ERP, referido na questao anterior, permitisse o
envio de uma justificacao de uma falta, por SMS ou E-Mail, no caso de a falta poder ser justificada,
aquando da rececao de uma notificacao com a falta dada, usaria tal funcionalidade?”
37
Frequencia Distribuicao
Sim 106 85%
Nao 18 16%
Tabela 3.5: Respostas a questao Q5: ”Gostaria que o mesmo sistema ERP, referido anteriormente, lhe
gerasse um planeamento personalizado, mediante o seu desempenho atual, sendo este atualizado em tempo
util?”
SimNão
Figura 3.4: Distribuicao de respostas nas questoes Q4 e Q5
Frequencia Distribuicao
Comparar notas finais de disciplinas a que esta inscrito com notas
de anos anteriores, da mesma disciplina
84 19%
Comparar notas de projetos, testes, fichas e/ou laboratorios de
uma disciplina que esta a frequentar, com notas de outros alunos,
de outros anos letivos
73 16%
Comparar notas de projetos, testes, fichas e/ou laboratorios de
uma disciplina que esta a frequentar, com as suas notas anteriores,
no caso de ser repetente
76 17%
Comparar medias do ano curricular atual com as dos anos ante-
riores
83 18%
Comparar as medias finais de curso, relacionadas com a emprega-
bilidade dos alunos
86 19%
Comparar numero de disciplinas feitas por aluno, por ano letivo 52 11%
Tabela 3.6: Respostas a questao Q6: ”Que tipo de comparacoes, relativamente a anos anteriores, gostaria
de poder fazer no sistema?”
38
O1 O2 O3 O4 O5 O60
20
40
60
80
100
Opções
Frequência
Figura 3.5: Frequencia de respostas a questao Q6
3.2 Definicao e Identificacao dos Indicadores
Os indicadores sao metricas de desempenho, que trabalham em conjunto na melhoria de scorecards para a
gestao da informacao [30]. Um balanced scorecard (BSC) e uma metodologia muito abrangente de gestao
do desempenho. Trata-se nao mais que um conceito para planear, executar e monitorizar as estrategias do
negocio [17]. De entre os indicadores existentes, salientam-se os KPI’s (key performance indicators), KCI’s
(key control indicators) e KRI’s (key risk indicators), que permitem medir o desempenho, o controlo e o risco,
respetivamente.
Um KPI e um indicador de desempenho que determina a monitorizacao dos objetivos a cumprir. Neste
caso, a cumprir pelo aluno [21].
Um KCI e um indicador de controlo para monitorizar os nıveis de controlo relativos com determinada
tolerancia, usado em organizacoes [21]. No nosso caso, iremos ter duas perspetivas: do ponto de vista do
aluno e do ponto de vista do docente.
Um KRI e um indicador que avalia o risco de determinada atividade, o que geralmente esta associado
a analise do risco operacional. No caso do FenixEDU, ira determinar se o aluno esta prestes a chumbar.
Trata-se de um indicador que permite fazer drill down, num dashboard, para a causa (raiz) dos eventos [21].
No trabalho desenvolvido, consideramos os seguintes indicadores:
• KPI’s:
1. Evolucao da media do aluno, em funcao do numero de matrıculas e do numero de anos do curso;
2. Media atual do aluno, em determinada disciplina, superior a media dos restantes alunos inscritos a
cadeira, nesse mesmo ano letivo;
3. Media de fim de curso;
39
4. Media do ano curricular;
5. Media ponderada do aluno no seu curso em desenvolvimento;
6. Nota de um componente de avaliacao;
7. Nota de um exame;
8. Nota de um laboratorio;
9. Nota de um projeto;
10. Nota de um teste;
11. Nota de uma disciplina realizada pelo aluno;
12. Nota de uma ficha de avaliacao;
13. Nota de uma prova oral;
14. Numero de disciplinas em atraso do aluno, em funcao da quantidade de matrıculas do mesmo e do
numero de anos do curso;
15. Quantidade de faltas em determinada disciplina, em funcao da atual media do aluno na mesma
disciplina;
16. Quantidade de faltas que um aluno pode dar a determinada disciplina, em funcao das faltas que ja
deu;
17. Taxa de empregabilidade.
• KCI’s:
1. Falta a determinada aula;
2. Media do aluno no curso;
3. Nota de um componente de avaliacao;
4. Nota de uma disciplina;
5. Nota mınima necessaria na avaliacao seguinte;
6. Realizacao de um componente de avaliacao.
• KRI’s:
1. Alteracao do planeamento gerado pelo sistema ERP;
2. Falta a uma aula obrigatoria;
3. Falta num (ou falha na entrega dum) componente de avaliacao;
4. Falha na entrega de uma justificacao de uma falta;
5. Nota 10 (em 20) numa componente de avaliacao;
6. Nota negativa num componente de avaliacao;
7. Reduzido numero de presencas nas aulas (menos de cinquenta por cento do numero de aulas atual-
mente lecionadas).
Os indicadores mais salientes no dashboard serao, sem duvida, os KRI’s, pelo mapa de cores a utilizar.
Numa situacao de alto risco, o valor apresentado sera vermelho; numa situacao de baixo risco, o valor apre-
40
sentado sera amarelo; e numa situacao sem qualquer tipo de risco, a cor sera neutra ou verde, correspondendo
a cor verde a uma situacao otima. Por outro lado, os indicadores de desempenho traduzem-se, em grande
parte, nas funcionalidades apresentadas pelo dashboard e, como, se pode ver na identificacao de KCI’s, estes
correspondem aos dados a utilizar na monitorizacao, para uma melhor gestao do desempenho do aluno.
3.3 Framework de Zachman
Para planear e projetar o trabalho, baseamo-nos na primeira linha da matriz da framework de Zachman,
onde podemos descrever o ambito, num termo mais contextual, em relacao aos dados, a funcao, a localizacao,
as pessoas, ao tempo e a motivacao do trabalho a desenvolver, como se pode ver na tabela 3.7. Embora o
foco do seu desenvolvimento seja a segunda linha da matriz, o modelo de negocio, em termos conceptuais,
iremos descreve-lo nas proximas seccoes, atraves de um mapa conceptual, que permite interligar todos os
conceitos envolvidos neste projeto; de diagramas de casos de uso e de atividades, de um modelo da arquitetura
tecnologica a implementar, de um modelo de domınio, de mockups para o desenvolvimento e teste da solucao,
mediante a descricao de um business case, e de um storyboard, a apresentar no proximo capıtulo.
Ambito
O que? (Dados) Dashboard Operacional
Como? (Funcao) Monitorizacao do desempenho dos alunos
Onde? (Localizacao) Faculdades ou universidades do ensino superior publico portugues
Quem? (Pessoas) Alunos, docentes e tutores
Quando? (Tempo) Ao longo de cada semestre
Porque? (Motivacao) Controlo e melhoria do desempenho dos alunos
Tabela 3.7: Aplicacao da framework de Zachman ao planeamento do trabalho
3.4 A Envolvente do Dashboard Academico
O desenvolvimento conceptual do nosso dashboard academico engloba uma serie de conceitos que diz respeito,
nao so ao dashboard em si, mas tambem a toda a sua envolvente, como podemos ver na figura 3.6.
Na mesma imagem, podemos ainda verificar a aplicacao do conceito de dashboard, aos varios tipos de
dashboards existentes no mercado e ao tipo de informacao apresentada em cada qual, trabalhando todos eles
segundo indicadores de risco (KCI), de desempenho (KPI) e de controlo (KCI). Neste caso, o dashboard e
utilizado por docentes, que monitorizam alunos, que por sua vez tambem utilizam o mesmo dashboard.
O dashboard pode conter elementos como balanced scorecards e outros tipos de representacoes de dados,
material apresentado e definido atraves da aplicacao do conceito de real-time reporting, o qual e despoletado
41
pelo conceito de business activity monitoring. Uma vez que o objetivo do dashboard e a monitorizacao, e
utilizado o termo business process management, sendo que o nucleo e projetado atraves da framework de
Zachman, onde e utilizado um sistema enterprise resource planning (ERP) como background e o conceito de
business intelligence, para inferir a base de dados e produzir relatorios analıticos.
Figura 3.6: Mapa Conceptual do Dashboard Academico
42
3.5 Modelo Conceptual
3.5.1 Levantamento do Modelo Conceptual Atual, do FenixEDU
O atual sistema FenixEDU nao apresenta qualquer dashboard nem outra interface para a monitorizacao do
desempenho do aluno, salientando-se alguns ecras nas interfaces de dois dos atores. Para realizar a descricao
do modelo conceptual da arquitetura levantada, identificamos cinco interlocutores (atores do negocio) e os
casos de uso que lhes estao associados. Uma vez que, na plataforma em estudo, existe apenas um portal
que disponibiliza as funcionalidades apresentadas nos casos descritos em seguida, consideremos os seguintes
atores:
Aluno - Interlocutor que frequenta a instituicao de ensino superior;
Coordenador - Interlocutor que coordena um ou mais cursos superiores numa instituicao de ensino supe-
rior;
Docente - Interlocutor que leciona determinada disciplina numa instituicao de ensino superior;
tutor como um interlocutor docente, responsavel pela orientacao pedagogica de determinado aluno;
Alumni - Interlocutor que tem um curso superior concluıdo.
Uma vez que os casos de uso representam determinadas possibilidades de realizacao de tarefas e/ou
operacoes no sistema ERP, apoiamos as imagens por uma tabela (por ator) que indica as atividades envol-
ventes, correspondentes a funcionalidades, passıveis de serem utilizadas, como podemos ver nas figuras 3.7,
3.8, 3.9, 3.10 e 3.11, relativamente ao Aluno, ao Docente, ao Coordenador, ao Tutor e ao Alumni, respeti-
vamente. Nos casos de uso do Docente e do Alumni, foram criados dois requisitos nao funcionais (RNFA e
RNFB), para identificar as dependencias necessarias, como veremos nas referidas imagens:
• RNFA: O Alumni em analise tem que ser o (ex) aluno;
• RNFB: A disciplina em analise tem que ser lecionada pelo Docente.
Figura 3.7: Diagrama de casos de uso atual, relativos ao ator Aluno
43
Figura 3.8: Diagrama de casos de uso atual, relativos ao ator Docente
Figura 3.9: Diagrama de casos de uso atual, relativos ao ator Coordenador
Figura 3.10: Diagrama de casos de uso atual, relativos ao ator Tutor
Figura 3.11: Diagrama de casos de uso atual, relativos ao ator Alumni
Como podemos ver nas tabelas 3.8, 3.9, 3.10, 3.11 e 3.12, as atividades existentes sao facilmente percetıveis
pela nomeacao dos casos de uso, relativas aos atores Aluno, Docente, Coordenador, Tutor e Alumni.
44
Descricao das Atividades do Aluno
Ver media atual
Ver notas finais do aluno em determinada disciplina
Ver numero de cadeiras feitas por semestre
Ver percentagem de aprovacoes por cadeira, por ano
Ver percentagem de ECTS concluıdos
Tabela 3.8: Descricao das atividades associadas ao Aluno
Descricao das Atividades do Docente
Ver nota de um exame
Ver nota de um laboratorio
Ver nota de um projeto
Ver nota de um teste
Ver nota de uma ficha de avaliacao
Ver notas de uma componente de avaliacao em determinada disciplina
Ver notas finais do aluno em determinada disciplina
Ver quantidade de alunos por numero de inscricoes, em determinada disciplina
Tabela 3.9: Descricao das atividades associadas ao Docente
Descricao das Atividades do Coordenador
Fazer analise curricular por ano letivo
Personalizar a analise de cada disciplina, em funcao da percentagem de aprovacoes
Ver currıculo do aluno
Ver distribuicao da avaliacao qualitativa em determinada disciplina
Ver media dos anos curriculares do curso que coordena, em relacao a uma disciplina
Ver notas finais do aluno em determinada disciplina
Ver numero de inscricoes numa cadeira por ano curricular
Ver resultados QUC
Tabela 3.10: Descricao das atividades associadas ao Coordenador
Descricao das Atividades do Tutor
Ver currıculo do aluno
Ver estatısticas de aprovacoes dos alunos, por ano letivo
Ver grelha de desempenho dos alunos
Ver notas finais do aluno em determinada disciplina
Tabela 3.11: Descricao das atividades associadas ao Tutor
45
Descricao das Atividades do Alumni
Ver currıculo do aluno
Ver notas finais do aluno em determinada disciplina
Tabela 3.12: Descricao das atividades associadas ao Alumni
Na interface apresentada, aquando da escolha do papel de Coordenador (ator), as atividades ”Fazer
analise curricular por ano letivo” e ”Personalizar a analise de cada disciplina, em funcao da percentagem
de aprovacoes” traduzem-nas nas figuras 3.12 e 3.13, respetivamente. No caso do papel de Tutor (ator),
as atividades ”Ver estatısticas de aprovacoes dos alunos, por ano letivo” e ”Ver grelha de desempenho dos
alunos” traduzem-nas nas figuras 3.14 e 3.15, respetivamente.
Figura 3.12: Exemplo de uma analise por ano curricular, no Portal do Coordenador, retirado do sistema
FenixEdu, implementado no Instituto Superior Tecnico
Figura 3.13: Exemplo de uma analise por disciplina, no Portal do Coordenador, retirado do sistema
FenixEdu, implementado no Instituto Superior Tecnico
46
Figura 3.14: Exemplo de estatısticas de tutorandos e outros alunos, na tab do Tutor, retirado do sistema
FenixEdu, implementado no Instituto Superior Tecnico
Figura 3.15: Exemplo de uma grelha de desempenho, na tab do Tutor, retirado do sistema FenixEdu,
implementado no Instituto Superior Tecnico
Uma vez que os casos de uso identificados e as atividades levantadas nao fornecem qualquer tipo de analise
em tempo util, ou sequer um sistema de alarmıstica, passıvel de ser utilizado por todos os atores do contexto,
e feita uma proposta de um modelo conceptual projetado, o qual e apresentado na proxima subseccao.
3.5.2 Modelo Conceptual Proposto
A projecao da solucao e suportada atraves da realizacao de uma pequena analise funcional de toda a
plataforma, onde e destacado o modelo de domınio, a arquitetura tecnologica, os casos de uso, as vistas
sobre os casos de uso, as atividades, os requisitos, as entidades informacionais e os mockups, os quais irao
servir de base para a implementacao do dashboard, para a monitorizacao do desempenho academica.
A arquitetura tecnologica projetada, tal como podemos ver na figura 3.16, contempla o sistema (Dash-
board), no qual temos dois servicos intervenientes (o Gestor de Alertas e o Configurador de Indicadores),
47
um software de sistema, que e o dashboard em si, dois servidores (de e-mail e SMS (mobile short message
service), uma interface utilizador e um modelo preditivo, representado por um no. Uma vez que o no e
uma entidade generica de uma arquitetura tecnologica, na norma ArchiMate 2.1, muitas vezes chamada de
interface tecnologica [31], optou-se por esta representacao para o modelo preditivo, por depender de regras de
negocio, definidas num ambito externo ao Dashboard. Os servidores de e-mail e de SMS encontram-se ligados
a internet e a base de dados alimenta tanto o dashboard, como o sistema ERP, onde o proprio dashboard
esta integrado. Ao Configurador de Indicadores estao associados os varios tipos de indicadores, descritos
como funcionalidades infraestruturais, tal como ja definimos ha duas seccoes atras, e as Regras de Negocio
estao associadas as varias regras de aprovacao nas disciplinas dos cursos do estabelecimento de ensino, onde
o dashboard e integrado e onde existe o sistema ERP. Estas regras de negocio irao servir de base para o
modelo preditivo, pois irao suportar o planeamento automaticamente gerado para cada aluno, funcionalidade
a descrever nos proximos paragrafos.
Figura 3.16: Arquitetura Tecnologica do Dashboard
48
Segundo Lankhorst, o modelo de domınio e o primeiro ponto a considerar na analise conceptual de uma
arquitetura tecnologica, pelo que iremos fazer uma prolepse, para explicar o modelo de domınio proposto e
descrever o modelo do contexto [7].
Numa primeira vista a arquitetura tecnologica, nao conseguimos identificar para que tipo de negocio esta
a ser o dashboard projetado, ideia chave para a introducao a especificacao, pois podera ser aplicado a qualquer
area. No entanto, como o nosso tema consiste no ambito academico, vejamos a figura 3.17, onde se descreve
todo o modelo de domınio do dashboard a projetar.
Como podemos ver no modelo de domınio, o dashboard que projetamos tem agregadas ferramentas
analıticas, onde sao utilizados graficos e outros elementos visuais, tıpicos de um dashboard, como listas e
tabelas, por exemplo. Optamos por nao desenvolver um scorecard, porque o dashboard mostra graficos e
dados em tabelas, cujo objetivo e a visualizacao dos eventos, enquanto que um scorecard mostra graficos e
comentarios, sendo objetivo a sumarizacao de dados e a mostra de resultados periodicos, medindo o pregresso
a longo prazo e nao as medidas de desempenho em tempo util. Para o sistema de alarmıstica, utilizamos
a nocao de traffic light indicators for dashboard reporting, com um codigo de cores igual a um conjunto de
semaforos, e de ıcones de alerta. Estes ultimos sao os indicadores de notificacoes, os quais sao usados quando
ha necessidade de agrupar indicadores visivelmente, como por exemplo KRI’s (indicadores de risco). Uma
vez que os executivos e os clientes pretendem uma visualizacao da informacao mais crıtica, ocupando um
ınfimo espaco no ecra, e feita entao a analogia com os semaforos, em que a luz vermelha indica que existe
um problema que afeta o tempo, o custo, a qualidade ou o ambito; a luz amarela indica a necessidade de
precaucao, podendo existir um problema num futuro proximo, nesta sequencia; e a luz verde indica que o
trabalho corre como planeado, nao sendo necessario o envolvimento de nenhum interlocutor extra, a execucao
do ator do negocio, onde insere o ecra do dashboard em causa.
Voltando ainda as ferramentas analıticas, utilizamos graficos circulares porque sao uma forma muito pobre
de visualizacao de dados, pelo que sao uteis quando nao ha necessidade de ter nenhuma analise detalhada;
graficos de barras e de colunas, para fazer analises categorizadas; graficos de linhas, para evidenciar o progresso
de uma ou mais medidas em simultaneo; e tabelas e listas, para agrupar valores nao numericos ou com relacoes
entre os dados que nao pode ser facilmente visualizada [24].
Consoante o estabelecimento de ensino superior a aplicar o dashboard, os componentes de avaliacao
poderao ser menos ou mais, quando comparado com o que esta descrito no modelo de domınio, sendo que se
optou por descrever pormenorizadamente os componentes mais genericos.
Fazendo uma analepse a analise, voltemos ao diagrama da arquitetura tecnologica, para descrever o modelo
de contexto. Aqui, podemos visualizar duas cores, pois estao representadas duas camadas do ArchiMate 2.1.
Os elementos a verde pertendem a camada tecnologica e os elementos a amarelo evidenciam a camada de
negocio da aplicacao. Uma vez que o Dashboard iria ser utilizado pelos utilizadores descritos no diagrama, os
atores do negocio, optamos por incluı-los na arquitetura tecnologica. No entanto, o nosso modelo do contexto
e definido na figura 5.1, em UML 2.
49
Figura 3.17: Modelo de Domınio do Dashboard de Monitorizacao Academica
A ferramenta proposta ira conter as funcionalidades descritas, embora de uma forma abstrata, pelos casos
de uso das figuras 3.19, 3.20, 3.21, 3.22 e 3.23, referentes aos atores Aluno, Docente, Coordenador, Tutor
e Alumni, respetivamente. Os casos de uso identificados representam os requisitos funcionais da aplicacao.
Em particular, nos casos de uso do Docente e do Tutor, foram criados tres requisitos nao funcionais (RNF1,
RNF2 e RNF3), para identificar as dependencias necessarias (ver figuras 3.20 e 3.22):
• RNF1: A disciplina em analise tem que ser lecionada pelo Docente;
• RNF2: O aluno em analise tem que ser aluno do Docente;
• RNF3: O aluno em analise tem que ser tutorando do Tutor.
Associados aos caso de uso (mais propriamente as atividades), existem entidades informacionais, passıveis
50
de serem representadas na matriz de CRUD. No entanto, dispensamos tal representacao, por, no dashboard,
terem sempre o mesmo owner (o Aluno) e por serem apenas readable:
- Nota de um exame;
- Nota de um laboratorio;
- Nota de um projeto;
- Nota de um teste;
- Nota de uma ficha de avaliacao;
- Nota de uma prova oral;
- Nota final;
- Currıculo do aluno;
- Grelha de desempenho do aluno.
Figura 3.18: Modelo do Contexto
So o docente pode fazer update as entidades, mas nunca no dashboard, pois trata-se apenas de uma
ferramenta de inferencia analıtica.
Figura 3.19: Diagrama de casos de uso proposto para o Aluno
51
Figura 3.20: Diagrama de casos de uso proposto para o Docente
Figura 3.21: Diagrama de casos de uso proposto para o Coordenador
Figura 3.22: Diagrama de casos de uso proposto para o Tutor
52
Figura 3.23: Diagrama de casos de uso proposto para o Alumni
Na subseccao anterior, indicamos as atividades a agregar a cada diagrama de casos de uso, associadas
a cada ator. No entanto, nesta fase da arquitetura proposta, colocamo-los apenas em anexo. No anexo B,
podemos encontrar cinco diagramas de atividades, por ator, por swimlanes, onde as varias funcionalidades
a projetar sao descritas, assim como os mockups dos atores Docente, Tutor e Alumni, no anexo C, D e E,
respetivamente. Relativamente aos atores Aluno e Coordenador, podemos encontrar o dashboard desenvolvido
(no Microsoft Excel), na descricao dos cenarios de aplicacao da solucao, no capıtulo cinco.
Para terminar a especificacao, o modelo da arquitetura tecnologica refere ainda a existencia de um visu-
alizador do dashboard e de um modelo predititivo, como ja foi referido, mas nao aprofundado. O visualizador
esta associado a um utilizador generico, que se especializa em varios tipos de utilizador (e ainda sub-tipos,
como acontece com o Docente e com o Tutor). Nestes casos, nao basta desenhar casos de uso por ator, pelo
que faz tambem sentido projetar vistas de casos de uso, no que diz respeito aos tipos de funcionalidades
existentes. Desta forma, podemos ver nas figuras 3.24, 3.25, 3.26, 3.27 e 3.28, as funcionalidades relativas a
Analise Curricular, a Taxa de Empregabilidade, a Media, a Assiduidade e ao Planeamento, respetivamente.
Uma vez que se trata de uma vista, cada diagrama integra os tipos de funcionalidades, de entre uma sequencia
de casos de uso, nao tendo todos os atores acesso aos casos de uso preceded. O caso de uso ”Contribuir para
o planeamento” e a chave para o funcionamento do modelo preditivo. Como veremos no caso de estudo,
o planeamento gerado automaticamente pelo sistema ERP contem os dias remanescentes para a proxima
avaliacao de cada cadeira a que o aluno esta inscrito, a quantidade mınima de dias de estudo recomendada
para cada cadeira, na epoca de exames e o numero maximo de faltas recomendado para cada cadeira. Uma
vez que e objetivo do tutor a melhoria do desempenho do aluno, este pode contribuir para o planeamento,
sugerindo melhorias ao mesmo. Os dias mınimos de estudo recomendado sao despoletados pelas regras de
negocio definidas, associadas as regras de avaliacao de cada disciplina. Assim, e possıvel ajustar a dinamica
do dashboard e tornar a monitorizacao preditiva, sem recurso a data mining.
53
Figura 3.24: Vista de Casos de Uso - Analise Curricular
Figura 3.25: Vista de Casos de Uso - Taxa de Empregabilidade
Figura 3.26: Vista de Casos de Uso - Media
54
Figura 3.27: Vista de Casos de Uso - Assiduidade
Figura 3.28: Vista de Casos de Uso - Planeamento
55
Capıtulo 4
Caso de Estudo: FenixEDU
O exemplo de aplicacao da solucao adotado para esta dissertacao de mestrado foi uma plataforma de gestao
academica, o FenixEDU, sistema projetado, desenvolvido e implementado pela Direcao dos Servicos de
Informatica do Instituto Superior Tecnico, na Universidade de Lisboa. Comecemos por apresentar o caso de
estudo em causa e os objetivos da aplicacao da solucao.
O sistema FenixEDU e um sistema ERP (Enterprise Resource Planning), disponibilizado em varias
faculdades e institutos da Universidade de Lisboa. O sistema nao permite apenas a gestao academica da
faculdade em si, mas tambem todo o apoio aos concursos publicos de admissao de funcionarios docentes e
nao docentes, alunos e investigadores, com uma plataforma tecnologica propria.
O FenixEDU possui algumas funcionalidades de analise do desempenho curricular generico de um curso,
baseado na base de dados fornecida pelos questionarios semestrais da QUC (Qualidade das Unidades Curric-
ulares) e dos dados existentes na base de dados do proprio Fenix. Estas encontram-se apenas no Portal do
Coordenador e no Portal do Aluno (ja referidas no capıtulo tres), disponibilizando as acoes descritas nos dia-
gramas de casos de uso, relativos a cada ator do negocio, e nos diagramas de atividades identificados durante
o levantamento do atual sistema, no mesmo capıtulo. O acesso as ferramentas analıticas do coordenador
esta contido numa tab relativa a tal, onde e possıvel escolher o ano letivo a analisar (figura 4.1) e onde e
mostrada uma lista de disciplinas, a qual pode ser personalizada, mostrando a percentagem de aprovacoes,
reprovacoes e as varias medias em particular (figura 4.2). Paralelamente a esta analise, o coordenador pode
tambem verificar os resultados da aplicacao dos questionarios da QUC, numa perspetiva de alto nıvel, de um
relatorio estatico com um codigo de cores bem representado (figura 4.3), depois de os alunos responderem
aos questionarios.
O Portal do Aluno dispoe tambem de uma ferramenta analıtica, embora seja um sistema de relatorios
estaticos, como podemos ver na figura 4.4, no qual podemos ver algumas estatısticas de aprovacoes de cada
disciplina, ao longo de alguns anos. Aqui, como podemos ver pela imagem, nao existe qualquer legenda para
o codigo de cores utilizado, nem e possıvel aceder a outro tipo de funcionalidades, como e proposto nos casos
de uso da arquitetura proposta. No que diz respeito aos alumni e aos docentes, nao existe qualquer tipo de
56
ferramenta analıtica, a nao ser as descricoes do currıculo dos alunos, sob a forma de uma interface web, assim
como o tutor, embora neste exista uma interface baseada em listas e tabelas, com as grelhas de desempenho
dos seus tutorandos, ja descrito no capıtulo tres.
Figura 4.1: Analise do ano letivo
Figura 4.2: Personalizacao da escolha das disciplinas
Figura 4.3: Relatorio resultante da aplicacao dos questionarios da QUC
57
Figura 4.4: Estatısticas do Aluno
Em anexo a este documento (anexos C, D e E), encontram-se os mockups desenhados no Balsamiq 1.6.69,
os quais representam as interfaces das funcionalidades indicadas nos casos de uso da seccao anterior, da
ferramenta analıtica a desenvolver, o dashboard operacional, relativos aos atores Docente, Alumni e Tutor.
Os objetivos da aplicacao da solucao projetada foram concluıdos de acordo com as perguntas de inves-
tigacao definidas:
• Criar um sistema de alarmıstica para o aluno;
• Melhorar o desempenho curricular academico do aluno;
• Monitorizar o desempenho curricular academico do aluno;
• Possibilitar a interacao entre o tutor e o aluno.
A avaliacao do trabalho segue parte do metodo de avaliacao sugerido por Hevner, havendo um caso de
estudo (FenixEDU), aplicado num determinado local (Instituto Superior Tecnico - Universidade de Lisboa)
e a descricao de cenarios de aplicacao/utilizacao da solucao projetada (descritos na segunda seccao deste
capıtulo) [5].
Ao longo deste capıtulo, iremos descrever dois cenarios de aplicacao da solucao projetada, relativos a dois
dos atores do negocio identificados: o Coordenador e o Aluno. Uma vez que a validacao da solucao e baseada
na metodologia Design Science Research, iremos tambem descrever toda a sua aplicacao a proposta em causa
individualmente na proxima seccao.
4.1 Aplicacao da metodologia Design Science Research
A DSR e uma metodologia que visa o desenvolvimento de solucoes “baseadas na tecnologia, para problemas
de negocio relevantes”, atraves de artefactos, como um processo de investigacao [6]. Esta assenta em sete
diretrizes, as quais se descrevem em seguida:
58
1. O desenho como um artefacto.
A Design Science Research garante a producao de artefactos, podendo estes serem sistemas de prototipos
e aplicacoes, praticas, vocabulario, abstracoes e/ou representacoes.
Para este caso particular, foi produzida uma serie de artefactos, que serviram de base a resposta
das perguntas de investigacao colocadas. Foi produzido um diagrama de arquitetura tecnologica, que
descreve a arquitetura da solucao, um modelo de domınio, os diagramas de casos de uso e os diagramas
de atividades, associados a cada ator do negocio, os mockups projetados para a implementacao da
solucao, os indicadores associados e a definicao de cenarios para o teste da solucao.
2. Relevancia do problema.
O objetivo desta metodologia e desenvolver solucoes tecnologicas para os problemas importantes, ao
nıvel do negocio.
A especializacao para o desenvolvimento de um dashboard para a monitorizacao do desempenho academico,
numa perspetiva estrategica, podera ser uma vantagem competitiva entre os varios estabelecimentos
de ensino superior, com o objetivo de melhorar as medias finais dos seus alunos e de intervir sobre
eles. Hoje em dia, em grande parte das faculdades, das universidades publicas em Portugal, com mais
de dois mil alunos, e complicado ao corpo docente preocupar-se com as notas e com as medias da sua
populacao. Nestes casos, um dashboard, seja este estatico ou dinamico, cuja atualizacao e em tempo util
ou real, e a chave para o controlo desse tipo de desempenho, que se pode concretizar na sua melhoria.
3. Avaliacao do desenho.
A utilidade, a qualidade e a eficacia do desenho de um artefacto tem que ser rigorosamente demon-
stradas, atraves de metodos de avaliacao bem executados.
Neste ponto, e utilizada a metodologia de avaliacao do trabalho, de Hevner, para avaliar os artefactos
produzidos, como se encontra detalhado neste capıtulo, atraves da descricao dos cenarios e da justi-
ficacao para a escolha dos varios tipos de visualizacao apresentada nos ecras, a excecao dos casos de
uso, que foram apenas referidos no capıtulo tres.
4. Contribuicao da investigacao.
A eficacia da metodologia tem que providenciar contributos verificaveis nas areas do desenho dos arte-
factos, dos fundamentos do desenho e/ou do desenho das metodologias.
Este estudo envolveu uma investigacao cientıfica devidamente validada, com o objetivo de projetar uma
solucao que possa contribuir para a area, para a projecao conceptual de um dashboard. Para alem de
ter havido uma solida pesquisa sobre o estado da arte, como podemos ver na capıtulo dois, e ainda
utilizada uma framework de arquitetura de sistemas de informacao, a framework de Zachman, para
planear a projecao da solucao.
59
5. Rigor da investigacao.
A Design Science Research depende da aplicacao de metodos rigorosos na construcao e na avaliacao do
desenho do artefacto.
Durante este estudo, a construcao e a validacao dos artefactos produzidos seguiu um metodo rigoroso,
atraves do levantamento de indicadores, do seu suporte para a projecao de uma solucao, e da criacao
de cenarios, para a sua validacao e demonstracao, aplicados a uma instituticao real, com dados reais,
disponibilizados pela Direcao dos Servicos de Informatica, do Instituto Superior Tecnico.
6. Desenho como um processo.
A pesquisa por um artefacto efetivo requer a utilizacao dos meios disponıveis para alcancar os fins
desejados na envolvente do problema.
Foram definidos requisitos, para a resolucao do problema, no contexto atual, e foram utilizados todos
os metodos e conhecimentos disponıveis, de forma a atingir a solucao a que se chegou.
7. Comunicacao da investigacao.
A metodologia tem que ser efetivamente apresentada, tanto numa vertente orientada a tecnologia, como
numa vertente orientada a gestao.
Uma vez que o objetivo principal deste estudo e a melhoria curricular academica do aluno, a compo-
nente de gestao e saliente atraves do objetivo de utilizacao do dashboard. Acompanhado deste, esta a
especificacao da projecao conceptual, do mesmo, o que e referente a tecnologia. Uma vez que a tese
e realizada em contexto empresarial, a divulgacao do trabalho estara a cargo de uma das sessoes de
investigacao e desenvolvimento do grupo Capgemini, na Universidade da Capgemini, em Les Fontaines
(Paris, Franca) [5].
4.2 Cenarios de Aplicacao da Solucao
Nesta seccao, serao descritos dois cenarios, atraves do recurso as interfaces do dashboard, no Microsoft Excel, a
descricoes textuais e a diagramas de atividades, concretizados atraves do Enterprise Architect. Os diagramas
de atividades mostram-nos a sequencia de acoes tomadas, ou a tomar, na concretizacao do storyboard textual,
descrito em cada uma das subseccoes que se seguem.
4.2.1 Cenario 1 - O Portal do Coordenador do Mestrado em Engenharia In-
formatica e de Computadores (Taguspark)
A base de um storyboard textual assenta num diagrama de atividades, descrito na figura 4.5, onde podemos
verificar todo o desenrolar do processo, de forma ordenada, seguindo-se uma descricao da historia.
60
Figura 4.5: Diagrama de atividades referente ao ator Coordenador, relativo ao Cenario 1
O Professor Jose e coordenador dos cursos de Programa Doutoral em Engenharia Informatica e de Com-
putadores (DEAEIC), Licenciatura Bolonha em Engenharia Informatica e de Computadores - Taguspark
(LEIC-T), Mestrado Bolonha em Engenharia Informatica e de Computadores - Alameda (MEIC-A) e de
Mestrado Bolonha em Engenharia Informatica e de Computadores - Taguspark (MEIC-T) (ver figura 4.6); e
pretende fazer uma analise curricular ao curso de MEIC-T, relativamente ao atual ano letivo (2013/2014).
Por saber da brusca reducao de alunos inscritos a cadeira de Gestao e Tratamento de Informacao, para alem
de verificar a percentagem de aprovacoes genericas do curso, no referido semestre, e nos anos curriculares (1
e 2), escolhe entao a referida disciplina na caixa de combinacao aberta da analise por disciplina. Aqui, ve nos
graficos circular e de barras, a percentagem de alunos aprovados, reprovados e nao avaliados; e a quantidade
de alunos que teve as notas 12, 13 e 14, em particular, respetivamente (ver figura 4.7). Insatisfeito com os re-
sultados, o professor pretende visualizar a media descritiva de cada componente de avaliacao e a assiduidade,
atraves da media de faltas e presencas em cada tipo de aula (teorica e laboratorial), necessitando de, para
tal, clicar na sigla da cadeira, para despoletar uma operacao de drill down e poder ver os graficos respetivos
(ver figura 4.8). Ainda assim, para aprofundar a analise, o docente pretende validar a avaliacao qualitativa,
gerada automaticamente atraves do preenchimento dos questionarios da QUC (Qualidade das Unidades Cur-
riculares), procedendo de novo a uma operacao de drill down, ao clicar em ”Ver Avaliacao Qualitativa” (ver
figura 4.10). Uma vez que e importante relacionar a quantidade de alunos com a media, na generalidade
de todas as disciplinas de um ano curricular, o Professor Jose faz um drill down no dashboard, ao clicar
no grafico do primeiro ano, sendo mostrado um grafico de linhas, onde podemos relacionar a quantidade de
alunos com a media, por disciplina, como podemos ver na figura 4.8.
Neste cenario de exemplo, podemos verificar a existencia dos indicadores definidos no capıtulo tres, assim
como dos casos de uso identificados, nos varios ecras, associados ao ator Coordenador. Embora o atual
Portal do Coordenador ja possuısse algumas funcionalidades, neste dashboard foram desenvolvidas outras,
como a possibilidade de relacao entre a quantidade de alunos e a media de cada cadeira, como a possıvel
61
visualizacao da media dos varios componentes de avaliacao na disciplina e da assiduidade em cada tipo de
aula da mesma disciplina. A inexistencia destas funcionalidades representavam algumas lacunas no sistema
de reporting existente previamente.
Figura 4.6: Dashboard do Coordenador - Escolha do curso
Figura 4.7: Dashboard do Coordenador - Analise curricular
Figura 4.8: Dashboard do Coordenador - Media dos componentes de avaliacao e de assiduidade
62
Figura 4.9: Dashboard do Coordenador - Relacao entre media e quantidade de alunos
Figura 4.10: Dashboard do Coordenador - Avaliacao qualitativa
4.2.2 Cenario 2 - O Portal do Aluno do Mestrado em Engenharia Informatica
e de Computadores (Taguspark)
A base de um storyboard textual assenta num diagrama de atividades, descrito na figura 4.11, onde podemos
verificar todo o desenrolar do processo, de forma ordenada, seguindo-se descricao da historia.
A Rita e uma aluna do Instituto Superior Tecnico, inscrita em quatro cadeiras do Mestrado em Engen-
haria Informatica e de Computadores (Taguspark), neste semestre. Por ser trabalhadora-estudante, nao pode
comparecer a nenhuma aula (teorica ou pratica). Desta forma, precisa de um plano de estudo personalizado,
que possa consultar regularmente. Mas, por nao conseguir consultar o Fenix com regularidade e por nao
passar muito tempo na faculdade, o corpo docente permitiu que a Rita fizesse os trabalhos e os projetos in-
dividualmente, sendo que a Rita gostaria de receber notificacoes exporadicas, com o lembrete da entrega de
63
projetos ou trabalhos e com a indicacao de notas negativas.
Figura 4.11: Diagrama de atividades referente ao ator Aluno, relativo ao Cenario 2
Depois de escolher o semestre e o ano letivo, as primeiras operacoes necessarias no dashboard, a Rita
escolhe a disciplina que pretende visualizar, para ver as notas dos seus componentes de avaliacao (ver figura
4.12 e assim poder aceder ao seu plano de estudo. Aqui, a Rita pode ver os dias de estudo remanescentes
ate a proxima avaliacao, nas disciplinas em que esta inscrita, os dias de estudo recomendados para cada
disciplina e as notificacoes mais recentes, como podemos ver na figura 4.13.
Com algum grau de satisfacao, depois de avaliar o seu plano de estudo, a Rita volta ao ecra inicial,
fazendo roll up no dashboard, ate a analise da cadeira de Gestao e Tratamento de Informacao, cadeira
escolhida inicialmente, e clica em MEIC-T, tıtulo do primeiro grafico da figura 4.12, para fazer uma analise
personalizada do seu ano letivo, no que diz respeito ao seu currıculo, como podemos ver na figura 4.14. No
primeiro grafico circular, a Rita pode ver as cadeiras em que reprovou, por ano curricular, assim como a sua
media ao longo do ano curricular em que se encontra. No segundo grafico, podemos ter a mesma percecao,
mas numa perspetiva de matrıculas. Uma vez que a Rita esta inscrita pela segunda vez no primeiro ano
curricular, estes dois graficos apresentam situacoes diferentes. No terceiro grafico, podemos ver a evolucao
da sua media ao longo do numero de matrıculas.
Neste ultimo, adotou-se a visualizacao por grafico de barras, porque se pretende utilizar a notacao de
64
semaforo, no qual a cor amarela simboliza uma nota perto do limiar negativo (por exemplo 10 ou 11), e a
cor verde um valor bom ou regular [24].
No presente ecra, e ainda possıvel fazer um novo drill down, para analisar o historico do curso, nos
ultimos tres anos letivos, clicando no tıtulo do grafico de barras (por se referir a media), ou em qualquer uma
das medias dos graficos circulares, sendo entao mostrado o ecra da figura 4.15. Ao ver este ecra, a Rita fica
desapontada, por a sua media ser inferior as do historico e pretende, por isso, ver a media da cadeira que
esta a analisar, escolhendo Gestao e Tratamento de Informacao na drop down das disciplinas, no qual lhe e
mostrado o ecra apresentado na figura 4.16.
Conformada com a situacao, a Rita da por terminada a sua analise, depois de ver a taxa de empregabili-
dade do curso, cujo ecra resultante e mostrado na figura 4.17.
Figura 4.12: Dashboard do Aluno - Escolha do ano letivo, do semestre e da disciplina
Figura 4.13: Dashboard do Aluno - Plano de estudo
65
Neste cenario de exemplo, podemos verificar a existencia dos indicadores definidos no capıtulo tres, assim
como dos casos de uso identificados, nos varios ecras, associados ao ator Aluno. Embora o atual Portal do
Aluno ja possuısse algumas funcionalidades, neste dashboard foram desenvolvidas outras, como a possibilidade
de relacao entre a quantidade de cadeiras em atraso e a media de cada matrıcula ou ano curricular, ou de
visualizar um plano de estudo gerado automaticamente pelo Fenix. A inexistencia destas funcionalidades
representavam algumas lacunas no sistema de reporting existente previamente, no qual so eram apresentadas
as aprovacoes por ano letivo de cada disciplina e de cada ano curricular em particular, sendo que a maior
lacuna e a inexistencia de um sistema de monitorizacao em tempo util, com a possibilidade de atualizacao e
geracao de um plano de estudo, funcionalidade que pode abolir a necessidade das tarefas de um tutor.
Figura 4.14: Dashboard do Aluno - Analise personalizada por ano letivo
Figura 4.15: Dashboard do Aluno - Historico do curso
66
Figura 4.16: Dashboard do Aluno - Historico da disciplina
Figura 4.17: Dashboard do Aluno - Taxa de empregabilidade
Neste cenario de exemplo, podemos verificar a existencia dos indicadores definidos no capıtulo tres, assim
como dos casos de uso identificados, nos varios ecras, associados ao ator Aluno. Embora o atual Portal do
Aluno ja possuısse algumas funcionalidades, neste dashboard foram desenvolvidas outras, como a possibilidade
de relacao entre a quantidade de cadeiras em atraso e a media de cada matrıcula ou ano curricular, ou de
visualizar um plano de estudo gerado automaticamente pelo Fenix. A inexistencia destas funcionalidades
representavam algumas lacunas no sistema de reporting existente previamente, no qual so eram apresentadas
as aprovacoes por ano letivo de cada disciplina e de cada ano curricular em particular, sendo que a maior
lacuna e a inexistencia de um sistema de monitorizacao em tempo util, com a possibilidade de atualizacao e
geracao de um plano de estudo, funcionalidade que pode abolir a necessidade das tarefas de um tutor.
67
Capıtulo 5
Conclusoes e Trabalho Futuro
Este trabalho permitiu a criacao de uma especificacao, em termos conceptuais, de uma ferramenta de dash-
boards, passıvel de ser integrada num sistema ERP, como o do caso de estudo, por exemplo, o FenixEDU.
O potencial da ferramenta a desenvolver reside nos objetivos da mesma: a monitorizacao do desempenho
pedagogico do aluno, associados a um sistema de alarmıstica, que permite o despertar do aluno em situacoes
de perigo de chumbo em determinada disciplina, via e-mail ou SMS (mobile short message service).
Este projeto, embora seja aplicado a um sistema de gestao academica, podera tambem ser aplicado a uma
qualquer empresa, de qualquer ramo, pois conceptualmente tera a mesma especificacao, mudando apenas os
indicadores e a enfase dos casos de uso e das atividades identificadas.
Tal como comprovado pela projecao da especificacao, pelas perguntas de investigacao, colocadas com
validade citentıfica, e pelo estado da arte, existem algumas lacunas que este trabalho de investigacao procura
resolver. Chegou-se a um modelo de domınio e a um diagrama de arquitetura tecnologica, apoiados por
diagramas de casos de uso, por diagramas de atividades e, consequentemente, por mockups (de baixa e de
alta fidelidade), de forma a suportar a especificacao do trabalho projetado, sendo estes testados em dois
cenarios reais de aplicacao, no caso de estudo escolhido, com o apoio da Direcao dos Servicos de Informatica
do Instituto Superior Tecnico e da Capgemini Portugal. Nas proximas seccoes, iremos descrever o metodo
de avaliacao do trabalho e indicar as perguntas de investigacao respondidas.
5.1 Metodologia de Avaliacao do Trabalho
A metodologia de avaliacao do trabalho adotada foi a proposta por Hevner [5], aquando da utilizacao da De-
sign Science Research, embora apenas parte dos metodos tenham sido utilizados, como os metodos observavel,
atraves de um caso de estudo real, e descritivo, atraves de cenarios.
No metodo observavel, o caso de estudo utilizado, como ja se viu no capıtulo anterior, foi o FenixEDU,
aplicado especificamente a um estabelecimento de ensino superior, o Instituto Superior Tecnico, da Univer-
sidade de Lisboa. O campo de estudo em causa foi a monitorizacao de eventos no sistema ERP, em que
68
os atores intervenientes foram utilizadores com o papel de docente, tutor, alumni, aluno e coordenador, os
mesmos utilizados na identificacao de atores, no capıtulo tres, e nos atores do negocio referidos no capıtulo
quatro.
No metodo descritivo, recorreu-se a construcao de cenarios, baseados em factos reais, em torno de alguns
dos artefactos indicados (Indicadores, Cenarios, Diagramas de Atividades, Digramas de Casos de Uso e
Mockups projetados). Utilizamos dois dos atores do negocio mais relevantes, onde era urgente a melhoria
das ferramentas analıticas existentes, um coordenador de um curso do Instituto Superior Tecnico e um aluno
trabalhador-estudante da mesma instituicao. Para este metodo, foram descritos dois diagramas de atividades
personalizados e foram referenciados dois dashboards implementados no Microsoft Excel, com recurso a dados
reais, da base de dados do Fenix, disponilizados pelo Direcao dos Servicos de Informatica do IST, atraves de
um protocolo de colaboracao com a Capgemini Portugal, na qual sou consultor.
5.2 Perguntas de Investigacao
As respostas as perguntas de investigacao identificadas tem como objetivo a resolucao de determinadas lacu-
nas existentes na area, como podemos ver nos proximos paragrafos. Na resposta as mesmas, como poderemos
ver, recorremos aos capıtulos anteriormente redigidos.
Pergunta de Investigacao 1
Como projetar um dashboard de monitorizacao academica?
A resposta a esta questao encontra-se no inıcio do capıtulo tres, onde sao enunciados todos os passos a
percorrer (e consequentes modelos a desenhar), sendo estes os seguintes:
1. Identificacao dos atores do negocio;
2. Desenvolvimento de um questionario a aplicar aos atores existentes no contexto;
3. Analise dos dados do questionario indicado anteriormente;
4. Definicao de indicadores de desempenho, de controlo e de risco;
5. Definicao dos casos de uso a projetar;
6. Associacao dos casos de uso aos atores do negocio;
7. Definicao das atividades associadas a cada dashboard ;
8. Definicao do modelo de domınio;
9. Definicao da arquitetura da solucao proposta por intermedio de um diagrama de arquitetura te nologica;
69
10. Desenvolvimento dos mockups associados, como referencia a arquitetura tecnologica e ao modelo de
domınio.
Pergunta de Investigacao 2
Como definir o codigo de cores a utilizar no dashboard?
Atraves da identificacao dos indicadores de risco e do limiar entre a positiva e a negativa, no caso das
notas das cadeiras e dos varios componentes de avaliacao, no caso de estudo em causa, assim como entre a
aprovacao e a reprovacao. Como exemplo de aplicacao, seguem-se os KRI’s identificados:
1. Alteracao do planeamento gerado pelo sistema ERP;
2. Falha na entrega de uma justificacao de uma falta;
3. Falta a uma aula obrigatoria;
4. Falta a uma componente de avaliacao;
5. Falha na entrega de um trabalho, ficha eletronica ou projeto;
6. Nota 10 (em 20) num componente de avaliacao;
7. Nota negativa num componente de avaliacao;
8. Reduzido numero de presencas nas aulas (menos de cinquenta por cento do numero de aulas atualmente
lecionadas).
O codigo de cores usado foi o referente aos semaforos, em que uma nota negativa tera a cor vermelha; as
notas no ”limbo”, como o 10 e o 11 (em 20), ou como os valores aproximados a 50 por cento, terao a cor
amarela; e a boa nota tera uma cor verde, que simboliza regularidade na avaliacao.
Pergunta de Investigacao 3
Como identificar as funcionalidades a implementar num dashboard?
Atraves da identificacao de casos de uso e de atividades, associados a cada ator, em diferentes swimlanes.
Cada swimlane corresponde a um ator diferente e aglomera o conjunto de funcionalidades por ordem de
execucao, de cada dashboard, de cada utilizador: Aluno, Docente, Coordenador, Alumni e Tutor.
Pergunta de Investigacao 4
Como levantar as acoes passıveis de serem executadas nos dashboards de cada ator?
70
Atraves da realizacao de questionarios a populacao do contexto, para que os KCI’s, KRI’s e KPI’s possam
ser definidos, como podemos ver no capıtulo tres. Com os indicadores definidos, podemos, atraves deles,
projetar as acoes a implementar no dashboard, criando vistas atraves dos KCI’s e definindo atividades atraves
dos KPI’s.
Pergunta de Investigacao 5
Como representar os fluxos de informacao entre cada dashboard e entre cada drill down?
Atraves da identificacao de entidades informacionais, das atividades associadas a cada ator e dos requisi-
tos nao funcionais identificados.
Pergunta de Investigacao 6
Como criar um modelo preditivo para a geracao de um plano de estudo automatizado e per-
sonalizado para cada aluno?
Atraves de um conjunto de regras de negocio pre-definidas, que garanta as regras de aprovacao das cadeiras
em questao, e atraves das contribuicoes individualizadas de cada tutor, relativas a cada aluno, como podemos
ver no ultimo mockup do tutor, no anexo E.
Pergunta de Investigacao 7
Quais sao os atores intervenientes no processo de projecao do dashboard?
Os atores intervenientes foram identificados atraves dos papeis existentes no sistema ERP, onde o dash-
board vai ser aplicado. No nosso caso de estudo, os papeis dos utilizadores intervenientes sao o Aluno, o
Alumni, o Docente, o Coordenador e o Tutor, que completam o contexto, tal como podemos ver na figura
5.1.
Figura 5.1: Modelacao do contexto
71
5.2.1 Artefactos
A criacao de artefactos inovadores, ou que sirvam de suporte a concretizacao da solucao projetada, permite
a resolucao de algumas lacunas no trabalho de investigacao decorrido. Uma vez que se trata de um tipo de
investigacao aplicada, os artefactos nao sao abstratos, mas sim instancias existentes no contexto modelado.
Na tabela 5.1, podemos ver a relacao entre os artefactos produzidos e as perguntas de investigacao.
Perguntas de Investigacao
Artefactos 1 2 3 3.1 4 5 6
Cenarios X X X X X
Diagramas de Atividades X X X
Diagrama de Arquitetura Tecnologica X
Diagramas de Casos de Uso X X X X
Indicadores X X X X X
{Mockups} Projetados X X X X
Tabela 5.1: Relacao entre os artefactos e as perguntas de investigacao
5.3 Trabalho Futuro
Paralelamente ao contributo cientıfico, a especificacao, o facto de a ferramenta ser implementada no sistema
escolhido para o caso de estudo, permite-nos uma melhor percepcao do negocio, de forma a lhe criarmos
mais valor. Deste modo, conseguimos que o alinhamento, entre os processos existentes e os requeridos, seja
atingido com uma maior rapidez e consequentemente com uma maior taxa de sucesso [32], garantindo ainda
um dos princıpios de alto desempenho do IT. Uma vez que orientamos o negocio a atividade, permitimos que
futuramente um tutor nao seja tao requisitado, pois o proprio dashboard podera assumir esse papel [33].
Ainda assim, uma possıvel continuacao deste trabalho de investigacao podera agregar um sistema de
alarmıstica, com um modelo preditivo (data mining), que permita a rececao de feedback, por parte de todos
os atores do contexto, no qual o obstaculo sera a escolha de uma tecnologia especıfica, nao deixando em aberto
um leque tao grande de possibilidades, como as existentes para a generalidade dos dashboards. Deste modo,
terıamos um sistema de dashboards desenvolvdo atraves da conjuncao de data warehouses com o conceito de
data mining, utilizando os conceitos de business activity monitoring e de business intelligence, para suportar
a analise da atividade do contexto.
72
Referencias
[1] E. Renaux. Framework d’architecture d’entreprise zachman. http://manurenaux.wp.mines-
telecom.fr/2012/09/27/framework-darchitecture-dentreprise-zachman-l-gamassia-q-maurice-d-thomas/,
2012. Acedido em 02/2013.
[2] O. Velcu; O. Yigitbasioglu. The use of dashboards in performance management: Evidence from sales
managers. The International Journal of Digital Accounting Research, 12:39–58, 2012.
[3] B. Wetzstein; P. Leitner; F. Rosenberg; I. Brandic; S. Dustdar; F. Leymann. Monitoring and analyzing
influential factors of business process performance. In IEEE International Enterprise Distributed Object
Computing Conference, pages 141–150, 2009.
[4] T. Chieu; L. Zeng. Real-time performance monitoring for an enterprise information management sys-
tem. In IEEE International Conference on e-Business Engineering, pages 429–434, IBM T. J. Watson
Research Center, 19 Skyline Drive 2008.
[5] A. Hevner; S. March; J. Park; S. Ram. Design science in information systems research. MIS Quarterly,
8:78–90, 2004.
[6] P. Mota. Gestao de competencias internacionais. Master’s thesis, Instituto Superior Tecnico, 2011.
[7] M. Lankhorst. Enterprise Architecture at Work: Modelling, Communication and Analysis. Springer,
2005.
[8] Navman Wireless Certainy Delivered. Dynamic dashboard: Analyse your fleet with ease.
http://www.navmanwireless.com/solutions/onlineavl2/dynamic-dashboard, 03 2013. Acedido em
18/03/2013.
[9] JVKellyGroup Inc. Intelligent dashboards: Managing large scale disparate data.
http://www.jvkg.com/Pages/IntelligentDashboards.aspx, 03 2013. Acedido em 18/03/2013.
[10] Implementing a dashboard on repox. Technical report, Instituto Superior Tecnico, 2012.
[11] A. Vaidya; S. Carter; S. Isaacson. Collaborative decision making, 2011.
73
[12] D. Luckham. The beginnings of it insight: Business activity monitoring. Technical report, Stanford
University, 2004. Stanford University.
[13] K. Han; S. Choi; J. Kang; G. Lee. Business activity monitoring system design framework integrated
with process-based performance measurement model. Wseas Transactions on Information Science and
Applications, 7:443–452, 2010.
[14] J. Yoo; S. Yoo; C. Lance; J. Hankins. Student progress monitoring tool using treeview. SIGCSE, pages
373–377, 2006.
[15] B. Kang; S. Lee; Y. Min; S. Kang; N. Cho. Real-time process quality control for business activity
monitoring. In International Conference on Computational Science and its Applications, 2009.
[16] J. Lee; B. Kang; K. Shin; S. Kang. Online process monitoring scheme for fauld detection based on
independent component analysis (ica) and local outlier factor (lof). Technical report, Seoul National
University (Republic of Korea), 2009. Seoul National University.
[17] J. Vicente. Monitoring it services for supporting business processes. Master’s thesis, Instituto Superior
Tecnico, 2007.
[18] J. Kang; K. Han. Third 2008 international conference on convergence and hybrid information technology.
In A Business Activity Monitoring System Supporting Real-Time Business Performance Management,
pages 473–478, 2008.
[19] U. Dayal; M. Castellanos; A. Simitsis; K. Wilkinson. Data integration flows for business intelligence. St.
Petersburg, Russia, 03 2009. EDBT.
[20] K. Pauwels; T. Ambler; B. Clark; P. LaPointe; D. Reibstein; B. Skiera; B. Wierenga; T. Wiesel. Dash-
boards & marketing: Why, what, how and what research is needed? Technical report, Goethe University
Frankfurt am Main, 2012.
[21] O. Velcu; O. Yigitbasioglu. A review of dashboards in performance management: Implications for design
and research. International Journal of Accounting Information Systems, 13:41–59, 2012.
[22] Craig Schoenecker; Linda L. Baer. Measuring what matters: A dashboard for success. The Chair
Academy s 19th Annual International Conference, 2010.
[23] A. Vasconcelos. Arquitectura dos Sistemas de Informacao: Representacao e Avaliacao. PhD thesis,
Instituto Superior Tecnico, 2007. pp. 2-4, 49-51.
[24] H. Kerzner. Project Management Metrics, KPI’s and Dashboards - A Guide to Measuring and Monitoring
Project Performance. John Wiley & Sons, Inc., 2011.
74
[25] MicroStrategy. Microstrategy dashboards - perfect dashboards. created by anyone. used by everyone.
http://www.microstrategy.com/software/business-intelligence/dashboards-and-scorecards/, 2013. Ace-
dido em 18/03/2013.
[26] MicroStrategy. Business dashboards gallery: Improving the way you see and run your business.
http://www.microstrategy.com/software/business-intelligence/dashboards-and-scorecards/gallery/,
2013. Acedido em 18/03/2013.
[27] S. Kumaran S. Fu; T. Chieu; J. Yih. An intelligent event adaptation mechanism for business performance
monitoring. In IEEE International Conference on e-Business Engineering, 2005.
[28] L. Noyez. Interactive cardiovascular and thoracic surgery 9. In Control charts, Cusum techniques and
funnel plots. A review of methods for monitoring performance in healthcare, pages 494–499. European
Association for Cardio-Thoracic Surgery, 2009.
[29] S. Thorn. Togaf and itil. Technical report, Merck Serono International SA, 2007.
[30] Hernan Huwyler. Key indicators: Kpis, kris, kcis and klis.
http://mydailyexecutive.blogspot.pt/2011/06/key-indicators-kpis-kris-kcis-and-klis.html, 2011. acedido
dia 31/05/2013.
[31] The Open Group. Archimate 2.1 specification, 2013.
[32] B. Bruno. It management automation. Technical report, Instituto Superior Tecnico, 2008.
[33] William D., Robert; H. Endre; M. David; M. Six principles of high-performance it. Technical Report 3,
The McKinsey Company, 1997.
75
Anexos
A. Questionario Realizado aos Alunos do Instituto Superior Tecnico
No ambito do desenvolvimento de um dashboard dinamico, para melhoria do progresso curricular academico
do aluno, do ensino superior publico portugues, foi desenvolvido um questionario para a implementacao de
determinadas funcionalidades.
1. Acharia interessante o facto de ter um aplicacao no seu telemovel, que monitorizasse o seu percurso
academico ao longo de um semestre, em determinada disciplina? (Selecione uma das seguintes opcoes)
(a) Sim;
(b) Nao.
2. Gostaria de se poder comparar com os outros alunos, em todos os elementos de avaliacao de determi-
nada disciplina, de forma a manter a sua rentabilidade? (Selecione uma das seguintes opcoes)
(a) Sim;
(b) Nao.
3. Se o sistema ERP (Enterprise Resource Planning) que gere a sua faculdade, instituto, universidade ou
escola superior, como por exemplo o Sistema Fenix, tivesse um sistema de alarmıstica associado, que
tipo de mensagem (por SMS e/ou E-Mail) gostaria de receber com as devidas notificacoes? (Escolha
as opcoes que achar interessantes)
(a) Risco de reprovacao;
(b) Aproximacao da data de entrega de um projeto;
(c) Aproximacao da data de um teste;
(d) Falta dada a uma aula obrigatoria;
76
(e) Nota mınima necessaria na avaliacao seguinte;
(f) Quantidade de faltas que o aluno pode ainda dar a cadeira a que acabou de faltar.
4. Se o mesmo sistema ERP, referido na questao anterior, permitisse o envio de uma justificacao de uma
falta, por SMS ou E-Mail, no caso de a falta poder ser justificada, aquando da rececao de uma noti-
ficacao com a falta dada, usaria tal funcionalidade? (Selecione uma das seguintes opcoes)
(a) Sim;
(b) Nao.
5. Gostaria que o mesmo sistema ERP, referido anteriormente, lhe gerasse um planeamento personalizado,
mediante o seu desempenho atual, sendo este atualizado em tempo util? (Selecione uma das seguintes
opcoes)
• Sim;
• Nao.
6. Que tipo de comparacoes, relativamente a anos anteriores, gostaria de poder fazer no sistema? (Escolha
as opcoes que achar interessantes)
(a) Comparar notas finais de disciplinas a que esta inscrito(a) com notas de anos anteriores, da mesma
disciplina;
(b) Comparar notas de projetos, testes, fichas e/ou laboratorios de uma disciplina que esta a frequen-
tar, com notas de outros alunos, de outros anos letivos;
(c) Comparar notas de projetos, testes, fichas e/ou laboratorios de uma disciplina que esta a frequen-
tar, com as suas notas anteriores, no caso de ser repetente;
(d) Comparar medias do ano curricular atual com as dos anos anteriores;
(e) Comparar as medias finais de curso, relacionadas com a empregabilidade dos alunos;
(f) Comparar numero de disciplinas feitas por aluno, por ano letivo.
77
B. Diagramas de Atividades
Nesta seccao, serao apresentados os diagramas de atividades do Aluno, do Docente, do Coordenador, do Tutor
e do Alumni, nas respetivas swimlanes, com a descricao das varias funcionalidades a projetar no dashboard e
com referencia aos varios requisitos nao funcionais, nas figuras B.1, B.2, B.3, B.4 e B.5, respetivamente.
Figura B.1: Diagrama de Atividades do Aluno
78
Figura B.2: Diagrama de Atividades do Docente
Figura B.3: Diagrama de Atividades do Coordenador
79
Figura B.4: Diagrama de Atividades do Tutor
Figura B.5: Diagrama de Atividades do Alumni
80
C. Mockups Propostos para o Dashboard do Docente
O dashboard do docente permite que as notas dos alunos e as faltas destes as disciplinas do docente sejam
supervisionadas, assim como o seu plano de estudo individualizado, com um esquema de cores adequado.
Depois da disciplina escolhida (figura C.1), o dashboard do docente apresenta a listagem dos alunos inscritos
na mesma, seguido da informacao do numero mecanografico e do curso a que pertencem. Paralelamente a
esta informacao, o ecra completa-se com um grafico circular para cada componente de avaliacao da cadeira
escolhida, onde e possıvel ver as percentagens das notas que foram negativas, entre 10 e 13 e superiores a
13; com um grafico de colunas, onde sao apresentadas as faltas gerais de cada aluno a cadeira; e uma area
de notificacoes para informar o docente de algumas situacoes particulares, como podemos ver na figura C.2.
No grafico de colunas, referente as faltas, e possıvel fazer uma operacao de drill down, no qual o docente
clica na coluna correspondente a cada aluno e lhe e entao apresentado um grafico com as faltas a cada tipo
de aula (teorica, laboratorial, pratica, etc.), relativo ao aluno em causa (ver figura C.3). Se o docente assim
o pretender, podera visualizar em pormenor as notas de cada componente de avaliacao, clicando no nome
do aluno, neste ecra ou no inicial, e ser-lhe-ao mostradas todas as notas de cada componente de avaliacao
na disciplina escolhida, assim como um grafico de colunas que relaciona a quantidade de faltas dadas com a
quantidade de presencas assinaladas, a cada tipo de aula, podendo tambem aceder ao seu currıculo academico
ou ao seu plano de estudo automaticamente gerado pelo Fenix, tal como e apresentado na figura C.4. Se
o docente preferir visualizar o currıculo do aluno, o ecra que lhe sera mostrado e o da figura C.5, onde
pode escolher o ano letivo a analisar e o semestre, sendo entao apresentada uma tabela com as disciplinas
a que o aluno se inscreveu nesse semestre, juntamente da sua avaliacao final, e um grafico de barras que
relaciona a quantidade de aprovacoes com a quantidade de inscricoes, na mesma linha de tempo. Quando a
operacao escolhida e a visualizacao do plano de estudo, entao o ecra que lhe e mostrado e o da figura C.6,
o qual apresenta, por ordem cronologica, as avaliacoes remanescentes de cada disciplina, os dias de estudo
recomendados por disciplina durante a epoca de exames, a quantidade maxima de faltas recomendada por
disciplina e uma area de notificacoes, relativa a conselhos e as ultimas notas negativas.
Figura C.1: Dashboard do Docente - Escolha da disciplina
81
Figura C.2: Dashboard do Docente - Analise por cadeira
Figura C.3: Dashboard do Docente - Faltas do aluno aos tipos de aula
Figura C.4: Dashboard do Docente - Analise do aluno, na cadeira escolhida
82
Figura C.5: Dashboard do Docente - Currıculo do aluno
Figura C.6: Dashboard do Docente - Plano de estudo do aluno
D. Mockups Propostos para o Dashboard do Alumni
O dashboard do alumni permite a um ex-aluno do estabelecimento de ensino superior em causa, do Instituto
Superior Tecnico, no nosso caso de estudo, fazer uma analise detalhada do seu currıculo, enquanto antigo
aluno, podendo aceder as notas das componentes de avaliacao de cada disciplina concluıda com sucesso, para
alem das suas notas finais, podendo assim tambem verificar qual a taxa de empregabilidade dos cursos que
concluiu, nos ultimos anos letivos (tres anos e o valor padrao para a quantidade de anos letivos a mostrar no
historico). A figura D.1 mostra-nos a interface generica do alumni e a figura D.2 apresenta-nos a interface
da taxa de empregabilidade, ecra resultante do acesso a ”Ver taxa de empregabilidade”.
Figura D.1: Dashboard do Alumni - Currıculo do ex-aluno
83
Figura D.2: Dashboard do Alumni - Taxa de empregabilidade
E. Mockups Propostos para o Dashboard do Tutor
O dashboard do tutor e util para os docente com papel de tutor, uma vez que ira permitir a monitorizacao
do desempenho dos seus tutorandos, salientando-se o facto de o objetivo do trabalho realizado pelo tutor se
concretizar na melhoria do desempenho dos alunos, seus tutorandos.
O ecra inicial proposto para o tutor, no caso de estudo em causa, esta representado na figura E.1, em
que sao listados os seus tutorandos, acompanhados do numero mecanografico e do curso que frequentam,
e e saliente a existencia de uma area de notificacao, com as notificacoes mais preocupantes para o tutor,
relativamente aos seus alunos. Na lista apresentada, o tutor pode aceder as notas das disciplinas e as
faltas dadas por cada aluno, fazendo uma operacao de drill down atraves do nome de cada aluno, como
podemos ver na figura E.2. Neste exemplo, estao selecionadas todas as disciplinas pretendidas para que o
aluno seja analisado, mas tambem podemos escolher uma unica disciplina (ver figura E.3). Se o tutor assim
pretender, pode tambem aceder ao currıculo do aluno (figura E.4), clicando no botao correspondente, em
que a informacao apresentada e o conjunto de disciplinas em que se inscreveu no ano letivo e no semestre
selecionados, assim como um grafico de barras, numa perspetiva de alto nıvel, que nos mostra a relacao entre
as disciplinas concluıdas com sucesso e a quantidade de disciplinas a que se escreveu, informacao essa que
o docente tambem consegue visualizar. Para visualizar o plano de estudo gerado para o aluno em causa, o
botao ”Ver plano de estudo” despoletara o novo ecra (figura E.5), onde sao mostradas todas as disciplinas em
que o aluno esta inscrito, agregadas do tempo remanescente para as proximas avaliacoes, dos dias de estudo
mınimos recomendados durante a epoca de exames e das faltas maximas recomendadas para cada cadeira,
para alem de uma area de notificacoes, que alerta o aluno para as avaliacoes menos boas, onde e tambem
saliente uma sugestao para que o desempenho melhore. Ainda neste ecra, e tambem possıvel ao tutor sugerir
melhorias ao plano de estudo, uma acao importante para os docentes com este papel. Sem esta interacao, o
dashboard poderia vir a substituir o papel do tutor no estabelecimento de ensino onde esta implementado.
84
Figura E.1: Dashboard do Tutor - Listagem de tutorandos
Figura E.2: Dashboard do Tutor - Analise de todas as cadeiras
Figura E.3: Dashboard do Tutor - Analise de uma cadeira em particular
85
Figura E.4: Dashboard do Tutor - Currıculo do aluno
Figura E.5: Dashboard do Tutor - Plano de estudo
86