Desenvolvimento de software colaborativo de learning objects integrado em equipa de desenvolvimento empresarial

Dissertação de Mestrado Apresentada Por António José Azevedo Botelho
Sob a orientação de Leonel Caseiro Morgado e Arnaldo Manuel Pinto dos Santos

UNIVERSIDADE DE TRÁS-OS-MONTES E ALTO DOURO

ESCOLA DE CIÊNCIA E TECNOLOGIA
DEPARTAMENTO DE ENGENHARIAS

Vila Real, 2014

Dissertação apresentada por António José Azevedo Botelho à Universidade de Trás-os-Montes para o

cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia Informática, sob a orientação do Professor Doutor Leonel Caseiro Morgado e do Doutor Arnaldo Manuel Pinto dos Santos.

III

IV

RESUMO
O presente documento descreve o processo de desenvolvimento de um software em contexto empresarial, do ponto de vista de um participante, através de registos sistemáticos de campo de atuação. O autor aproveitou a oportunidade de integrar uma equipa de trabalho na criação do COLOR, um portal Web de learning objects focado na colaboração entre os alunos/formandos. É descrito o projeto e a forma como surgiu através de factos e de seguida é feita uma análise e reflexão sobre os dados recolhidos durante todo o processo.

V

VI

ABSTRACT
This document intends to let people know about the development process of software in the context of an enterprise in the point of view of a participant, through the systematic registration in the field. The author took the opportunity to participate in a work team for the creation of COLOR, which is a learning objects web portal focused in the teamwork between students/trainees. It is described how the project came to be through facts, and then it is made an analysis and reflection about collected data throughout the all process.

VII

VIII

AGRADECIMENTOS
A presente dissertação é o resultado da união entre o esforço e o empenho do autor e também de todos aqueles que o rodearam e que, de alguma forma, durante o trabalho apoiaram e incentivaram na realização do mesmo. Agradeço ao Professor Doutor Leonel Morgado, orientador da minha investigação, que me auxiliou com o seu conhecimento científico, experiência e disponibilidade constante que muito contribuíram para ultrapassar dificuldades e concretizar a realização do presente trabalho. Agradeço também ao Doutor Arnaldo Santos pela oportunidade da participação numa equipa fantástica de trabalho e por toda a ajuda dispensada durante o mesmo. Aos meus colegas de ‘sala’ Álvaro Almeida e João Fonseca pelo apoio, força e pela ajuda prestada sempre que necessitava. Quero agradecer à minha família, em particular à minha mãe, por todo o carinho, paciência e por estar sempre presente. Aos meus amigos, em particular o André Pinheiro, José Mendonça, Paulo Fernandes pelo companheirismo e por estarem sempre disponíveis.

IX

X

ÍNDICE
Resumo .................................................................................................................................. V Abstract ............................................................................................................................... VII Agradecimentos.................................................................................................................... IX Índice .................................................................................................................................... XI Lista de figuras ..................................................................................................................... XV Lista de tabelas .................................................................................................................. XVII Glossário, acrónimos e abreviaturas .................................................................................. XIX Capítulo 1: Introdução ........................................................................................................... 1 1.1 1.2 1.3 1.4 Enquadramento ...................................................................................................... 2 Objetivos ................................................................................................................. 3 Motivação e contribuições ..................................................................................... 4 Estrutura ................................................................................................................. 5

Capítulo 2: Enquadramento tecnológico............................................................................... 7 2.1 Plataformas de ensino e aprendizagem ................................................................. 8 Learning Management Systems ...................................................................... 8 Learning Content Management System ........................................................ 11 Personal Learning Enviroments ..................................................................... 12

2.2.1 2.2.2 2.2.3 2.2 2.3 2.4 2.5 2.6 2.7

Learning Objects ................................................................................................... 13 Metadados ............................................................................................................ 14 Repositórios de Learning Objects ......................................................................... 15 Software colaborativo........................................................................................... 17 Metodologia de desenvolvimento de software ................................................... 18 Norma SCORM ...................................................................................................... 19

Capítulo 3: Projeto COLOR................................................................................................... 21

XI

3.1

Metodologia adotada ........................................................................................... 22 Equipa ............................................................................................................ 22

3.1.1 3.2 3.3

Descrição do projeto ............................................................................................. 23 Casos de uso.......................................................................................................... 23

3.3.1 Package “Consulta do sistema” ....................................................................... 25 3.3.2 Package “Gestão dos utilizadores” ................................................................... 25 3.3.3 Package “Gestão de conteúdo do LO” .............................................................. 27 3.3.4 Package “Gestão do LO” ................................................................................... 29 3.4 3.5 3.6 Perfis de utilizadores............................................................................................. 30 Requisitos funcionais ............................................................................................ 31 Arquitetura............................................................................................................ 37 Camada de dados .......................................................................................... 38 Camada de aplicação ..................................................................................... 39 Camada de apresentação .............................................................................. 40

3.6.1 3.6.2 3.6.3

Capítulo 4: Método de investigação.................................................................................... 52 4.1 4.2 Estudo de Caso ...................................................................................................... 53 Características de um estudo de caso .................................................................. 54

4.2.1 Projeto de investigação ........................................................................................ 54 4.3 4.4 Recolha de dados no estudo de caso ................................................................... 56 Análise de conteúdo ............................................................................................. 57

Capítulo 5: Vivência de desenvolvimento de software a nível empresarial ....................... 59 5.1 5.2 Introdução............................................................................................................. 60 Ambiente de trabalho ........................................................................................... 60 Colaboração intra-grupo ............................................................................... 60 Comunicação ................................................................................................. 61

5.2.1 5.2.2

XII

5.2.3 5.2.4 5.3 5.4 5.5

Escrita de código ............................................................................................ 62 Testes ............................................................................................................. 62

Tecnologias e ferramentas utilizadas ................................................................... 62 Panorama geral do processo de desenvolvimento .............................................. 65 Análise do software anterior (PoLO II).................................................................. 66 Problemas/Erros no código ........................................................................... 66 Limitações ...................................................................................................... 69

5.5.1 5.5.2 5.6

Desenvolvimento do COLOR ................................................................................. 71 Implementação dos requisitos ...................................................................... 71 Desafios encontradas pelo autor na implementação ................................... 80

5.6.1 5.6.2

Capítulo 6: Análise ............................................................................................................... 83 6.1 6.2 6.3 Problemas/Erros no código do sistema anterior - PoLO II ................................... 84 Limitações do sistema anterior - PoLO II .............................................................. 88 Implementação dos requisitos do COLOR ............................................................ 88

Capítulo 7: Conclusões ........................................................................................................ 90 7.1 7.2 7.3 Problemas/Erros no código do sistema anterior - PoLO II ................................... 91 Limitações do sistema anterior – PoLO II ............................................................. 94 Implementação dos requisitos do COLOR ............................................................ 94

Referências bibliográficas .................................................................................................... 97 Problemas/Erros e limitações no PoLO II - Código .......................................................... 99

XIII

XIV

LISTA DE FIGURAS
Figura 1 - Componentes de um sistema de e-learning (Pereira, 2011) ................................ 9 Figura 2 - Fases do modelo em cascata ............................................................................... 19 Figura 3 - Organigrama da equipa ....................................................................................... 22 Figura 4 - Perfis de utilizador ............................................................................................... 24 Figura 5 - Casos de uso da consulta do sistema .................................................................. 25 Figura 6 - Casos de uso da gestão dos utilizadores ............................................................. 26 Figura 7 - Listagem dos utilizadores .................................................................................... 27 Figura 8 - Casos de uso de gestão de conteúdo do LO ........................................................ 28 Figura 9 - Listagem de áreas temáticas ............................................................................... 29 Figura 10 - Casos de uso da gestão do LO ........................................................................... 30 Figura 11 - Áreas dos requisitos funcionais ......................................................................... 32 Figura 12 - Menu do Portal .................................................................................................. 41 Figura 13 - Área do LO ......................................................................................................... 42 Figura 14 - Área Lateral do Perfil ......................................................................................... 43 Figura 15 - Menu do Estudo do LO ...................................................................................... 44 Figura 16 - Informação principal ......................................................................................... 45 Figura 17 - Objetivos............................................................................................................ 45 Figura 18 - Adição e disposição do conteúdo ...................................................................... 45 Figura 19 - Síntese ............................................................................................................... 46 Figura 20 - Conceitos ........................................................................................................... 46 Figura 21 - Etiquetas ............................................................................................................ 46 Figura 22 - Competências .................................................................................................... 47 Figura 23 - Resumo .............................................................................................................. 47 Figura 24 - Etapas ................................................................................................................ 47 Figura 25 - Página de criação do LO .................................................................................... 48 Figura 26 - Página Inicial ...................................................................................................... 49 Figura 27 - Página de estudo do lo ...................................................................................... 50 Figura 28 - Página de edição do perfil ................................................................................. 51 Figura 29 - Estrutura de ferramentas usadas ...................................................................... 64 Figura 30 - Diagrama do processo de desenvolvimeno ...................................................... 66 XV

Figura 31 - Tabelas para a relação da permissão do utilizador num lo ............................... 69 Figura 32 - ER do PTP11 ....................................................................................................... 92 Figura 33 - Solução para o PTP11 ........................................................................................ 93

XVI

LISTA DE TABELAS
Tabela 2 - Requisitos funcionais ....................................................................................................... 34 Tabela 3 - Situações relevantes para diferentes estratégias de investigação (Yin, 1984) ............... 53 Tabela 4 - Problemas/erros no código ............................................................................................. 67 Tabela 5 - limitações ........................................................................................................................ 69 Tabela 6 - Reuniões gerais de equipa............................................................................................... 71 Tabela 7 - Problemas técnicos ocorridos ......................................................................................... 71 Tabela 8 - Ocorrências...................................................................................................................... 72 Tabela 9 - Desafios do autor ............................................................................................................ 80 Tabela 10 - Gestão de estados (Abreu, 2011) .................................................................................. 82 Tabela 11 - Tabela "permissao_utilizador_lo" com dados ............................................................... 87

XVII

XVIII

GLOSSÁRIO, ACRÓNIMOS E ABREVIATURAS
ARIADNE - Alliance of Remote Instructional Authoring and Distribution Networks for Europe ADL - Advanced Distance Learning COLOR - Collaboration Learning Objects Repository CSCW - Computer Supported Cooperative Work CSS - Cascading Style Sheets E-mail - Electronic Mail HP - Hewlett-Packard IEEE - Institute of Electrical and Electronics Engineers IMS - Instructional Management System LO - Learning Object LMC - Learning Content Management System LMS - Learning Management System LTSC - Learning Technology Standards Committee MERLOT - Multimedia Educational Resource for Online Learning and Teaching Moodle - Modular Object-Oriented Dynamic Learning Enviroment ORM - Object-relational mapping PoLO - Portal de Learning Objects PLE - Personal Learning Environments PT - Portugal Telecom SCORM - Sharable Content Object Reference Model SQL - Structured Query Language SVN - Subversion TIC - Tecnologias de Informação e Comunicação URL - Uniform Resource Locator VLE - Virtual Learning Environment WTCS - Wisconsin Technical College System

XIX

XX

CAPÍTULO 1: INTRODUÇÃO
Este capítulo introdutório apresenta um enquadramento de toda a dissertação, explicando os projetos que deram inicio à mesma, e de seguida as contribuições e motivações que levaram o autor à escolha do tema. São ainda apresentados os objetivos gerais que se pretendem cumprir e a estrutura do documento, descrevendo de forma resumida o conteúdo que é abordado em cada um dos capítulos.

1

1.1

Enquadramento
Com o aumento do uso das Tecnologias de Informação e Comunicação nos processos

de ensino e aprendizagem surgiram os modelos de e-learning, processos pelos quais o aluno ou formando aprende através do conteúdo e interação proporcionados pelo computador, em particular através da Internet. Os professores ou formadores, com vários graus de interatividade, estão habitualmente em locais físicos distintos daqueles onde se encontram os alunos/formandos, utilizando a Internet como meio de comunicação (síncrono ou assíncrono), coexistindo ainda estes modelos com outros onde podem existir sessões presenciais intermédias, designados por blended learning ou b-learning (Amaral & Leal, 2004). Com o aparecimento destas práticas, surgiu a necessidade de serviços informáticos de gestão de formação que apoiassem o desenvolvimento da atividade pedagógica. Designados por Learning Management Systems (LMS), tais serviços vieram dar resposta a essa necessidade, sendo mais orientados a cenários de aprendizagem formal do que a cenários de autoaprendizagem. O crescimento da utilização destes serviços levou a um grande aumento de conteúdos pedagógicos compostos de texto, imagens, vídeos e outros recursos de multimédia. Para usufruir dessa variedade de conteúdo, de forma a tornar a sua classificação, organização e pesquisa surgiram os learning objects (LO). Neste contexto os LO permitem a criação de pequenos componentes de material pedagógico e a sua organização de forma a permitir a sua reusabilidade, poupando tempo e custo na produção de cursos. Os trabalhos de suporte a esta dissertação decorreram no âmbito da atividade profissional do autor na Portugal Telecom Inovação, e que é considerada por vários autores a instituição pioneira da introdução do e-learning a nível nacional, sendo responsável desde 1993, pela Formação Tecnológica e de Serviços (FTS) do Grupo Portugal Telecom (Barbeira, Santos, & PT Inovação, 2003). Desenvolveu um LMS que suporta soluções de formação e educação em ambientes de e-learning e b-learning, designado Formare. Como parte da expansão e aprimoramento da linha de produtos ao Formare, sugiu, no âmbito dos learning objects o projeto PoLO (Martins, 2010), uma colaboração entre a Portugal Telecom Inovação e a Universidade de Coimbra, tendo por objetivo a criação de uma solução que permitisse a criação, gestão e apresentação de learning objects. A criação e gestão dos conteúdos eram vocacionadas para os gestores e formadores, enquanto os formandos frequentavam cursos e aprendiam a partir dos conteúdos. Era também pretendido o aumento da qualidade dos conteúdos disponibilizados introduzindo a organização dos conteúdos através da catalogação e a interoperabilidade para que se tornem o mais independentes possível dos sistemas.

2

O projeto PoLO atingiu os objetivos a que se propôs, tendo sido identificadas no seguimento desse projeto algumas linhas de evolução consequentes: o sistema não tinha então funcionalidades para interação entre alunos, não tirando partido do espírito participativo da Web 2.0. Era considerado gerador de sobrecarga de informação, dificultando aos utilizadores a tarefa de encontrarem a informação que procuravam. Foi então desenvolvido pelas mesmas entidades o projeto PoLO II (Sá & Gomes, 2010), que tinha por objetivo desenvolver essas linhas de evolução, fornecendo ao aluno um conjunto de ferramentas que lhe permitissem encontrar informação mais rapidamente e ao mesmo tempo organizar os seus conteúdos. Este projeto PoLO II conseguiu desenvolver um ambiente Web 2.0 para aumentar o nível de interação entre alunos/formandos. De modo a ultrapassar algumas limitações do projeto PoLO II, ao nível de espaços de aprendizagem pessoal para o ambiente de aprendizagem colaborativa e de aprendizagem não formal, surgiu a implementação de funcionalidades que deram origem ao projeto COLOR. O projeto COLOR enquadra-se no conceito de software colaborativo na aprendizagem, pois inclui, na sua plataforma, ferramentas que possibilitam a colaboração entres os alunos/formandos e a monitorização das interações, potenciando a comunicação durante o estudo do LO de forma a guiar o processo de colaboração com o principal propósito da aprendizagem. O autor integrou uma equipa da Portugal Telecom Inovação que deu seguimento aos projetos PoLO e PoLO II (sistema COLOR). Constituindo esta circunstância uma oportunidade de analisar e refletir sobre os processos de desenvolvimento de software em contexto empresarial, o autor procedeu ao registo sistemático da sua atuação e vivência ao longo do processo. Nesta dissertação são expostos e analisados esses registos de atuação e essa vivência, enquadrados pelas características das tecnologias utilizadas e por uma reflexão teórica sobre o processo.

1.2

Objetivos
A presente dissertação teve como principal objetivo analisar e refletir sobre uma

experiência pessoal de desenvolvimento de software em contexto empresarial, visando contribuir para a melhor perceção pública dos desafios e realidades do exercício de engenharia informática nestes contextos. Para atingir este objetivo, descreve-se o novo sistema implementado (evolução do PoLO e PoLO II). Inicia-se esse processo pela definição de novas funcionalidades, cruzando a

3

identificação das limitações dos sistemas anteriores com a visão da gestão e da equipa sobre a relevância dessas novas funcionalidades. Desse processo, descrito no capítulo 3, o desafio a ultrapassar foi o desenvolvimento de raiz de um sistema que se baseasse no projeto PoLO/PoLO II, mas focado nas funcionalidades de ligação a redes sociais e espaços de aprendizagem personalizados, tendo também em consideração aspetos de aprendizagem colaborativa centrados em Learning Objects. Prossegue-se dando conta de como decorreu a especificação e desenvolvimento das novas funcionalidades identificadas. Para tal, recorre-se a registos de vários tipos: diários de apontamentos; mensagens de e-mails trocadas entre a equipa; exemplares de documentos de especificação; atas de reuniões; e documentos produzidos no âmbito do projeto (requisitos, conceção e manuais). Conclui-se efetuando uma reflexão sobre todo o processo, enquadrando as decisões tomadas e abordagens efetuadas na teoria sobre desenvolvimento de especificações e software. Reflete-se igualmente de forma crítica sobre as consequências das decisões tomadas e atos efetuados. A participação do autor no projeto terminou um pouco antes de se iniciar a fase de testes, motivo pelo qual a fase de testes não integra o registo de dados da presente dissertação.

1.3

Motivação e contribuições
Após vários anos de estudo na área técnico-científica de Engenharia Informática, o

autor deparou-se com o seu primeiro trabalho num ambiente empresarial onde tentou aplicar da melhor forma o conhecimento adquirido na universidade. Assim a nível pessoal, esta experiência vivida foi enriquecedora e merecedora de um detalhado registo, onde o autor pretende identificar lacunas de modo a auxiliar futuros casos semelhantes, na área do desenvolvimento de aplicações Web. Esta dissertação dá a conhecer todo o processo de desenvolvimento de software num ambiente empresarial e contribuirá para aqueles que irão iniciar a sua vida profissional como Engenheiros Informáticos e para as empresas que os recebem. Os futuros Engenheiros Informáticos ficam a conhecer a experiência vivida na primeira pessoa, com identificação de problemas e as diferentes formas como os mesmos foram ultrapassados. As empresas conhecem do ponto de vista do trabalhador as dificuldades que o mesmo encontra e assim

4

podem tentar ajustar a organização e/ou os métodos de trabalho para que o processo de desenvolvimento de software se torne mais produtivo e eficaz.

1.4

Estrutura
A estrutura do documento está organizada em oito capítulos: A presente introdução e

