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

Dissertao de Mestrado Apresentada Por Antnio Jos Azevedo Botelho

Sob a orientao de Leonel Caseiro Morgado e Arnaldo Manuel Pinto dos Santos

UNIVERSIDADE DE TRS-OS-MONTES E ALTO DOURO

ESCOLA DE CINCIA E TECNOLOGIA

DEPARTAMENTO DE ENGENHARIAS

Vila Real, 2014

Dissertao apresentada por Antnio Jos Azevedo Botelho Universidade de Trs-os-Montes para o

cumprimento dos requisitos necessrios obteno do grau de Mestre em Engenharia Informtica, sob a orientao 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, atravs de registos sistemticos de campo de atuao. O autor aproveitou a oportunidade de integrar uma equipa de trabalho na criao do COLOR, um portal Web de learning objects focado na colaborao entre os alunos/formandos. descrito o projeto e a forma como surgiu atravs de factos e de seguida feita uma anlise e reflexo sobre os dados recolhidos durante todo o processo.

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 dissertao o resultado da unio entre o esforo e o empenho do autor e tambm de todos aqueles que o rodearam e que, de alguma forma, durante o trabalho apoiaram e incentivaram na realizao do mesmo. Agradeo ao Professor Doutor Leonel Morgado, orientador da minha investigao, que me auxiliou com o seu conhecimento cientfico, experincia e disponibilidade constante que muito contriburam para ultrapassar dificuldades e concretizar a realizao do presente trabalho. Agradeo tambm ao Doutor Arnaldo Santos pela oportunidade da participao numa equipa fantstica de trabalho e por toda a ajuda dispensada durante o mesmo. Aos meus colegas de sala lvaro Almeida e Joo Fonseca pelo apoio, fora e pela ajuda prestada sempre que necessitava. Quero agradecer minha famlia, em particular minha me, por todo o carinho, pacincia e por estar sempre presente. Aos meus amigos, em particular o Andr Pinheiro, Jos Mendona, Paulo Fernandes pelo companheirismo e por estarem sempre disponveis.

IX

NDICE
Resumo .................................................................................................................................. V Abstract ............................................................................................................................... VII Agradecimentos.................................................................................................................... IX ndice .................................................................................................................................... XI Lista de figuras ..................................................................................................................... XV Lista de tabelas .................................................................................................................. XVII Glossrio, acrnimos e abreviaturas .................................................................................. XIX Captulo 1: Introduo ........................................................................................................... 1 1.1 1.2 1.3 1.4 Enquadramento ...................................................................................................... 2 Objetivos ................................................................................................................. 3 Motivao e contribuies ..................................................................................... 4 Estrutura ................................................................................................................. 5

Captulo 2: Enquadramento tecnolgico............................................................................... 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 Repositrios de Learning Objects ......................................................................... 15 Software colaborativo........................................................................................... 17 Metodologia de desenvolvimento de software ................................................... 18 Norma SCORM ...................................................................................................... 19

Captulo 3: Projeto COLOR................................................................................................... 21

XI

3.1

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

3.1.1 3.2 3.3

Descrio do projeto ............................................................................................. 23 Casos de uso.......................................................................................................... 23

3.3.1 Package Consulta do sistema ....................................................................... 25 3.3.2 Package Gesto dos utilizadores ................................................................... 25 3.3.3 Package Gesto de contedo do LO .............................................................. 27 3.3.4 Package Gesto do LO ................................................................................... 29 3.4 3.5 3.6 Perfis de utilizadores............................................................................................. 30 Requisitos funcionais ............................................................................................ 31 Arquitetura............................................................................................................ 37 Camada de dados .......................................................................................... 38 Camada de aplicao ..................................................................................... 39 Camada de apresentao .............................................................................. 40

3.6.1 3.6.2 3.6.3

Captulo 4: Mtodo de investigao.................................................................................... 52 4.1 4.2 Estudo de Caso ...................................................................................................... 53 Caractersticas de um estudo de caso .................................................................. 54

4.2.1 Projeto de investigao ........................................................................................ 54 4.3 4.4 Recolha de dados no estudo de caso ................................................................... 56 Anlise de contedo ............................................................................................. 57

Captulo 5: Vivncia de desenvolvimento de software a nvel empresarial ....................... 59 5.1 5.2 Introduo............................................................................................................. 60 Ambiente de trabalho ........................................................................................... 60 Colaborao intra-grupo ............................................................................... 60 Comunicao ................................................................................................. 61

5.2.1 5.2.2

XII

5.2.3 5.2.4 5.3 5.4 5.5

Escrita de cdigo ............................................................................................ 62 Testes ............................................................................................................. 62

Tecnologias e ferramentas utilizadas ................................................................... 62 Panorama geral do processo de desenvolvimento .............................................. 65 Anlise do software anterior (PoLO II).................................................................. 66 Problemas/Erros no cdigo ........................................................................... 66 Limitaes ...................................................................................................... 69

5.5.1 5.5.2 5.6

Desenvolvimento do COLOR ................................................................................. 71 Implementao dos requisitos ...................................................................... 71 Desafios encontradas pelo autor na implementao ................................... 80

5.6.1 5.6.2

Captulo 6: Anlise ............................................................................................................... 83 6.1 6.2 6.3 Problemas/Erros no cdigo do sistema anterior - PoLO II ................................... 84 Limitaes do sistema anterior - PoLO II .............................................................. 88 Implementao dos requisitos do COLOR ............................................................ 88

Captulo 7: Concluses ........................................................................................................ 90 7.1 7.2 7.3 Problemas/Erros no cdigo do sistema anterior - PoLO II ................................... 91 Limitaes do sistema anterior PoLO II ............................................................. 94 Implementao dos requisitos do COLOR ............................................................ 94

Referncias bibliogrficas .................................................................................................... 97 Problemas/Erros e limitaes no PoLO II - Cdigo .......................................................... 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 gesto dos utilizadores ............................................................. 26 Figura 7 - Listagem dos utilizadores .................................................................................... 27 Figura 8 - Casos de uso de gesto de contedo do LO ........................................................ 28 Figura 9 - Listagem de reas temticas ............................................................................... 29 Figura 10 - Casos de uso da gesto 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 - Informao principal ......................................................................................... 45 Figura 17 - Objetivos............................................................................................................ 45 Figura 18 - Adio e disposio do contedo ...................................................................... 45 Figura 19 - Sntese ............................................................................................................... 46 Figura 20 - Conceitos ........................................................................................................... 46 Figura 21 - Etiquetas ............................................................................................................ 46 Figura 22 - Competncias .................................................................................................... 47 Figura 23 - Resumo .............................................................................................................. 47 Figura 24 - Etapas ................................................................................................................ 47 Figura 25 - Pgina de criao do LO .................................................................................... 48 Figura 26 - Pgina Inicial ...................................................................................................... 49 Figura 27 - Pgina de estudo do lo ...................................................................................... 50 Figura 28 - Pgina de edio do perfil ................................................................................. 51 Figura 29 - Estrutura de ferramentas usadas ...................................................................... 64 Figura 30 - Diagrama do processo de desenvolvimeno ...................................................... 66 XV

Figura 31 - Tabelas para a relao da permisso do utilizador num lo ............................... 69 Figura 32 - ER do PTP11 ....................................................................................................... 92 Figura 33 - Soluo para o PTP11 ........................................................................................ 93

XVI

LISTA DE TABELAS
Tabela 2 - Requisitos funcionais ....................................................................................................... 34 Tabela 3 - Situaes relevantes para diferentes estratgias de investigao (Yin, 1984) ............... 53 Tabela 4 - Problemas/erros no cdigo ............................................................................................. 67 Tabela 5 - limitaes ........................................................................................................................ 69 Tabela 6 - Reunies gerais de equipa............................................................................................... 71 Tabela 7 - Problemas tcnicos ocorridos ......................................................................................... 71 Tabela 8 - Ocorrncias...................................................................................................................... 72 Tabela 9 - Desafios do autor ............................................................................................................ 80 Tabela 10 - Gesto de estados (Abreu, 2011) .................................................................................. 82 Tabela 11 - Tabela "permissao_utilizador_lo" com dados ............................................................... 87

XVII

XVIII

GLOSSRIO, ACRNIMOS 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 Informao e Comunicao URL - Uniform Resource Locator VLE - Virtual Learning Environment WTCS - Wisconsin Technical College System

XIX

XX

CAPTULO 1: INTRODUO
Este captulo introdutrio apresenta um enquadramento de toda a dissertao, explicando os projetos que deram inicio mesma, e de seguida as contribuies e motivaes que levaram o autor escolha do tema. So ainda apresentados os objetivos gerais que se pretendem cumprir e a estrutura do documento, descrevendo de forma resumida o contedo que abordado em cada um dos captulos.

1.1

Enquadramento
Com o aumento do uso das Tecnologias de Informao e Comunicao nos processos

de ensino e aprendizagem surgiram os modelos de e-learning, processos pelos quais o aluno ou formando aprende atravs do contedo e interao proporcionados pelo computador, em particular atravs da Internet. Os professores ou formadores, com vrios graus de interatividade, esto habitualmente em locais fsicos distintos daqueles onde se encontram os alunos/formandos, utilizando a Internet como meio de comunicao (sncrono ou assncrono), coexistindo ainda estes modelos com outros onde podem existir sesses presenciais intermdias, designados por blended learning ou b-learning (Amaral & Leal, 2004). Com o aparecimento destas prticas, surgiu a necessidade de servios informticos de gesto de formao que apoiassem o desenvolvimento da atividade pedaggica. Designados por Learning Management Systems (LMS), tais servios vieram dar resposta a essa necessidade, sendo mais orientados a cenrios de aprendizagem formal do que a cenrios de autoaprendizagem. O crescimento da utilizao destes servios levou a um grande aumento de contedos pedaggicos compostos de texto, imagens, vdeos e outros recursos de multimdia. Para usufruir dessa variedade de contedo, de forma a tornar a sua classificao, organizao e pesquisa surgiram os learning objects (LO). Neste contexto os LO permitem a criao de pequenos componentes de material pedaggico e a sua organizao de forma a permitir a sua reusabilidade, poupando tempo e custo na produo de cursos. Os trabalhos de suporte a esta dissertao decorreram no mbito da atividade profissional do autor na Portugal Telecom Inovao, e que considerada por vrios autores a instituio pioneira da introduo do e-learning a nvel nacional, sendo responsvel desde 1993, pela Formao Tecnolgica e de Servios (FTS) do Grupo Portugal Telecom (Barbeira, Santos, & PT Inovao, 2003). Desenvolveu um LMS que suporta solues de formao e educao em ambientes de e-learning e b-learning, designado Formare. Como parte da expanso e aprimoramento da linha de produtos ao Formare, sugiu, no mbito dos learning objects o projeto PoLO (Martins, 2010), uma colaborao entre a Portugal Telecom Inovao e a Universidade de Coimbra, tendo por objetivo a criao de uma soluo que permitisse a criao, gesto e apresentao de learning objects. A criao e gesto dos contedos eram vocacionadas para os gestores e formadores, enquanto os formandos frequentavam cursos e aprendiam a partir dos contedos. Era tambm pretendido o aumento da qualidade dos contedos disponibilizados introduzindo a organizao dos contedos atravs da catalogao e a interoperabilidade para que se tornem o mais independentes possvel dos sistemas.

O projeto PoLO atingiu os objetivos a que se props, tendo sido identificadas no seguimento desse projeto algumas linhas de evoluo consequentes: o sistema no tinha ento funcionalidades para interao entre alunos, no tirando partido do esprito participativo da Web 2.0. Era considerado gerador de sobrecarga de informao, dificultando aos utilizadores a tarefa de encontrarem a informao que procuravam. Foi ento desenvolvido pelas mesmas entidades o projeto PoLO II (S & Gomes, 2010), que tinha por objetivo desenvolver essas linhas de evoluo, fornecendo ao aluno um conjunto de ferramentas que lhe permitissem encontrar informao mais rapidamente e ao mesmo tempo organizar os seus contedos. Este projeto PoLO II conseguiu desenvolver um ambiente Web 2.0 para aumentar o nvel de interao entre alunos/formandos. De modo a ultrapassar algumas limitaes do projeto PoLO II, ao nvel de espaos de aprendizagem pessoal para o ambiente de aprendizagem colaborativa e de aprendizagem no formal, surgiu a implementao 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 colaborao entres os alunos/formandos e a monitorizao das interaes, potenciando a comunicao durante o estudo do LO de forma a guiar o processo de colaborao com o principal propsito da aprendizagem. O autor integrou uma equipa da Portugal Telecom Inovao que deu seguimento aos projetos PoLO e PoLO II (sistema COLOR). Constituindo esta circunstncia uma oportunidade de analisar e refletir sobre os processos de desenvolvimento de software em contexto empresarial, o autor procedeu ao registo sistemtico da sua atuao e vivncia ao longo do processo. Nesta dissertao so expostos e analisados esses registos de atuao e essa vivncia, enquadrados pelas caractersticas das tecnologias utilizadas e por uma reflexo terica sobre o processo.

1.2

Objetivos
A presente dissertao teve como principal objetivo analisar e refletir sobre uma

experincia pessoal de desenvolvimento de software em contexto empresarial, visando contribuir para a melhor perceo pblica dos desafios e realidades do exerccio de engenharia informtica nestes contextos. Para atingir este objetivo, descreve-se o novo sistema implementado (evoluo do PoLO e PoLO II). Inicia-se esse processo pela definio de novas funcionalidades, cruzando a

identificao das limitaes dos sistemas anteriores com a viso da gesto e da equipa sobre a relevncia dessas novas funcionalidades. Desse processo, descrito no captulo 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 ligao a redes sociais e espaos de aprendizagem personalizados, tendo tambm em considerao aspetos de aprendizagem colaborativa centrados em Learning Objects. Prossegue-se dando conta de como decorreu a especificao e desenvolvimento das novas funcionalidades identificadas. Para tal, recorre-se a registos de vrios tipos: dirios de apontamentos; mensagens de e-mails trocadas entre a equipa; exemplares de documentos de especificao; atas de reunies; e documentos produzidos no mbito do projeto (requisitos, conceo e manuais). Conclui-se efetuando uma reflexo sobre todo o processo, enquadrando as decises tomadas e abordagens efetuadas na teoria sobre desenvolvimento de especificaes e software. Reflete-se igualmente de forma crtica sobre as consequncias das decises tomadas e atos efetuados. A participao do autor no projeto terminou um pouco antes de se iniciar a fase de testes, motivo pelo qual a fase de testes no integra o registo de dados da presente dissertao.