os seguintes: • Capítulo 2 – Enquadramento tecnológico Apresentam-se as definições dos conceitos mais relevantes relacionados com o projeto, incluindo o estado atual ao nível do desenvolvimento na área dos repositórios de Learning Objects, expondo de forma comparativa alguns trabalhos na área. • Capítulo 3 – Projeto COLOR
Descreve-se o projeto cujo desenvolvimento gerou os dados de suporte a esta dissertação, o COLOR. Resume-se a metodologia adotada, os requisitos e a arquitetura final do sistema, as suas três camadas: aplicação, apresentação e dados.

Capítulo 4 – Método de investigação Apresentam-se os métodos utilizados para a recolha de dados e análise dos mesmos. Explicita-se de que forma esse processo sustenta uma reflexão sobre a prática de atos de engenharia informática em contexto empresarial.

Capítulo 5 – Vivência de desenvolvimento de software a nível empresarial Descrevem-se as dimensões que caracterizam a experiência de

desenvolvimento de um software a nível empresarial, nomeadamente as pessoas envolventes, a hierarquia da organização, as necessidades do projeto, as dinâmicas de colaboração intra-grupo e o ambiente tecnológico e profissional de atuação. De seguida, descrevem-se os dados recolhidos durante o processo, explicitando a sua relação com a evolução do projeto. • Capítulo 6 – Análise À luz da literatura de enquadramento do capítulo 2 são analisados os dados (descritos no capítulo 5), para proporcionar uma visão crítica do processo. • Capítulo 7 – Conclusões

Com base na análise efetuada no capítulo 6, efetua-se uma reflexão sobre as consequências dessa análise para uma melhor perceção da natureza do desempenho de atos

5

de engenharia informática em contexto empresarial, incluindo recomendações para melhoria do processo.

6

CAPÍTULO 2: ENQUADRAMENTO TECNOLÓGICO
Este capítulo apresenta o estado da arte relativamente aos repositórios de LO já existentes no mercado ou em fase de desenvolvimento, assim como a apresentação de conceitos associados ao e-learning, entre normas, especificações e modelos de referência. São apresentadas algumas plataformas de ensino e aprendizagem e é feito um levantamento sobre Personal Learning Environments, devido à sua importância no aspeto colaborativo. E ainda no contexto da colaboração, são descritos alguns trabalhos relevantes na área da aprendizagem colaborativa.

7

2.1

Plataformas de ensino e aprendizagem
O crescente aumento do uso das novas tecnologias juntamente com a necessidade de

se aprender o mais rápido possível torna cada vez mais o ensino à distância, ou e-learning, uma ferramenta útil nos dias atuais. São usadas as plataformas de ensino e aprendizagem para centralizar a atividade pedagógica de todo o ensino à distância. Permitem gerir a aprendizagem dos alunos, dos conteúdos, personalizar a aprendizagem de acordo com as necessidades dos alunos, eliminar barreiras de espaço e tempo, e ainda incentivar e promover a partilha de conhecimento. As plataformas de ensino e aprendizagem são divididas em três categorias: os LMS (Learning Management System), LCMS (Learning Content Management Systems) e PLE (Personal Learning Environment). Estes sistemas são essenciais nos processos de e-learning e b-learning e são usados por muitas instituições de carácter educativo e/ou formativo.

2.2.1

Learning Management Systems

Um sistema de gestão de aprendizagem é definido como um sistema usado para a administração, documentação, monitorização, planeamento e descrição de programas de formação e aprendizagem, eventos online e em salas de aula, programas de e-learning e conteúdo de treino ou seja, de todos os eventos de aprendizagem dentro de uma organização (Ellis, 2009). De um ponto de vista mais prático é uma aplicação Web que permite a gestão de processos de formação/aprendizagem nas perspetivas administrativas e pedagógica, ou seja, permite, do ponto de vista administrativo, a gestão de turmas e calendários, alocação de formadores, gestão de planos de formação, e, do ponto de vista pedagógico, ao formador o planeamento e gestão de cursos e de conteúdos de aprendizagem, aos alunos o acesso aos materiais de formação, a atividades, a avaliação das suas competências. Permitem a comunicação entre o formador e os formandos através de ferramentas tecnológicas de comunicação como chats, e-mail, videoconferências, etc. De seguida são apontados alguns sistemas de gestão de aprendizagem existentes.

Formare LMS O Formare é uma solução de formação e educação de e-learning e b-learning, desenvolvido pela PT Inovação, em ambientes Internet/Intranet.

8

Existem várias formas e modelos de ensinar ou formar em ambiente e-learning. Cada organização tenta seguir um modelo próprio de forma a encaixar os seus processos e alcançar os seus objetivos. A pensar na multiplicidade de perfis dos seus parceiros, a PT Inovação identifica cinco componentes principais em sistemas e-learning: • A difusão de materiais pedagógicos (conteúdos formativos e informativos) em diversos formatos; • • A disponibilização de serviços intuitivos e inovadores para os professores; A interação eficaz e intuitiva com o utilizador, tanto ao nível dos alunos como dos professores; • • O acesso fácil à tecnologia (plataforma); Avaliação da formação.

FIGURA 1 - COMPONENTES DE UM SISTEMA DE E-LEARNING (PEREIRA, 2011)

Para que um curso de formação seja dado com sucesso em ambiente de e-learning a PT Inovação considera importante garantir e conceber o mesmo tendo em conta cinco componentes estratégicos (Figura 1). Tentando desta forma, minimizar a incerteza relativa aos resultados pedagógicos dos cursos de e-learning e a qualidade dos mesmos. Algumas das principais características de LMS Formare (Pereira, 2011): • • • Visualização da plataforma em português e inglês; Possibilita customizações à medida; Permite uma gestão flexível de recursos para e-learning, para b-learning e para apoio a aulas presenciais;

9

• •

Disponibiliza serviços síncronos e assíncronos para ensino a distância; Possibilita a criação, gestão e difusão de conteúdos formativos e informativos em diversos formatos, normalizados e não normalizados;

É certificado pela ADL (Advanced Distance Learning) e segue as recomendações do standard SCORM 1.2;

Moodle O Moodle1 (Modular Object-Oriented Dynamic Learning Enviroment) é um LMS de código aberto, livre e gratuito, que os utilizadores podem usar, modificar e distribuir seguindo apenas os termos estabelecidos pela licença GNU Public License. Foi lançada a primeira versão, em 1999, pelo australiano Martin Dougiamas, quando este era webmaster da Curtin – Universidade de Tecnologia em Perth, sendo também gerente do sistema WebCT (Sistema de Ensino à distância – comercializado pela Blackboard). O sistema Moodle está em constante desenvolvimento pela comunidade que abrange pessoas de várias partes do globo, professores, formadores, investigadores, programadores, administradores de sistemas. Este conjunto de pessoas centraliza as informações, discussões e colaborações no portal Web. Além disso o portal conta um relatório de perguntas frequentes, suporte gratuito, orientações para a realização do download e a instalação do software, documentação e a descrição de futuras atualizações para o sistema. Para além do uso do sistema de forma mais frequente em universidades, é ainda usado por todos que têm necessidade de interagir de forma colaborativa pela Web, tais como escolas, instituições privadas, pessoas e grupos independentes. A plataforma é utilizada principalmente no contexto do e-learning e b-learning, permitindo a criação de cursos on-line, páginas de disciplinas, grupos de trabalho e comunidades de aprendizagem (ColaboraCom).

Blackboard Learning System A plataforma Blackboard Learning System2 é um sistema de gestão de aprendizagem baseado na Web desenvolvido e proprietário da Blackboard Inc.

1

http://moodle.org/ http://uki.blackboard.com/sites/international/globalmaster/

2

10

Como potenciais benefícios no uso desta plataforma são destacados os seguintes (Bradford, Porciello, Balkon, & Backus, 2007): • Grande disponibilidade. É possível aceder ao sistema através da Internet em qualquer sítio ou em qualquer momento; • • Rápido feedback; Comunicação melhorada. Existem várias formas de comunicação na plataforma: Anúncios, como sendo uma forma geral de comunicar entre a instituição de ensino e os alunos, assegurando que todos recebem a informação corrente e minimizando o trabalho administrativo da instituição; Discussões, é possível a criação de discussões dentro de um curso, onde o aluno pode colocar uma pergunta sobre o mesmo e os restantes podem responder, sob a vigilância do educador, incentivando assim a participação dos alunos; Sala virtual, como sendo um ambiente síncrono de conversas permitindo a interação entre os participantes; • Tracking. O sistema rastreia o percurso dos alunos nos cursos e coloca os resultados numa área de estatísticas de cursos. Assim os educadores podem obter as estatísticas sobre todos os alunos ou sobre alunos individuais dentro de um curso. Os mesmos autores associam alguns problemas à plataforma Blackboard, como o facto da dificuldade de aprender, ter algumas que são restritas a sistemas operativos específicos, ser ineficiente no uso da banda larga, particularmente quando os materiais têm que ser descarregados e ainda o custo elevado do software.

2.2.2

Learning Content Management System

Um sistema de gestão de conteúdo está relacionado com os LMS, mas o seu foco reside na criação, gestão e publicação do conteúdo que é utilizado pelos LMS (Greenberg, 2002). Podemos considerar que os LCMS produzem conteúdos digitais para serem posteriormente disponibilizados e explorados pelos utilizadores de ambientes LMS. Oferecem aos autores, instrutores e entendidos nas matérias meios para criar conteúdos mais eficientemente. Estes conteúdos digitais de aprendizagem podem ser apresentados na forma

11

de por exemplo: texto, vídeo, ilustrações, slides, demos, etc. e são apelidados de objetos de aprendizagem (Learning Objects), apresentados na secção 2.2. Um LCMS guarda objetos de aprendizagem num repositório central para que os designers educativos, pessoas que desenvolvem conteúdo multimédia de aprendizagem, os possam ir buscar a anexar em cursos personalizados com a ajuda dos professores. Os cursos tradicionais contêm mais conteúdos sobre um tópico, do que aquelas que o aluno apenas consegue ou precisa assimilar. Ao dividir esses conteúdos dos cursos em objetos de aprendizagem, disponibilizando-os de acordo com as necessidades, os especialistas que desenvolvem conteúdos podem beneficiar da aprendizagem na hora e na dose certa, evitando desenvolver cursos inteiros e de os adaptar a audiências múltiplas. Isto elimina esforços de desenvolvimento repetidos e permite a rápida agregação de conteúdo personalizado (Greenberg, 2002). No mercado encontram-se algumas soluções comerciais de gestão de conteúdo: Xyleme LCMS3, OutStart4, GeoLearning LCMS5, Kenexa LCMS6. O ATutor7 é uma solução open source baseada na Web para a gestão de conteúdo que já adotou a norma de empacotamento de conteúdo IMS e a norma SCORM, permitindo assim que os criadores criem conteúdo reutilizável entre sistemas de e-learning diferentes.

2.2.3

Personal Learning Enviroments

A existência de uma série de abordagens e perspetivas de vários autores tornam difícil chegar a uma única definição estável deste conceito que agrupe toda essa diversidade. Foi tomada em conta a perspetiva de (van Harmelen, 2006), sobre a área dos Personal Leaning Enviroments (PLE). Este autor define os PLE como sistemas que ajudam os alunos a controlar e gerir a sua própria aprendizagem. No trabalho desenvolvido na Universidade de Manchester, em Design trajectories: four experiments in PLE implementation, (van Harmelen, 2008) considera os PLE parte de um ecossistema de aprendizagem, o qual é constituído por todos os recursos disponíveis para o

3

http://www.xyleme.com/product/lcms http://www.outstart.com/ http://www.aura-infotech.com/lcms.htm http://www.kenexa.com/Solutions/Learning/LearningContentManagementSystems http://atutor.ca/index.php

4

5

6

7

12

aluno, incluindo colegas e professores, e materiais em diversos suportes e formatos. Fazem parte ainda desse ecossistema partes baseadas na tecnologia, como browsers, programas cliente, servidores e serviços Web, dispositivos móveis, etc. Van Harmelen considera que os PLE mais do que um software são um conceito. O conceito de que cada utilizador gera o um ambiente pessoal onde várias peças tecnológicas interagem e não apenas uma criada especificamente para ser um PLE, é o resultado dos atos dos utilizadores. Identifica que os PLE são fundamentados pela necessidade de um sistema que ofereça aos alunos um padrão ao nível da interface mas com os diferentes sistemas de e-learning das intuições, a abordagem pedagógica que defende que os sistemas de e-learning devem ser centralizados e controlados pelos “aprendentes”, e a necessidade que os alunos por vezes têm de trabalhar offline.

2.2

Learning Objects
Os documentos em papel e os materiais de vídeo, áudio e imagem, com o avanço da

tecnologia têm sido transformados em documentos digitais. Atualmente há diversos conteúdos digitais disponibilizados nas plataformas de ensino e aprendizagem (secção 2.1), que proporcionam de maneira prática as condições indispensáveis para que estudantes, professores e formadores os utilizem. Esses conteúdos digitais, quando descritos segundo padrões denominados metadados como “materiais de aprendizagem online” (MERLOT) reutilizáveis, são conhecidos como learning objects (LO). Os LO devem ser reutilizáveis e independentes da plataforma, de modo a resolverem os problemas relacionados com a falta de flexibilidade dos sistemas de e-learning. É necessário que os sistemas disponibilizem conteúdos de tamanho reduzido e que ofereçam rapidez e simplicidade aos utilizadores. Não existe um conceito definido para o termo “learning object”, sendo diferente entre autores e organizações: “Qualquer recurso digital que pode ser reutilizado como apoio à aprendizagem” (Wiley, 2002); “Qualquer entidade, digital ou não, que pode ser utilizada, reutilizada ou referenciada durante o processo de aprendizagem que utilize tecnologia” (IEEE, 2002); “Um arquivo digital (imagem, filme, etc.) destinado a ser utilizado para fins pedagógicos e que possui, internamente ou através de associação, sugestões sobre o contexto apropriado para a sua utilização” (Sosteric & Hesemeier, 2002);

13

“Unidade de conteúdo de aprendizagem independente e auto-compreensível que está predisposta a ser reutilizada em múltiplos contextos instrutivos” (Polsani, 2003). Vários autores corroboram a posição de que independentemente do tipo de aplicação educativa, os LO apresentam as seguintes características (Longmire, 2001): Reusabilidade: o LO pode ser usado em diversas plataformas de aprendizagem diferentes; Facilidade de atualizações, pesquisas e gestão do conteúdo: com a utilização dos padrões de metadados existentes é possível obter informações sobre os learning objects, como o seu conteúdo utilização, autor, tamanho, formato, e outras, tornando-o compreensível para diversas plataformas; Modularidade: um learning object pode conter outros learning objects, ou estar contido em um ou mais materiais de aprendizagem. Deve ser construído de forma que os utilizadores não necessitem de saber os seus componentes ou sobre a sua complexidade interna; Interoperabilidade: um LO deve ser capaz de ser utilizado em diversos tipos de hardware, sistemas operativos, browsers, ou outros ambientes de aprendizagem.

2.3

Metadados
Frequentemente encontra-se na literatura que metadados significa “dados sobre

dados”, sendo esta definição partilhada por vários autores. Em (Équille, 2004) essa definição é alargada, indicando que os metadados devem estruturar os dados para que possam ser usados como dicionários quando é necessário usar os dados neles contidos. Vários autores referem que os metadados fornecem informações sobre um determinado recurso, de forma a promover a interoperabilidade, pesquisa, partilha, integração, utilização/reutilização, gestão e localização dos mesmos de maneira mais eficiente. Os metadados são um conjunto de palavras, frases que resumem ou descrevem o conteúdo de um site, uma página Web ou um recurso digital com o objetivo de beneficiar o trabalho de agentes de pesquisa (Babu, 2001). Existem várias iniciativas de empresas e organizações para a conceção e implementação de metadados para LO: DCMI8 (Dublin Core Metadata Iniciative), LOM

8

http://dublincore.org/

14

(Learning Object Metadata) (IEEE, 2002), IMS9 (Instructional Management System), SCORM10 (Scharable Content Object Reference Model).

2.4

Repositórios de Learning Objects
De modo a evitar um aumento dos LO de forma desorganizada foram criados os

repositórios de learning objects, destinados ao armazenamento e gestão dos mesmos e à sua disponibilização na Internet. Os repositórios contribuem para a melhoria da reutilização dos LO, pois facilitam na sua organização e a catalogação. São ainda entendidos como estruturas de encaixe para os learning objects, para que os mesmos sejam acoplados e interligados. Os repositórios de LO permitem submeter, armazenar e pesquisar Learning Objects. Um repositório digital diferencia-se de outras coleções digitais pelas seguintes características (Heery & Anderson, 2005): • O conteúdo é depositado num repositório seja pelo criador do conteúdo, detentor do conteúdo ou por terceiros; • • A arquitetura do repositório gere o conteúdo assim como metadados; O repositório oferece um conjunto mínimo de serviços básicos, como por exemplo put, get, pesquisa e controlo de acesso; • O repositório deve ser sustentável e confiável, bem suportado e bem gerido.

Repositórios de LO existentes
MERLOT
O MERLOT11 (Multimedia Educational Resource for Online Learning and Teaching) foi um projeto que começou com algumas universidades do estado da Califórnia (USA) e cresceu incorporando as grandes universidades norte-americanas. Atualmente é constituído por um consórcio internacional que permite a partilha de recursos online de alta qualidade e que pretende melhorar a aprendizagem e o ensino dentro do ensino superior. Tem como objetivo aumentar a eficiência do ensino e aprendizagem, expandindo a quantidade e a qualidade de materiais de aprendizagem online. É uma ferramenta de software baseada na Web e

9

http://www.imsproject.org/ http://www.adlnet.org/scorm/scorm-version-1-2/ http://www.merlot.org/

10

11

15

desenhada dinamicamente para suportar o desenvolvimento de comunidades de ensino e de aprendizagem, coleções, serviços, e pesquisa no ensino superior. O sistema não armazena os objetos propriamente ditos, mas somente os metadados, acrescentando um link para os URL dos objetos.

WISC-ONLINE
O Wisc-Online12 ou Wisconsin Online Resource Center é uma biblioteca digital de recursos de aprendizagem baseados na Web, nomeadamente LO. A biblioteca digital de objetos tem sido desenvolvida principalmente no Wisconsin Technical College System (WTCS) e produzida por técnicos multimédia, designer, editores e estudantes. Todos os objetos estão disponíveis gratuitamente para a comunidade da faculdade. E os professores podem utilizá-los nas aulas.

PoLO e PoLO II
O PoLO, Portal de Learning Objects, já mencionado na introdução, é um projeto que resultou da uma parceria entre a PT Inovação e pela Universidade de Coimbra, com o propósito da exploração de técnicas e metodologias de integração e gestão do conhecimento para a geração de Learning Objects (Martins & Gomes, 2009). Permite a criação, gestão e apresentação de learning objects assente numa lógica de autoformação e de ensino à distância. Pretende aumentar o potencial dos conteúdos disponibilizados, na sua catalogação, interoperabilidade e reutilização. Por fim, o visou a integração com o Formare LMS, mencionado na secção 2.2.1, capacitando-o para disponibilizar conteúdos na forma de Learning Objects. Foi então criado um sistema que oferece soluções quanto às carências na área da aprendizagem à distância, através de um ambiente simplificado, prático, onde são disponibilizados conteúdos sob a forma de Learning Objects, potenciados por uma classificação baseada em conceitos e etiquetas, e compatíveis com a norma SCORM. Para a descrição dos metadados, o PoLO é baseado na norma SCORM, trazendo esse fato vantagens ao nível da interoperabilidade, isto é, da possibilidade da utilização de conteúdos em locais diferentes, e da reutilização, ou seja, da possibilidade de utilizar conteúdos em contextos distintos e com objetivos completamente diferentes.

12

http://www.wisc-online.com/

16

COLOR
O sistema PoLO II apesar das suas qualidades, apresentava algumas limitações. Por exemplo, a aplicação não suportava aprendizagem colaborativa, não existindo qualquer tipo de funcionalidade que permitisse a interação entre alunos, como fóruns e mensagens instantâneas, por exemplo. Estas limitações deveram-se às prioridades do PoLO terem envolvido sobretudo a criação e execução de LO, de forma rápida e simplificada, visto ser essa a principal necessidade do mercado (PT Inovação, 2011). Devido à identificação de algumas destas limitações surgiu o projeto COLOR (Collaboration Learning Objects Repository) que tem como principal objetivo acrescentar a dinâmica da aprendizagem colaborativa ao anterior projeto. O projeto COLOR tem também um portal completamente novo, com um design mais moderno e apelativo para a experiência do utilizador. No capítulo 3, na secção 3.2 descreve-se o projeto em detalhe.

2.5

Software colaborativo
A área que envolve o estudo de sistemas baseados em computador que auxiliam o

trabalho cooperativo é conhecida por CSCW (Computer Supported Collaborative Learning). Portanto, o software colaborativo pode ser considerado uma ferramenta desenvolvida a partir dos conceitos abordados em CSCW. Alguns investigadores usam o termo CSCW para expressar a ideia de colaboração entre um grupo de pessoas usando computadores (Howard, 1988; Kling, 1991), onde o foco é centrado na aprendizagem do grupo de participantes como um todo. De acordo com (Bannon & Schmidt, 1991) CSCW é o apoio fornecido pelo computador para múltiplos indivíduos trabalharem em conjunto, no entanto, não basta juntar um grupo de indivíduos para que estes trabalhem efetivamente. É necessário fornecer mecanismos para que estes aprendam a colaborar entre si. É preciso aprender a colaborar para posteriormente colaborar para aprender (Burton, Brna, & Treasure-Jone, 1997). O conceito de software colaborativo ou groupware refere-se ao desenvolvimento de tecnologias que suportam o modo como as pessoas comunicam e colaboram para cumprir metas de trabalho no contexto de processos pessoais, organizacionais e de gestão (Ehrlich, 1999).

17

Software colaborativo na aprendizagem
De modo a ultrapassar a barreira da distância e com a evolução das Tecnologias de Informação e Comunicação, os utilizadores começaram a usar os sistemas para trabalharem em grupo. O que também se refletiu na educação, onde a houve um crescimento do uso das TIC na aprendizagem em grupo, e onde esta se tem mostrado eficiente (Dillenbourg, Baker, Blaye, & O'Malley, 1996). Atualmente existem vários sistemas colaborativos disponíveis a nível comercial. Estes sistemas dispõem unicamente de ferramentas arbitrárias para a comunicação. É necessário mais do que isso para que exista colaboração entres os participantes. Podemos auxiliar o processo de colaboração incluindo o mesmo no projeto dos sistemas e cursos, ou monitorizando a interação, e guiando o processo conforme necessário (Dillenbourg, 1999). O projeto COLOR implementa alguma monitorização da interação dos intervenientes, de modo a tentar analisar o histórico das interações e um diagnóstico dos pontos fortes e fracos.

2.6

Metodologia de desenvolvimento de software
O processo de software refere-se a um conjunto de ferramentas, métodos e práticas

usadas para produzir um produto de software (Humphrey, 1989). O processo utilizado para desenvolver e manter o software afeta de forma significativa o custo, qualidade e prazo de entrega do produto. O impacto é tão significante que a melhoria do processo de software é vista por alguns como a mais importante forma para melhorar o produto de software (Henry, Henry, Kafura, & Matheson, 1994). O processo de desenvolvimento de software consiste nas atividades e na informação associada que é necessária para o desenvolvimento de um software. Todas as organizações têm um próprio processo para o desenvolvimento de software mas normalmente estas abordagens são baseadas em um dos modelos genéricos: modelo em cascata, modelo iterativo, modelo em V, modelo em espiral (Ribeiro, 2008). O fracasso de vários projetos de software de alto nível na década de 60 levou à criação de um processo de um ciclo de vida do software. O modelo de ciclo de vida inicial, (Royce, 1970) denominado modelo em cascata, consiste numa série de etapas sequenciais, começando com a especificação do sistema.

18

Análise de requisitos

Especificação

Implementação

Integração

Teste

Instalação

Manutenção

FIGURA 2 - FASES DO MODELO EM CASCATA

Para o desenvolvimento do pro projeto de suporte à presente dissertação, foi seguido este modelo devido a ser fácil de implementar e perceber, ser muito usado e conhecido, consolida bons hábitos: definir antes de desenhar e desenhar antes de de definir finir e define entregas e metas (Munassar Munassar & Govardhan, 2010 2010). Este modelo foi oi definido pela equipa, sendo já o método utilizado pela PT Inovação para o desenvolvimento dos seus projetos.

2.7

Norma SCORM
Durante o desenvolvimento do projeto de suporte à presente dissertação, dissertação no que diz

respeito ao desenvolvimento do dos conteúdos foi utilizada a norma SCORM. A norma SCORM (Sharable Content Object Reference Model; ADLI, 2001a) 2001 define um modo de agregação de conteúdos, um ambiente de execução e sequenciamento e navegação learning objects. É um conjunto de padrões e especificação para e-learning earning baseado em tecnologia Web. O modelo surgiu do Departamento de Defesa dos EUA como resultado às necessidades de educação do governo, da indústria e na da academia estabelecendo a iniciativa Advanced Distributed Learning13 (ADL), em 1997. Esta inicia iniciativa tiva definiu requisitos de alto nível para conteúdo de aprendizagem, tal como reutilização, acessibilidade, durabilidade e interoperabilidade para melhorar práticas existentes, promover o uso de aprendizagem baseada em tecnologia e fornecer uma base económ económica ica para o investimento. A versão chamase SCORM 2004, datando a sua mais recente edição (4.ª) de 2009. O SCORM aplica desenvolvimentos de tecnologia atuais, como as desenvolvidas pelo IMS Global Learning Consortium, Inc., o Aviation Industry CBT Committee, o Alliance of Remote Instructional Authoring & Distribution Networks for Europe (ARIADNE) e o Institute of Electrical

13

http://www.adlnet.org/

19

and Electronics Engineers (IEEE) Learning Technology Standards Committee (LTSC), para um modelo de conteúdo específico de modo a produzir recomendações para implementações consistentes pela comunidade. A implementação da norma SCORM visou dar ao PoLO interoperabilidade, isto é, a possibilidade da utilização de conteúdos em locais diferentes, e reutilização, ou seja, a possibilidade de utilizar conteúdos distintos e com objetivos completamente diferentes (Martins & Gomes, 2009).

20

CAPÍTULO 3: PROJETO COLOR
Neste capítulo é apresentado em detalhe o projeto COLOR. Descreve-se a metodologia de desenvolvimento adotada, a arquitetura, os perfis de utilizadores, a especificação e as funcionalidades implementadas. A arquitetura do projeto é baseada num projeto anterior (designado PoLO II, secção 0), sendo composta por três camadas principais: camada de dados; camada de negócio; e camada de interface. As funcionalidades implementadas surgem da vontade de ir além das limitações do anterior projeto PoLO II e focam-se em três áreas principais: a ligação a redes sociais; ligação a espaços de aprendizagem colaborativos; e a introdução de mecanismos de apoio à aprendizagem pessoal.

21

3.1

Metodologia adotada
3.1.1
PT Inovação

Equipa

Universidade1

Chefe de departamento

Gestor de equipa (Parte técnica)

Gestora de equipa

Gestor de equipa (Professor)

Programador1

Programador2 (Tempo Parcial)

Designer

Programador3 (Aluno)

FIGURA 3 - ORGANIGRAMA DA EQUIPA

A equipa do projeto foi constituída por dois grupos: o grupo da PT Inovação e o grupo de uma universidade portuguesa (Universidade1, U1). O organigrama acima mostra esquematicamente os distintos níveis de hierarquia e a relação entre eles durante o desenvolvimento de todo o projeto. Na parte da PT Inovação o chefe de departamento era o responsável principal por todo o projeto, seguido na hierarquia dos dois gestores. A gestora da equipa era a responsável ativa sobe os três elementos de trabalho. E o gestor de equipa da parte técnica era responsável e acompanhava todo o trabalho de implementação do código do projeto. Na parte da universidade o gestor de equipa (professor) era o responsável pelo "Programador3", orientando o mesmo durante o desenvolvimento do projeto. O programador1 e o programador3 estiveram ativos no decorrer de todo o projeto, sendo que o programador2 apenas interagiu numa etapa final do desenvolvimento para ajudar a concluir o projeto no tempo definido. A designer foi responsável pelo desenho da interface gráfica do protótipo, definindo também juntamente com os programadores a estrutura da mesma.

22

3.2 Descrição do projeto
O projeto COLOR nasceu a partir das limitações e problemas identificados pela equipa no anterior projeto PoLO II, apresentados no capítulo 5. Destas limitações e da intenção de evoluir a partir do projeto PoLO II nasceu o novo projeto para o qual a equipa definiu os requisitos a implementar, apresentados na secção 3.5 do presente capítulo. O novo sistema foi designado COLOR (COllaboration Learning Objects Repository) e as funcionalidades focaram-se em cinco grandes áreas: a) A análise e construção do perfil de utilizador, tendo em particular atenção a forma como este interage com a rede de contactos (Polsani, 2003); b) Desenvolvimento de mecanismos que permitam ao utilizador pesquisar e encontrar a informação desejada rapidamente, através de técnicas de information retrieval: c) Construção de ferramentas que impulsionem a colaboração entre os utilizadores do sistema, melhorando o ambiente Web 2.0 do PoLO II: d) Desenvolvimento de ferramentas que possibilitassem a participação do aluno na definição de conteúdos. Considerou-se relevante que o aluno sentisse que o seu papel ativo seria fundamental para o crescimento do conteúdo do sistema: e) Criação de funcionalidades de apoio à atividade pedagógica que a equipa considerasse relevantes. O COLOR adotou o seguinte processo de apoio à especificação e desenvolvimento: • Estudo de vários sistemas de Learning Objects para a formação profissional, como suporte à formação formal e informal; • Especificação e desenvolvimento de um protótipo do modelo de colaboração a implementar sobre o PoLO II; • Realização de testes à plataforma.

3.3

Casos de uso
Os diagramas de casos de uso têm sido uma das atividades da fase inicial do processo

de desenvolvimento de software (orientado a objetos) e representam os requisitos funcionais do sistema. Esta representação é composta por atores, casos de uso e associações entre eles. Os casos de uso representam as funcionalidades de um sistema (OMG, 2013).

23

Quando existem vários casos de uso ou atores é possível usar os packages (pacotes) de casos de uso para organizar o modelo. Excetuando o package da “Gestão dos LO” (Figura 8), os restantes casos de uso foram consultados nos relatórios de especificação dos anteriores projetos: PoLO (PT Inovação, 2010) e PoLO II (PT Inovação, 2011). Na Figura 4 é mostrado o diagrama geral de casos de uso do sistema. É mostrado através de packages as principais ações dos vários tipos de perfil de utilizador, através da representação de atores. O “Utilizador do sistema” e o “Convidado” são generalizações do ator abstrato “Utilizador”. E os atores: “Administrador”, “Coordenador/Professor”, “Gestor de conteúdos” e “Aluno” são generalizações do “Utilizador do sistema”.

Utilizador

Estudo dos LO Utilizador do sistema Convidado

Consulta do sistema

Administrador

Coordenador/Professor

Gestor de conteúdos

Aluno

Gestão dos utilizadores

Gestão dos Conteúdos dos LO

Gestão dos LO

FIGURA 4 - PERFIS DE UTILIZADOR

24

3.3.1 Package “Consulta do sistema”
Ao autor deixou a equipa antes de serem esclarecidas as ações concretas que o perfil de convidado poderia fazer no sistema, apenas foi falado que o “convidado” tem acesso ao sistema e que pode pesquisar por LO.

Consulta do sistema

Efetuar login

Pesquisar por LO Convidado

FIGURA 5 - CASOS DE USO DA CONSULTA DO SISTEMA

3.3.2 Package “Gestão dos utilizadores”
Para os casos de uso da gestão dos utilizadores (Figura 6) a equipa de desenvolvimento apenas interagiu sobre a camada de apresentação construindo as páginas onde o administrador gere os utilizadores, fazendo invocação aos métodos da camada de aplicação. Como exemplo é apresentada na Figura 7, a página da listagem dos utilizadores do sistema, referente ao caso de uso “Listar utilizadores”.

25

Gestão dos utilizadores

Adicionar utilizador

Remover utilizador Administrador Listar utilizadores

Editar utilizador

FIGURA 6 - CASOS DE USO DA GESTÃO DOS UTILIZADORES

26

FIGURA 7 - LISTAGEM DOS UTILIZADORES