1.3

Motivao e contribuies
Aps vrios anos de estudo na rea tcnico-cientfica de Engenharia Informtica, 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 nvel pessoal, esta experincia 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 aplicaes Web. Esta dissertao d a conhecer todo o processo de desenvolvimento de software num ambiente empresarial e contribuir para aqueles que iro iniciar a sua vida profissional como Engenheiros Informticos e para as empresas que os recebem. Os futuros Engenheiros Informticos ficam a conhecer a experincia vivida na primeira pessoa, com identificao 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

podem tentar ajustar a organizao e/ou os mtodos 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 captulos: A presente introduo e

os seguintes: Captulo 2 Enquadramento tecnolgico Apresentam-se as definies dos conceitos mais relevantes relacionados com o projeto, incluindo o estado atual ao nvel do desenvolvimento na rea dos repositrios de Learning Objects, expondo de forma comparativa alguns trabalhos na rea. Captulo 3 Projeto COLOR
Descreve-se o projeto cujo desenvolvimento gerou os dados de suporte a esta dissertao, o COLOR. Resume-se a metodologia adotada, os requisitos e a arquitetura final do sistema, as suas trs camadas: aplicao, apresentao e dados.

Captulo 4 Mtodo de investigao Apresentam-se os mtodos utilizados para a recolha de dados e anlise dos mesmos. Explicita-se de que forma esse processo sustenta uma reflexo sobre a prtica de atos de engenharia informtica em contexto empresarial.

Captulo 5 Vivncia de desenvolvimento de software a nvel empresarial Descrevem-se as dimenses que caracterizam a experincia de

desenvolvimento de um software a nvel empresarial, nomeadamente as pessoas envolventes, a hierarquia da organizao, as necessidades do projeto, as dinmicas de colaborao intra-grupo e o ambiente tecnolgico e profissional de atuao. De seguida, descrevem-se os dados recolhidos durante o processo, explicitando a sua relao com a evoluo do projeto. Captulo 6 Anlise luz da literatura de enquadramento do captulo 2 so analisados os dados (descritos no captulo 5), para proporcionar uma viso crtica do processo. Captulo 7 Concluses

Com base na anlise efetuada no captulo 6, efetua-se uma reflexo sobre as consequncias dessa anlise para uma melhor perceo da natureza do desempenho de atos

de engenharia informtica em contexto empresarial, incluindo recomendaes para melhoria do processo.

CAPTULO 2: ENQUADRAMENTO TECNOLGICO

Este captulo apresenta o estado da arte relativamente aos repositrios de LO j existentes no mercado ou em fase de desenvolvimento, assim como a apresentao de conceitos associados ao e-learning, entre normas, especificaes e modelos de referncia. So apresentadas algumas plataformas de ensino e aprendizagem e feito um levantamento sobre Personal Learning Environments, devido sua importncia no aspeto colaborativo. E ainda no contexto da colaborao, so descritos alguns trabalhos relevantes na rea da aprendizagem colaborativa.

2.1

Plataformas de ensino e aprendizagem

O crescente aumento do uso das novas tecnologias juntamente com a necessidade de

se aprender o mais rpido possvel torna cada vez mais o ensino distncia, ou e-learning, uma ferramenta til nos dias atuais. So usadas as plataformas de ensino e aprendizagem para centralizar a atividade pedaggica de todo o ensino distncia. Permitem gerir a aprendizagem dos alunos, dos contedos, personalizar a aprendizagem de acordo com as necessidades dos alunos, eliminar barreiras de espao e tempo, e ainda incentivar e promover a partilha de conhecimento. As plataformas de ensino e aprendizagem so divididas em trs categorias: os LMS (Learning Management System), LCMS (Learning Content Management Systems) e PLE (Personal Learning Environment). Estes sistemas so essenciais nos processos de e-learning e b-learning e so usados por muitas instituies de carcter educativo e/ou formativo.

2.2.1

Learning Management Systems

Um sistema de gesto de aprendizagem definido como um sistema usado para a administrao, documentao, monitorizao, planeamento e descrio de programas de formao e aprendizagem, eventos online e em salas de aula, programas de e-learning e contedo de treino ou seja, de todos os eventos de aprendizagem dentro de uma organizao (Ellis, 2009). De um ponto de vista mais prtico uma aplicao Web que permite a gesto de processos de formao/aprendizagem nas perspetivas administrativas e pedaggica, ou seja, permite, do ponto de vista administrativo, a gesto de turmas e calendrios, alocao de formadores, gesto de planos de formao, e, do ponto de vista pedaggico, ao formador o planeamento e gesto de cursos e de contedos de aprendizagem, aos alunos o acesso aos materiais de formao, a atividades, a avaliao das suas competncias. Permitem a comunicao entre o formador e os formandos atravs de ferramentas tecnolgicas de comunicao como chats, e-mail, videoconferncias, etc. De seguida so apontados alguns sistemas de gesto de aprendizagem existentes.

Formare LMS O Formare uma soluo de formao e educao de e-learning e b-learning, desenvolvido pela PT Inovao, em ambientes Internet/Intranet.

Existem vrias formas e modelos de ensinar ou formar em ambiente e-learning. Cada organizao tenta seguir um modelo prprio de forma a encaixar os seus processos e alcanar os seus objetivos. A pensar na multiplicidade de perfis dos seus parceiros, a PT Inovao identifica cinco componentes principais em sistemas e-learning: A difuso de materiais pedaggicos (contedos formativos e informativos) em diversos formatos; A disponibilizao de servios intuitivos e inovadores para os professores; A interao eficaz e intuitiva com o utilizador, tanto ao nvel dos alunos como dos professores; O acesso fcil tecnologia (plataforma); Avaliao da formao.

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

Para que um curso de formao seja dado com sucesso em ambiente de e-learning a PT Inovao considera importante garantir e conceber o mesmo tendo em conta cinco componentes estratgicos (Figura 1). Tentando desta forma, minimizar a incerteza relativa aos resultados pedaggicos dos cursos de e-learning e a qualidade dos mesmos. Algumas das principais caractersticas de LMS Formare (Pereira, 2011): Visualizao da plataforma em portugus e ingls; Possibilita customizaes medida; Permite uma gesto flexvel de recursos para e-learning, para b-learning e para apoio a aulas presenciais;

Disponibiliza servios sncronos e assncronos para ensino a distncia; Possibilita a criao, gesto e difuso de contedos formativos e informativos em diversos formatos, normalizados e no normalizados;

certificado pela ADL (Advanced Distance Learning) e segue as recomendaes do standard SCORM 1.2;

Moodle O Moodle1 (Modular Object-Oriented Dynamic Learning Enviroment) um LMS de cdigo aberto, livre e gratuito, que os utilizadores podem usar, modificar e distribuir seguindo apenas os termos estabelecidos pela licena GNU Public License. Foi lanada a primeira verso, em 1999, pelo australiano Martin Dougiamas, quando este era webmaster da Curtin Universidade de Tecnologia em Perth, sendo tambm gerente do sistema WebCT (Sistema de Ensino distncia comercializado pela Blackboard). O sistema Moodle est em constante desenvolvimento pela comunidade que abrange pessoas de vrias partes do globo, professores, formadores, investigadores, programadores, administradores de sistemas. Este conjunto de pessoas centraliza as informaes, discusses e colaboraes no portal Web. Alm disso o portal conta um relatrio de perguntas frequentes, suporte gratuito, orientaes para a realizao do download e a instalao do software, documentao e a descrio de futuras atualizaes para o sistema. Para alm do uso do sistema de forma mais frequente em universidades, ainda usado por todos que tm necessidade de interagir de forma colaborativa pela Web, tais como escolas, instituies privadas, pessoas e grupos independentes. A plataforma utilizada principalmente no contexto do e-learning e b-learning, permitindo a criao de cursos on-line, pginas de disciplinas, grupos de trabalho e comunidades de aprendizagem (ColaboraCom).

Blackboard Learning System A plataforma Blackboard Learning System2 um sistema de gesto de aprendizagem baseado na Web desenvolvido e proprietrio da Blackboard Inc.

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

10

Como potenciais benefcios no uso desta plataforma so destacados os seguintes (Bradford, Porciello, Balkon, & Backus, 2007): Grande disponibilidade. possvel aceder ao sistema atravs da Internet em qualquer stio ou em qualquer momento; Rpido feedback; Comunicao melhorada. Existem vrias formas de comunicao na plataforma: Anncios, como sendo uma forma geral de comunicar entre a instituio de ensino e os alunos, assegurando que todos recebem a informao corrente e minimizando o trabalho administrativo da instituio; Discusses, possvel a criao de discusses dentro de um curso, onde o aluno pode colocar uma pergunta sobre o mesmo e os restantes podem responder, sob a vigilncia do educador, incentivando assim a participao dos alunos; Sala virtual, como sendo um ambiente sncrono de conversas permitindo a interao entre os participantes; Tracking. O sistema rastreia o percurso dos alunos nos cursos e coloca os resultados numa rea de estatsticas de cursos. Assim os educadores podem obter as estatsticas 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 so restritas a sistemas operativos especficos, ser ineficiente no uso da banda larga, particularmente quando os materiais tm que ser descarregados e ainda o custo elevado do software.

2.2.2

Learning Content Management System

Um sistema de gesto de contedo est relacionado com os LMS, mas o seu foco reside na criao, gesto e publicao do contedo que utilizado pelos LMS (Greenberg, 2002). Podemos considerar que os LCMS produzem contedos digitais para serem posteriormente disponibilizados e explorados pelos utilizadores de ambientes LMS. Oferecem aos autores, instrutores e entendidos nas matrias meios para criar contedos mais eficientemente. Estes contedos digitais de aprendizagem podem ser apresentados na forma

11

de por exemplo: texto, vdeo, ilustraes, slides, demos, etc. e so apelidados de objetos de aprendizagem (Learning Objects), apresentados na seco 2.2. Um LCMS guarda objetos de aprendizagem num repositrio central para que os designers educativos, pessoas que desenvolvem contedo multimdia de aprendizagem, os possam ir buscar a anexar em cursos personalizados com a ajuda dos professores. Os cursos tradicionais contm mais contedos sobre um tpico, do que aquelas que o aluno apenas consegue ou precisa assimilar. Ao dividir esses contedos dos cursos em objetos de aprendizagem, disponibilizando-os de acordo com as necessidades, os especialistas que desenvolvem contedos podem beneficiar da aprendizagem na hora e na dose certa, evitando desenvolver cursos inteiros e de os adaptar a audincias mltiplas. Isto elimina esforos de desenvolvimento repetidos e permite a rpida agregao de contedo personalizado (Greenberg, 2002). No mercado encontram-se algumas solues comerciais de gesto de contedo: Xyleme LCMS3, OutStart4, GeoLearning LCMS5, Kenexa LCMS6. O ATutor7 uma soluo open source baseada na Web para a gesto de contedo que j adotou a norma de empacotamento de contedo IMS e a norma SCORM, permitindo assim que os criadores criem contedo reutilizvel entre sistemas de e-learning diferentes.

2.2.3

Personal Learning Enviroments

A existncia de uma srie de abordagens e perspetivas de vrios autores tornam difcil chegar a uma nica definio estvel 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 prpria 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 constitudo por todos os recursos disponveis para o

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

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 servios Web, dispositivos mveis, etc. Van Harmelen considera que os PLE mais do que um software so um conceito. O conceito de que cada utilizador gera o um ambiente pessoal onde vrias peas tecnolgicas interagem e no apenas uma criada especificamente para ser um PLE, o resultado dos atos dos utilizadores. Identifica que os PLE so fundamentados pela necessidade de um sistema que oferea aos alunos um padro ao nvel da interface mas com os diferentes sistemas de e-learning das intuies, a abordagem pedaggica que defende que os sistemas de e-learning devem ser centralizados e controlados pelos aprendentes, e a necessidade que os alunos por vezes tm de trabalhar offline.

2.2

Learning Objects
Os documentos em papel e os materiais de vdeo, udio e imagem, com o avano da

tecnologia tm sido transformados em documentos digitais. Atualmente h diversos contedos digitais disponibilizados nas plataformas de ensino e aprendizagem (seco 2.1), que proporcionam de maneira prtica as condies indispensveis para que estudantes, professores e formadores os utilizem. Esses contedos digitais, quando descritos segundo padres denominados metadados como materiais de aprendizagem online (MERLOT) reutilizveis, so conhecidos como learning objects (LO). Os LO devem ser reutilizveis e independentes da plataforma, de modo a resolverem os problemas relacionados com a falta de flexibilidade dos sistemas de e-learning. necessrio que os sistemas disponibilizem contedos de tamanho reduzido e que ofeream rapidez e simplicidade aos utilizadores. No existe um conceito definido para o termo learning object, sendo diferente entre autores e organizaes: Qualquer recurso digital que pode ser reutilizado como apoio aprendizagem (Wiley, 2002); Qualquer entidade, digital ou no, 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 pedaggicos e que possui, internamente ou atravs de associao, sugestes sobre o contexto apropriado para a sua utilizao (Sosteric & Hesemeier, 2002);

13

Unidade de contedo de aprendizagem independente e auto-compreensvel que est predisposta a ser reutilizada em mltiplos contextos instrutivos (Polsani, 2003). Vrios autores corroboram a posio de que independentemente do tipo de aplicao educativa, os LO apresentam as seguintes caractersticas (Longmire, 2001): Reusabilidade: o LO pode ser usado em diversas plataformas de aprendizagem diferentes; Facilidade de atualizaes, pesquisas e gesto do contedo: com a utilizao dos padres de metadados existentes possvel obter informaes sobre os learning objects, como o seu contedo utilizao, autor, tamanho, formato, e outras, tornando-o compreensvel para diversas plataformas; Modularidade: um learning object pode conter outros learning objects, ou estar contido em um ou mais materiais de aprendizagem. Deve ser construdo de forma que os utilizadores no 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 definio partilhada por vrios autores. Em (quille, 2004) essa definio alargada, indicando que os metadados devem estruturar os dados para que possam ser usados como dicionrios quando necessrio usar os dados neles contidos. Vrios autores referem que os metadados fornecem informaes sobre um determinado recurso, de forma a promover a interoperabilidade, pesquisa, partilha, integrao, utilizao/reutilizao, gesto e localizao dos mesmos de maneira mais eficiente. Os metadados so um conjunto de palavras, frases que resumem ou descrevem o contedo de um site, uma pgina Web ou um recurso digital com o objetivo de beneficiar o trabalho de agentes de pesquisa (Babu, 2001). Existem vrias iniciativas de empresas e organizaes para a conceo e implementao de metadados para LO: DCMI8 (Dublin Core Metadata Iniciative), LOM