3.3.3 Package “Gestão de conteúdo do LO”
Também para os casos de uso da gestão de conteúdo do LO ( (Figura Figura 8) a lógica da camada de dados e da camada de aplicação já estava construída. Salvo algumas alterações, a equipa apenas interagiu com a camada de apresentação construindo as páginas necessárias para os casos de uso. Como exemplo é apresentada na Figura 9 a página da listagem das áreas temáticas do caso de uso “Listar áreas temáticas”, e caixa de texto para o utilizador pesquisar do caso de uso “Pesquisar por área temática”.

27

Gestão de conteúdo do LO Inserir área temática Listar áreas temáticas <<extend>> <<extend>> <<extend>> Gerir áreas temáticas <<extend>> Pesquisar área temática Remover área temática

<<extend>>

Gestor de Conteúdos

Associar gestor a área temática

Gestão do cursos

<<extend>> <<extend>>

<<extend>>

Criar curso

Listar cursos

Remover curso

FIGURA 8 - CASOS DE USO DE GESTÃO DE CONTEÚDO DO LO

28

FIGURA 9 - LISTAGEM DE ÁREAS TEMÁTICAS

3.3.4 Package “Gestão do LO”
Os requisitos implementados pela equipa foram mais direcionados para gestão e estudo do LO. Nos casos de uso apresentados na Figura 10 a equipa interagiu nas três camadas cam da arquitetura alterando e implementando os requisitos assinados.

29

RF 1

Gestão de LO
P esquisar de for ma avançada

P esuisar por LO <<extend>>

Utilizador RF 4 <<include>> Rever LO A tr ibuir uma nota

RF 10 <<include>> C r iar LO V alidar LO

<<extend>> RF 11 C r iar LO com objetivo de par tilha T ir ar notas A luno

RF 16

<<extend>> T ir ar notas ger ais

Submeter LO

<<extend>>

RF 20 Fazer like a um LO

T ir ar notas associadas a um LO

FIGURA 10 - CASOS DE USO DA GESTÃO DO LO

3.4

Perfis de utilizadores
A equipa adotou os mesmos tipos de perfis de utilizador do sistema PoLO II

para o COLOR, mantendo as funções de cada um, e adicionou o perfil de convidado:
• Administrador - o qual faz a gestão de todo o sistema, em especial dos vários utilizadores; • Gestor de conteúdos - é responsável pelos conteúdos dos LO, fazendo a validação e classificação dos mesmos; • Coordenador/ Professor - faz a gestão dos LO, apenas podendo efetuar operações básicas sobre os mesmos: criação, remoção e edição; • • Aluno - perfil que faz a visualização, estudo, pesquisa e criação de LO; Convidado - apenas pode visualizar o sistema não podendo criar LO.

30

3.5

Requisitos funcionais
Esta secção apresenta os requisitos definidos até à data em que o autor deixou o

projeto e a informação apresentada foi consultada nos documentos de análise de requisitos funcionais definidos no âmbito do mesmo.

31

Perfil do Utilizador

•O O sistema deve registar os LOs visualizados por um utilizador •Um Um Utilizador deve ter uma página pessoal

Encontrar a informação desejada

•O O sistema deve sugerir LOs aos alunos; • O utilizador deverá poder pesquisar por LOs

Colaboração entre utilizadores

•O O sistema deve disponibilizar um fórum de discussão associado a cada LO •O sistema deve disponibilizar um chat associado a cada LO •Um Um utilizador deve poder comunicar através de mensagens com outros utilizadores •Um utilizador deve poder fazer Like a um LO •Um Um utilizador deve ter uma página pessoal

Participação do aluno nos conteúdos

•Um aluno deve poder submeter LOs •Um Um aluno deve poder sugerir novos temas para LOs

Apoio à atividade pedagógica

•O O sistema deve fornecer gestão global de notas pessoais •O O sistema deve enviar notificações de novas versões de LOs aos utilizadores Um concetor deve poder indicar se um LO •Um está apto para um ambiente móvel ou não •Um Um utilizador poderá ter o perfil de convidado •Um Um utilizador deverá ter uma data de validade •Um utilizador deve poder validar LOs •Um Um utilizador poderá criar LOs que tenham como objetivo a partilha de informação e não sejam formativos

FIGURA 11 - ÁREAS DOS REQUISITOS FUNCIONAIS

Como foi descrito na secção 3.2, , os requisitos definidos para o projeto podem ser agrupados em cinco áreas. Estes requisitos foram definidos mediante os problemas e as limitações apresentadas na secção 5.4.

32

A primeira área é centrada no perfil do utilizador e na forma como este interage com a sua rede de contactos e com os seus LO, nesta área é apresentado: • • • • • O perfil do utilizador; Os seus contactos; Contactos que seguem o utilizador; Os contactos que o utilizador segue; As competências que o utilizador já obteve através do estudo dos LO.

A segunda área consiste no desenvolvimento de mecanismos que permitam ao utilizador pesquisar e encontrar a informação desejada rapidamente, usando técnicas de information retrieval. A terceira área engloba os requisitos que impulsionam a colaboração entre os utilizadores do sistema. A quarta área consiste no desenvolvimento de ferramentas que possibilitem a participação do aluno na definição de conteúdos.

A quinta e última área consistem na criação de funcionalidade que apoiem a atividade pedagógica do sistema.

A seguinte tabela apresenta todos os requisitos funcionais.

Código
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10

Descrição
O utilizador deverá poder pesquisar por LO O sistema deve sugerir LO aos alunos O sistema deve disponibilizar um fórum de gestão associado a cada LO Um utilizador deve poder rever LO O sistema deve disponibilizar um chat associado a cada LO Um utilizador deve poder comunicar através de mensagens com outros utilizadores Um utilizador deve poder seguir ações de outros utilizadores O sistema deve registar os LO visualizados por um utilizador O sistema deve apresentar aos utilizadores os LO mais populares Um utilizador poderá criar LO que tenham como objetivo a partilha de informação e não sejam formativos

RF11 RF12 RF13

O sistema deve fornecer gestão global de notas pessoais Os LO devem ser validados antes de estarem disponíveis para os alunos Um utilizador deve ter uma página pessoal

33

RF14 RF15 RF16 RF17 RF18 RF19 RF20

O sistema deve enviar notificações de novas versões de LO aos utilizadores Um concetor deve poder indicar se um LO está apto para um ambiente móvel ou não Um aluno deve poder submeter LO Um aluno deve poder sugerir novos temas para LO Um utilizador poderá ter o perfil de convidado Um utilizador deverá ter uma data de validade Um utilizador deve poder fazer Like a um LO
TABELA 1 - REQUISITOS FUNCIONAIS

Descrição de cada requisito
RF1 - O utilizador deverá poder pesquisar por LO
Já era possível efetuar pesquisas por LO no PoLO II, mas este mecanismo era limitado pois era apenas efetuada uma pesquisa simples à base de dados pelo nome ou palavras que o LO continha. Assim para o COLOR foi adicionada uma pesquisa avançada de LO por relevância, popularidade, por data e por título. Para este requisito foram definidos os seguintes subrequisitos: • RF1.1 - O sistema deve fornecer ordenamento de pesquisa por popularidade. Neste subrequisito é pretendido que o utilizador tenha a possibilidade de ordenar os resultados das pesquisas por popularidade. • RF1.3 - O sistema deve disponibilizar resultados de pesquisa baseados no perfil dos utilizadores. Este subrequisito permite que as pesquisas apresentem resultados baseando-se no perfil do utilizador, sempre que este efetuar uma pesquisa por relevância. Para esta pesquisa são tidos em conta os LO a que o aluno fez Like anteriormente, os LO que o utilizador adicionou aos favoritos e os LO visualizados recentemente pelo utilizador.

RF2 - O sistema deve sugerir LO aos alunos
O sistema deve ter uma área onde irá apresentar LO sugeridos ao utilizador. Estas sugestões devem-se basear em dados sobre o utilizador recolhidos anteriormente. RF3 - O sistema deve disponibilizar um fórum de gestão associado a cada LO De forma a promover a discussão entre os utilizadores em torno do LO esta funcionalidade pretende a criação de um fórum associado a um LO, que apenas poderá ser visualizado por alunos que já tenham feito o LO, pelos gestores, concetores e administradores RF4 - Um utilizador deve poder rever LO

34

Com este requisito os utilizadores devem poder fazer a revisão dos LO, isto é, ter a possibilidade de os avaliar respondendo a perguntas pré-definidas no sistema. O revisor atribuirá uma nota ao LO, com escala de 1 a 5, com representação da escala qualitativa. Os dados do LO a classificar são os seguintes: qualidade do LO, originalidade, facilidade de utilização e rigor. O revisor deverá ainda indicar se recomendaria ou não o LO a outro utilizador. Apenas os gestores de conteúdos poderão convidar utilizadores a serem revisores. Pode ser pedido a qualquer tipo de utilizador para fazer a revisão. RF5 - O sistema deve disponibilizar um chat associado a cada LO Neste requisito é pretendida a criação de um sistema de mensagens instantâneas para os utilizadores comuniquem entre si em cada LO, de modo a discutirem assuntos relacionados com o conteúdo do LO. Neste chat apenas estarão os utilizadores que estejam no momento a estudar o LO, para assim trocarem ideias sobre o mesmo. RF6 - Um utilizador deve poder comunicar através de mensagens com outros utilizadores Este requisito permite que os utilizadores do sistema comuniquem através de mensagens de forma assíncrona. As tarefas deste requisito incluem: • O envio de mensagem para um utilizador; • A resposta à mensagem, em que esta conterá o histórico da conversa decorrida até ao momento. RF7 - Um utilizador deve poder seguir ações de outros utilizadores O requisito permite que um utilizador tenha a possibilidade de seguir outros utilizadores e também de receber notificações das suas atividades. Com esta funcionalidade o utilizador pode acompanhar o percurso de estudo de outros utilizadores. RF8 - O sistema deve registar os LO visualizados por um utilizador Para este requisito em gravar a ação do utilizador entrar no modo de estudo do LO. RF9 - O sistema deve apresentar aos utilizadores os LO mais populares O sistema deve apresentar uma lista com os LO mais populares para este requisito. RF10 - Um utilizador poderá criar LO que tenham como objetivo a partilha de informação e não sejam formativos Com este requisito o criador de conteúdo irá ter uma opção na criação do LO, que indique se este é formativo, isto é, se tem avaliação e conta para histórico, ou se é apenas informativo com o intuito de partilha de informação.

35

RF11 - O sistema deve fornecer gestão global de notas pessoais O utilizador deve ter uma forma de escrever e visualizar as suas notas. Estas notas devem ser independentes do sítio em que o utilizador se encontre na plataforma, para que o mesmo as possa consultar e editar sempre que desejar. Esta gestão de notas pessoais deve conter dois tipos de notas: notas associadas a um LO e notas gerais, que o utilizador poderá tirar podendo não estarem associadas a algum LO. RF12 - Os LO devem ser validados antes de estarem disponíveis para os alunos Este requisito obriga que exista uma validação do LO antes do mesmo estar disponível para ser visualizado. Esta validação apenas pode ser realizada por gestores de conteúdos e administradores, no caso dos gestores de conteúdos, estes apenas podem validar os LO da sua área de gestão. RF13 - Um utilizador deve ter uma página pessoal Este requisito consiste na criação de uma página que deve conter a informação relacionada com o utilizador. Esta página pode ser visualizada pelo próprio utilizador e pelos seus contactos. A página pessoal do utilizador deve conter: • Informação pessoal e também a opção de privacidade do mesmo, indicando se o perfil é privado ou publico; • Campo para indicar se o utilizador está ativo e a opção de o utilizador estar ativo até uma determinada data, havendo portanto utilizadores com prazo de vida; • • LO revistos pelo utilizador; Quem está a seguir o utilizador e que outros utilizadores é que o utilizador está a seguir; • • • • • LO produzidos pelo utilizador; LO já realizados, no caso dos alunos; LO a frequentar atualmente, no caso dos alunos; LO sugeridos à comunidade; Um link para as suas redes.

RF14 - O sistema deve enviar notificações de novas versões de LO aos utilizadores Para aqueles LO que o utilizador já tenha frequentado, sempre que existam novas versões dos mesmos, o sistema deve notificar os utilizadores. RF15 - Um concetor deve poder indicar se um LO está apto para ambiente móvel ou não

36

Este requisito consiste na adição de um atributo ao LO, o qual permita ao criador do LO indicar se este está preparado para um ambiente móvel ou não. RF16 - Um aluno deve poder submeter LO Inicialmente apenas os concetores podiam submeter LO, mas de forma a enriquecer o sistema os alunos poderão submeter também LO para serem aprovados. Após a submissão ser aprovada, o respetivo utilizador passa a ter também funções de concetor. RF17 - Um aluno deve poder sugerir novos temas para LO De modo a enriquecer e aumentar a biblioteca de LO do sistema, deve ser desenvolvida a possibilidade dos alunos sugerirem novos temas para LO. Na prática, esta sugestão consiste numa mensagem enviada dos alunos para os administradores, ficando assim estes com a noção das necessidades de formação. RF18 - Um utilizador poderá ter o perfil de convidado Este requisito implica, na prática, a adição de um novo tipo de perfil de utilizador: o convidado. Este novo perfil é como o próprio nome indica, um convidado, que apenas poderá efetuar consultas sobre o sistema, mas não edições, avaliações, sugestões ou criações. RF19 - Um utilizador deverá ter uma data de validade Esta funcionalidade consiste na adição de um novo dado ao utilizador: data de validade. O utilizador irá ter um prazo de validade, após o qual não poderá aceder ao sistema. RF20 - Um utilizador deve poder fazer Like a um LO Para este requisito deve-se implementar uma forma dos utilizadores fazerem like a um LO.

3.6

Arquitetura
A arquitetura do projeto COLOR assenta na arquitetura do anterior projeto, o PoLO II.

Assim foi decidido desenvolver as novas funcionalidades do sistema COLOR na arquitetura já existente. A solução de arquitetura usada para a implementação do sistema baseou-se na arquitetura de três camadas principais, em que existe uma clara separação das mesmas: dados, aplicação e apresentação.

As camadas são as seguintes:
• Dados - vão ser armazenados os dados relativos aos LO, registos de utilização e utilizadores, competências, etiquetas, índices, gestão de versões, fóruns, registos

37

dos chats, monitorização dos alunos, notas tiradas pelos utilizadores, conteúdos das páginas pessoais, notificações e seguimento de utilizadores; • Aplicação - efetua as operações lógicas sobre o negócio, com destaque para: a gestão do repositório, gestão da ontologia de representação, pesquisa, sugestão/recomendação e criação de LO; • Apresentação - apresenta o conteúdo ao utilizador e permite a interação entre ele e o sistema.

3.6.1
base ao COLOR: •

Camada de dados

O PoLO II, na camada de dados, apresentava já os seguintes módulos, que serviram de

Repositório de LO, Logs, Utilizadores, Contactos e gestão de versões: módulo responsável pelo armazenamento dos seguintes tipos de informação: o o o o o LO: Learning Objects Logs: registos de utilização do sistema. Utilizadores: informação sobre utilizadores do sistema. Versões: informação sobre as versões de cada LO do sistema. Contactos: informação sobre os contactos de cada utilizador do sistema.

Ontologia de Competências, Indexação, Etiquetas e Áreas Temáticas: módulo responsável pelo armazenamento de quatro tipos fundamentais de informação para pesquisas e sugestões: o Ontologia de Competências: estrutura de conhecimento que armazena as competências possíveis. o Estrutura de Indexação: estrutura de indexação que armazena informação associativa entre competências e utilizadores e LO. o Estrutura de Etiquetas: estrutura que armazena informação associativa entre etiquetas e utilizadores e LO. o Estrutura de Áreas Temáticas: estrutura que armazena informação associativa entre LO e áreas temáticas.

No COLOR, alterou-se o primeiro destes módulos, para armazenar dados relativos às novas funcionalidades: mensagens, chats, logs das ações dos alunos, anotações, notificações, formato técnico dos LO, data de validade dos utilizadores, dados sobre se um LO está apto

38

para um ambiente móvel ou não, número de Likes dos LO e dados relativos ao seguimento dos utilizadores. O módulo ficou definido da seguinte forma: • Repositório de LO, logs, utilizadores, contatos, gestão de versões, mensagens, Wikis, registos dos chats, monitorização dos alunos, notas tiradas pelos utilizadores, conteúdos das páginas pessoais, notificações. As alterações face ao PoLO II foram: o LO: passou a ser armazenada informação sobre o número de Likes dos LO, sobre o seu destacamento, uma indicação sobre se o LO está apto para ambientes móveis ou não e sobre o formato técnico do LO. Esta informação foi adicionada àquela que o LO já armazenava no PoLO II. o Logs: registos de utilização do sistema, onde passaram a ser armazenados logs de várias ações dos alunos, como das suas interações e tempos gastos nas atividades.

o Utilizadores: informação sobre utilizadores do sistema, que pode ser recolhida de outro subsistema Formare. o Versões: informação sobre as versões de cada LO do sistema. o Contatos: informação sobre os contactos de cada utilizador do sistema. o Mensagens: informação sobre as mensagens trocadas entre os utilizadores. o Chat: registos de mensagens instantâneas que os utilizadores poderão trocar quando estiverem a realizar um LO. o Seguimento de utilizadores: informação relativa ao seguimento de utilizadores.

3.6.2

Camada de aplicação

Do PoLO II, a camada de aplicação proporcionou ao COLOR os seguintes módulos: • Gestor do Repositório: módulo que implementa todos os métodos de acesso entre os módulos da camada de negócio e o repositório de informação (LO, Logs e Utilizadores). • Gestor da Base de Conhecimento: módulo que implementa todos os métodos de acesso entre os módulos da camada de negócio e a base de conhecimento (Ontologia de Competências, Indexação, Etiquetas e áreas temáticas).

39

Pesquisa: módulo da camada de negócio que recebe pedidos da camada de interface para efetuar pesquisas e que as vai processar.

Sugestão / Recomendação: módulo da camada de negócio que recebe pedidos da camada de interface para efetuar sugestões e recomendações e que as vai processar.

Criação de LO: módulo da camada de negócio que recebe pedidos da camada de interface para a criação de LO, e que as realiza.

No COLOR, foi alterado o módulo de pesquisa, de modo a ser possível ordenar os resultados da pesquisa por popularidade e de modo a que sejam apresentados resultados tendo em conta o perfil do utilizador. Quanto ao módulo Gestor do Repositório, foram implementados nele o chat e o sistema de mensagens, o sistema de anotações. Foram adicionados métodos que permitem aos utilizadores fazerem Like nos LO. Foi ainda implementada neste módulo a funcionalidade de seguimento de utilizadores. Foram então adicionadas as seguintes classes: • Chat: classe que faz a ligação à base de dados e gere os dados relativos ao chat; • Mensagem: classe obtida do sistema Formare que faz ligação à base de dados e gere os dados relativos às mensagens trocadas entre os utilizadores; • Pedido de submissão: classe que faz a ligação à base de dados e gere os pedidos de submissão.

E modificadas as seguintes:
• UtilizadorEAD – modificou-se a classe para que seja possível o utilizador ter o perfil de convidado e adicionaram-se campos da área da interação entre utilizadores. • LO – adicionou-se o campo para registo de likes do LO e um campo a indicar se o LO está apto para ambiente móvel. • AnotaçãoLO – foi modificada esta classe para que as notas tiradas pelos utilizadores possam ser vistas de uma forma global, e não apenas dentro de cada LO.

3.6.3

Camada de apresentação

Para o chefe do departamento o PoLO II apresentava um portal desadequado à personalidade da empresa e com problemas a vários níveis apresentados no capítulo 5, secção 5.4.

40

O portal Web do COLOR foi desenhado para transmitir alguma da personalidade da empresa através do layout. Com a combinação de cores, escolha de tipografia, imagens e estrutura do portal é possível associar o mesmo à imagem da empresa.

Estrutura base
Antes de dar inicio à implementação da aplicação Web para o portal COLOR, foi realizado um estudo sobre algumas boas práticas para o desenvolvimento da mesma. Assim foram definidos e aplicados alguns conceitos encontrados: o uso de user controls, quando é necessário implementar funcionalidades e/ou atributos visuais que necessitam de ser reutilizados em mais de que uma página, o estruturação das páginas definindo master pages, de forma a evitar a manutenção de diversas páginas e centralizar funcionalidades das páginas. Nesta secção serão apresentados os user controls criados e as master pages definidas.

User Controls
Os user control são controlos baseados na classe UserControl da plataforma .NET e permitem a construção de controlos que podem ser reutilizados ao longo de uma aplicação Web. Os user controls contêm uma extensão própria “.acsx”. De seguida são apresentados os user control definidos para o portal do COLOR.

Menu principal do portal Uma vez que várias páginas utilizam o menu superior foi criado para o mesmo um user control de forma a ser reutilizado em todas as que necessitem.

FIGURA 12 - MENU DO PORTAL

Como é possível observar na ilustração acima este controlo contém: • • • • Uma mensagem de boas vindas ao utilizador; Um ícone com mostra alguns atalhos para sua informação pessoal; Uma hiperligação mas as suas mensagens; Um atalho para uma pesquisa rápida sobre os LO do sistema.

41

Este controlo contém ainda hiperligações para as quatro grandes áreas do portal: • "Inicio", como sendo a página principal do sistema, que incluí os vários filtros dos LO associados ao utilizador: "Mais recentes", "Mais populares", "Sugeridos para mim", "Mais comentados" e "Favoritos"; • "MyColor", esta é a área pessoal do utilizador, onde é apresentada a sua informação; • "LOs", aqui são mostradas todos os los do sistema, bem como a possibilidade de criação de um novo lo. Para o caso dos administradores e gestores de conteúdos são mostradas as opções de validação e gestão de LO; • "Gestão", esta área apenas está disponível para os administradores, pois aqui é feita a gestão do sistema; • "Comunidade do Color", onde são listados todos os utilizadores do sistema. Para os utilizadores com perfil de administradores são mostradas opções de adicionar e remover utilizadores.

Área do LO A área do LO (Figura 13) é um user control usado nas listagens do LO. Este apresenta informação relativa a respetivo LO: • • • • • Thumbnail do mesmo; Titulo; Número de comentários; Um ícone indicando se o lo contém questionário; Número de rantings e atribuição de estrelas ao lo.

FIGURA 13 - ÁREA DO LO

42

Área lateral do perfil O controlo da área lateral do perfil (Figura 14) apresenta a informação relacionada com o utilizador: • • • • Fotografia; Nome; Quem o utilizador segue; Quem segue o utilizador.

FIGURA 14 - ÁREA LATERAL DO PERFIL

Menu principal do estudo Este controlo (Figura 15) é utilizado nas páginas de estudo do lo, e contém as seguintes opções: • “Info”, onde é apresentada sumariamente a informação relativa ao lo que está a visualizar; • • • • “Estudo”, aqui é apresentado todo o conteúdo referente ao lo; “Avaliação”, onde é feito uma avaliação ao utilizador sobre o lo; “Marcar como favorito”, em que o utilizador pode marcar o lo como favorito; “Partilhar”, o utilizador pode partilhar o lo à sua comunidade;

43

• •

“Menu”, é mostrado um índice do conteúdo do lo; “Home”, em que o utilizador é encaminhado para a sua página inicial.

FIGURA 15 - MENU DO ESTUDO DO LO

Criação do LO O processo de criação do LO é uma sequência de etapas onde utilizador defini as características do LO: 1. Informação principal. Nesta área o utilizador define a capa do LO, bem como algumas das suas características principais (Figura 16); 2. Objetivos. É apresentada uma caixa de texto onde o utilizador insere os objetivos do LO (Figura 17); 3. Conteúdo do LO. São mostrados os ficheiros que definem o conteúdo do LO, bem como a disposição dos mesmos. O utilizador tem um botão para a adicionar e gerir a disposição do conteúdo (Figura 18). 4. Síntese. É apresentada uma caixa de texto ao utilizador para colocar a síntese do LO (Figura 19); 5. Conceitos. Nesta área é mostrada a árvore de conceitos do sistema. O utilizador define os conceitos aos quais o LO estará associado (Figura 20); 6. Etiquetas. O utilizador defini as etiquetas do LO através de uma caixa de texto (Figura 21); 7. Competências. Nesta área o u apresentadas as competências que o aluno irá obter depois de estudar o aluno, bem como os níveis de proficiências de cada uma (Figura 22); 8. Resumo. É mostrado um resumo das características do LO preenchidas pelo utilizador (Figura 23). Para essa sequência de etapas no processo de criação do LO foram criados vários user controls (um para cada etapa):

44

FIGURA 16 - INFORMAÇÃO PRINCIPAL

FIGURA 17 - OBJETIVOS

FIGURA 18 - ADIÇÃO E DISPOSIÇÃO DO CONTEÚDO

45

FIGURA 19 - SÍNTESE

FIGURA 20 - CONCEITOS

FIGURA 21 - ETIQUETAS

46

FIGURA 22 - COMPETÊNCIAS

FIGURA 23 - RESUMO

Foi ainda criado um user control para ajudar o utilizador com as etapas para a criação do LO, indicando a etapa em que o utilizador se encontra, aquelas que já preencheu e as que ainda necessita de preencher ( (Figura 24).

FIGURA 24 - ETAPAS

O aspeto da página de criação é mostrado na seguinte ilustração na etapa do resumo do LO.

47

FIGURA 25 - PÁGINA DE CRIAÇÃO DO LO

Master Pages
As master pages foram criadas devido à necessidade de construção de um mecanismo que permita o desenvolvimento de várias páginas com o mesmo layout. Estas páginas são representadas por ficheiros de extensão “.master”. Para a aplicação Web do COLOR foram definidas três páginas padrão (master pages) evitando a manutenção e centralizando funcionalidades das páginas: Geral, apresentada na ilustração da página inicial do portal (Figura 26); Estudo, apresentada na ilustração da p página de estudo do lo (Figura 27); 27 Perfil, mostrada na ilustração da p página de edição do perfil do utilizador (Figura ( 28). Com este recurso é possível criar uma página padrão podendo as demais páginas criadas serem herdar a sua aparência visual. Em cada master page é definido um ou mais content place holder cujo conteúdo será personalizado pelas páginas finais. finais O restante

48

conteúdo da master page é fixo, ou seja, as páginas finais que herdem dela terão automaticamente todo esse conteúdo.

Master Page geral
A master page geral é a página padrão mais herdada pelas páginas do portal do COLOR, pois contém a estrutura base da aplicação Web. A master page geral contem o user control principal geral (Figura 12) na parte superior e o content place holder no centro da página onde é inserido o conteúdo das páginas herdadas. De seguida é apresentada a página inicial da plataforma, que herdou da master page geral, onde é possível observar todo o conteúdo pertencente à página no content place holder. No conteúdo da página podemos ainda identificar o uso do user control da área do lo (Figura 13) na listagem dos learning objects.

FIGURA 26 - PÁGINA INICIAL

Master Page de estudo
Esta master page de estudo é herdada pelas páginas relacionadas com o estudo de um determinado lo. Esta contém o menu principal do estudo (Figura 15) e o contentplaceholder

49

para o conteúdo das páginas herdadas. Como exemplo é mostrada abaixo a página de apresentação de um lo, contendo alguma informação resumida sobre o mesmo.

FIGURA 27 - PÁGINA DE ESTUDO DO LO

Master page do Perfil
A página padrão do perfil do utilizador é construída com o user control do menu principal geral (Figura 12) e com o user control da área lateral do perfil (Figura 14). É possível observar na ilustração abaixo a página de edição do perfil, herdada da master page do perfil, onde foi inserido no contentplaceholder o conteúdo pertencente à mesma.

50

FIGURA 28 - PÁGINA DE EDIÇÃO DO PERFIL

51

CAPÍTULO 4: MÉTODO DE INVESTIGAÇÃO
Neste capítulo é apresentado o método de investigação escolhido pelo autor, dentro dos métodos da análise: o estudo de caso. É descrito o método comparando-o com outros, apresentadas as suas características, a recolha dos dados na sua aplicação. É também apresentado o método de análise em que o autor se baseou para categorizar os problemas identificados durante o processo.

52

4.1

Estudo de Caso
O estudo de caso é um método de investigação que visa compreender melhor um

fenómeno, um processo de uma organização, um individuo, através do cruzamento dos factos apontados pelo investigador. Tem sido um dos métodos de pesquisa mais utilizados em algumas áreas da administração como, por exemplo, nos sistemas de informação (Hoppen & Meirelles, 2005). Através do estudo de caso o investigador procura resposta a duas perguntas essenciais, o “como” e o “porquê” do caso em concreto que se esta a compreender. Estas respostas são dadas segundo a análise dos factos que foram recolhidos durante a ocorrência do caso. Segundo Yin o estudo do caso deve ocorrer mediante três condições: quando o investigador, mesmo participando, tem pouco ou nenhum controlo sobre os eventos; quando o caso se encontra em fenómenos atuais inseridos num contexto da vida real; e, como referido anteriormente, quando se procura respostas ao “como” e “porque” do caso (Tabela 2). É ainda caracterizada toda a envolvente do caso, sejam entidades, pessoas, programas ou processos, etc.

Exige controlo Questões de Estratégia/Método pesquisa
Como, porquê Quem, o que, onde, Recolha de dados quantos, quanto Quem, o que, onde, Análise de arquivos quantos, quanto Método histórico Estudo de caso Como, porquê Como, porquê Não Não Não Não

Foco em acontecimentos contemporâneos?
Sim Sim

sobre eventos comportamentais?

Experiência

Sim

Sim/Não Não Sim

TABELA 2 - SITUAÇÕES RELEVANTES PARA DIFERENTES ESTRATÉGIAS DE INVESTIGAÇÃO (YIN, 1984)

Yin define o método estudo de caso como “uma investigação empírica sobre um fenómeno contemporâneo no seu contexto natural, em situações em que as fronteiras entre o contexto e o fenômeno não são claramente evidentes, utilizando múltiplas fontes de evidência” (ibid, p.23). Para o autor o estudo do caso baseia-se no trabalho de campo ou na análise de factos, afasta o estudo do caso dos métodos de investigação como o método

53

histórico, e refere ainda que devem ser utilizadas diversas fontes de dados de forma a aumentar a veracidade dos acontecimentos. No caso da presente dissertação o objeto de estudo foi o processo de desenvolvimento de software ao nível empresarial.

4.2

Características de um estudo de caso
O estudo de caso pretende compreender uma dada entidade no seu contexto real,

tirando o máximo partido possível de múltiplas fontes de evidência como entrevistas, observações, documentos e artefactos (Yin, 1984). O autor admite a dificuldade na definição de um estudo de caso exemplar, pois interroga-se sobre as suas características ideias. Mas arrisca-se a propor as seguintes características: • O caso deve ter identificar e considerar outras perspetivas ou hipóteses alternativas. O investigador deve procurar explicações ou outras perspetivas diferentes daquelas adotadas no estudo e examinar as evidências de acordo com essas perspetivas; • Os dados tratados (evidências) devem fortes e suficientes para sustentar as conclusões ganhando assim a confiança do leitor relativamente ao trabalho; • O relato do estudo deve ser atraente. Isto significa que deve ser escrito de maneira clara e atraente para o leitor, de modo a que este fique atento durante a narrativa; • O caso deve ser completo. E para tal são indicadas três características: o As fronteiras do caso, isto é, a distinção entre o fenómeno que esta a ser estudado e o seu contexto; o Objeto de atenção, a descrição narrativa demonstra, de modo convincente, que houve “um esforço exaustivo” para juntar as evidências relevantes; o A exposição de evidências adequadas deve vir acompanhada por alguma indicação de que o investigador esteve atento à validade das evidências (Yin, 1984).

4.2.1

Projeto de investigação

Robert Yin afirma que para os estudos de caso, são especialmente importantes cinco componentes de um projeto de investigação:

54

1) As questões de estudo; As questões de estudo, podem variar, mas num estudo de caso é provável que a estratégia mais apropriada a questões do tipo “como” e “porquê”, como referido anteriormente. A questão do “como” refere-se à descrição de um processo e à identificação de como as coisas decorreram. E a questão “porquê” refere-se à causa ou causas do acontecimento e incluí uma análise explicativa. No resumo do capítulo 5 são dadas as respostas às questões de estudo do processo de desenvolvimento de software. 2) As proposições, se houver; As proposições são as ideias ou preconceitos que foram definidas previamente para ao estudo da investigação. Quando um trabalho tem um objetivo é definida uma ideia prévia de como esse trabalho deve ser feito. Mas agora se refletirmos, à posteriori, conclui-se que ocorrem factos com os quais não se estava a contar e por isso não foram registados porque na altura não se sabia que eram importantes. No estudo do caso do processo da presente dissertação tomou-se a seguinte proposição: os pontos relevantes para o estudo são as trocas formais de informação: e-mail, atas de reuniões e decisões de gestão. E nessa proposição ignorou-se o facto de existirem outros pontos relevantes, como por exemplo: conversas de café onde se falava de trabalho, conversas fora do local de trabalho, e de onde surgiam soluções. Agora, em retrospetiva, deveriam ser consideras essas conversas pois foi delas que surgiram algumas soluções. 3) A unidade de análise; A unidade de análise relaciona-se com o problema de definir o que é o “caso”, ou seja, qual é a unidade primária de análise. E para tal deve-se relacionar a maneira como as questões iniciais da investigação foram definidas. Uma vez estabelecida a unidade de análise devem-se colocar limites de tempo específicos para se definir o começo e o fim do caso (Yin). A unidade de análise visa definir o que é o caso de investigação concreto. Como unidade primária de análise a ser considerada no trabalho é o processo de desenvolvimento de software ao nível empresarial. Como unidade

55

secundária de análise pode-se definir a equipa de desenvolvimento que participou no projeto. 4) A lógica que une os dados às proposições; A maneira como se relacionam os dados às proposições. 5) Os critérios para se interpretar as descobertas. Para estes dois últimos componentes, que têm como objetivo indicar o que se deve ser feito com os dados recolhidos, Yin indica que foram os menos desenvolvidos não havendo um padrão que ligue os dados às proposições nem uma maneira de estabelecer os critérios para se interpretar as descobertas.

4.3

Recolha de dados no estudo de caso
Segundo Yin as evidências para um estudo de caso podem vir de seis fontes distintas:

documentos, registos em arquivos, entrevistas, observação direta, observação participante e artefactos físicos. Refere ainda a incorporação de três princípios na investigação de um estudo de caso, de forma a aumentar substancialmente a sua qualidade: a) Múltiplas fontes de dados, de modo a permitir assegurar as diferentes perspetivas dos participantes no estudo e obter várias “medidas” do mesmo fenómeno possibilitando assim uma triangulação dos dados, durante a fase de análise dos mesmos. O que torna as conclusões e descobertas mais convincentes pois são extraídas de um conjunto de confirmações; b) Criar uma base de dados, ao longo do estudo. Deve-se tentar separar os dados da narrativa. c) Manter o encadeamento dos dados. Devem ser escritos os dados de forma encadeada de modo que um leitor externo consiga perceber a apresentação dos dados que sustentam o estudo, desde as questões de investigação até às conclusões finais. No presento estudo foram recolhidos dados através da seguinte documentação: • Diários de bordo, mensagens de e-mails trocadas pela equipa, exemplares de documentos de especificação, atas de reuniões e documentos produzidos no âmbito do projeto (requisitos, conceção e manuais). No âmbito do registo em arquivos foram utilizados:

56

Os registos pessoais, nomeadamente diários de bordo e anotações. Segundo (Bogdan & Biklen, 1994) o diário de bordo é utilizado para registo de notas de campo e constitui um dos principais instrumentos do estudo de caso. No caso em concreto o investigador foi um observador-participante. A observação participante implica um processo longo em que o investigador passa

meses a negociar a sua entrada na área (Whyte, 1993). No presente trabalho não foi necessário esse longo processo de negociação, uma vez que o autor já estava envolvido no processo de desenvolvimento, aproveitando assim essa oportunidade. Whyte refere ainda para se compreender a evolução do comportamento de pessoas e de grupos é necessário observá-los por um longo período e não num único momento. O que aconteceu no caso em concreto, como é possível verificar no capítulo 5, que o autor esteve participou durante uns meses no desenvolvimento do software. A observação participante supõe a interação entre o investigador e o investigado. O autor foi simultaneamente o investigador e um objeto de investigação.

4.4

Análise de conteúdo
A análise de conteúdo reúne um conjunto de técnicas que podem ser aplicadas no

tratamento de dados reunidos pelo analista. A definição citada por vários autores que se tornou clássica: “a análise de conteúdo é uma técnica de investigação objetiva, sistemática e quantitativa do conjunto manifesto da comunicação”. (Stemler, 2001) refere que “a análise de conteúdo é uma técnica sistemática e replicável para comprimi muitas palavras de texto em poucas categorias de conteúdo, baseada em regras explícitas de codificação”. Os métodos de análise de conteúdo são distinguidos em procedimentos fechados e procedimentos abertos ou exploratórios (Henry e Moscrovici, 1986): • Procedimentos fechados – são aqueles casos em que o analista já possui uma lista prévia de categorias apropriadas ao objeto de estudo e a usa para classificar os dados; • Procedimentos abertos (processo seguido pelo autor) – não existe a lista prévia referida no procedimento fechado, ou sejas as categorias surgem do próprio material. É um processo indutivo, em que o analista caminha dos dados empíricos para a formulação de uma classificação. A categorização feita pelo analista durante o

57

processo mantém-se provisória, pois é possível que existam remodelações à medida que novos dados vão surgindo.

58

CAPÍTULO 5: VIVÊNCIA DE DESENVOLVIMENTO DE SOFTWARE A NÍVEL
EMPRESARIAL
Neste capítulo, são descritas, de forma detalhada através de registos recolhidos na primeira pessoa as dimensões que caracterizam a vivência do autor na evolução do desenvolvimento do projeto. Para este processo é descrito segundo o método apresentado no capítulo 4: estudo de caso. Este método é utilizado quando se pretende conhecer o “como?” e o “porquê?” da investigação. No caso da presente dissertação pretende-se dar a conhecer como decorreu o processo de desenvolvimento do software, descrevendo o mesmo através de factos. E esse mesmo processo decorreu de modo (porquê) a visar contribuir para a melhor perceção pública dos desafios e realidades do exercício de engenharia informática nestes contextos.

59

5.1

Introdução
Após vários anos de estudo na área científica de Engenharia Informática o autor

deparou-se com o seu primeiro desafio num ambiente empresarial ao integrar uma equipa de trabalho para o desenvolvimento de um novo software. A empresa que integrou foi a Portugal Telecom Inovação, uma empresa focada no desenvolvimento e entrega de produtos e serviços para o mercado das telecomunicações e das tecnologias de informação. O software a desenvolver foi um portal colaborativo de Learning Objects na Web e o autor tentou aplicar os conhecimentos adquiridos integrando a equipa de desenvolvimento focada na camada de apresentação do portal. O autor inicia a sua participação na fase em que se estão a definir as limitações e problemas existentes no anterior portal PoLO II. A informação apresentada neste capítulo são os registos que o autor agregou durante a realização da sua participação no projeto, nomeadamente, diários de bordo, mensagens de e-mails trocadas pela equipa, exemplares de documentos de especificação, atas de reuniões e documentos produzidos no âmbito do projeto (requisitos, conceção e manuais). Neste capítulo é descrito o ambiente de trabalho: caracterizados os elementos de trabalho, e é explicada a comunicação entre os mesmos e a sua periodicidade. São explicados para que serviram as tecnologias e ferramentas descritas no capítulo 2, secção 2.8 no desenvolvimento do projeto. E de seguida são apresentados os registos que o autor agregou, como já referido anteriormente.

5.2

Ambiente de trabalho
5.2.1 Colaboração intra-grupo

Os elementos da equipa de trabalho (programador1, programador2, programador3 e designer) não se conheciam antes do projeto em causa. O progamador1 é o autor da presente dissertação e apresentava as seguintes características: 24 anos, Licenciatura em Informática, experiência ao nível de trabalhos académicos. O programador2 era o elemento com mais experiência com as seguintes características: 29 anos, Licenciado em Engenharia Informática e com mais de 4 anos de experiência a nível empresarial, nomeadamente no desenvolvimento Web.

60

O programador3 era estudante de Engenharia Informática, tinha 22 anos de idade e experiência ao nível de trabalhos académicos. A designer tinha 23 anos e acabava de terminar o seu percurso académico no curso de Novas Tecnologias de Comunicação, onde adquiriu conhecimento e experiência na área do design vetorial.

5.2.2

Comunicação

Nesta seção são apresentadas as características da comunicação entre os elementos da equipa, nomeadamente a periodicidade e ferramentas utilizadas referindo os elementos que as usaram.

Periodicidade
Os elementos de trabalho, da parte da PT Inovação, nomeadamente o programador1, programador2 e designer, falavam praticamente todos os dias pessoalmente pois trabalhavam juntos, excetuando 1 ou 2 dias por semana em que o programador2 se tinha de ausentar. Mas mesmo nessas ausências, quando era necessário resolver algum assunto premente, utilizaramse as ferramentas descritas abaixo. A comunicação entre os gestores de projeto e a equipa de trabalho da PT Inovação era feita pessoalmente uma vez por semana, excetuando quando havia necessidade de alguma das partes resolver algum assunto premente. O programador3 comunicava em média todos os dias com os elementos de trabalho da PT Inovação. O gestor de projeto da universidade1 comunicava com os elementos da PT Inovação em cerca de 1 vez por semana.

Ferramentas utilizadas Os elementos da equipa utilizavam as seguintes ferramentas:
• Portal Colaborativo Wiki do projeto, onde se encontrava a informação atualizada e onde se fazia o tracking do desenvolvimento, utilizado pela equipa; • E-mails, utilizados pela equipa;

61

Chamadas via Skype14, mais frequentemente entre o programador3 e os elementos de trabalho da PT Inovação;

Chats, mais frequentemente entre os elementos de trabalho, nomeadamente Skype e o serviço de mensagens do Gmail15.

5.2.3

Escrita de código

No que diz respeito à escrita de código não foi mencionada, em qualquer uma das reuniões, alguma regra ou prática nem mesmo um padrão de desenho de software a ser seguido. E também não existiu um processo formal para a validação de código. Assim sendo o autor procedeu da forma que achou mais correta na escrita do código necessário.

5.2.4

Testes

Na fase de desenvolvimento os testes foram realizados pelos próprios elementos da equipa. Muitas vezes eram feitos pedidos aos colegas de forma a testar a funcionalidade implementada para tentar identificar algum problema. Na fase final do projeto foi utilizada a ferramenta HP Quality Center para validar e testar com passos predeterminados as funcionalidades implementadas no projeto por utilizadores externos ao mesmo.

5.3

Tecnologias e ferramentas utilizadas
Durante o desenvolvimento do projeto COLOR foram utilizadas as seguintes

ferramentas e tecnologias: • Microsoft Visual Studio 201016, ferramenta da Microsoft para desenvolvimento de software; • Telerik RadControls for ASP.NET AJAX17, pacote de controlos desenvolvidos para utilização em páginas Web, com o objetivo de agilizar o seu o desenvolvimento;

14

http://www.skype.com/pt/ https://mail.google.com/ http://www.microsoft.com/visualstudio/en-us/products/2010-editions

15

16

62

Telerik OpenAccess ORM18, software de mapeamento objeto-relacionamento, que através do modelo de dados da aplicação gera a camada de acesso a dados e a própria base de dados;

SQL Server Management Studio19, ferramenta de gestão de base de dados através de uma interface gráfica;