http://dublincore.org/

14

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

2.4

Repositrios de Learning Objects

De modo a evitar um aumento dos LO de forma desorganizada foram criados os

repositrios de learning objects, destinados ao armazenamento e gesto dos mesmos e sua disponibilizao na Internet. Os repositrios contribuem para a melhoria da reutilizao dos LO, pois facilitam na sua organizao e a catalogao. So ainda entendidos como estruturas de encaixe para os learning objects, para que os mesmos sejam acoplados e interligados. Os repositrios de LO permitem submeter, armazenar e pesquisar Learning Objects. Um repositrio digital diferencia-se de outras colees digitais pelas seguintes caractersticas (Heery & Anderson, 2005): O contedo depositado num repositrio seja pelo criador do contedo, detentor do contedo ou por terceiros; A arquitetura do repositrio gere o contedo assim como metadados; O repositrio oferece um conjunto mnimo de servios bsicos, como por exemplo put, get, pesquisa e controlo de acesso; O repositrio deve ser sustentvel e confivel, bem suportado e bem gerido.

Repositrios de LO existentes
MERLOT
O MERLOT11 (Multimedia Educational Resource for Online Learning and Teaching) foi um projeto que comeou com algumas universidades do estado da Califrnia (USA) e cresceu incorporando as grandes universidades norte-americanas. Atualmente constitudo por um consrcio 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 eficincia do ensino e aprendizagem, expandindo a quantidade e a qualidade de materiais de aprendizagem online. uma ferramenta de software baseada na Web e

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, colees, servios, e pesquisa no ensino superior. O sistema no 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 tcnicos multimdia, designer, editores e estudantes. Todos os objetos esto disponveis 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 introduo, um projeto que resultou da uma parceria entre a PT Inovao e pela Universidade de Coimbra, com o propsito da explorao de tcnicas e metodologias de integrao e gesto do conhecimento para a gerao de Learning Objects (Martins & Gomes, 2009). Permite a criao, gesto e apresentao de learning objects assente numa lgica de autoformao e de ensino distncia. Pretende aumentar o potencial dos contedos disponibilizados, na sua catalogao, interoperabilidade e reutilizao. Por fim, o visou a integrao com o Formare LMS, mencionado na seco 2.2.1, capacitando-o para disponibilizar contedos na forma de Learning Objects. Foi ento criado um sistema que oferece solues quanto s carncias na rea da aprendizagem distncia, atravs de um ambiente simplificado, prtico, onde so disponibilizados contedos sob a forma de Learning Objects, potenciados por uma classificao baseada em conceitos e etiquetas, e compatveis com a norma SCORM. Para a descrio dos metadados, o PoLO baseado na norma SCORM, trazendo esse fato vantagens ao nvel da interoperabilidade, isto , da possibilidade da utilizao de contedos em locais diferentes, e da reutilizao, ou seja, da possibilidade de utilizar contedos 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 limitaes. Por exemplo, a aplicao no suportava aprendizagem colaborativa, no existindo qualquer tipo de funcionalidade que permitisse a interao entre alunos, como fruns e mensagens instantneas, por exemplo. Estas limitaes deveram-se s prioridades do PoLO terem envolvido sobretudo a criao e execuo de LO, de forma rpida e simplificada, visto ser essa a principal necessidade do mercado (PT Inovao, 2011). Devido identificao de algumas destas limitaes surgiu o projeto COLOR (Collaboration Learning Objects Repository) que tem como principal objetivo acrescentar a dinmica da aprendizagem colaborativa ao anterior projeto. O projeto COLOR tem tambm um portal completamente novo, com um design mais moderno e apelativo para a experincia do utilizador. No captulo 3, na seco 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 colaborao 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 mltiplos indivduos trabalharem em conjunto, no entanto, no basta juntar um grupo de indivduos para que estes trabalhem efetivamente. necessrio 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 gesto (Ehrlich, 1999).

17

Software colaborativo na aprendizagem

De modo a ultrapassar a barreira da distncia e com a evoluo das Tecnologias de Informao e Comunicao, os utilizadores comearam a usar os sistemas para trabalharem em grupo. O que tambm se refletiu na educao, 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 vrios sistemas colaborativos disponveis a nvel comercial. Estes sistemas dispem unicamente de ferramentas arbitrrias para a comunicao. necessrio mais do que isso para que exista colaborao entres os participantes. Podemos auxiliar o processo de colaborao incluindo o mesmo no projeto dos sistemas e cursos, ou monitorizando a interao, e guiando o processo conforme necessrio (Dillenbourg, 1999). O projeto COLOR implementa alguma monitorizao da interao dos intervenientes, de modo a tentar analisar o histrico das interaes e um diagnstico dos pontos fortes e fracos.

2.6

Metodologia de desenvolvimento de software

O processo de software refere-se a um conjunto de ferramentas, mtodos e prticas

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 to 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 informao associada que necessria para o desenvolvimento de um software. Todas as organizaes tm um prprio processo para o desenvolvimento de software mas normalmente estas abordagens so baseadas em um dos modelos genricos: modelo em cascata, modelo iterativo, modelo em V, modelo em espiral (Ribeiro, 2008). O fracasso de vrios projetos de software de alto nvel na dcada de 60 levou criao 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 srie de etapas sequenciais, comeando com a especificao do sistema.

18

Anlise de requisitos

Especificao

Implementao

Integrao

Teste

Instalao

Manuteno

FIGURA 2 - FASES DO MODELO EM CASCATA

Para o desenvolvimento do pro projeto de suporte presente dissertao, foi seguido este modelo devido a ser fcil de implementar e perceber, ser muito usado e conhecido, consolida bons hbitos: 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 mtodo utilizado pela PT Inovao para o desenvolvimento dos seus projetos.

2.7

Norma SCORM
Durante o desenvolvimento do projeto de suporte presente dissertao, dissertao no que diz

respeito ao desenvolvimento do dos contedos foi utilizada a norma SCORM. A norma SCORM (Sharable Content Object Reference Model; ADLI, 2001a) 2001 define um modo de agregao de contedos, um ambiente de execuo e sequenciamento e navegao learning objects. um conjunto de padres e especificao para e-learning earning baseado em tecnologia Web. O modelo surgiu do Departamento de Defesa dos EUA como resultado s necessidades de educao do governo, da indstria e na da academia estabelecendo a iniciativa Advanced Distributed Learning13 (ADL), em 1997. Esta inicia iniciativa tiva definiu requisitos de alto nvel para contedo de aprendizagem, tal como reutilizao, acessibilidade, durabilidade e interoperabilidade para melhorar prticas existentes, promover o uso de aprendizagem baseada em tecnologia e fornecer uma base econm econmica ica para o investimento. A verso chamase SCORM 2004, datando a sua mais recente edio (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 contedo especfico de modo a produzir recomendaes para implementaes consistentes pela comunidade. A implementao da norma SCORM visou dar ao PoLO interoperabilidade, isto , a possibilidade da utilizao de contedos em locais diferentes, e reutilizao, ou seja, a possibilidade de utilizar contedos distintos e com objetivos completamente diferentes (Martins & Gomes, 2009).

20

CAPTULO 3: PROJETO COLOR

Neste captulo apresentado em detalhe o projeto COLOR. Descreve-se a metodologia de desenvolvimento adotada, a arquitetura, os perfis de utilizadores, a especificao e as funcionalidades implementadas. A arquitetura do projeto baseada num projeto anterior (designado PoLO II, seco 0), sendo composta por trs camadas principais: camada de dados; camada de negcio; e camada de interface. As funcionalidades implementadas surgem da vontade de ir alm das limitaes do anterior projeto PoLO II e focam-se em trs reas principais: a ligao a redes sociais; ligao a espaos de aprendizagem colaborativos; e a introduo de mecanismos de apoio aprendizagem pessoal.

21

3.1

Metodologia adotada
3.1.1
PT Inovao

Equipa

Universidade1

Chefe de departamento

Gestor de equipa (Parte tcnica)

Gestora de equipa

Gestor de equipa (Professor)

Programador1

Programador2 (Tempo Parcial)

Designer

Programador3 (Aluno)

FIGURA 3 - ORGANIGRAMA DA EQUIPA

A equipa do projeto foi constituda por dois grupos: o grupo da PT Inovao e o grupo de uma universidade portuguesa (Universidade1, U1). O organigrama acima mostra esquematicamente os distintos nveis de hierarquia e a relao entre eles durante o desenvolvimento de todo o projeto. Na parte da PT Inovao o chefe de departamento era o responsvel principal por todo o projeto, seguido na hierarquia dos dois gestores. A gestora da equipa era a responsvel ativa sobe os trs elementos de trabalho. E o gestor de equipa da parte tcnica era responsvel e acompanhava todo o trabalho de implementao do cdigo do projeto. Na parte da universidade o gestor de equipa (professor) era o responsvel 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 responsvel pelo desenho da interface grfica do prottipo, definindo tambm juntamente com os programadores a estrutura da mesma.

22

3.2 Descrio do projeto

O projeto COLOR nasceu a partir das limitaes e problemas identificados pela equipa no anterior projeto PoLO II, apresentados no captulo 5. Destas limitaes e da inteno de evoluir a partir do projeto PoLO II nasceu o novo projeto para o qual a equipa definiu os requisitos a implementar, apresentados na seco 3.5 do presente captulo. O novo sistema foi designado COLOR (COllaboration Learning Objects Repository) e as funcionalidades focaram-se em cinco grandes reas: a) A anlise e construo do perfil de utilizador, tendo em particular ateno a forma como este interage com a rede de contactos (Polsani, 2003); b) Desenvolvimento de mecanismos que permitam ao utilizador pesquisar e encontrar a informao desejada rapidamente, atravs de tcnicas de information retrieval: c) Construo de ferramentas que impulsionem a colaborao entre os utilizadores do sistema, melhorando o ambiente Web 2.0 do PoLO II: d) Desenvolvimento de ferramentas que possibilitassem a participao do aluno na definio de contedos. Considerou-se relevante que o aluno sentisse que o seu papel ativo seria fundamental para o crescimento do contedo do sistema: e) Criao de funcionalidades de apoio atividade pedaggica que a equipa considerasse relevantes. O COLOR adotou o seguinte processo de apoio especificao e desenvolvimento: Estudo de vrios sistemas de Learning Objects para a formao profissional, como suporte formao formal e informal; Especificao e desenvolvimento de um prottipo do modelo de colaborao a implementar sobre o PoLO II; Realizao de testes plataforma.

3.3

Casos de uso
Os diagramas de casos de uso tm sido uma das atividades da fase inicial do processo

de desenvolvimento de software (orientado a objetos) e representam os requisitos funcionais do sistema. Esta representao composta por atores, casos de uso e associaes entre eles. Os casos de uso representam as funcionalidades de um sistema (OMG, 2013).

23

Quando existem vrios casos de uso ou atores possvel usar os packages (pacotes) de casos de uso para organizar o modelo. Excetuando o package da Gesto dos LO (Figura 8), os restantes casos de uso foram consultados nos relatrios de especificao dos anteriores projetos: PoLO (PT Inovao, 2010) e PoLO II (PT Inovao, 2011). Na Figura 4 mostrado o diagrama geral de casos de uso do sistema. mostrado atravs de packages as principais aes dos vrios tipos de perfil de utilizador, atravs da representao de atores. O Utilizador do sistema e o Convidado so generalizaes do ator abstrato Utilizador. E os atores: Administrador, Coordenador/Professor, Gestor de contedos e Aluno so generalizaes do Utilizador do sistema.

Utilizador

Estudo dos LO Utilizador do sistema Convidado

Consulta do sistema

Administrador

Coordenador/Professor

Gestor de contedos

Aluno

Gesto dos utilizadores

Gesto dos Contedos dos LO

Gesto 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 aes 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 Gesto dos utilizadores

Para os casos de uso da gesto dos utilizadores (Figura 6) a equipa de desenvolvimento apenas interagiu sobre a camada de apresentao construindo as pginas onde o administrador gere os utilizadores, fazendo invocao aos mtodos da camada de aplicao. Como exemplo apresentada na Figura 7, a pgina da listagem dos utilizadores do sistema, referente ao caso de uso Listar utilizadores.

25

Gesto dos utilizadores

Adicionar utilizador

Remover utilizador Administrador Listar utilizadores

Editar utilizador

FIGURA 6 - CASOS DE USO DA GESTO DOS UTILIZADORES

26

FIGURA 7 - LISTAGEM DOS UTILIZADORES

3.3.3 Package Gesto de contedo do LO

Tambm para os casos de uso da gesto de contedo do LO ( (Figura Figura 8) a lgica da camada de dados e da camada de aplicao j estava construda. Salvo algumas alteraes, a equipa apenas interagiu com a camada de apresentao construindo as pginas necessrias para os casos de uso. Como exemplo apresentada na Figura 9 a pgina da listagem das reas temticas do caso de uso Listar reas temticas, e caixa de texto para o utilizador pesquisar do caso de uso Pesquisar por rea temtica.

27

Gesto de contedo do LO Inserir rea temtica Listar reas temticas <<extend>> <<extend>> <<extend>> Gerir reas temticas <<extend>> Pesquisar rea temtica Remover rea temtica

<<extend>>

Gestor de Contedos

Associar gestor a rea temtica

Gesto do cursos

<<extend>> <<extend>>

<<extend>>

Criar curso

Listar cursos

Remover curso

FIGURA 8 - CASOS DE USO DE GESTO DE CONTEDO DO LO

28

FIGURA 9 - LISTAGEM DE REAS TEMTICAS

3.3.4 Package Gesto do LO

Os requisitos implementados pela equipa foram mais direcionados para gesto e estudo do LO. Nos casos de uso apresentados na Figura 10 a equipa interagiu nas trs camadas cam da arquitetura alterando e implementando os requisitos assinados.

29

RF 1

Gesto de LO
P esquisar de for ma avanada

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 GESTO 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 funes de cada um, e adicionou o perfil de convidado:

Administrador - o qual faz a gesto de todo o sistema, em especial dos vrios utilizadores; Gestor de contedos - responsvel pelos contedos dos LO, fazendo a validao e classificao dos mesmos; Coordenador/ Professor - faz a gesto dos LO, apenas podendo efetuar operaes bsicas sobre os mesmos: criao, remoo e edio; Aluno - perfil que faz a visualizao, estudo, pesquisa e criao de LO; Convidado - apenas pode visualizar o sistema no podendo criar LO.

30

3.5

Requisitos funcionais
Esta seco apresenta os requisitos definidos at data em que o autor deixou o

projeto e a informao apresentada foi consultada nos documentos de anlise 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 pgina pessoal

Encontrar a informao desejada

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

Colaborao entre utilizadores

O O sistema deve disponibilizar um frum de discusso associado a cada LO O sistema deve disponibilizar um chat associado a cada LO Um Um utilizador deve poder comunicar atravs de mensagens com outros utilizadores Um utilizador deve poder fazer Like a um LO Um Um utilizador deve ter uma pgina pessoal

Participao do aluno nos contedos

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

Apoio atividade pedaggica

O O sistema deve fornecer gesto global de notas pessoais O O sistema deve enviar notificaes de novas verses de LOs aos utilizadores Um concetor deve poder indicar se um LO Um est apto para um ambiente mvel ou no 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 informao e no sejam formativos

FIGURA 11 - REAS DOS REQUISITOS FUNCIONAIS

Como foi descrito na seco 3.2, , os requisitos definidos para o projeto podem ser agrupados em cinco reas. Estes requisitos foram definidos mediante os problemas e as limitaes apresentadas na seco 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 competncias que o utilizador j obteve atravs do estudo dos LO.

A segunda rea consiste no desenvolvimento de mecanismos que permitam ao utilizador pesquisar e encontrar a informao desejada rapidamente, usando tcnicas de information retrieval. A terceira rea engloba os requisitos que impulsionam a colaborao entre os utilizadores do sistema. A quarta rea consiste no desenvolvimento de ferramentas que possibilitem a participao do aluno na definio de contedos.

A quinta e ltima rea consistem na criao de funcionalidade que apoiem a atividade pedaggica do sistema.

A seguinte tabela apresenta todos os requisitos funcionais.

Cdigo
RF1 RF2 RF3 RF4 RF5 RF6 RF7 RF8 RF9 RF10

Descrio
O utilizador dever poder pesquisar por LO O sistema deve sugerir LO aos alunos O sistema deve disponibilizar um frum de gesto 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 atravs de mensagens com outros utilizadores Um utilizador deve poder seguir aes 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 informao e no sejam formativos

RF11 RF12 RF13

O sistema deve fornecer gesto global de notas pessoais Os LO devem ser validados antes de estarem disponveis para os alunos Um utilizador deve ter uma pgina pessoal

33

RF14 RF15 RF16 RF17 RF18 RF19 RF20

O sistema deve enviar notificaes de novas verses de LO aos utilizadores Um concetor deve poder indicar se um LO est apto para um ambiente mvel ou no 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

Descrio de cada requisito

RF1 - O utilizador dever poder pesquisar por LO
J era possvel 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 avanada de LO por relevncia, popularidade, por data e por ttulo. 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 relevncia. Para esta pesquisa so 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 sugestes devem-se basear em dados sobre o utilizador recolhidos anteriormente. RF3 - O sistema deve disponibilizar um frum de gesto associado a cada LO De forma a promover a discusso entre os utilizadores em torno do LO esta funcionalidade pretende a criao de um frum 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 reviso 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 representao da escala qualitativa. Os dados do LO a classificar so os seguintes: qualidade do LO, originalidade, facilidade de utilizao e rigor. O revisor dever ainda indicar se recomendaria ou no o LO a outro utilizador. Apenas os gestores de contedos podero convidar utilizadores a serem revisores. Pode ser pedido a qualquer tipo de utilizador para fazer a reviso. RF5 - O sistema deve disponibilizar um chat associado a cada LO Neste requisito pretendida a criao de um sistema de mensagens instantneas para os utilizadores comuniquem entre si em cada LO, de modo a discutirem assuntos relacionados com o contedo do LO. Neste chat apenas estaro os utilizadores que estejam no momento a estudar o LO, para assim trocarem ideias sobre o mesmo. RF6 - Um utilizador deve poder comunicar atravs de mensagens com outros utilizadores Este requisito permite que os utilizadores do sistema comuniquem atravs de mensagens de forma assncrona. As tarefas deste requisito incluem: O envio de mensagem para um utilizador; A resposta mensagem, em que esta conter o histrico da conversa decorrida at ao momento. RF7 - Um utilizador deve poder seguir aes de outros utilizadores O requisito permite que um utilizador tenha a possibilidade de seguir outros utilizadores e tambm de receber notificaes 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 ao 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 informao e no sejam formativos Com este requisito o criador de contedo ir ter uma opo na criao do LO, que indique se este formativo, isto , se tem avaliao e conta para histrico, ou se apenas informativo com o intuito de partilha de informao.

35

RF11 - O sistema deve fornecer gesto global de notas pessoais O utilizador deve ter uma forma de escrever e visualizar as suas notas. Estas notas devem ser independentes do stio em que o utilizador se encontre na plataforma, para que o mesmo as possa consultar e editar sempre que desejar. Esta gesto de notas pessoais deve conter dois tipos de notas: notas associadas a um LO e notas gerais, que o utilizador poder tirar podendo no estarem associadas a algum LO. RF12 - Os LO devem ser validados antes de estarem disponveis para os alunos Este requisito obriga que exista uma validao do LO antes do mesmo estar disponvel para ser visualizado. Esta validao apenas pode ser realizada por gestores de contedos e administradores, no caso dos gestores de contedos, estes apenas podem validar os LO da sua rea de gesto. RF13 - Um utilizador deve ter uma pgina pessoal Este requisito consiste na criao de uma pgina que deve conter a informao relacionada com o utilizador. Esta pgina pode ser visualizada pelo prprio utilizador e pelos seus contactos. A pgina pessoal do utilizador deve conter: Informao pessoal e tambm a opo de privacidade do mesmo, indicando se o perfil privado ou publico; Campo para indicar se o utilizador est ativo e a opo 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 notificaes de novas verses de LO aos utilizadores Para aqueles LO que o utilizador j tenha frequentado, sempre que existam novas verses dos mesmos, o sistema deve notificar os utilizadores. RF15 - Um concetor deve poder indicar se um LO est apto para ambiente mvel ou no

36

Este requisito consiste na adio de um atributo ao LO, o qual permita ao criador do LO indicar se este est preparado para um ambiente mvel ou no. RF16 - Um aluno deve poder submeter LO Inicialmente apenas os concetores podiam submeter LO, mas de forma a enriquecer o sistema os alunos podero submeter tambm LO para serem aprovados. Aps a submisso ser aprovada, o respetivo utilizador passa a ter tambm funes 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 prtica, esta sugesto consiste numa mensagem enviada dos alunos para os administradores, ficando assim estes com a noo das necessidades de formao. RF18 - Um utilizador poder ter o perfil de convidado Este requisito implica, na prtica, a adio de um novo tipo de perfil de utilizador: o convidado. Este novo perfil como o prprio nome indica, um convidado, que apenas poder efetuar consultas sobre o sistema, mas no edies, avaliaes, sugestes ou criaes. RF19 - Um utilizador dever ter uma data de validade Esta funcionalidade consiste na adio de um novo dado ao utilizador: data de validade. O utilizador ir ter um prazo de validade, aps o qual no 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 soluo de arquitetura usada para a implementao do sistema baseou-se na arquitetura de trs camadas principais, em que existe uma clara separao das mesmas: dados, aplicao e apresentao.

As camadas so as seguintes:
Dados - vo ser armazenados os dados relativos aos LO, registos de utilizao e utilizadores, competncias, etiquetas, ndices, gesto de verses, fruns, registos

37

dos chats, monitorizao dos alunos, notas tiradas pelos utilizadores, contedos das pginas pessoais, notificaes e seguimento de utilizadores; Aplicao - efetua as operaes lgicas sobre o negcio, com destaque para: a gesto do repositrio, gesto da ontologia de representao, pesquisa, sugesto/recomendao e criao de LO; Apresentao - apresenta o contedo ao utilizador e permite a interao 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 mdulos, que serviram de

Repositrio de LO, Logs, Utilizadores, Contactos e gesto de verses: mdulo responsvel pelo armazenamento dos seguintes tipos de informao: o o o o o LO: Learning Objects Logs: registos de utilizao do sistema. Utilizadores: informao sobre utilizadores do sistema. Verses: informao sobre as verses de cada LO do sistema. Contactos: informao sobre os contactos de cada utilizador do sistema.

Ontologia de Competncias, Indexao, Etiquetas e reas Temticas: mdulo responsvel pelo armazenamento de quatro tipos fundamentais de informao para pesquisas e sugestes: o Ontologia de Competncias: estrutura de conhecimento que armazena as competncias possveis. o Estrutura de Indexao: estrutura de indexao que armazena informao associativa entre competncias e utilizadores e LO. o Estrutura de Etiquetas: estrutura que armazena informao associativa entre etiquetas e utilizadores e LO. o Estrutura de reas Temticas: estrutura que armazena informao associativa entre LO e reas temticas.

No COLOR, alterou-se o primeiro destes mdulos, para armazenar dados relativos s novas funcionalidades: mensagens, chats, logs das aes dos alunos, anotaes, notificaes, formato tcnico dos LO, data de validade dos utilizadores, dados sobre se um LO est apto

38

para um ambiente mvel ou no, nmero de Likes dos LO e dados relativos ao seguimento dos utilizadores. O mdulo ficou definido da seguinte forma: Repositrio de LO, logs, utilizadores, contatos, gesto de verses, mensagens, Wikis, registos dos chats, monitorizao dos alunos, notas tiradas pelos utilizadores, contedos das pginas pessoais, notificaes. As alteraes face ao PoLO II foram: o LO: passou a ser armazenada informao sobre o nmero de Likes dos LO, sobre o seu destacamento, uma indicao sobre se o LO est apto para ambientes mveis ou no e sobre o formato tcnico do LO. Esta informao foi adicionada quela que o LO j armazenava no PoLO II. o Logs: registos de utilizao do sistema, onde passaram a ser armazenados logs de vrias aes dos alunos, como das suas interaes e tempos gastos nas atividades.

o Utilizadores: informao sobre utilizadores do sistema, que pode ser recolhida de outro subsistema Formare. o Verses: informao sobre as verses de cada LO do sistema. o Contatos: informao sobre os contactos de cada utilizador do sistema. o Mensagens: informao sobre as mensagens trocadas entre os utilizadores. o Chat: registos de mensagens instantneas que os utilizadores podero trocar quando estiverem a realizar um LO. o Seguimento de utilizadores: informao relativa ao seguimento de utilizadores.

3.6.2

Camada de aplicao

Do PoLO II, a camada de aplicao proporcionou ao COLOR os seguintes mdulos: Gestor do Repositrio: mdulo que implementa todos os mtodos de acesso entre os mdulos da camada de negcio e o repositrio de informao (LO, Logs e Utilizadores). Gestor da Base de Conhecimento: mdulo que implementa todos os mtodos de acesso entre os mdulos da camada de negcio e a base de conhecimento (Ontologia de Competncias, Indexao, Etiquetas e reas temticas).

39

Pesquisa: mdulo da camada de negcio que recebe pedidos da camada de interface para efetuar pesquisas e que as vai processar.

Sugesto / Recomendao: mdulo da camada de negcio que recebe pedidos da camada de interface para efetuar sugestes e recomendaes e que as vai processar.

Criao de LO: mdulo da camada de negcio que recebe pedidos da camada de interface para a criao de LO, e que as realiza.

No COLOR, foi alterado o mdulo de pesquisa, de modo a ser possvel ordenar os resultados da pesquisa por popularidade e de modo a que sejam apresentados resultados tendo em conta o perfil do utilizador. Quanto ao mdulo Gestor do Repositrio, foram implementados nele o chat e o sistema de mensagens, o sistema de anotaes. Foram adicionados mtodos que permitem aos utilizadores fazerem Like nos LO. Foi ainda implementada neste mdulo a funcionalidade de seguimento de utilizadores. Foram ento adicionadas as seguintes classes: Chat: classe que faz a ligao base de dados e gere os dados relativos ao chat; Mensagem: classe obtida do sistema Formare que faz ligao base de dados e gere os dados relativos s mensagens trocadas entre os utilizadores; Pedido de submisso: classe que faz a ligao base de dados e gere os pedidos de submisso.

E modificadas as seguintes:
UtilizadorEAD modificou-se a classe para que seja possvel o utilizador ter o perfil de convidado e adicionaram-se campos da rea da interao 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 mvel. AnotaoLO foi modificada esta classe para que as notas tiradas pelos utilizadores possam ser vistas de uma forma global, e no apenas dentro de cada LO.

3.6.3

Camada de apresentao

Para o chefe do departamento o PoLO II apresentava um portal desadequado personalidade da empresa e com problemas a vrios nveis apresentados no captulo 5, seco 5.4.

40

O portal Web do COLOR foi desenhado para transmitir alguma da personalidade da empresa atravs do layout. Com a combinao de cores, escolha de tipografia, imagens e estrutura do portal possvel associar o mesmo imagem da empresa.

Estrutura base
Antes de dar inicio implementao da aplicao Web para o portal COLOR, foi realizado um estudo sobre algumas boas prticas para o desenvolvimento da mesma. Assim foram definidos e aplicados alguns conceitos encontrados: o uso de user controls, quando necessrio implementar funcionalidades e/ou atributos visuais que necessitam de ser reutilizados em mais de que uma pgina, o estruturao das pginas definindo master pages, de forma a evitar a manuteno de diversas pginas e centralizar funcionalidades das pginas. Nesta seco sero apresentados os user controls criados e as master pages definidas.

User Controls
Os user control so controlos baseados na classe UserControl da plataforma .NET e permitem a construo de controlos que podem ser reutilizados ao longo de uma aplicao Web. Os user controls contm uma extenso prpria .acsx. De seguida so apresentados os user control definidos para o portal do COLOR.

Menu principal do portal Uma vez que vrias pginas 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 possvel observar na ilustrao acima este controlo contm: Uma mensagem de boas vindas ao utilizador; Um cone com mostra alguns atalhos para sua informao pessoal; Uma hiperligao mas as suas mensagens; Um atalho para uma pesquisa rpida sobre os LO do sistema.

41

Este controlo contm ainda hiperligaes para as quatro grandes reas do portal: "Inicio", como sendo a pgina principal do sistema, que inclu os vrios 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 informao; "LOs", aqui so mostradas todos os los do sistema, bem como a possibilidade de criao de um novo lo. Para o caso dos administradores e gestores de contedos so mostradas as opes de validao e gesto de LO; "Gesto", esta rea apenas est disponvel para os administradores, pois aqui feita a gesto do sistema; "Comunidade do Color", onde so listados todos os utilizadores do sistema. Para os utilizadores com perfil de administradores so mostradas opes de adicionar e remover utilizadores.

rea do LO A rea do LO (Figura 13) um user control usado nas listagens do LO. Este apresenta informao relativa a respetivo LO: Thumbnail do mesmo; Titulo; Nmero de comentrios; Um cone indicando se o lo contm questionrio; Nmero de rantings e atribuio 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 informao 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 pginas de estudo do lo, e contm as seguintes opes: Info, onde apresentada sumariamente a informao relativa ao lo que est a visualizar; Estudo, aqui apresentado todo o contedo referente ao lo; Avaliao, onde feito uma avaliao 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 contedo do lo; Home, em que o utilizador encaminhado para a sua pgina inicial.

FIGURA 15 - MENU DO ESTUDO DO LO

Criao do LO O processo de criao do LO uma sequncia de etapas onde utilizador defini as caractersticas do LO: 1. Informao principal. Nesta rea o utilizador define a capa do LO, bem como algumas das suas caractersticas principais (Figura 16); 2. Objetivos. apresentada uma caixa de texto onde o utilizador insere os objetivos do LO (Figura 17); 3. Contedo do LO. So mostrados os ficheiros que definem o contedo do LO, bem como a disposio dos mesmos. O utilizador tem um boto para a adicionar e gerir a disposio do contedo (Figura 18). 4. Sntese. apresentada uma caixa de texto ao utilizador para colocar a sntese 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 atravs de uma caixa de texto (Figura 21); 7. Competncias. Nesta rea o u apresentadas as competncias que o aluno ir obter depois de estudar o aluno, bem como os nveis de proficincias de cada uma (Figura 22); 8. Resumo. mostrado um resumo das caractersticas do LO preenchidas pelo utilizador (Figura 23). Para essa sequncia de etapas no processo de criao do LO foram criados vrios user controls (um para cada etapa):

44

FIGURA 16 - INFORMAO PRINCIPAL

FIGURA 17 - OBJETIVOS

FIGURA 18 - ADIO E DISPOSIO DO CONTEDO

45

FIGURA 19 - SNTESE

FIGURA 20 - CONCEITOS

FIGURA 21 - ETIQUETAS

46

FIGURA 22 - COMPETNCIAS

FIGURA 23 - RESUMO

Foi ainda criado um user control para ajudar o utilizador com as etapas para a criao 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 pgina de criao mostrado na seguinte ilustrao na etapa do resumo do LO.

47

FIGURA 25 - PGINA DE CRIAO DO LO

Master Pages
As master pages foram criadas devido necessidade de construo de um mecanismo que permita o desenvolvimento de vrias pginas com o mesmo layout. Estas pginas so representadas por ficheiros de extenso .master. Para a aplicao Web do COLOR foram definidas trs pginas padro (master pages) evitando a manuteno e centralizando funcionalidades das pginas: Geral, apresentada na ilustrao da pgina inicial do portal (Figura 26); Estudo, apresentada na ilustrao da p pgina de estudo do lo (Figura 27); 27 Perfil, mostrada na ilustrao da p pgina de edio do perfil do utilizador (Figura ( 28). Com este recurso possvel criar uma pgina padro podendo as demais pginas criadas serem herdar a sua aparncia visual. Em cada master page definido um ou mais content place holder cujo contedo ser personalizado pelas pginas finais. finais O restante

48

contedo da master page fixo, ou seja, as pginas finais que herdem dela tero automaticamente todo esse contedo.

Master Page geral

A master page geral a pgina padro mais herdada pelas pginas do portal do COLOR, pois contm a estrutura base da aplicao Web. A master page geral contem o user control principal geral (Figura 12) na parte superior e o content place holder no centro da pgina onde inserido o contedo das pginas herdadas. De seguida apresentada a pgina inicial da plataforma, que herdou da master page geral, onde possvel observar todo o contedo pertencente pgina no content place holder. No contedo da pgina podemos ainda identificar o uso do user control da rea do lo (Figura 13) na listagem dos learning objects.

FIGURA 26 - PGINA INICIAL

Master Page de estudo

Esta master page de estudo herdada pelas pginas relacionadas com o estudo de um determinado lo. Esta contm o menu principal do estudo (Figura 15) e o contentplaceholder

49

para o contedo das pginas herdadas. Como exemplo mostrada abaixo a pgina de apresentao de um lo, contendo alguma informao resumida sobre o mesmo.

FIGURA 27 - PGINA DE ESTUDO DO LO

Master page do Perfil

A pgina padro do perfil do utilizador construda com o user control do menu principal geral (Figura 12) e com o user control da rea lateral do perfil (Figura 14). possvel observar na ilustrao abaixo a pgina de edio do perfil, herdada da master page do perfil, onde foi inserido no contentplaceholder o contedo pertencente mesma.

50

FIGURA 28 - PGINA DE EDIO DO PERFIL

51

CAPTULO 4: MTODO DE INVESTIGAO

Neste captulo apresentado o mtodo de investigao escolhido pelo autor, dentro dos mtodos da anlise: o estudo de caso. descrito o mtodo comparando-o com outros, apresentadas as suas caractersticas, a recolha dos dados na sua aplicao. tambm apresentado o mtodo de anlise 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 mtodo de investigao que visa compreender melhor um

fenmeno, um processo de uma organizao, um individuo, atravs do cruzamento dos factos apontados pelo investigador. Tem sido um dos mtodos de pesquisa mais utilizados em algumas reas da administrao como, por exemplo, nos sistemas de informao (Hoppen & Meirelles, 2005). Atravs 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 so dadas segundo a anlise dos factos que foram recolhidos durante a ocorrncia do caso. Segundo Yin o estudo do caso deve ocorrer mediante trs condies: quando o investigador, mesmo participando, tem pouco ou nenhum controlo sobre os eventos; quando o caso se encontra em fenmenos 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 Questes de Estratgia/Mtodo pesquisa

Como, porqu Quem, o que, onde, Recolha de dados quantos, quanto Quem, o que, onde, Anlise de arquivos quantos, quanto Mtodo histrico Estudo de caso Como, porqu Como, porqu No No No No

Foco em acontecimentos contemporneos?

Sim Sim

sobre eventos comportamentais?

Experincia

Sim

Sim/No No Sim

TABELA 2 - SITUAES RELEVANTES PARA DIFERENTES ESTRATGIAS DE INVESTIGAO (YIN, 1984)

Yin define o mtodo estudo de caso como uma investigao emprica sobre um fenmeno contemporneo no seu contexto natural, em situaes em que as fronteiras entre o contexto e o fenmeno no so claramente evidentes, utilizando mltiplas fontes de evidncia (ibid, p.23). Para o autor o estudo do caso baseia-se no trabalho de campo ou na anlise de factos, afasta o estudo do caso dos mtodos de investigao como o mtodo

53

histrico, e refere ainda que devem ser utilizadas diversas fontes de dados de forma a aumentar a veracidade dos acontecimentos. No caso da presente dissertao o objeto de estudo foi o processo de desenvolvimento de software ao nvel empresarial.

4.2

Caractersticas de um estudo de caso

O estudo de caso pretende compreender uma dada entidade no seu contexto real,

tirando o mximo partido possvel de mltiplas fontes de evidncia como entrevistas, observaes, documentos e artefactos (Yin, 1984). O autor admite a dificuldade na definio de um estudo de caso exemplar, pois interroga-se sobre as suas caractersticas ideias. Mas arrisca-se a propor as seguintes caractersticas: O caso deve ter identificar e considerar outras perspetivas ou hipteses alternativas. O investigador deve procurar explicaes ou outras perspetivas diferentes daquelas adotadas no estudo e examinar as evidncias de acordo com essas perspetivas; Os dados tratados (evidncias) devem fortes e suficientes para sustentar as concluses ganhando assim a confiana 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 so indicadas trs caractersticas: o As fronteiras do caso, isto , a distino entre o fenmeno que esta a ser estudado e o seu contexto; o Objeto de ateno, a descrio narrativa demonstra, de modo convincente, que houve um esforo exaustivo para juntar as evidncias relevantes; o A exposio de evidncias adequadas deve vir acompanhada por alguma indicao de que o investigador esteve atento validade das evidncias (Yin, 1984).

4.2.1

Projeto de investigao

Robert Yin afirma que para os estudos de caso, so especialmente importantes cinco componentes de um projeto de investigao:

54

1) As questes de estudo; As questes de estudo, podem variar, mas num estudo de caso provvel que a estratgia mais apropriada a questes do tipo como e porqu, como referido anteriormente. A questo do como refere-se descrio de um processo e identificao de como as coisas decorreram. E a questo porqu refere-se causa ou causas do acontecimento e inclu uma anlise explicativa. No resumo do captulo 5 so dadas as respostas s questes de estudo do processo de desenvolvimento de software. 2) As proposies, se houver; As proposies so as ideias ou preconceitos que foram definidas previamente para ao estudo da investigao. Quando um trabalho tem um objetivo definida uma ideia prvia de como esse trabalho deve ser feito. Mas agora se refletirmos, posteriori, conclui-se que ocorrem factos com os quais no se estava a contar e por isso no foram registados porque na altura no se sabia que eram importantes. No estudo do caso do processo da presente dissertao tomou-se a seguinte proposio: os pontos relevantes para o estudo so as trocas formais de informao: e-mail, atas de reunies e decises de gesto. E nessa proposio 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 solues. Agora, em retrospetiva, deveriam ser consideras essas conversas pois foi delas que surgiram algumas solues. 3) A unidade de anlise; A unidade de anlise relaciona-se com o problema de definir o que o caso, ou seja, qual a unidade primria de anlise. E para tal deve-se relacionar a maneira como as questes iniciais da investigao foram definidas. Uma vez estabelecida a unidade de anlise devem-se colocar limites de tempo especficos para se definir o comeo e o fim do caso (Yin). A unidade de anlise visa definir o que o caso de investigao concreto. Como unidade primria de anlise a ser considerada no trabalho o processo de desenvolvimento de software ao nvel empresarial. Como unidade