Apache Subversion20 (também conhecido por SVN), ferramenta de controlo e gestão de diferentes versões de software, histórico e desenvolvimento, contendo uma componente de servidor e outra de cliente.

O Atlassian21, software colaborativo wiki de partilha de informação. É utilizado na gestão de projetos, e tem como objetivo integrar indivíduos e departamentos dentro de uma organização. O Atlassian acumula duas funções básicas: Portal Colaborativo Wiki (Confluence22) e o JIRA23.

O JIRA é um tracker, software desenhado para seguir issues (tarefas) e bugs reportados no desenvolvimento de uma aplicação, que estava conectado ao servidor SVN e ao Confluence;

O HP Quality Center é um software para a gestão de testes funcionais, de desempenho e de segurança nos projetos.

Framework Microsoft .Net24 4.0, plataforma para o desenvolvimento e execução de sistemas e aplicações;

Framework ASP.NET25, plataforma baseada na Framework .NET, que permite a construção de aplicações Web;

Microsoft SQL Server 2005, sistema de gestão de base de dados relacionais;

17

http://www.telerik.com/products/aspnet-ajax.aspx http://www.telerik.com/products/orm.aspx http://www.microsoft.com/net http://subversion.apache.org/ https://www.atlassian.com/software https://www.atlassian.com/software/confluence https://www.atlassian.com/software/jira http://www.microsoft.com/net http://www.asp.net/

18

19

20

21

22

23

24

25

63

Linguagem de programação C#, linguagem de programação orientada a objetos, desenvolvida esenvolvida pela Microsoft;

Linguagem JavaScript, linguagem de script páginas Web.

Numa fase inicial ocorreram várias reuniões onde foram explicadas as tecnologias e ferramentas utilizadas no dia-a-dia da equipa de desenvolvimento:

FIGURA 29 - ESTRUTURA DE FERRAMENTAS USADAS

No desenvolvimento do projeto em questão foram utilizadas ferramentas de desenvolvimento de código, de controlo de versões do mesmo e ferramentas de gestão. O SQL Server Management Studio Express foi utilizado para a equipa para interagir com a base de dados e efetuar a gestão da mesma. Como ferramenta base de desenvolvimento de código foi utilizado pela equipa o Visual Studio 2010 com a componente de construção de páginas Web o ASP.NET. Na construção rução das páginas Web, foi utilizada a linguagem de programação C#. Foram utilizadas bibliotecas da Telerik: • Para a implementação das interfaces da plataforma Web foram usados os controlos RadControls for ASP.NET AJAX.

64

A ferramenta OpenAccess ORM estava integrada com o Visual Studio e foi utilizada, através do modelo de classes criadas, gerar o modelo relacional de base de dados de forma automática.

Como ferramenta de controlo de versões do código desenvolvido foi utilizado o Apache Subversion. A equipa utilizou também Confluence como portal colaborativo wiki e o JIRA para a gestão do desenvolvimento dos requisitos do projeto. No Portal Colaborativo Wiki foi possível partilhar a informação do projeto, assim a informação do mesmo estava centralizada e atualizada num único local e não tão dispersa por e-mails pessoais e documentos. Através do JIRA acompanhou-se o processo de desenvolvimento de código do projeto. Para cada requisito do projeto eram criados issues com a informação referente ao requisito (descrição, dependências, etc.). Caso o requisito fosse demasiado complexo ou extensivo, dividia-se o mesmo em vários subrequisitos de forma ajudar a implementação do mesmo. Com esta ferramenta a equipa de desenvolvimento acompanhava o trabalho de cada um. O SVN estava conectado ao Jira através dos códigos definidos através dos issues. Assim era possível associar o código realizado a determinado requisito ou sub-requisito.

5.4

Panorama geral do processo de desenvolvimento
O processo de desenvolvimento ocorreu em duas fases, a primeira foi incidiu sobre

uma análise do software anterior e a segunda sobre o desenvolvimento do COLOR (Figura 30).

65

Análise do software anterior

Desenvolvimento do COLOR

Estudo da documentação dos projetos PoLO e PoLO II

Definição dos requisitos a implementar

Identificação de problemas/erros no código do PoLO II

Implementação dos requisitos e construção do portal Web

Identificação das limitações do PoLO II

Descrição das dificuldades encontradas pelo autor na implementação

FIGURA 30 - DIAGRAMA DO PROCESSO DE DESENVOLVIMENO

5.5

Análise do software anterior (PoLO II)
Após as primeiras reuniões de ponto de situação sobre os projetos anteriores e a

apresentação das ferramentas utilizadas, a equipa deu início ao processo de verificação do estado do projeto PoLO II. O autor ficou responsável efetuar um estudo sobre o PoLO II no sentido de identificar problemas e limitações. Nesta secção são apresentados os dados do autor sobre os problemas e erros encontrados ao nível da implementação de código, e limitações ao nível pedagógico e do portal Web. No anexo é apresentado o cód código de alguns problemas.

5.5.1

Problemas/Erros no código
Tipo Problema técnico Problema técnico Problema técnico Problema técnico Problema técnico Problema técnico Problema técnico Data 12/10/2011 17/10/2011 19/10/2011 20/10/2011 21/10/2011 24/10/2011 25/10/2011

Identificação PTP1 PTP2 PTP3 PTP4 PTP5 PTP6 PTP7

66

PTP8 PTP9 PTP10 PTP11

Problema técnico Problema técnico Problema técnico Problema técnico
TABELA 3 - PROBLEMAS/ERROS NO CÓDIGO

27/10/2011 27/10/2011 27/10/2011 27/10/2011

No decorrer do trabalho foram encontrados alguns problemas ao nível da escrita de código: • PTP1 (12/10/2011) - O autor constatou que fora implementado no código da camada de aplicação um método “getPathFicheiro” que tinha os mesmos objetivos de um dos métodos disponíveis nas bibliotecas-padrão (namespace Systema.IO) da Framework .NET 4.0: Path.GetDirectoryName26. • PTP2 (17/10/2011) – Na classe “Gestor” o autor deparou-se com um método que tinha como objetivo receber um objeto que incluía um ficheiro de vídeo e convertê-lo para o formato .swf, usando um executável (ffmpeg.exe) retirado da biblioteca opensource ffmpeg27. O objeto recebido como parâmetro não tinha qualquer validação antes das instruções do método. • PTP3 (19/10/2011) - O autor constatou que o método “AlteraEstado” localizado na classe “Gestor” do projeto não continha qualquer descrição, desconhecendo assim o seu propósito. E o mesmo não foi encontrado na documentação do projeto. Foi então necessário verificar onde o método era chamado para tentar perceber o seu objetivo. • PTP4 (20/10/2011) - Após a verificação de uma tabela na base de dados designada “Mensagem” sem qualquer entrada o autor encontrou a classe que originou a mesma (através do ORM): “Mensagem”. Esta classe não tinha qualquer modificador de acesso (Access Modifiers28) logo é assumido por defeito pelo Visual Studio o modificador de acesso privado (Private29). Este facto faz com que aquela tabela nunca seja usada estando recursos alocados na base de dados que nunca irão ser usados pois a classe não pode ser instanciada.

26

http://msdn.microsoft.com/en-us/library/system.io.path.getdirectoryname(v=vs.110).aspx http://www.ffmpeg.org/ http://msdn.microsoft.com/en-us/library/wxh6fsc7(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/st6sy9xe(v=vs.100).aspx

27

28

29

67

PTP5 (21/10/2011) – O autor constatou a utilização de forma menos apropriada da estrutura Guid30 como tipo de identificador principal para a classe “LO”. O seu uso pode tornar a pesquisa por LO lenta quando é feita uma busca à base de dados por um determinado GUID.

PTP6 (24/10/2011) – O autor constatou que foram definidas quatro variáveis globais, na master page utilizadas por todas as páginas da aplicação Web, como referências. Estas variáveis não são alteradas ao longo do seu uso no projeto, uma vez que representam as cores dos menus que não são alteradas. Estas variáveis estarão alocadas por cada utilizador/página que esteja ativa no servidor Web fazendo assim com que sejam gastos mais recursos.

PTP7 (25/10/2011) – O autor deparou-se com duas mensagens com o mesmo objetivo.

PTP8 (27/10/2011) – O autor constatou um evento cujo único método que continha estava comentado.

PTP9 (27/10/2011) – O autor constatou haver vários métodos com as mesmas funcionalidades em diversas páginas Web.

PTP10 (27/10/2011) – O autor constatou na página de listagem dos utilizadores a implementação de código que utilizava uma string para representar as permissões do perfil do utilizador na plataforma. E de seguida era copiada para a ViewState31 de modo a ser passada e utilizada entre as diferentes páginas Web. Este mecanismo é pouco intuitivo e dificulta a manutenção de código para os programadores.

PTP11 (27/10/2011) – O autor deparou-se com as tabelas apresentadas na Figura 31, que tinham como objetivo mapear as relações entre a tabela “permissão”, a tabela “UtilizadorEAD” e a tabela “lo”.

O autor deparou-se com uma tabela na base de dados denominada “permissao_utilizador_lo”, a qual tinha como objetivo associar uma permissão a um utilizador (tabela “Utilizador”) em determinado LO (tabela “LO”) (Figura 31). Esta tabela, segundo o mapeamento atual, permite fazer múltiplas inserções dos mesmos grupos fazendo assim com que não obedeça á primeira

30

http://msdn.microsoft.com/en-us/library/system.guid(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/bb386448(v=vs.100).aspx

31

68

forma de e normalização a qual diz que não deve ser possível a inserção de múltiplos grupos iguais (Coulson, 2007).

FIGURA 31 - TABELAS PARA A RELAÇÃO DA PERMISSÃO DO UTILIZADOR NUM LO

5.5.2

Limitações

De seguida são apresentadas os dados recolhidos ao nível das limitações do portal Web e pedagógicos do PoLO II II, que geraram melhorias no COLOR.

Identificação LP1 LP2 LP3 LP4 LP5 LP6

Tipo Ocorrência Ocorrência Reunião Geral Reunião Geral Reunião Geral Reunião Geral
TABELA 4 - LIMITAÇÕES

Data 03/10/2011 03/10 03/10/2011 03/ 05/10/2011 05/ 10/10/2011 10/ 10/10/2011 10/ 10/10/2011 10/

Portal • LP1 – Ocorrência Data: 03/10/2011 03/10/2011: Participantes: programador1

69

O programador1 constou que a plataforma apenas continha uma master page herdada por todas as páginas. • LP2 – Ocorrência Data: 03/10/2011: Participantes: programador1 O programador1 verificou que as várias páginas Web repetiam código e controlos. Pedagógico • LP3 – Reunião geral Data: 05/10/2011: Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1; U1: gestor e programador3 A equipa concordou de forma unanime que a área do perfil do utilizador apresentava pouco informação, pois apenas apresentava os dados do utilizador, os LO criados e os seus LO favoritos. Foi falado pela gestora que o COLOR deveria centrar-se no perfil do utilizador apresentando as suas ações no sistema especialmente relacionadas com os LO. • LP4 – Reunião geral Data: 10/10/2011: Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1; U1: gestor e programador3 O chefe de equipa referiu que o PoLO II continha apenas uma funcionalidade no que diz respeito à colaboração entre os utilizadores, que consistia na possibilidade de um utilizador sugerir um LO a outro utilizador do sistema. LP5 – Reunião geral (10/10/2011) A gestora argumentou que o não existia qualquer funcionalidade que potenciasse a participação do aluno na criação do LO, pois o aluno não podia criar LO. LP6 – Reunião geral (10/10/2011) O gestor a universidade referiu que os utilizadores não eram avisados quando existia uma nova versão de um LO que eles já estudaram. LP7 – Reunião geral (10/10/2011) O autor referiu que a plataforma apenas permite visualizar notas pessoais dentro do LO.

70

5.6

Desenvolvimento do COLOR
Nesta secção são descritos os registos do autor (programador1) em relação à

implementação dos requisitos e os desafios com os quais ele se deparou.

5.6.1

Implementação dos requisitos

Aqui são descritos os registos do autor no decorrer da implementação dos requisitos apresentados no capítulo 3, secção 3.5. Estes registos encontram-se ordenados temporalmente mediante o desenrolar de cada acontecimento.

Identificação RG1 RG2 RG3 RG4 RG5 RG6 RG7 RG8 RG9 RG10 RG11 RG12

Tipo Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral Reunião geral
TABELA 5 - REUNIÕES GERAIS DE EQUIPA

Data 01/11/2011 17/11/2011 28/11/2011 09/12/2011 12/01/2011 09/02/2012 22/03/2012 26/04/2012 03/05/2012 01/06/2012 14/06/2012 25/06/2012

Local PT PT PT PT PT PT PT PT PT PT PT PT

Identificação PT1 PT2 PT3 PT4

Tipo Problema técnico Problema técnico Problema técnico Problema técnico

Data 05/11/2011 24/11/2011 02/02/2012 20/01/2012

Local PT PT PT PT

TABELA 6 - PROBLEMAS TÉCNICOS OCORRIDOS

Identificação OC1 OC2 OC3 OC4 OC5 OC6

Tipo Ocorrência Ocorrência (via e-mail) Ocorrência Ocorrência Ocorrência (via e-mail) Ocorrência

Data 28/05/2012 23/02/2012 27/04/2012 01/05/2012 19/01/2012 24/01/2012

Local PT PT U1 PT PT PT

71

OC7 OC8 OC9 OC10 OC11 OC12

Ocorrência Ocorrência Ocorrência Ocorrência (via e-mail) Ocorrência Ocorrência (via e-mail)
TABELA 7 - OCORRÊNCIAS

15/02/2012 07/05/2012 04/06/2012 12/06/2012 20/06/2012 13/06/2012

PT PT PT PT PT PT

RG1 – Reunião geral Data: 01/11/2011; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1; U1: gestor e programador3; Duração: 2 horas • Discussão de brainstorm para os novos requisitos a implementar; • Apresentadas ideias por todos os elementos; • De forma a manter a divisão de tarefas do projeto anterior, o chefe de departamento e o gestor da U1 decidiram que se mantinham as camadas divididas: PTin, responsável pela parte da apresentação e U1 responsável pela camada de dados e aplicação; PT1 – Problema técnico Data: 5/11/2011; Participantes: Gestor técnico e programador3; Via: e-mail O programador3 comunicou dificuldade com o mapeamento entre as classes do core e a base de dados, ou seja, o funcionamento do sistema OpenAccess ORM. PT2 – Problema técnico Data: 24/11/2011; Participantes: Gestor técnico e programador1; via: presencial O programador1 comunicou que estava a ter dificuldades em aplicar a RadGrid (controlo para listagens da Telerik). Foi então necessário combinar esforços para tapar lacunas, e o programador2 sendo o programador mais experiente com os controlos da Telerik, tanto nos controlos Web como no OpenAccess ORM, ficou responsável por auxiliar o programador1 e o programador3.

• De modo a melhorar a pesquisa do PoLO II, a gestora decidiu implementar o requisito: RF1 – O utilizador deverá poder pesquisar por LO. O programador3 manifestou o interesse em ficar responsável pelo requisito e disse que ia

72

elaborar um estudo para sobre pesquisas avançadas em outros sistemas de learning objects com o objetivo de tentar aplicar algumas ideias no COLOR. RG2 – Reunião geral: Data: 17/11/2011; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1; U1: gestor e programador3; Duração: 1:30 Apresentação pelo programador3 do estudo sobre pesquisas avançadas em outras plataformas de learning objects, focando os campos que se utilizavam nessas pesquisas e os vários tipos de ordenação; Após uma discussão sobre os campos e os tipos de ordenamento a serem utilizados para a pesquisa avançada de LO, ficaram definidos consensualmente os que foram apresentados no capítulo 3, secção 3.5.1.

• Decisão consensual de implementar o requisito: RF2 – O sistema deve sugerir LO. Este requisito foi sugerido pelo Programador3 que argumentou que o sistema deveria tentar adaptar-se ao perfil do utilizador sugerindo-lhes LO. Por determinação do gestor da U1 o Programador3 ficou responsável pela realização de um estudo para um sistema de recomendações de LO. RG2 – Reunião geral: A gestora indicou que o requisito não era prioritário. Ficando para implementar posteriormente.

• Decisão do chefe da implementação do requisito: RF3 – O sistema deve disponibilizar um fórum de discussão associado a cada LO. O Chefe de Equipa lembrou que existia um fórum de discussão no sistema Formare e que poderia ser integrado no COLOR. Para essa integração a gestora mencionou o programador1. RG3 – Reunião geral Data: 28/11/2011; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1; U1: gestor e programador3; Duração: 2 horas O programador1 apresentou uma grande dificuldade em integrar o fórum do sistema Formare para o COLOR;

73

O chefe indicou que o requisito ficaria para uma fase final do desenvolvimento. RG2 – Reunião geral O chefe decidiu abandonar o requisito RF3 e implementar um sistema de comentários na página do estudo do LO. Isto porque o programador1 e o gestor técnico argumentaram que a implementação do fórum de raiz ou a integração do forúm do Formare não seria concretizada em tempo útil; A gestora apontou como responsável para essa tarefa o programador2. OC1 - Ocorrência Data: 28/05/2012; Participantes: programador2 O programador2 fecha os issues no Jira que estão associados ao requisito RF3 e dá o requisito por implementado.

RG4 – Reunião geral Data: 09/12/2011; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer; U1: gestor e programador3; Duração: 2:30 horas • Devido aos problemas identificados pelo programador1 no portal PoLO, a equipa decidiu abandonar o mesmo e implementar portal para o COLOR de raiz; • Apresentado um novo elemento à equipa, a designer para o novo portal que tinha como principais tarefas: estudar uma nova estrutura juntamente com a equipa, desenhar o novo layout para a plataforma e programar as CSS das páginas. PT3 – Problema técnico Data: 02/02/2012; Participantes: designer, programador1, programador2; A designer teve dificuldades com a construção das CSS, especialmente relativamente aos estilos das mesmas para os controlos Web da Telerik. O programador2 auxiliou a designer na alteração das CSS que estavam aplicadas por defeito nos controlos Web da Telerik.

• Ocorreu novo brainstorm sobre os requisitos para o COLOR a decisão da implementação do RF4 – Um utilizador deve poder rever LO. A equipa decidiu de forma unanime que um LO teria que ter um conjunto de características a ser

74

avaliadas de acordo com o seu conteúdo. Numa primeira fase definiu-se que o gestor de conteúdos, responsável pela área temática onde o LO estava inserido, faria essa avaliação. Mas a gestora de projeto alertou para o facto de no futuro o número de LO a avaliar por cada gestor de conteúdos ser enorme. A designer sugeriu então dar a possibilidade também aos alunos de efetuarem essa avaliação. No que diz respeito aos itens a avaliar sobre o LO surgiram várias ideias dos elementos: tamanho do conteúdo do LO, qualidade do LO, duração estimada, originalidade, dificuldade, facilidade de utilização, clareza e rigor. Como eram demasiadas características ficou para decidir posteriormente as que prevaleciam, e também a escala quantitativa para cada uma delas. OC2 - Ocorrência Data: 23/02/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer, programador2; U1: gestor e programador3; via: e-mail Troca de e-mails entre a equipa para decidir os itens a avaliar sobre o LO assim como a escala para os mesmos, apresentados na secção 0, na descrição do requisito. O programador3 dá início à implementação do mesmo. RG8 – Reunião geral Data: 26/04/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer; U1: gestor e programador3; Duração: 2 horas A gestora altera os itens a avaliar sobre o LO no requisito. O programador3 dá início à alteração da implementação dos mesmos. OC3 - Ocorrência