55

secundria de anlise pode-se definir a equipa de desenvolvimento que participou no projeto. 4) A lgica que une os dados s proposies; A maneira como se relacionam os dados s proposies. 5) Os critrios para se interpretar as descobertas. Para estes dois ltimos componentes, que tm como objetivo indicar o que se deve ser feito com os dados recolhidos, Yin indica que foram os menos desenvolvidos no havendo um padro que ligue os dados s proposies nem uma maneira de estabelecer os critrios para se interpretar as descobertas.

4.3

Recolha de dados no estudo de caso

Segundo Yin as evidncias para um estudo de caso podem vir de seis fontes distintas:

documentos, registos em arquivos, entrevistas, observao direta, observao participante e artefactos fsicos. Refere ainda a incorporao de trs princpios na investigao de um estudo de caso, de forma a aumentar substancialmente a sua qualidade: a) Mltiplas fontes de dados, de modo a permitir assegurar as diferentes perspetivas dos participantes no estudo e obter vrias medidas do mesmo fenmeno possibilitando assim uma triangulao dos dados, durante a fase de anlise dos mesmos. O que torna as concluses e descobertas mais convincentes pois so extradas de um conjunto de confirmaes; 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 apresentao dos dados que sustentam o estudo, desde as questes de investigao at s concluses finais. No presento estudo foram recolhidos dados atravs da seguinte documentao: Dirios de bordo, mensagens de e-mails trocadas pela equipa, exemplares de documentos de especificao, atas de reunies e documentos produzidos no mbito do projeto (requisitos, conceo e manuais). No mbito do registo em arquivos foram utilizados:

56

Os registos pessoais, nomeadamente dirios de bordo e anotaes. Segundo (Bogdan & Biklen, 1994) o dirio 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 observao participante implica um processo longo em que o investigador passa

meses a negociar a sua entrada na rea (Whyte, 1993). No presente trabalho no foi necessrio esse longo processo de negociao, uma vez que o autor j estava envolvido no processo de desenvolvimento, aproveitando assim essa oportunidade. Whyte refere ainda para se compreender a evoluo do comportamento de pessoas e de grupos necessrio observ-los por um longo perodo e no num nico momento. O que aconteceu no caso em concreto, como possvel verificar no captulo 5, que o autor esteve participou durante uns meses no desenvolvimento do software. A observao participante supe a interao entre o investigador e o investigado. O autor foi simultaneamente o investigador e um objeto de investigao.

4.4

Anlise de contedo
A anlise de contedo rene um conjunto de tcnicas que podem ser aplicadas no

tratamento de dados reunidos pelo analista. A definio citada por vrios autores que se tornou clssica: a anlise de contedo uma tcnica de investigao objetiva, sistemtica e quantitativa do conjunto manifesto da comunicao. (Stemler, 2001) refere que a anlise de contedo uma tcnica sistemtica e replicvel para comprimi muitas palavras de texto em poucas categorias de contedo, baseada em regras explcitas de codificao. Os mtodos de anlise de contedo so distinguidos em procedimentos fechados e procedimentos abertos ou exploratrios (Henry e Moscrovici, 1986): Procedimentos fechados so aqueles casos em que o analista j possui uma lista prvia de categorias apropriadas ao objeto de estudo e a usa para classificar os dados; Procedimentos abertos (processo seguido pelo autor) no existe a lista prvia referida no procedimento fechado, ou sejas as categorias surgem do prprio material. um processo indutivo, em que o analista caminha dos dados empricos para a formulao de uma classificao. A categorizao feita pelo analista durante o

57

processo mantm-se provisria, pois possvel que existam remodelaes medida que novos dados vo surgindo.

58

CAPTULO 5: VIVNCIA DE DESENVOLVIMENTO DE SOFTWARE A NVEL

EMPRESARIAL
Neste captulo, so descritas, de forma detalhada atravs de registos recolhidos na primeira pessoa as dimenses que caracterizam a vivncia do autor na evoluo do desenvolvimento do projeto. Para este processo descrito segundo o mtodo apresentado no captulo 4: estudo de caso. Este mtodo utilizado quando se pretende conhecer o como? e o porqu? da investigao. No caso da presente dissertao pretende-se dar a conhecer como decorreu o processo de desenvolvimento do software, descrevendo o mesmo atravs de factos. E esse mesmo processo decorreu de modo (porqu) a visar contribuir para a melhor perceo pblica dos desafios e realidades do exerccio de engenharia informtica nestes contextos.

59

5.1

Introduo
Aps vrios anos de estudo na rea cientfica de Engenharia Informtica 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 Inovao, uma empresa focada no desenvolvimento e entrega de produtos e servios para o mercado das telecomunicaes e das tecnologias de informao. 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 apresentao do portal. O autor inicia a sua participao na fase em que se esto a definir as limitaes e problemas existentes no anterior portal PoLO II. A informao apresentada neste captulo so os registos que o autor agregou durante a realizao da sua participao no projeto, nomeadamente, dirios de bordo, mensagens de e-mails trocadas pela equipa, exemplares de documentos de especificao, atas de reunies e documentos produzidos no mbito do projeto (requisitos, conceo e manuais). Neste captulo descrito o ambiente de trabalho: caracterizados os elementos de trabalho, e explicada a comunicao entre os mesmos e a sua periodicidade. So explicados para que serviram as tecnologias e ferramentas descritas no captulo 2, seco 2.8 no desenvolvimento do projeto. E de seguida so apresentados os registos que o autor agregou, como j referido anteriormente.

5.2

Ambiente de trabalho
5.2.1 Colaborao intra-grupo

Os elementos da equipa de trabalho (programador1, programador2, programador3 e designer) no se conheciam antes do projeto em causa. O progamador1 o autor da presente dissertao e apresentava as seguintes caractersticas: 24 anos, Licenciatura em Informtica, experincia ao nvel de trabalhos acadmicos. O programador2 era o elemento com mais experincia com as seguintes caractersticas: 29 anos, Licenciado em Engenharia Informtica e com mais de 4 anos de experincia a nvel empresarial, nomeadamente no desenvolvimento Web.

60

O programador3 era estudante de Engenharia Informtica, tinha 22 anos de idade e experincia ao nvel de trabalhos acadmicos. A designer tinha 23 anos e acabava de terminar o seu percurso acadmico no curso de Novas Tecnologias de Comunicao, onde adquiriu conhecimento e experincia na rea do design vetorial.

5.2.2

Comunicao

Nesta seo so apresentadas as caractersticas da comunicao 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 Inovao, 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 ausncias, quando era necessrio resolver algum assunto premente, utilizaramse as ferramentas descritas abaixo. A comunicao entre os gestores de projeto e a equipa de trabalho da PT Inovao era feita pessoalmente uma vez por semana, excetuando quando havia necessidade de alguma das partes resolver algum assunto premente. O programador3 comunicava em mdia todos os dias com os elementos de trabalho da PT Inovao. O gestor de projeto da universidade1 comunicava com os elementos da PT Inovao 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 informao 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 Inovao;

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

5.2.3

Escrita de cdigo

No que diz respeito escrita de cdigo no foi mencionada, em qualquer uma das reunies, alguma regra ou prtica nem mesmo um padro de desenho de software a ser seguido. E tambm no existiu um processo formal para a validao de cdigo. Assim sendo o autor procedeu da forma que achou mais correta na escrita do cdigo necessrio.

5.2.4

Testes

Na fase de desenvolvimento os testes foram realizados pelos prprios 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 utilizao em pginas 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 atravs do modelo de dados da aplicao gera a camada de acesso a dados e a prpria base de dados;

SQL Server Management Studio19, ferramenta de gesto de base de dados atravs de uma interface grfica;

Apache Subversion20 (tambm conhecido por SVN), ferramenta de controlo e gesto de diferentes verses de software, histrico e desenvolvimento, contendo uma componente de servidor e outra de cliente.

O Atlassian21, software colaborativo wiki de partilha de informao. utilizado na gesto de projetos, e tem como objetivo integrar indivduos e departamentos dentro de uma organizao. O Atlassian acumula duas funes bsicas: Portal Colaborativo Wiki (Confluence22) e o JIRA23.

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

O HP Quality Center um software para a gesto de testes funcionais, de desempenho e de segurana nos projetos.

Framework Microsoft .Net24 4.0, plataforma para o desenvolvimento e execuo de sistemas e aplicaes;

Framework ASP.NET25, plataforma baseada na Framework .NET, que permite a construo de aplicaes Web;

Microsoft SQL Server 2005, sistema de gesto 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 programao C#, linguagem de programao orientada a objetos, desenvolvida esenvolvida pela Microsoft;

Linguagem JavaScript, linguagem de script pginas Web.

Numa fase inicial ocorreram vrias reunies 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 questo foram utilizadas ferramentas de desenvolvimento de cdigo, de controlo de verses do mesmo e ferramentas de gesto. O SQL Server Management Studio Express foi utilizado para a equipa para interagir com a base de dados e efetuar a gesto da mesma. Como ferramenta base de desenvolvimento de cdigo foi utilizado pela equipa o Visual Studio 2010 com a componente de construo de pginas Web o ASP.NET. Na construo ruo das pginas Web, foi utilizada a linguagem de programao C#. Foram utilizadas bibliotecas da Telerik: Para a implementao 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, atravs do modelo de classes criadas, gerar o modelo relacional de base de dados de forma automtica.

Como ferramenta de controlo de verses do cdigo desenvolvido foi utilizado o Apache Subversion. A equipa utilizou tambm Confluence como portal colaborativo wiki e o JIRA para a gesto do desenvolvimento dos requisitos do projeto. No Portal Colaborativo Wiki foi possvel partilhar a informao do projeto, assim a informao do mesmo estava centralizada e atualizada num nico local e no to dispersa por e-mails pessoais e documentos. Atravs do JIRA acompanhou-se o processo de desenvolvimento de cdigo do projeto. Para cada requisito do projeto eram criados issues com a informao referente ao requisito (descrio, dependncias, etc.). Caso o requisito fosse demasiado complexo ou extensivo, dividia-se o mesmo em vrios subrequisitos de forma ajudar a implementao do mesmo. Com esta ferramenta a equipa de desenvolvimento acompanhava o trabalho de cada um. O SVN estava conectado ao Jira atravs dos cdigos definidos atravs dos issues. Assim era possvel associar o cdigo 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 anlise do software anterior e a segunda sobre o desenvolvimento do COLOR (Figura 30).

65

Anlise do software anterior

Desenvolvimento do COLOR

Estudo da documentao dos projetos PoLO e PoLO II

Definio dos requisitos a implementar

Identificao de problemas/erros no cdigo do PoLO II

Implementao dos requisitos e construo do portal Web

Identificao das limitaes do PoLO II

Descrio das dificuldades encontradas pelo autor na implementao

FIGURA 30 - DIAGRAMA DO PROCESSO DE DESENVOLVIMENO

5.5

Anlise do software anterior (PoLO II)

Aps as primeiras reunies de ponto de situao sobre os projetos anteriores e a

apresentao das ferramentas utilizadas, a equipa deu incio ao processo de verificao do estado do projeto PoLO II. O autor ficou responsvel efetuar um estudo sobre o PoLO II no sentido de identificar problemas e limitaes. Nesta seco so apresentados os dados do autor sobre os problemas e erros encontrados ao nvel da implementao de cdigo, e limitaes ao nvel pedaggico e do portal Web. No anexo apresentado o cd cdigo de alguns problemas.

5.5.1

Problemas/Erros no cdigo
Tipo Problema tcnico Problema tcnico Problema tcnico Problema tcnico Problema tcnico Problema tcnico Problema tcnico Data 12/10/2011 17/10/2011 19/10/2011 20/10/2011 21/10/2011 24/10/2011 25/10/2011

Identificao PTP1 PTP2 PTP3 PTP4 PTP5 PTP6 PTP7

66

PTP8 PTP9 PTP10 PTP11

Problema tcnico Problema tcnico Problema tcnico Problema tcnico

TABELA 3 - PROBLEMAS/ERROS NO CDIGO

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

No decorrer do trabalho foram encontrados alguns problemas ao nvel da escrita de cdigo: PTP1 (12/10/2011) - O autor constatou que fora implementado no cdigo da camada de aplicao um mtodo getPathFicheiro que tinha os mesmos objetivos de um dos mtodos disponveis nas bibliotecas-padro (namespace Systema.IO) da Framework .NET 4.0: Path.GetDirectoryName26. PTP2 (17/10/2011) Na classe Gestor o autor deparou-se com um mtodo que tinha como objetivo receber um objeto que inclua um ficheiro de vdeo e convert-lo para o formato .swf, usando um executvel (ffmpeg.exe) retirado da biblioteca opensource ffmpeg27. O objeto recebido como parmetro no tinha qualquer validao antes das instrues do mtodo. PTP3 (19/10/2011) - O autor constatou que o mtodo AlteraEstado localizado na classe Gestor do projeto no continha qualquer descrio, desconhecendo assim o seu propsito. E o mesmo no foi encontrado na documentao do projeto. Foi ento necessrio verificar onde o mtodo era chamado para tentar perceber o seu objetivo. PTP4 (20/10/2011) - Aps a verificao de uma tabela na base de dados designada Mensagem sem qualquer entrada o autor encontrou a classe que originou a mesma (atravs do ORM): Mensagem. Esta classe no 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 iro ser usados pois a classe no 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 utilizao 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 variveis globais, na master page utilizadas por todas as pginas da aplicao Web, como referncias. Estas variveis no so alteradas ao longo do seu uso no projeto, uma vez que representam as cores dos menus que no so alteradas. Estas variveis estaro alocadas por cada utilizador/pgina 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 mtodo que continha estava comentado.

PTP9 (27/10/2011) O autor constatou haver vrios mtodos com as mesmas funcionalidades em diversas pginas Web.

PTP10 (27/10/2011) O autor constatou na pgina de listagem dos utilizadores a implementao de cdigo que utilizava uma string para representar as permisses do perfil do utilizador na plataforma. E de seguida era copiada para a ViewState31 de modo a ser passada e utilizada entre as diferentes pginas Web. Este mecanismo pouco intuitivo e dificulta a manuteno de cdigo para os programadores.

PTP11 (27/10/2011) O autor deparou-se com as tabelas apresentadas na Figura 31, que tinham como objetivo mapear as relaes entre a tabela permisso, 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 permisso a um utilizador (tabela Utilizador) em determinado LO (tabela LO) (Figura 31). Esta tabela, segundo o mapeamento atual, permite fazer mltiplas inseres dos mesmos grupos fazendo assim com que no obedea 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 normalizao a qual diz que no deve ser possvel a insero de mltiplos grupos iguais (Coulson, 2007).

FIGURA 31 - TABELAS PARA A RELAO DA PERMISSO DO UTILIZADOR NUM LO

5.5.2

Limitaes

De seguida so apresentadas os dados recolhidos ao nvel das limitaes do portal Web e pedaggicos do PoLO II II, que geraram melhorias no COLOR.

Identificao LP1 LP2 LP3 LP4 LP5 LP6

Tipo Ocorrncia Ocorrncia Reunio Geral Reunio Geral Reunio Geral Reunio Geral
TABELA 4 - LIMITAES

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 Ocorrncia 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 pginas. LP2 Ocorrncia Data: 03/10/2011: Participantes: programador1 O programador1 verificou que as vrias pginas Web repetiam cdigo e controlos. Pedaggico LP3 Reunio geral Data: 05/10/2011: Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1; U1: gestor e programador3 A equipa concordou de forma unanime que a rea do perfil do utilizador apresentava pouco informao, 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 aes no sistema especialmente relacionadas com os LO. LP4 Reunio geral Data: 10/10/2011: Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1; U1: gestor e programador3 O chefe de equipa referiu que o PoLO II continha apenas uma funcionalidade no que diz respeito colaborao entre os utilizadores, que consistia na possibilidade de um utilizador sugerir um LO a outro utilizador do sistema. LP5 Reunio geral (10/10/2011) A gestora argumentou que o no existia qualquer funcionalidade que potenciasse a participao do aluno na criao do LO, pois o aluno no podia criar LO. LP6 Reunio geral (10/10/2011) O gestor a universidade referiu que os utilizadores no eram avisados quando existia uma nova verso de um LO que eles j estudaram. LP7 Reunio 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 seco so descritos os registos do autor (programador1) em relao

implementao dos requisitos e os desafios com os quais ele se deparou.

5.6.1

Implementao dos requisitos

Aqui so descritos os registos do autor no decorrer da implementao dos requisitos apresentados no captulo 3, seco 3.5. Estes registos encontram-se ordenados temporalmente mediante o desenrolar de cada acontecimento.

Identificao RG1 RG2 RG3 RG4 RG5 RG6 RG7 RG8 RG9 RG10 RG11 RG12

Tipo Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral Reunio geral
TABELA 5 - REUNIES 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

Identificao PT1 PT2 PT3 PT4

Tipo Problema tcnico Problema tcnico Problema tcnico Problema tcnico

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

Local PT PT PT PT

TABELA 6 - PROBLEMAS TCNICOS OCORRIDOS

Identificao OC1 OC2 OC3 OC4 OC5 OC6

Tipo Ocorrncia Ocorrncia (via e-mail) Ocorrncia Ocorrncia Ocorrncia (via e-mail) Ocorrncia

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

Ocorrncia Ocorrncia Ocorrncia Ocorrncia (via e-mail) Ocorrncia Ocorrncia (via e-mail)
TABELA 7 - OCORRNCIAS

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 Reunio geral Data: 01/11/2011; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1; U1: gestor e programador3; Durao: 2 horas Discusso de brainstorm para os novos requisitos a implementar; Apresentadas ideias por todos os elementos; De forma a manter a diviso de tarefas do projeto anterior, o chefe de departamento e o gestor da U1 decidiram que se mantinham as camadas divididas: PTin, responsvel pela parte da apresentao e U1 responsvel pela camada de dados e aplicao; PT1 Problema tcnico Data: 5/11/2011; Participantes: Gestor tcnico 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 tcnico Data: 24/11/2011; Participantes: Gestor tcnico e programador1; via: presencial O programador1 comunicou que estava a ter dificuldades em aplicar a RadGrid (controlo para listagens da Telerik). Foi ento necessrio combinar esforos 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 responsvel 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 responsvel pelo requisito e disse que ia

72

elaborar um estudo para sobre pesquisas avanadas em outros sistemas de learning objects com o objetivo de tentar aplicar algumas ideias no COLOR. RG2 Reunio geral: Data: 17/11/2011; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1; U1: gestor e programador3; Durao: 1:30 Apresentao pelo programador3 do estudo sobre pesquisas avanadas em outras plataformas de learning objects, focando os campos que se utilizavam nessas pesquisas e os vrios tipos de ordenao; Aps uma discusso sobre os campos e os tipos de ordenamento a serem utilizados para a pesquisa avanada de LO, ficaram definidos consensualmente os que foram apresentados no captulo 3, seco 3.5.1.