Data: 27/04/2012; Participantes: programador3
O programador3 fecha os issues no Jira associados ao requisito.

RG5 – Reunião geral Data: 12/01/2012; Participantes: Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer; programdor2; U1: gestor e programador3; Duração: 2:30 horas • A equipa decidiu implementar o RF5 – O sistema deve disponibilizar um chat associado a cada LO. Surgiu a discussão sobre um chat disponível em toda a plataforma mas a gestora alertou para o facto de esse chat ser mais propício a

75

conversas alheias ao estudo. A gestora apontou o programador2 como responsável por implementar o requisito. OC4 – Ocorrência Data: 01/05/2012; Participantes: programador2 O programador2 fecha os issues associados a esse requisito e dá por implementado o mesmo.

• A gestora apresentou o requisito RF6 – Um utilizador deve poder comunicar através de mensagens com outros utilizadores. A equipa concordou com a implementação do mesmo. A gestora definiu que o programador1 ficaria responsável pelo mesmo. OC5 – Ocorrência Data: 19/01/2012; Participantes: programador1, gestor técnico; via: e-mail O programador1 envia e-mail ao gestor da equipa técnica com a lógica de funcionamento para a implementação do sistema de mensagens (classes e modelo relacional para a BD). O mesmo responde que não há necessidade de efetuar uma construção de um sistema de mensagens, uma vez que o Formare tinha um sistema que podia ser integrado. O programador1 fica responsável por efetuar a integração e adaptação do sistema de mensagens para o COLOR. PT4 – Problema técnico Data: 20/01/2012; Participantes: programador1, gestor técnico O programado1 apresenta ao gestor técnico alguma dificuldade em perceber a lógica de funcionamento relacionada com o core do sistema de mensagens do Formare. O gestor técnico ajudou o programador1 explicando o funcionamento do sistema de mensagens. OC6 – Ocorrência Data: 24/01/2012 O programador1 fecha os issues associados ao requisito e dá por implementado o mesmo.

RG6 – Reunião geral Data: 09/02/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer; U1: gestor e programador3; Duração: 2 horas

76

• Apresentação pela designer do novo layout para o portal do COLOR. Discutiramse alguns pontos sobre o layout decidindo alterar algumas partes. • Com parte do layout já definido foi dado início à implementação de raiz do portal. Para tal os programadores e a designer definiram issues no Jira para representar as tarefas a realizar para criação do portal. RG7 – Reunião geral Data: 22/03/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, designer; U1: gestor e programador3; Duração: 2 horas Apresentação da página de login do portal pelo programador2; O programador 1 apresentou a master page geral do portal (Figura 26) e do user control do menu principal (Figura 15) já integrado na mesma; A designer participou na implementação dos estilos CSS. O gestor técnico pediu ao programador1 para elaborar um estudo sobre a manutenção de estado de vários utilizadores entre pedidos diferentes, para que se tentem usar os adequados para cada situação. DC1 – Desafio Data: 29/03/2012; Participantes: programador1 Descrito na secção 5.6.2. DC2 – Desafio Data: 30/03/2012; Participantes: programador1 Descrito na secção 5.6.2. OC7 - Ocorrência Data: 06/02/2012; Participantes: gestor técnico, programador1, programador2 O programador1 apresentou a Tabela 9 sobre um resumo das várias opções que a plataforma .NET disponibiliza para a manutenção do estado. O gestor indicou que se deveria ter em atenção sobre o uso dos vários tipos de estados. DC3 – Desafio (03/03/2012): Descrito na secção 5.6.2. DC4 – Desafio Data: 04/04/2012; Participantes: programador1 Descrito na secção 5.6.2 • A equipa decidiu implementar o requisito: RF13 – Um utilizador deve ter uma página pessoal. Foram definidos no Jira pelo programador1 os issues para este requisito.

77

RG8 – Reunião geral O programador1 apresentou a página de perfil implementada, com a master page do perfil (Figura 28) e o controlo lateral (Figura 14). A gestora do projeto indicou várias alterações à página. RG9 – Reunião geral Data: 03/05/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Duração: 2 horas O programador1 mostrou novamente a página de perfil à equipa e foram fechados os issues associados ao requisito.

Ficou definida a implementação do requisito RF15 – Um concetor deve poder indicar se um LO está apto para ambiente móvel ou não. Este requisito foi colocado pela gestora de projeto que argumentou se mais tarde poderia ser realizada uma versão mobile do COLOR e assim o conteúdo já estava preparado. OC8 – Ocorrência Data: 07/05/2012; Participantes: programador1 O programador1 adicionou uma propriedade booleana à classe do LO para indicar se o LO está ou não apto para mobile. Ficou para definido o issue para adicionar uma checkbox à página de criação do LO.

RG10 – Reunião geral Data: 01/06/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Duração: 1:30 horas • Apresentação do programador2. O chefe indicou que o programador2 iria acompanhar o desenvolvimento do portal para o COLOR de modo a tentar auxiliar a restante equipa com a sua experiência. O gestor técnico informou ainda que o programador2 estava apenas a trabalhar a part-time no projeto. • Decisão da equipa para implementar o requisito RF16 - Um aluno deve poder submeter LO. No projeto anterior não era possível ao aluno submeter LO. OC 9 - Ocorrência Data:04/06/2012; Participantes: programador3

78

O programador3 fechou os issues associados a este requisito.

A gestora sugeriu implementar o requisito RF17 - Um aluno deve poder sugerir novos temas para LO, o qual foi aceite pela equipa. A gestora colocou o programador3 responsável por implementar requisito. RG11 – Reunião geral Data: 14/06/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Duração: 1:30 horas A gestora alertou para o facto do prazo de conclusão do projeto estar próximo e o gestor técnico argumentou que requisito o requisito poderia consistir no envio de uma mensagem para o administrador do sistema com a sugestão do LO. Logo este requisito não teve qualquer implementação, uma vez que o utilizador já continha a sua caixa de mensagens.

Decisão de implementar o requisito RF18 - Um utilizador poderá ter o perfil de convidado. Este requisito foi apresentado pelo chefe de equipa para que exista um perfil apenas para consulta do sistema. OC10 – Ocorrência Data: 12/06/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; via: e-mail O programador2 indicou que o requisito não estava claro, era necessário esclarecer em concreto o que o convidado pode ou não fazer.

Decisão de implementar o requisito RF19 - Um utilizador deverá ter uma data de validade. OC11 – Ocorrência Data 20/06/2012; Participantes: programador1 O programador1 acabou a implementação do requisito. Adicionou uma propriedade (data de validade) à classe do utilizador, e

79

implementou a lógica no portal, de modo impedir o login do utilizador cuja data de validade expirou e mostra-lhe uma mensagem específica. RG12 – Reunião geral Data: 25/06/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Duração: 1:30 horas O programador1 apresentou o requisito implementado à equipa.

Decisão de implementar o requisito RF20 - Um utilizador deve poder fazer Like a um LO. OC12 – Ocorrência Data 13/06/2012; Participantes: PTin: chefe de departamento, gestor técnico, gestora, programador1, programador2, designer; U1: gestor e programador3; via: e-mail O programador1 adicionou uma propriedade à classe do LO “nLikes” para registar os likes do LO e implementou os métodos ao nível da camada de aplicação para a gestão dos mesmos; O programador1 enviou e-mail à equipa sobre o facto de ainda não existir um “botão de like” no novo layout.

5.6.2

Desafios encontradas pelo autor na implementação

Durante a participação do autor na implementação de funcionalidades e páginas Web surgiram diversos desafios a nível técnico:

Identificação DC1 DC2 DC3 DC4

Tipo Desafio Desafio Desafio Desafio
TABELA 8 - DESAFIOS DO AUTOR

Data 29/03/2012 30/03/2012 03/04/2012 04/04/2012

Local PT PT PT PT

DC1 (29/03/2012): Existiam um conjunto de páginas que se encontravam fora da plataforma, isto é não necessitavam de autenticação do utilizador para serem acedidas. Era

80

importante definir uma forma de separar os recursos que requerem autenticação daqueles que não querem, neste caso por pastas. O autor não tinha conhecimento de qualquer forma de resolver o problema. Solução: Após algum estudo o autor chegou à conclusão que é possível através da configuração do ficheiro WebConfig no atributo path do elemento location identificar o recurso ao qual devem ser aplicadas as regras definidas no interior do elemento. Este atributo também pode ser usado para especificar uma pasta existente na aplicação. Assim bastou colocar todas as páginas que não requerem autenticação numa pasta e as que requerem em outra. E definir a autenticação das mesmas no ficheiro WebConfig.

DC2 (30/03/2012): Nos controlos de listagens da Telerik era necessário no preenchimento dos dados dos controlos através de código (Codefile). Era necessário de alguma forma encontrar controlos que se encontravam dentro do elemento de listagem. Solução: Através do método FindControl, método definido na classe Control usada como classe base dos controlos servidores e páginas ASP.NET, é possível obter a referência de um controlo mantido na árvore de controlos do elemento sobre o qual o método é invocado. No caso concreto nos controlos de listagens da Telerik.

DC3 (03/04/2012) : No início da criação e implementação do portal para o COLOR foi pedido ao autor um estudo sobre gestão de estados individuais (associado a cada utilizador da plataforma) entre pedidos possíveis que a plataforma ASP.NET permite. Pois um dos problemas que a anterior versão apenas usava a propriedade Application. O autor foi estudar sobre as possíveis formas de manter o estado do utilizador entre pedidos diferentes e apresentou-os à equipa. A plataforma ASP.NET contém várias opções que permitem manter o estado individual (associado a cada utilizador) e global (partilhado pelos utilizadores da aplicação) entre pedidos.

Tipos Application

Âmbito Global

Características • “Dicionário” chave/valor com itens que mantêm informação que pode ser acedida por todos os clientes; • Pode limitar a escalabilidade da aplicação; • Exemplo da sua utilização: o this.Application[nome_da_chave] = conteúdo

81

Session

Utilizador

• “Dicionário” chave/valor que permite manter dados por utilizador; • Exemplo da sua utilização: • Necessita de cookies ou URL mangling (técnica usada para incluir a chave da Session no URL); • Pode levar à diminuição da performance da aplicação; • Exemplo da sua utilização: o Session[nome_da_chave] = conteúdo

Cookie

Utilizador

• O estado é armazenado no lado do cliente; • Os dados podem ser mantidos ao longo de várias sessões; • Tem um tamanho limitado de aprox. 4KB; • O utilizador pode desativar o uso de cookies de browser, inviabilizando assim a sua utilização; • Exemplo da sua utilização: o Cookie [nome_da_chave] = conteúdo

Cache

Global

• Os dados são partilhados por todos os utilizadores; • É possível definir o tempo que um item permanece em cache;

ViewState

POST

• Os dados são mantidos através de pedidos POST; • Os dados são mantidos através de um campo escondido; • É necessário que o ViewState esteja ativo para este funcionar.
TABELA 9 - GESTÃO DE ESTADOS (ABREU, 2011)

DC4 (04/04/2012) – Era necessário validar se as caixas de texto do formulário de edição de utilizador (Figura 28) estavam vazias, umas vez que alguns campos eram obrigatórios. Solução: De forma a evitar, a verificação da falta de conteúdo nas caixas de texto, por código no server side ou através de código JavaScript próprio, o autor aplicou a propriedade: ValidationGroup32, poupando assim tempo. A propriedade permite: • • • Validar os campos que estão vazios; Apresentar uma mensagem específica para cada um deles; Agrupar campos para serem validados mediante um único evento.

32

http://msdn.microsoft.com/en-us/library/ms227424(v=vs.100).aspx

82

CAPÍTULO 6: ANÁLISE

Neste capítulo é feita uma análise sobre os dados recolhidos no capítulo 5. Esta análise é feita mediante a técnica de análise de conteúdo, descrita no capítulo 4 secção 4.4, no que diz respeito à categorização dos problemas e limitações encontrados pelo autor. É seguido o método aberto ou exploratório de análise de conteúdo. O autor classificou cada problema/ erro ou limitação à medida que surgiram.

83

6.1

Problemas/Erros no código do sistema anterior - PoLO II
No capítulo 5, secção 5.5.1 foram constatados pelo autor alguns problemas e erros

associados à implementação de código no PoLO II. Nesta secção é feita uma análise pelo autor sobre esses mesmos problemas ou erros e as consequências que deles podem advir. Os códigos de identificação (ex., PTP1) são os já utilizados no capítulo 5. Os problemas ou erros identificados foram divididos nos seguintes grupos, pela sua não prevalência mas pelas características técnicas distintas: • • • • • • • Repetição de código e métodos (PTP1, PTP9); Métodos não usados (PTP4, PTP8); Falta de estruturas de controlo de erro (PTP2, PTP1); Falta de documentação (PTP3); Otimização (PTP5, PTP6); Falhas na normalização de tabelas (PTP11); Gerais (PTP7, PTP10).

Repetição de código e métodos: • No PTP1 o autor deparou-se com o uso de um método que replica um já existente na Framework .NET. Esta implementação causa uma perda de produtividade, uma vez que o programador perdeu tempo com a sua implementação, e podem surgir bugs com a implementação do mesmo. Pois tendo em conta que é um método nativo da biblioteca-padrão parte-se do princípio que já foram tomados cuidados pelos criadores da plataforma, por exemplo no que diz respeito a testes de bugs como o tratamento de exceções que possam ocorrer. • No PTP9 o autor constatou que existiam vários métodos que se repetiam pelas páginas da plataforma. Caso seja necessário alterar algum dos métodos é preciso localizá-lo e alterá-lo em cada uma das páginas que foi utilizado.

Métodos não usados: • O facto apresentado no PTP4 em que existe uma tabela e uma classe sem qualquer uso provoca dois problemas: a alocação de recursos físicos na base de dados para mais uma tabela e o desperdício de recursos sempre que

84

houver necessidade de o ORM verificar alterações nas classes face à base de dados. • No PTP8 foi apresentado pode provocar dificuldade na manutenção de código, uma vez que tem linhas de código sem utilidade.

Falta de estruturas de controlo de erro: • No método PTP2, o facto do objeto recebido por parâmetro não ter qualquer validação pode causar dois problemas: No caso do objeto estar nulo, é lançada uma exceção pelo sistema (NullReferenceException33), que o programador não controlou com o uso de exceções disponíveis na Framework. O que provoca que irá ser lançada, no momento da execução do programa, uma exceção pelo sistema que o programador não saberá a sua origem. Por outro lado, ainda no mesmo método, é verificado que é chamado um novo método: Process.Start34 para a conversão do vídeo, este método é inicializado num processo com um thread à parte e não existe qualquer notificação de quando este é concluído e/ou concluído com sucesso. Perante esta situação, caso o objeto recebido por parâmetro não esteja válido (verificadas as propriedades do objeto para ver se o ficheiro existe efetivamente no disco) irá ser lançada uma exceção no processo do thread do método: Process.Start. O que pode provocar que não seja gravado qualquer vídeo sem que o programador saiba disso. Após verificar a classe Process35 constatamos que a mesma permite associar o evento: Exited que é ativado através da mudança da propriedade: EnableRaisingEvents para true e que será invocado quando o processo, neste caso o processo de conversão terminar. Assim com esse evento configurado é possível saber quando o processo termina, permitindo assim verificar se ocorreu algum erro e fazendo com que o programador faça a lógica de

33

http://msdn.microsoft.com/en-us/library/system.nullreferenceexception(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/0w4h05yb(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/system.diagnostics.process(v=vs.110).aspx

34

35

85

inserção do novo ficheiro convertido, sem que este seja sempre introduzido por defeito, mesmo no caso de erro. • No método encontrado no PTP1 verificou-se também que não existe qualquer validação dos parâmetros de entrada. Como acontece na função referida acima caso seja lançada a exceção NullReferenceException, o programador não identificará a sua origem

Falta de documentação: • No PTP3 o autor deparou-se com um método que não descrevia o seu propósito (a documentação de referência apenas continha as funcionalidades gerais), foi então necessário analisar a sua implementação e verificar onde era chamado, para entender qual era o seu objetivo.

Otimizações: • No PTP5 é apresentado um exemplo do uso da estrutura GUID (Globally Unique Identifier), uma estrutura utilizada como variável que gera um identificador único para o LO. Este uso não é apropriado especialmente para o uso em questão. Após um grande número de entradas na tabela dos LO a pesquisa pode tornar-se lenta quando é feita uma busca à base de dados por um determinado GUID. Como o GUID é tratado como umas string, apesar de este ser uma chave primária que por defeito é indexada (Tripp, 2009), a forma como esta é guardada não é sequencial. Este facto faz com que exista fragmentação na tabela dos LO. • No caso do PTP6 o uso das variáveis globais, como referências pelas páginas da aplicação Web, causa alocações de memória desnecessárias, por exemplo: se estiverem três utilizadores com sessão ativa no servidor este estará a alocar quatro vezes o número de utilizadores (três) o que perfaz um total de doze alocações, das quais oito repetem dados.

Falhas na normalização de tabelas • No PTP11 a associação entre as tabelas não está normalizada. Como referido no problema a tabela segundo o mapeamento atual permite fazer múltiplas inserções dos mesmos grupos. Por exemplo se existir na tabela “permissao_utilizador_lo” (tabela usada para relacionar lo, utilizador e

86

permissão): “idLo: 1”, “idPermissao: 1” “idLo:1” é possível acrescentar múltiplas entradas com os mesmos valores, mudando apenas o identificador principal (Tabela 10). Em termos lógicos para a aplicação não há nenhum caso em que o mesmo utilizador necessite de ter a mesma permissão múltiplas vezes mapeada. Deste modo a base de dados não mantém a integridade dos dados uma vez que as chaves primárias se repetem (Hernandez, 2003)

idPermissaoUtilizadorLo 1 2 3

idLo 1 1 1

idPermissao 1 1 1

idUser 1 1 1

TABELA 10 - TABELA "PERMISSAO_UTILIZADOR_LO" COM DADOS

Gerais: • No PTP7 é mostrado um exemplo de duas mensagens diferentes mas com a mesma finalidade de erro. De modo a evitar esta situação poder-se-ia usar o sistema de Resources36 onde é possível tipificar todas as mensagens para que o programador possa verificar se a mensagem já existe e caso não exista adicioná-la à lista. Além desta vantagem é possível com este mecanismo suportar várias línguas para a aplicação Web. • A string usada no PTP10 que é partilhada entre várias páginas Web como mecanismo de permissão associado ao perfil do utilizador, é pouco intuitivo para um programador, no sentido em que a string não descreve qual é o perfil em questão. E também dificulta na manutenção do código pois no caso de ser necessário modificar a string associada ao perfil, a sua modificação não garante que todos os sítios onde essa string era usada foi modificada.