Deciso 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 determinao do gestor da U1 o Programador3 ficou responsvel pela realizao de um estudo para um sistema de recomendaes de LO. RG2 Reunio geral: A gestora indicou que o requisito no era prioritrio. Ficando para implementar posteriormente.

Deciso do chefe da implementao do requisito: RF3 O sistema deve disponibilizar um frum de discusso associado a cada LO. O Chefe de Equipa lembrou que existia um frum de discusso no sistema Formare e que poderia ser integrado no COLOR. Para essa integrao a gestora mencionou o programador1. RG3 Reunio geral Data: 28/11/2011; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1; U1: gestor e programador3; Durao: 2 horas O programador1 apresentou uma grande dificuldade em integrar o frum do sistema Formare para o COLOR;

73

O chefe indicou que o requisito ficaria para uma fase final do desenvolvimento. RG2 Reunio geral O chefe decidiu abandonar o requisito RF3 e implementar um sistema de comentrios na pgina do estudo do LO. Isto porque o programador1 e o gestor tcnico argumentaram que a implementao do frum de raiz ou a integrao do form do Formare no seria concretizada em tempo til; A gestora apontou como responsvel para essa tarefa o programador2. OC1 - Ocorrncia Data: 28/05/2012; Participantes: programador2 O programador2 fecha os issues no Jira que esto associados ao requisito RF3 e d o requisito por implementado.

RG4 Reunio geral Data: 09/12/2011; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, designer; U1: gestor e programador3; Durao: 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 pginas. PT3 Problema tcnico Data: 02/02/2012; Participantes: designer, programador1, programador2; A designer teve dificuldades com a construo das CSS, especialmente relativamente aos estilos das mesmas para os controlos Web da Telerik. O programador2 auxiliou a designer na alterao das CSS que estavam aplicadas por defeito nos controlos Web da Telerik.

Ocorreu novo brainstorm sobre os requisitos para o COLOR a deciso da implementao do RF4 Um utilizador deve poder rever LO. A equipa decidiu de forma unanime que um LO teria que ter um conjunto de caractersticas a ser

74

avaliadas de acordo com o seu contedo. Numa primeira fase definiu-se que o gestor de contedos, responsvel pela rea temtica onde o LO estava inserido, faria essa avaliao. Mas a gestora de projeto alertou para o facto de no futuro o nmero de LO a avaliar por cada gestor de contedos ser enorme. A designer sugeriu ento dar a possibilidade tambm aos alunos de efetuarem essa avaliao. No que diz respeito aos itens a avaliar sobre o LO surgiram vrias ideias dos elementos: tamanho do contedo do LO, qualidade do LO, durao estimada, originalidade, dificuldade, facilidade de utilizao, clareza e rigor. Como eram demasiadas caractersticas ficou para decidir posteriormente as que prevaleciam, e tambm a escala quantitativa para cada uma delas. OC2 - Ocorrncia Data: 23/02/2012; Participantes: PTin: chefe de departamento, gestor tcnico, 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 seco 0, na descrio do requisito. O programador3 d incio implementao do mesmo. RG8 Reunio geral Data: 26/04/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, designer; U1: gestor e programador3; Durao: 2 horas A gestora altera os itens a avaliar sobre o LO no requisito. O programador3 d incio alterao da implementao dos mesmos. OC3 - Ocorrncia

Data: 27/04/2012; Participantes: programador3

O programador3 fecha os issues no Jira associados ao requisito.

RG5 Reunio geral Data: 12/01/2012; Participantes: Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, designer; programdor2; U1: gestor e programador3; Durao: 2:30 horas A equipa decidiu implementar o RF5 O sistema deve disponibilizar um chat associado a cada LO. Surgiu a discusso sobre um chat disponvel em toda a plataforma mas a gestora alertou para o facto de esse chat ser mais propcio a

75

conversas alheias ao estudo. A gestora apontou o programador2 como responsvel por implementar o requisito. OC4 Ocorrncia 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 atravs de mensagens com outros utilizadores. A equipa concordou com a implementao do mesmo. A gestora definiu que o programador1 ficaria responsvel pelo mesmo. OC5 Ocorrncia Data: 19/01/2012; Participantes: programador1, gestor tcnico; via: e-mail O programador1 envia e-mail ao gestor da equipa tcnica com a lgica de funcionamento para a implementao do sistema de mensagens (classes e modelo relacional para a BD). O mesmo responde que no h necessidade de efetuar uma construo de um sistema de mensagens, uma vez que o Formare tinha um sistema que podia ser integrado. O programador1 fica responsvel por efetuar a integrao e adaptao do sistema de mensagens para o COLOR. PT4 Problema tcnico Data: 20/01/2012; Participantes: programador1, gestor tcnico O programado1 apresenta ao gestor tcnico alguma dificuldade em perceber a lgica de funcionamento relacionada com o core do sistema de mensagens do Formare. O gestor tcnico ajudou o programador1 explicando o funcionamento do sistema de mensagens. OC6 Ocorrncia Data: 24/01/2012 O programador1 fecha os issues associados ao requisito e d por implementado o mesmo.

RG6 Reunio geral Data: 09/02/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, designer; U1: gestor e programador3; Durao: 2 horas

76

 Apresentao 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 incio implementao de raiz do portal. Para tal os programadores e a designer definiram issues no Jira para representar as tarefas a realizar para criao do portal. RG7 Reunio geral Data: 22/03/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, designer; U1: gestor e programador3; Durao: 2 horas Apresentao da pgina 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 implementao dos estilos CSS. O gestor tcnico pediu ao programador1 para elaborar um estudo sobre a manuteno de estado de vrios utilizadores entre pedidos diferentes, para que se tentem usar os adequados para cada situao. DC1 Desafio Data: 29/03/2012; Participantes: programador1 Descrito na seco 5.6.2. DC2 Desafio Data: 30/03/2012; Participantes: programador1 Descrito na seco 5.6.2. OC7 - Ocorrncia Data: 06/02/2012; Participantes: gestor tcnico, programador1, programador2 O programador1 apresentou a Tabela 9 sobre um resumo das vrias opes que a plataforma .NET disponibiliza para a manuteno do estado. O gestor indicou que se deveria ter em ateno sobre o uso dos vrios tipos de estados. DC3 Desafio (03/03/2012): Descrito na seco 5.6.2. DC4 Desafio Data: 04/04/2012; Participantes: programador1 Descrito na seco 5.6.2 A equipa decidiu implementar o requisito: RF13 Um utilizador deve ter uma pgina pessoal. Foram definidos no Jira pelo programador1 os issues para este requisito.

77

RG8 Reunio geral O programador1 apresentou a pgina de perfil implementada, com a master page do perfil (Figura 28) e o controlo lateral (Figura 14). A gestora do projeto indicou vrias alteraes pgina. RG9 Reunio geral Data: 03/05/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Durao: 2 horas O programador1 mostrou novamente a pgina de perfil equipa e foram fechados os issues associados ao requisito.

Ficou definida a implementao do requisito RF15 Um concetor deve poder indicar se um LO est apto para ambiente mvel ou no. Este requisito foi colocado pela gestora de projeto que argumentou se mais tarde poderia ser realizada uma verso mobile do COLOR e assim o contedo j estava preparado. OC8 Ocorrncia Data: 07/05/2012; Participantes: programador1 O programador1 adicionou uma propriedade booleana classe do LO para indicar se o LO est ou no apto para mobile. Ficou para definido o issue para adicionar uma checkbox pgina de criao do LO.

RG10 Reunio geral Data: 01/06/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Durao: 1:30 horas Apresentao 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 experincia. O gestor tcnico informou ainda que o programador2 estava apenas a trabalhar a part-time no projeto. Deciso da equipa para implementar o requisito RF16 - Um aluno deve poder submeter LO. No projeto anterior no era possvel ao aluno submeter LO. OC 9 - Ocorrncia 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 responsvel por implementar requisito. RG11 Reunio geral Data: 14/06/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Durao: 1:30 horas A gestora alertou para o facto do prazo de concluso do projeto estar prximo e o gestor tcnico argumentou que requisito o requisito poderia consistir no envio de uma mensagem para o administrador do sistema com a sugesto do LO. Logo este requisito no teve qualquer implementao, uma vez que o utilizador j continha a sua caixa de mensagens.

Deciso 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 Ocorrncia Data: 12/06/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, programador2, designer; U1: gestor e programador3; via: e-mail O programador2 indicou que o requisito no estava claro, era necessrio esclarecer em concreto o que o convidado pode ou no fazer.

Deciso de implementar o requisito RF19 - Um utilizador dever ter uma data de validade. OC11 Ocorrncia Data 20/06/2012; Participantes: programador1 O programador1 acabou a implementao do requisito. Adicionou uma propriedade (data de validade) classe do utilizador, e

79

implementou a lgica no portal, de modo impedir o login do utilizador cuja data de validade expirou e mostra-lhe uma mensagem especfica. RG12 Reunio geral Data: 25/06/2012; Participantes: PTin: chefe de departamento, gestor tcnico, gestora, programador1, programador2, designer; U1: gestor e programador3; Durao: 1:30 horas O programador1 apresentou o requisito implementado equipa.

Deciso de implementar o requisito RF20 - Um utilizador deve poder fazer Like a um LO. OC12 Ocorrncia Data 13/06/2012; Participantes: PTin: chefe de departamento, gestor tcnico, 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 mtodos ao nvel da camada de aplicao para a gesto dos mesmos; O programador1 enviou e-mail equipa sobre o facto de ainda no existir um boto de like no novo layout.

5.6.2

Desafios encontradas pelo autor na implementao

Durante a participao do autor na implementao de funcionalidades e pginas Web surgiram diversos desafios a nvel tcnico:

Identificao 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 pginas que se encontravam fora da plataforma, isto no necessitavam de autenticao do utilizador para serem acedidas. Era

80

importante definir uma forma de separar os recursos que requerem autenticao daqueles que no querem, neste caso por pastas. O autor no tinha conhecimento de qualquer forma de resolver o problema. Soluo: Aps algum estudo o autor chegou concluso que possvel atravs da configurao 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 tambm pode ser usado para especificar uma pasta existente na aplicao. Assim bastou colocar todas as pginas que no requerem autenticao numa pasta e as que requerem em outra. E definir a autenticao das mesmas no ficheiro WebConfig.

DC2 (30/03/2012): Nos controlos de listagens da Telerik era necessrio no preenchimento dos dados dos controlos atravs de cdigo (Codefile). Era necessrio de alguma forma encontrar controlos que se encontravam dentro do elemento de listagem. Soluo: Atravs do mtodo FindControl, mtodo definido na classe Control usada como classe base dos controlos servidores e pginas ASP.NET, possvel obter a referncia de um controlo mantido na rvore de controlos do elemento sobre o qual o mtodo invocado. No caso concreto nos controlos de listagens da Telerik.

DC3 (03/04/2012) : No incio da criao e implementao do portal para o COLOR foi pedido ao autor um estudo sobre gesto de estados individuais (associado a cada utilizador da plataforma) entre pedidos possveis que a plataforma ASP.NET permite. Pois um dos problemas que a anterior verso apenas usava a propriedade Application. O autor foi estudar sobre as possveis formas de manter o estado do utilizador entre pedidos diferentes e apresentou-os equipa. A plataforma ASP.NET contm vrias opes que permitem manter o estado individual (associado a cada utilizador) e global (partilhado pelos utilizadores da aplicao) entre pedidos.

Tipos Application

mbito Global

Caractersticas Dicionrio chave/valor com itens que mantm informao que pode ser acedida por todos os clientes; Pode limitar a escalabilidade da aplicao; Exemplo da sua utilizao: o this.Application[nome_da_chave] = contedo

81

Session

Utilizador

Dicionrio chave/valor que permite manter dados por utilizador; Exemplo da sua utilizao: Necessita de cookies ou URL mangling (tcnica usada para incluir a chave da Session no URL); Pode levar diminuio da performance da aplicao; Exemplo da sua utilizao: o Session[nome_da_chave] = contedo

Cookie

Utilizador

O estado armazenado no lado do cliente; Os dados podem ser mantidos ao longo de vrias sesses; Tem um tamanho limitado de aprox. 4KB; O utilizador pode desativar o uso de cookies de browser, inviabilizando assim a sua utilizao; Exemplo da sua utilizao: o Cookie [nome_da_chave] = contedo

Cache

Global

Os dados so partilhados por todos os utilizadores; possvel definir o tempo que um item permanece em cache;

ViewState

POST

Os dados so mantidos atravs de pedidos POST; Os dados so mantidos atravs de um campo escondido; necessrio que o ViewState esteja ativo para este funcionar.
TABELA 9 - GESTO DE ESTADOS (ABREU, 2011)

DC4 (04/04/2012) Era necessrio validar se as caixas de texto do formulrio de edio de utilizador (Figura 28) estavam vazias, umas vez que alguns campos eram obrigatrios. Soluo: De forma a evitar, a verificao da falta de contedo nas caixas de texto, por cdigo no server side ou atravs de cdigo JavaScript prprio, o autor aplicou a propriedade: ValidationGroup32, poupando assim tempo. A propriedade permite: Validar os campos que esto vazios; Apresentar uma mensagem especfica 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

CAPTULO 6: ANLISE

Neste captulo feita uma anlise sobre os dados recolhidos no captulo 5. Esta anlise feita mediante a tcnica de anlise de contedo, descrita no captulo 4 seco 4.4, no que diz respeito categorizao dos problemas e limitaes encontrados pelo autor. seguido o mtodo aberto ou exploratrio de anlise de contedo. O autor classificou cada problema/ erro ou limitao medida que surgiram.

83

6.1

Problemas/Erros no cdigo do sistema anterior - PoLO II

No captulo 5, seco 5.5.1 foram constatados pelo autor alguns problemas e erros

associados implementao de cdigo no PoLO II. Nesta seco feita uma anlise pelo autor sobre esses mesmos problemas ou erros e as consequncias que deles podem advir. Os cdigos de identificao (ex., PTP1) so os j utilizados no captulo 5. Os problemas ou erros identificados foram divididos nos seguintes grupos, pela sua no prevalncia mas pelas caractersticas tcnicas distintas: Repetio de cdigo e mtodos (PTP1, PTP9); Mtodos no usados (PTP4, PTP8); Falta de estruturas de controlo de erro (PTP2, PTP1); Falta de documentao (PTP3); Otimizao (PTP5, PTP6); Falhas na normalizao de tabelas (PTP11); Gerais (PTP7, PTP10).

Repetio de cdigo e mtodos: No PTP1 o autor deparou-se com o uso de um mtodo que replica um j existente na Framework .NET. Esta implementao causa uma perda de produtividade, uma vez que o programador perdeu tempo com a sua implementao, e podem surgir bugs com a implementao do mesmo. Pois tendo em conta que um mtodo nativo da biblioteca-padro parte-se do princpio que j foram tomados cuidados pelos criadores da plataforma, por exemplo no que diz respeito a testes de bugs como o tratamento de excees que possam ocorrer. No PTP9 o autor constatou que existiam vrios mtodos que se repetiam pelas pginas da plataforma. Caso seja necessrio alterar algum dos mtodos preciso localiz-lo e alter-lo em cada uma das pginas que foi utilizado.

Mtodos no usados: O facto apresentado no PTP4 em que existe uma tabela e uma classe sem qualquer uso provoca dois problemas: a alocao de recursos fsicos na base de dados para mais uma tabela e o desperdcio de recursos sempre que

84

houver necessidade de o ORM verificar alteraes nas classes face base de dados. No PTP8 foi apresentado pode provocar dificuldade na manuteno de cdigo, uma vez que tem linhas de cdigo sem utilidade.

Falta de estruturas de controlo de erro: No mtodo PTP2, o facto do objeto recebido por parmetro no ter qualquer validao pode causar dois problemas: No caso do objeto estar nulo, lanada uma exceo pelo sistema (NullReferenceException33), que o programador no controlou com o uso de excees disponveis na Framework. O que provoca que ir ser lanada, no momento da execuo do programa, uma exceo pelo sistema que o programador no saber a sua origem. Por outro lado, ainda no mesmo mtodo, verificado que chamado um novo mtodo: Process.Start34 para a converso do vdeo, este mtodo inicializado num processo com um thread parte e no existe qualquer notificao de quando este concludo e/ou concludo com sucesso. Perante esta situao, caso o objeto recebido por parmetro no esteja vlido (verificadas as propriedades do objeto para ver se o ficheiro existe efetivamente no disco) ir ser lanada uma exceo no processo do thread do mtodo: Process.Start. O que pode provocar que no seja gravado qualquer vdeo sem que o programador saiba disso. Aps verificar a classe Process35 constatamos que a mesma permite associar o evento: Exited que ativado atravs da mudana da propriedade: EnableRaisingEvents para true e que ser invocado quando o processo, neste caso o processo de converso terminar. Assim com esse evento configurado possvel saber quando o processo termina, permitindo assim verificar se ocorreu algum erro e fazendo com que o programador faa a lgica 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

insero do novo ficheiro convertido, sem que este seja sempre introduzido por defeito, mesmo no caso de erro. No mtodo encontrado no PTP1 verificou-se tambm que no existe qualquer validao dos parmetros de entrada. Como acontece na funo referida acima caso seja lanada a exceo NullReferenceException, o programador no identificar a sua origem

Falta de documentao: No PTP3 o autor deparou-se com um mtodo que no descrevia o seu propsito (a documentao de referncia apenas continha as funcionalidades gerais), foi ento necessrio analisar a sua implementao e verificar onde era chamado, para entender qual era o seu objetivo.

Otimizaes: No PTP5 apresentado um exemplo do uso da estrutura GUID (Globally Unique Identifier), uma estrutura utilizada como varivel que gera um identificador nico para o LO. Este uso no apropriado especialmente para o uso em questo. Aps um grande nmero 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 primria que por defeito indexada (Tripp, 2009), a forma como esta guardada no sequencial. Este facto faz com que exista fragmentao na tabela dos LO. No caso do PTP6 o uso das variveis globais, como referncias pelas pginas da aplicao Web, causa alocaes de memria desnecessrias, por exemplo: se estiverem trs utilizadores com sesso ativa no servidor este estar a alocar quatro vezes o nmero de utilizadores (trs) o que perfaz um total de doze alocaes, das quais oito repetem dados.

Falhas na normalizao de tabelas No PTP11 a associao entre as tabelas no est normalizada. Como referido no problema a tabela segundo o mapeamento atual permite fazer mltiplas inseres dos mesmos grupos. Por exemplo se existir na tabela permissao_utilizador_lo (tabela usada para relacionar lo, utilizador e

86

permisso): idLo: 1, idPermissao: 1 idLo:1 possvel acrescentar mltiplas entradas com os mesmos valores, mudando apenas o identificador principal (Tabela 10). Em termos lgicos para a aplicao no h nenhum caso em que o mesmo utilizador necessite de ter a mesma permisso mltiplas vezes mapeada. Deste modo a base de dados no mantm a integridade dos dados uma vez que as chaves primrias 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 situao poder-se-ia usar o sistema de Resources36 onde possvel tipificar todas as mensagens para que o programador possa verificar se a mensagem j existe e caso no exista adicion-la lista. Alm desta vantagem possvel com este mecanismo suportar vrias lnguas para a aplicao Web. A string usada no PTP10 que partilhada entre vrias pginas Web como mecanismo de permisso associado ao perfil do utilizador, pouco intuitivo para um programador, no sentido em que a string no descreve qual o perfil em questo. E tambm dificulta na manuteno do cdigo pois no caso de ser necessrio modificar a string associada ao perfil, a sua modificao no garante que todos os stios onde essa string era usada foi modificada.

36

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

87

6.2

Limitaes do sistema anterior - PoLO II

Na seco 5.5.2 do captulo 5 foram identificadas pela equipa algumas limitaes ao

nvel do PoLO II, que o autor categorizou em dois grupos, um com caractersticas mais tcnicas, outro com caractersticas mais pedaggicas: Portal Web (LP1, LP2, LP7). Atravs das ocorrncias (LP1, LP2) o autor constatou que o portal do PoLO II continha limitaes do aproveitamento de cdigo e controlos ao nvel das pginas. E na reunio LP7 identificou-se uma limitao ao nvel da gesto das notas pessoais do utilizador Pedaggico o o o o Perfil do Utilizador (LP3); Pesquisa por LO no sistema (LP3); Colaborao entre utilizadores (LP4); Informao em torno do LO (LP5).

Estas limitaes enquadram-se ao nvel da pedaggico relacionado com o sistema.

6.3

Implementao dos requisitos do COLOR

Na seco 5.6.1 do referente captulo so apresentados os factos do processo de

desenvolvimento associadas a cada requisito e criao do portal do COLOR. Durante esse processo houve alguns problemas, reunies e ocorrncias diversas, que o autor agrupou nas seguintes categorias, por anlise qualitativa de contedo (segundo o processo descrito no captulo 4): Falta de formao especfica (PT1, PT2, PT3) Houve vrias circunstncias onde os programadores no conheciam as formas de atuar concretas relativamente s ferramentas da Telerik: OpenAccess ORM e os RadControls. Os programadores e a designer tinham competncias basilares mas as ferramentas eram demasiado especficas e mesmo com material de referncia para estudo no compreenderam parte da sua aplicao. Os programadores estavam a ser jogados perante as ferramentas sem uma formao prvia que acompanhasse o material de referncia.

Documentao em falta ou insuficiente (PTP4, RG3)

88

O sistema Formare no tinha documentao interna de referncia sobre o sistema de mensagens nem sobre o frum, nem mesmo documentao ao nvel do cdigo sobre o mesmo.

Falta de comunicao (RG8, OC5) No RG8 programador depois de ter implementado a pgina do perfil necessitou de alterar vrias partes da mesma pois no houve na reunio uma definio clara do que a pgina deveria conter. No OC5 o programador perdeu tempo para especificar a lgica 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 especificao detalhada das funcionalidades (RG8, OC5, OC10) As funcionalidades foram implementadas mediante o que ficou registado nas reunies, sem uma especificao tcnica de cada uma e uma definio clara do que se pretendia. O que provocou por vezes a implementao de funcionalidades desnecessrias desperdiando tempo e recursos.

Falta de acompanhamento peridico (RG4, RG5, RG6, RG7, RG8, RG9) Como se pode verificar atravs de algumas datas, as reunies eram realizadas com um grande espaamento temporal. Isto provocava que os elementos de trabalho por vezes se encontrassem perdidos ao nvel do desenvolvimento do projeto, nomeadamente das suas funcionalidades.

89

CAPTULO 7: CONCLUSES
Como j referido no captulo 5 so apresentados os registos que o autor agregou durante a realizao da sua participao no projeto. Esses registos so analisados no captulo 6, onde o autor categoriza e interpreta identificando as suas consequncias. No presente captulo o autor faz uma reflexo sobre o processo e propes solues.

90

7.1

Problemas/Erros no cdigo do sistema anterior - PoLO II

No que diz respeito aos problemas e erros no cdigo do PoLO II o autor apresenta as

seguintes propostas de soluo: Repetio de cdigo e mtodos: No PTP9, o autor constou repetirem-se vrios mtodos pelas pginas da plataforma, esses mtodos podiam ser implementados numa master page base e estariam disponveis nas pginas que herdassem dessa master page, evitando assim cdigo repetido e tornando mais fcil a manuteno no caso de ocorrer alguma alterao. Falta de documentao: No PTP3 se tivesse sido descrito, por exemplo utilizando a tag <sumary>37 este problema no se verificaria. Para alm da descrio do mtodo convm adicionar tambm a descrio das variveis recebidas como parmetros atravs da tag <param>38. Assim sempre que o mtodo utilizado, o programador tem acesso sua descrio e descrio das suas variveis. Otimizaes: No PTP5, onde apresentado um exemplo do uso da estrutura GUID como identificador nico para o LO, era aconselhvel o uso da varivel 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 contrrio da utilizao do GUID pois reduziria a fragmentao interna da base de dados, sendo que os identificadores com Identity so alocados de forma sequencial e previsvel (w3schools), o que facilita o levantamento de dados nas pesquisas (Query). As variveis apresentadas no PTP6 deveriam conter o modificador: static39 (estticas), uma vez que no so alteradas pelas pginas herdadas. O facto de serem definidas como estticas significa que existe apenas uma instncia do objeto independentemente do nmero de objetos instanciados para cada uma das classes (Microsoft), poupando assim alocaes de memria. 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

variveis deveriam tambm 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 situao poder-se-ia usar o sistema de Resources41 onde possvel tipificar todas as mensagens para que o programador possa verificar se a mensagem j existe e caso no exista adicion-la lista. Alm desta vantagem possvel com este mecanismo suportar vrias lnguas para a aplicao Web.

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

No PTP11 para resolver a situao descrita bastava que a normalizao fosse devidamente aplicada, passando o esquema modelo relacional pelas trs fases da normalizao. 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

Aps a execuo da primeira forma normal, teramos a adio de uma tabela, por exemplo: TipoPermissao, que define os tipos de permisso e evita que se repitam na tabela permissao. A execuo da segunda e terceiras formas normais, no trariam mais nenhuma mudana. Aps as normalizaes teramos ento 4 entidades que sero transformadas nas tabelas da Figura 31. A chave primria da tabela permisso seria uma chave composta pelo idUtilizador, idLo e idTipoPermissao, identificadores que so chaves primrias nas suas tabelas e chaves estrangeiras na tabela permisso. Assim essa chave composta no se pode repetir, garantindo que um utilizador apenas tem um tipo de permisso para um lo. Com esta soluo no s se mantm a integridade da base de dados.

FIGURA 33 - SOLUO PARA O PTP11

Falta de estruturas de controlo de erro:

93

No mtodo PTP2, para o primeiro problema bastava verificar se o objeto estava nulo e nesse caso o programador lanava uma exceo controlada a qual tinha mais informao sobre a sua origem. Relativamente ao segundo problema apresentado, aps verificar a classe usada: Process43 constatamos que a mesma permite associar o evento: Exited que ativado atravs da mudana da propriedade: EnableRaisingEvents para true e que ser invocado quando o processo, neste caso o processo de converso terminar. O evento Exited executado quando o processo de converso termina. Nesse evento o programador pode verificar se o ficheiro existe, atravs do mtodo File.Exists44 e no caso de no existir lanar uma exceo controlada a indicar que o processo falhou.

7.2

Limitaes do sistema anterior PoLO II

Nas limitaes 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 pginas com a mesma estrutura a nvel de layout que poderiam ser agrupadas em vrias pginas padro. No LP2 a aplicao 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 repetio de controlos e o respetivo cdigo.

7.3

Implementao dos requisitos do COLOR

Para tecnologias especficas era aconselhvel alguma formao, especialmente

quando so trabalhadores com pouca experincia a ingressar uma equipa de trabalho. A documentao e especificao formal no desenvolvimento de software so essenciais, nomeadamente ao nvel da documentao tcnica para os programadores quando existem vrias pessoas diferentes a trabalhar no mesmo projeto. Para acompanhar de uma forma mais permanente, por exemplo todos os dias, poderia ser utilizado o mtodo gil Scrum, definido para a especificao 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 mtodo o facto de um acompanhamento mais permanente sobre o processo de desenvolvimento, atravs de por exemplo reunies 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

REFERNCIAS BIBLIOGRFICAS
Abreu, Lus. (2011). ASP.NET 4.0 Curso Completo. Pag. 279. Amaral, Lus, & Leal, David. (2004). Do ensino em sala ao e-Learning. Babu, Sarat. (2001). e-Learning Standards Barbeira, Jacinto, Santos, Arnaldo, & PT Inovao. (2003). Desenvolvimento de contedos normalizados para ambientes de e-Learning: um estudo de caso na PT Inovao. Bogdan, Robert, & Biklen, Sari. (1994). Investigao Qualitativa em Educao, Coleco Cincias da Educao. 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, disponvel 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 informao: um panorama da pesquisa cientfica entre 1990 e 2003. Revista de Administrao 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, Joo. (2010). Portal de Learning Objects. (Tese de Mestrado em Engenharia Informtica), Universidade de Coimbra, Coimbra. Martins, Joo, & Gomes, Paulo. (2009). PoLO: Portal de Learning Objects - Anlise 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 Inovao. (2010). Relatrio de Final de Projeto - PoLO. PT Inovao. (2011). Relatrio 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 - Especificao e Desenho. Relatrio 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 limitaes no PoLO II - Cdigo

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 dinmica public Color corADinamicaDefeito = Color.FromArgb(248, 248, 248); //Cor por defeito(paleta 1) para a opo seleccionada no men secundrio 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 pgina principal ou MasterPage."); () throw new Exception("O controlo rpoxy de FeedBack, no 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