36

http://msdn.microsoft.com/en-us/library/f45fce5x(v=vs.100).aspx

87

6.2

Limitações do sistema anterior - PoLO II
Na secção 5.5.2 do capítulo 5 foram identificadas pela equipa algumas limitações ao

nível do PoLO II, que o autor categorizou em dois grupos, um com características mais técnicas, outro com características mais pedagógicas: • Portal Web (LP1, LP2, LP7). Através das ocorrências (LP1, LP2) o autor constatou que o portal do PoLO II continha limitações do aproveitamento de código e controlos ao nível das páginas. E na reunião LP7 identificou-se uma limitação ao nível da gestão das notas pessoais do utilizador • Pedagógico o o o o Perfil do Utilizador (LP3); Pesquisa por LO no sistema (LP3); Colaboração entre utilizadores (LP4); Informação em torno do LO (LP5).

Estas limitações enquadram-se ao nível da pedagógico relacionado com o sistema.

6.3

Implementação dos requisitos do COLOR
Na secção 5.6.1 do referente capítulo são apresentados os factos do processo de

desenvolvimento associadas a cada requisito e à criação do portal do COLOR. Durante esse processo houve alguns problemas, reuniões e ocorrências diversas, que o autor agrupou nas seguintes categorias, por análise qualitativa de conteúdo (segundo o processo descrito no capítulo 4): • Falta de formação específica (PT1, PT2, PT3) Houve várias circunstâncias onde os programadores não conheciam as formas de atuar concretas relativamente às ferramentas da Telerik: OpenAccess ORM e os RadControls. Os programadores e a designer tinham competências basilares mas as ferramentas eram demasiado específicas e mesmo com material de referência para estudo não compreenderam parte da sua aplicação. Os programadores estavam a ser “jogados” perante as ferramentas sem uma formação prévia que acompanhasse o material de referência.

Documentação em falta ou insuficiente (PTP4, RG3)

88

O sistema Formare não tinha documentação interna de referência sobre o sistema de mensagens nem sobre o fórum, nem mesmo documentação ao nível do código sobre o mesmo.

Falta de comunicação (RG8, OC5) No RG8 programador depois de ter implementado a página do perfil necessitou de alterar várias partes da mesma pois não houve na reunião uma definição clara do que a página deveria conter. No OC5 o programador perdeu tempo para especificar a lógica de um sistema de mensagens para o COLOR. Posteriormente foi-lhe comunicado que o sistema Formare já continha um sistema de mensagens que poderia ser utilizado no COLOR.

Falta de especificação detalhada das funcionalidades (RG8, OC5, OC10) As funcionalidades foram implementadas mediante o que ficou registado nas reuniões, sem uma especificação técnica de cada uma e uma definição clara do que se pretendia. O que provocou por vezes a implementação de funcionalidades desnecessárias desperdiçando tempo e recursos.

Falta de acompanhamento periódico (RG4, RG5, RG6, RG7, RG8, RG9) Como se pode verificar através de algumas datas, as reuniões eram realizadas com um grande espaçamento temporal. Isto provocava que os elementos de trabalho por vezes se encontrassem perdidos ao nível do desenvolvimento do projeto, nomeadamente das suas funcionalidades.

89

CAPÍTULO 7: CONCLUSÕES
Como já referido no capítulo 5 são apresentados os registos que o autor agregou durante a realização da sua participação no projeto. Esses registos são analisados no capítulo 6, onde o autor categoriza e interpreta identificando as suas consequências. No presente capítulo o autor faz uma reflexão sobre o processo e propões soluções.

90

7.1

Problemas/Erros no código do sistema anterior - PoLO II
No que diz respeito aos problemas e erros no código do PoLO II o autor apresenta as

seguintes propostas de solução: Repetição de código e métodos: • No PTP9, o autor constou repetirem-se vários métodos pelas páginas da plataforma, esses métodos podiam ser implementados numa master page base e estariam disponíveis nas páginas que herdassem dessa master page, evitando assim código repetido e tornando mais fácil a manutenção no caso de ocorrer alguma alteração. Falta de documentação: • No PTP3 se tivesse sido descrito, por exemplo utilizando a tag <sumary>37 este problema não se verificaria. Para além da descrição do método convém adicionar também a descrição das variáveis recebidas como parâmetros através da tag <param>38. Assim sempre que o método é utilizado, o programador tem acesso à sua descrição e à descrição das suas variáveis. Otimizações: • No PTP5, onde é apresentado um exemplo do uso da estrutura GUID como identificador único para o LO, era aconselhável o uso da variável integer de modo a que o ORM quando procedesse ao mapeamento torna-se o indentificador do LO em Identity. Neste caso seria bastante vantajoso ao contrário da utilização do GUID pois reduziria a fragmentação interna da base de dados, sendo que os identificadores com Identity são alocados de forma sequencial e previsível (w3schools), o que facilita o levantamento de dados nas pesquisas (Query). • As variáveis apresentadas no PTP6 deveriam conter o modificador: static39 (estáticas), uma vez que não são alteradas pelas páginas herdadas. O facto de serem definidas como estáticas significa que existe apenas uma instância do objeto independentemente do número de objetos instanciados para cada uma das classes (Microsoft), poupando assim alocações de memória. Essas

37

http://msdn.microsoft.com/en-us/library/2d6dt3kf(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/8cw818w8(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/98f28cdx(v=vs.100).aspx

38

39

91

variáveis deveriam também ser definidas como só de leitura (readonly40) para evitar que outro programador tente alterar o valor das mesmas. Gerais: • No PTP7 é mostrado um exemplo de duas mensagens diferentes mas com a mesma finalidade de erro. De modo a evitar esta situação poder-se-ia usar o sistema de Resources41 onde é possível tipificar todas as mensagens para que o programador possa verificar se a mensagem já existe e caso não exista adicioná-la à lista. Além desta vantagem é possível com este mecanismo suportar várias línguas para a aplicação Web.

No caso do PTP10 a abordagem seria a utilização de um enum42 para definir as diferentes permissões, e assim o programador acedesse à permissão guardada na ViewState sabia exatamente qual era a permissão que estava a utilizar. Exemplo: enum Perfis {Administrador, Gestor, Concetor, Aluno};

No PTP11 para resolver a situação descrita bastava que a normalização fosse devidamente aplicada, passando o esquema modelo relacional pelas três fases da normalização. Definindo o ER (Entidade-Relacionamento) para o caso em concreto, ficaria definido segundo a Figura 32.

FIGURA 32 - ER DO PTP11

40

http://msdn.microsoft.com/en-us/library/acdd6hb7(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/f45fce5x(v=vs.100).aspx http://msdn.microsoft.com/en-us/library/sbbt4032(v=vs.100).aspx

41

42

92

Após a execução da primeira forma normal, teríamos a adição de uma tabela, por exemplo: “TipoPermissao”, que define os tipos de permissão e evita que se repitam na tabela “permissao”. A execução da segunda e terceiras formas normais, não trariam mais nenhuma mudança. Após as normalizações teríamos então 4 entidades que serão transformadas nas tabelas da Figura 31. A chave primária da tabela “permissão” seria uma chave composta pelo “idUtilizador”, “idLo” e “idTipoPermissao”, identificadores que são chaves primárias nas suas tabelas e chaves estrangeiras na tabela “permissão”. Assim essa chave composta não se pode repetir, garantindo que um utilizador apenas tem um tipo de permissão para um lo. Com esta solução não só se mantém a integridade da base de dados.

FIGURA 33 - SOLUÇÃO PARA O PTP11

Falta de estruturas de controlo de erro:

93

No método PTP2, para o primeiro problema bastava verificar se o objeto estava nulo e nesse caso o programador lançava uma exceção controlada a qual tinha mais informação sobre a sua origem. Relativamente ao segundo problema apresentado, após verificar a classe usada: Process43 constatamos que a mesma permite associar o evento: Exited que é ativado através da mudança da propriedade: EnableRaisingEvents para true e que será invocado quando o processo, neste caso o processo de conversão terminar. O evento Exited é executado quando o processo de conversão termina. Nesse evento o programador pode verificar se o ficheiro existe, através do método File.Exists44 e no caso de não existir lançar uma exceção controlada a indicar que o processo falhou.

7.2

Limitações do sistema anterior – PoLO II
Nas limitações identificadas no LP1 e LP2 poderiam ser feitas melhorias. No LP1 poder-

se-ia aproveitar melhor o uso das master pages uma vez que o portal continha páginas com a mesma estrutura a nível de layout que poderiam ser agrupadas em várias páginas padrão. No LP2 a aplicação do user control, controlo baseado na classe UserControl da plataforma, poderia agrupar um ou mais controlos e ser reutilizado ao longo das paginas Web, poupando repetição de controlos e o respetivo código.

7.3

Implementação dos requisitos do COLOR
Para tecnologias específicas era aconselhável alguma formação, especialmente

quando são trabalhadores com pouca experiência a ingressar uma equipa de trabalho. A documentação e especificação formal no desenvolvimento de software são essenciais, nomeadamente ao nível da documentação técnica para os programadores quando existem várias pessoas diferentes a trabalhar no mesmo projeto. Para acompanhar de uma forma mais permanente, por exemplo todos os dias, poderia ser utilizado o método ágil Scrum, definido para a especificação e desenvolvimento de software focado nas pessoas e indicado para ambiente em que os requisitos surgem e mudam

43

http://msdn.microsoft.com/en-us/library/system.diagnostics.process(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/system.io.file.exists(v=vs.110).aspx

44

94

rapidamente (SCHWABER, 2002). Outra mais-valia deste método é o facto de um acompanhamento mais permanente sobre o processo de desenvolvimento, através de por exemplo reuniões onde cada membro da equipa indica o que fez no dia anterior, o que tem planeado fazer para o dia seguinte e no caso de ter algum impedimento ou problema este é partilhado pela equipa de forma a tentar ultrapassá-lo em conjunto.

95

96

REFERÊNCIAS BIBLIOGRÁFICAS
Abreu, Luís. (2011). ASP.NET 4.0 Curso Completo. Pag. 279. Amaral, Luís, & Leal, David. (2004). Do ensino em sala ao e-Learning. Babu, Sarat. (2001). e-Learning Standards Barbeira, Jacinto, Santos, Arnaldo, & PT Inovação. (2003). Desenvolvimento de conteúdos normalizados para ambientes de e-Learning: um estudo de caso na PT Inovação. Bogdan, Robert, & Biklen, Sari. (1994). Investigação Qualitativa em Educação, Colecção Ciências da Educação. Bradford, Peter, Porciello, Margaret, Balkon, Nancy, & Backus, Debra. (2007). The Blackboard Learning System. Burton, Mark, Brna, Paul, & Treasure-Jone, Tamsin. (1997). Splitting the Collaborative Atom: How to Support Learning about Collaboration. Computer Based Learning Unit, Leeds University. ColaboraCom. (2008). Moodle. 2014, disponível em http://colaboracomwiki.wikispaces.com/Moodle, acedido em 24 de Janeiro de 2014 Coulson, Fred. (2007). The 3 Normal Forms: A Tutorial. Dillenbourg, Pierre. (1999). Introduction: What do you mean by Collaborative Learning. In P. Dillenbourg (Ed.), {Collaborative Learning. Cognitive and Computational Approaches} (pp. 1--19). Kidlington, Oxford: Elsevier Science Ltd. Dillenbourg, Pierre, Baker, Mike, Blaye, Agnes, & O'Malley, Claire. (1996). The evolution of research on collaborative learning E. Spada & P. Reiman (Eds) Learning in Humans and Machine: Towards an interdisciplinary learning science (pp. 189-211): Elsevier. Ellis, Ryann. (2009). Field guide to learning management systems. ASTD Learning Circuits. Équille, L.B. (2004). Metadata definition and specification. Greenberg, Leonard. (2002). LMS and LCMS: What's the Difference? Heery, Rachel, & Anderson, Sheila. (2005). Digital Repositories Review. Henry, J., Henry, S., Kafura, D., & Matheson, L. (1994). Improving software maintenance at Martin Marietta. Software, IEEE, 11(4), 67-75. doi: 10.1109/52.300092 Hernandez, Michael J. (2003). Database Design for Mere Mortals (Second Edition) - A Hands-On Guide to Relational Database Design. Hoppen, Norberto, & Meirelles, Fernando S. (2005). Sistemas de informação: um panorama da pesquisa científica entre 1990 e 2003. Revista de Administração de Empresas, 45, 2435. Howard, Robert. (1988). CSCW What does it mean? (Panel Session). Paper presented at the Proceedings of the 1988 ACM conference on Computer-supported cooperative work, Portland, Oregon, USA. Humphrey, Watts S. (1989). Managing the software process: Addison-Wesley Longman Publishing Co., Inc. IEEE. (2002). Standard for Learning Object Metadata. Learning Technology Standards Committee of the IEEE. Kling, Rob. (1991). Cooperation, coordination and control in computer-supported work. Commun. ACM, 34(12), 83-88. Longmire, Warren. (2001). A primer on learning objects. Martins, João. (2010). Portal de Learning Objects. (Tese de Mestrado em Engenharia Informática), Universidade de Coimbra, Coimbra. Martins, João, & Gomes, Paulo. (2009). PoLO: Portal de Learning Objects - Análise de Requisitos. Microsoft.). Static Classes and Static Class Members (C# Programming Guide). 2014

97

Munassar, Nabil, & Govardhan, A. (2010). A Comparison Between Five Models Of Software Engineering. IJCSI International Journal of Computer Science Issues, 75, 94-101. OMG. (2013). Unified Modeling Language. Object Management Group, Inc. 2014 Pereira, Diogo. (2011). LMS Formare. 2014 Polsani, Pithamber R. (2003). Use and Abuse of Reusable Learning Objects (Vol. 3). PT Inovação. (2010). Relatório de Final de Projeto - PoLO. PT Inovação. (2011). Relatório de Final de Projeto - PoLO II. Ribeiro, Pedro. (2008). Processo e Metodologias de Software – Modelos do Processo de Desenvolvimento de Software. Royce, Winston. (1970). Managing the Development of Large Software Systems. Proceedings of IEEE WESCON, 1-9. Sá, Raul, & Gomes, Paulo. (2010). PoLO II: Portal de Learning Objects - Especificação e Desenho. Relatório interno. SCHWABER, Ken; BEEDLE, Mike. (2002). Agile Software Development with SCRUM. Sosteric, Mike, & Hesemeier, Susan. (2002). When is a Learning Object not an Object: A first step towards a theory of learning objects (Vol. 3). Stemler, Steve. (2001). An overview of content analysis. Practical assessment, research & evaluation, 7(17), 137-146. Tripp, Kimberly. (2009). GUIDs as PRIMARY KEYs and/or the clustering key. van Harmelen, Mark. (2006). Personal Learning Environments Atas da Sixth International Conference on Advanced Learning Technologies (ICALT'06). van Harmelen, Mark. (2008). Design trajectories: four experiments in PLE implementation. Interactive Learning Environments, 16(1), 35-46. w3schools.). SQL AUTO INCREMENT Field. 2014 Whyte, William Foote. (1993). Street Corner Society (pp. 320). Wiley, David. (2002). Connecting Learning Objects to Instructional Design Theory: A Definition, a Metaphor, and a Taxonomy. (pp. 3-23): The Agency for Instructional Technology.

98

Anexo

Problemas/Erros e limitações no PoLO II - Código

PTP2 (17/10/2011)
{ string novoVideo = video.Nome.Substring(0,video.Nome.Length - 3) + "swf"; Ficheiro ficheiroSWF = new Ficheiro(); ProcessStartInfo ffmpeg = new ProcessStartInfo(AppDomain.CurrentDomain.BaseDirectory+"/ffmpeg.exe"); ffmpeg.Arguments = "-i " + "\"" + video.FPath + "\" \"" + Path.GetDirectoryName(video.FPath) + "\\" + novoVideo + "\""; //ffmpeg.Arguments = "-i " + "\""+video.FPath + "\" \"" + lo.Directoria + "\\" + novoVideo+"\""; ffmpeg.CreateNoWindow = true; ffmpeg.WindowStyle = ProcessWindowStyle.Hidden; Process.Start(ffmpeg) ficheiroSWF.Nome = novoVideo; ficheiroSWF.Tipo = Path.GetExtension(novoVideo); (…) public Ficheiro ConverteVideo(Ficheiro video)

PTP3 (19/10/2011)
public void AlteraEstado(int id, string estado) { InicializaTransaccao(); DevolveLO(id.ToString(CultureInfo.CurrentCulture)).Estado = estado; scope.Transaction.Commit(); }

PTP4 (20/10/2011)
namespace ColorCore { [Telerik.OpenAccess.Persistent()] class Mensagem { private int idMensagem; private UtilizadorEAD mUtilizadorRemetente; private IList<UtilizadorEAD> mUtilizadoresDestinatarios;

[FieldAlias("idMensagem")] (…)

PTP5 (21/10/2011)

99

namespace ColorCore.LO { [Serializable] [Telerik.OpenAccess.Persistent(IdentityField = "mIdLo")] public class Lo { private Guid mIdLo; private int mTentativas; private int mDuracao; private string mDataDeCriacao; private string mTitulo; (…)

PTP6 (24/10/2011)
public class MasterBasePage : System.Web.UI.MasterPage { //Cor por defeito(paleta 1) no fundo da área dinâmica public Color corADinamicaDefeito = Color.FromArgb(248, 248, 248); //Cor por defeito(paleta 1) para a opção seleccionada no menú secundário public Color corOpMenuSec = Color.FromArgb(146, 158, 172); //Cor por defeito(paleta 1) no fundo da área da miniNuvem de conceitos public Color corMiniNuvem = Color.FromArgb(218,222,228); //Cor por defeito(paleta 1) no fundo da area dos icones dos thumbnails public Color corAreaThumbI = Color.FromArgb(182, 190, 200); (…) }

PTP7 (25/10/2011)
(…) throw new Exception("O controlo de feedBack, necessita de um RadAjaxManager registado na página principal ou MasterPage."); (…) throw new Exception("O controlo rpoxy de FeedBack, não encontrou o controlo na MasterPage/Page. Terá de adicionar um FeedBackControl à MasterPage."); (…)

PTP8 (27/10/2011)
protected void Cancelar(object sender, EventArgs e) {

100

//Response.Redirect("CriaCurso.aspx?CID="+Request.QueryString["CID"]); }

PTP10 (27/10/2011)
if (!IsPostBack) { string tipoUtilizador = myUtilizador.Funcao; if (tipoUtilizador.Equals("Administrador")) { tipo = "0"; } if (tipoUtilizador.Equals("Gestor")) { tipo = "1"; } if (tipoUtilizador.Equals("Conceptor")) { tipo = "2"; } if (tipoUtilizador.Equals("Aluno")) { tipo = "3"; } PreencheEcra(); (Page.Master as Normal).TituloBreadcrumbs = this.Title; } else { tipo = (string)ViewState["tipos"]; (…)

101

Sign up to vote on this title
UsefulNot useful