UNIVERSIDADE FEDERAL DE PERNAMBUCO – UFPE CENTRO DE INFORMÁTICA – CIN MESTRADO EM CIÊNCIA DA COMPUTAÇÃO DESIGN INTERATIVO DE FERRAMENTA DE MANIPULAÇÃO DE OBJETOS DE APRENDIZAGEM DE AMBIENTES VIRTUAIS DE ENSINO À DISTÂNCIA JOCÉLIO DE OLIVEIRA DANTAS PASSOS
195
Embed
PASSOS, J. O. D. Design interativo de ferramenta de manipulação de objetos de aprendizagem de ambientes virtuais de ensino à distância. Dissertação (Mestrado em Ciências da
Esta pesquisa visa à concepção de ferramentas virtuais que permitam a manipulação de objetos de aprendizagem. Para tanto, buscou-se entender as práticas de gestão de conteúdo em ambientes de cursos de ensino à distância, obtendo-se requisitos. Os metadados educativos (modelo SCORM) foram estudados para entender os objetos de aprendizagem. Análises funcionais de ambientes competidores para ensino à distância foram levadas em consideração. Desenvolveu-se uma metodologia centrada no usuário: observou-se usuários desempenhando suas tarefas, elaboraram-se cenários, realizou-se prototipagem e testou-se a aceitação dos protótipos pelos usuários. O ambiente proposto nessa pesquisa faz parte de um projeto mais abrangente intitulado Projeto Amadeus_MM , cujo objetivo é desenvolver um ambiente virtual para o ensino baseado em uma proposta pedagógica centrada em processos de mediação e avaliação, coordenado pelos professores Fernando Fonseca e Alex Sandro Gomes (Cin/UFPE).
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
UNIVERSIDADE FEDERAL DE PERNAMBUCO – UFPE
CENTRO DE INFORMÁTICA – CIN
MESTRADO EM CIÊNCIA DA COMPUTAÇÃO
DESIGN INTERATIVO DE FERRAMENTA DE MANIPULAÇÃO DE OBJETOS DE
APRENDIZAGEM DE AMBIENTES VIRTUAIS DE ENSINO À DISTÂNCIA
JOCÉLIO DE OLIVEIRA DANTAS PASSOS
RECIFE-PE
2006
UNIVERSIDADE FEDERAL DE PERNAMBUCO
CENTRO DE INFORMÁTICA
PÓS-GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO
JOCÉLIO DE OLIVEIRA DANTAS PASSOS
DESIGN INTERATIVO DE FERRAMENTA DE MANIPULAÇÃO DE OBJETOS DE
APRENDIZAGEM DE AMBIENTES VIRTUAIS DE ENSINO À DISTÂNCIA
Dissertação apresentada à Universidade Federal
de Pernambuco – UFPE, Centro de Informática,
para a pós-graduação em Ciência da Computação.
Orientador: Prof. Dr. Alex Sandro Gomes
RECIFE-PE
2006
RESUMO
Esta pesquisa visa à concepção de ferramentas virtuais que permitam a manipulação de
objetos de aprendizagem. Para tanto, buscou-se entender as práticas de gestão de conteúdo em
ambientes de cursos de ensino à distância, obtendo-se requisitos. Os metadados educativos
(modelo SCORM) foram estudados para entender os objetos de aprendizagem. Análises
funcionais de ambientes competidores para ensino à distância foram levadas em consideração.
Desenvolveu-se uma metodologia centrada no usuário: observou-se usuários desempenhando
suas tarefas, elaboraram-se cenários, realizou-se prototipagem e testou-se a aceitação dos
protótipos pelos usuários. O ambiente proposto nessa pesquisa faz parte de um projeto mais
abrangente intitulado Projeto Amadeus_MM1, cujo objetivo é desenvolver um ambiente
virtual para o ensino baseado em uma proposta pedagógica centrada em processos de
mediação e avaliação, coordenado pelos professores Fernando Fonseca e Alex Sandro Gomes
(Cin/UFPE).
Palavras-chave: E-Learning, SCORM, CSCW, CSCL, Objetos de Aprendizagem, Ambientes
Virtuais de Ensino.
1 Processo CNPq no. Xxxx.xxxx/2005-xx.
ABSTRACT
This research aims the conception of vitual tools which allow the manipulation of learning
objects. Therefore, it was fetched to understand the practices of the content management in
aside courses environments, getting requisites. The educatives metadatas (SCORM model)
were studied to understand the learning objects. Functional analysis of competitive
environments to aside learning were took into consideration. It was developed a methodology
centred in the user: It was seeing users performing their tasks, it was made scenes, performed
prototyping and tested the accenptance of the prototypes by the users. The proposed
enviroment in this research takes part of a larger project called Amadeus MM Project, whose
objective is to develop a virtual enviroment to the learning based on a pedagogic purposal
centred in mediation and evaluation processes, coordinated by the Professors Fernando
3 AMBIENTES DE ENSINO À DISTÂNCIA................................................................................................53.1 AMBIENTES VIRTUAIS DE ENSINO..................................................................................................5
3.2 SISTEMAS DE GESTÃO DE CONTEÚDO...........................................................................................6
3.2.1 Características Básicas de um LMS.......................................................................................................7
4 METADADOS EDUCATIVOS: SHARABLE CONTENT OBJECT REFERENCE MODEL (SCORM)94.1 O QUE É SCORM?....................................................................................................................................9
4.2 OBJETOS DE APRENDIZAGEM...................................................................................................................11
4.3 ORIENTAÇÃO À OBJETO..........................................................................................................................13
4.4 HISTÓRIA DO SCORM............................................................................................................................14
4.5 ARQUITETURA DO SCORM 2004...........................................................................................................15
6 ANÁLISE DE COMPETIDORES DE LMS DISPONÍVEIS...................................................................266.1 CRITÉRIOS PARA ANÁLISE COMPETITIVA DE LMS.................................................................................27
6.3 OPEN LMS..............................................................................................................................................30
6.4 OUTROS AMBIENTES...............................................................................................................................31
6.5 RESULTADOS DA ANÁLISE DE COMPETIDORES.......................................................................................32
7 METODOLOGIA DE DESIGN INTERATIVO CENTRADA NO USUÁRIO.....................................347.1 OBJETIVOS...............................................................................................................................................35
7.4 PROTOTIPAGEM DE BAIXA FIDELIDADE...................................................................................................42
7.5 ANÁLISE DAS TAREFAS E TESTE DE USABILIDADE DOS PROTÓTIPOS......................................................44
8 RESULTADOS.............................................................................................................................................478.1 RESULTADOS DA OBSERVAÇÃO PARTE 1................................................................................................47
8.1.1 Requisitos de Observação e de Material..............................................................................................47
8.2 CENÁRIOS PARTE 1.................................................................................................................................53
8.2.1 Gestão de Conteúdo – Situação Atual..................................................................................................53
8.3 PROTOTIPAGEM DE BAIXA FIDELIDADE...................................................................................................55
8.3.1 Protótipo de Baixa Fidelidade 1 – Geração de dúvidas......................................................................56
8.3.2 Protótipo de baixa fidelidade 2 – Geração de dúvida.........................................................................57
8.3.3 Protótipo de Baixa Fidelidade 3 – Geração de dúvidas......................................................................61
8.3.4 Protótipo de Baixa Fidelidade 4 – Reuso de objetos de aprendizagem...............................................69
8.4 RESULTADOS DA OBSERVAÇÃO PARTE 2................................................................................................79
8.5 CASOS DE USO........................................................................................................................................80
8.6 DIAGRAMAS DE ATIVIDADE....................................................................................................................81
8.7 CENÁRIOS PARTE 2.................................................................................................................................83
8.7.1 Gestão de Conteúdo– Situação Futura................................................................................................83
8.8 ANÁLISE DAS TAREFAS E TESTE DE USABILIDADE DOS PROTÓTIPOS......................................................84
8.8.1 Análise da Tarefa 1 (Protótipo 3)........................................................................................................85
8.8.2 Análise da Tarefa 2 (Protótipo 4)........................................................................................................87
ANEXOS........................................................................................................................................................102ANEXO I - CONTEÚDO DO ARQUIVO IMSMANIFEST.XML.............................................................................102
ANEXO II - ARQUIVO VIEWCOURSES.JSP PERTENCENTE A API DO SCORM.............................................107
ANEXO III - SCRIPT DO BANCO DE DADOS SCORM..................................................................................111
ANEXO IV - SCRIPT DE ALTERAÇÃO DO BANCO DE DADOS SCORM.......................................................113
Anexo V – Código Fonte do protótipo funcional 2....................................................................................114
LISTA DE FIGURAS
Figura 1. Componentes LEGO..............................................................................................13
Figura 2. Visão da ADL: compartilhar objetos de aprendizagem.....................................15
Figura 3. Estrutura Básica de um pacote SCORM.............................................................17
Figura 4. API viewCourses.jsp em execução..........................................................................18
Figura 5. Árvore de Atividades do Ambiente SCORM.......................................................19
Figura 6. Opções de objetos do tipo asset.............................................................................23
Figura 7. SCO é um conjunto de asset´s...............................................................................23
Figura 8. Moodle: Registro de um curso SCORM no ambiente.........................................28
Figura 9. Moddle: Tela principal do Curso modelo SCORM............................................29
Figura 10. Moodle: Execução de uma lição do curso SCORM...........................................29
Figura 11. Open LMS: Tela principal...................................................................................30
Figura 12. Open LMS: Course Builder.................................................................................31
Figura 13. Open LMS: Execução de curso modelo SCORM...............................................31
Figura 14. Etapas principais da metodologia.......................................................................36
Figura 15. – Uso do Reload para criação do curso modelo SCORM..................................38
Figura 16. Protótipo de baixa fidelidade 1: Registrando Dúvida.......................................56
Figura 17. Protótipo de baixa fidelidade 1: Dúvida Enviada..............................................56
Figura 18. Protótipo Funcional: Registrar Dúvida..............................................................60
Figura 19. Protótipo Funcional: Enviando Dúvida.............................................................60
Figura 20. Tela Principal do Amadeus. Escolhendo um Curso..........................................61
Figura 21. Curso carregado segundo a estrutura de gestão de conteúdo..........................62
Figura 22. Aluno registrando uma dúvida em um item de um curso................................64
Figura 23. Professor respondendo uma dúvida de um item de um curso.........................66
Figura 24. Aluno tomando ciência da resposta do professor para um item de um curso.
Diagrama 4. Caso de Uso 2 – Aluno realizando curso com suporte ao registro de dúvida em
objetos de aprendizagem...................................................................................................81
Diagrama 5. Diagrama de Atividade 1 – Professor criando curso com reuso de objetos
de aprendizagem.............................................................................................................82
Diagrama 6. Diagrama de Atividade 2 – Aluno realizando curso com suporte a registro de
dúvida em objetos de aprendizagem.................................................................................82
Diagrama 7. Tarefa Realizar um Curso...............................................................................85
Diagrama 8. Tarefa Registrar Dúvida..................................................................................86
Diagrama 9. Tarefa Responder Dúvida................................................................................86
Diagrama 10. Tarefa Ciência da Dúvida..............................................................................87
Diagrama 11. Tarefa Criar Novo Curso...............................................................................88
1 INTRODUÇÃO
O ser humano, ao longo de sua história, sempre buscou avançar em seu conhecimento,
aprendendo de forma isolada, mas, principalmente, compartilhando seus saberes. Durante a
civilização grega, para citar apenas um exemplo, houve a formação de um “importante centro
cultural... para o alto aprendizado...” onde “... foram muitos e significativos os avanços na
medicina, astronomia, matemática geografia e ciência” [PAR 1995].
Muito conhecimento foi construído no decorrer desse processo histórico. Como o
conhecimento é volátil, muitas vezes é armazenado na mente das pessoas [AN3 2005], outras
formas de armazenar esses conteúdos têm sido buscadas. Durante muito tempo o papel foi
utilizado para isso. Contudo, o difícil acesso às informações contidas em papel, bem como os
incômodos em atualizá-lo [FAL 2004] provocou a necessidade de buscar outras formas de
armazenamento.
Hoje, com os avanços tecnológicos das mídias, o armazenamento deixou de ser o grande
problema. Passou-se a focar, então, outro aspecto: o conteúdo armazenado precisa ser
organizado de tal forma que permita ser facilmente encontrado, compartilhado, repensado e
novamente disponibilizado. Essa é uma das formas através das quais se desenvolve o processo
de aprendizagem. Por isso, há tanta preocupação em disponibilizar conhecimento visto que é a
capacidade de utilizar informação para resolver um determinado conjunto de problemas [AN3
2005]. O grande detalhe é que se pode transferir o conhecimento sem perdê-lo, configurando-
se uma característica muito importante na sua gestão.
A necessidade de se recuperar informações dispersas de forma eficiente também foi
comentada por Falbo et al. [FAL 2005]:
... o excesso de recursos de informação, associado à falta de semântica para guiar uma busca por recursos realmente relevantes para o contexto em mãos. Assim como a falta de informação constitui um problema grave, o excesso de recursos de informação também o é, já que, em última instância, pode não ser possível coletar em tempo hábil a informação necessária para apoiar à tomada de decisão durante a resolução de problemas. Este fato pode ser claramente percebido na Web, onde, muitas vezes, achar informação relevante pode ser uma tarefa árdua e complexa, e está relacionado, sobretudo, à falta de semântica associada aos recursos de informação.
1
Com o advento da Internet e o surgimento posterior de ambientes virtuais [EBE 2005], o
ensino à distância tornou-se um caminho para unir conhecimentos remotamente dispersos,
com uma estratégia, ou semântica, tal que permita maximizar o processo de aprendizagem.
Para viabilizar o ensino à distância, diversos softwares de gestão de conteúdo surgiram. Esses
Sistemas de Gestão de Conteúdo/Aprendizagem ou Learning Management System (LMS), são
softwares, geralmente baseados em tecnologia Web, criados para planejar, implementar e
avaliar um processo de aprendizagem específico à distância [WHA 2004]. Basicamente, um
LMS provê meios para criar e disponibilizar conteúdo, monitorar a participação do estudante
e avaliar sua performance. Esse pode também prover, ao estudante, condições para usar
recursos interativos tais como sala de discussão e vídeo conferência. LMS são considerados
hoje como “agente revolucionário da formação” [AN5 2005].
Além do aspecto acadêmico, segundo Natali et al. [NAT 2005], a gestão de conteúdo tem sido
vista também por outro ângulo:
... a gerência do conhecimento vem sendo reconhecida como uma fonte de vantagem competitiva para organizações de desenvolvimento de software. A gerência de conhecimento apresenta-se como uma forma de apoiar os desenvolvedores, de modo que esses realizem suas atividades melhor e mais rapidamente, aproveitando experiências anteriores para auxiliar à tomada de decisão.
Essa dissertação, por meio de um processo de Design Interativo baseado em cenários e
prototipagem de ambientes de gestão de conteúdo para ambientes de ensino à distância, busca
entender como o conteúdo deve ser organizado nesses ambientes.
Esse estudo está organizado da seguinte maneira: a importância da gestão de conteúdo
(capítulo 2), conceitos e as características dos ambientes de ensino à distância (capítulo 3),
metadados educativos e o conceito de objetos de aprendizagem, bem como a analise de um
dos modelos criados para implementar esse conceito, o SCORM, descrevendo seu propósito,
arquitetura e funcionamento (capítulo 4), realização da análise de competidores sob a ótica da
gestão de conteúdo e com base no modelo SCORM (capítulo 5), definição do problema a ser
resolvido (capítulo 6), explicação da metodologia para resolução do problema (capítulo 7),
resultados obtidos após a aplicação da metodologia (capítulo 8), conclusão (capítulo 9) e
trabalhos futuros (capítulo 10).
2
2 MOTIVAÇÃO
Muitas instituições públicas e privadas têm se interessado em disponibilizar informações na
Internet por meio de ambientes de ensino à distância. Um grande erro pode ser cometido no
processo de implantação desse tipo de solução: implantar programas grandes e caros e,
depois, economizar na hora de desenvolver e organizar conteúdo [BRI 2004]. Acredita-se que
o aplicativo que gerencia o conteúdo tem muito mais importância que a flexibilidade de
manusear o conteúdo propriamente dito (ibidem). Pode-se erroneamente pensar assim, por se
viver num mundo onde é dada tanta importância ao investimento em tecnologia. Por outro
lado, sem um programa que viabilize a organização do conteúdo não se alcançará nenhum
sucesso.
Essa área é conhecida como gerenciamento de conhecimento (ou Knowledge Management),
que possibilita à instituição ter uma infra-estrutura com recursos para criar, compartilhar e
gerenciar o conhecimento (ou conteúdos) [ROS 2002]. Em tal ambiente, pode haver mais
contribuição ou compartilhamento de conhecimento. Novos conteúdos podem ser criados a
partir de conteúdos já existentes, aumentando o banco de conhecimento.
Segundo Rosenberg [ROS 2002], a questão não é mais se o ensino à distância será
implementado ou não por diversas instituições. Essa é uma tendência atual e natural. A
questão é se tal forma de ensino será bem implantada, ou seja, se haverá uma gestão do
conhecimento ou de conteúdo. Preocupadas com a questão apresentada, várias instituições
criaram seus padrões de gestão de conteúdo [HEN 2002] [SUA 2005], como seguem:
Institute of Eletrical and Electronic Engineers (IEEE) Learning Technology Standards Committee (LTSC);
isso quando diz: “Ao criar bibliotecas de objetos, produtos diferentes podem utilizar o mesmo
material, reduzindo, portanto, a redundância e os custos” (p. 162).
As características e conceitos desse modelo citados acima são explicados a seguir.
1 – Framework, segundo Peters et al. [PET 2001], é um sistema conceitual modificável, para
propósitos gerais, que ajuda a estreitar à distância entre uma resolução de alto nível para um
problema e a sua implementação de software. Quem utiliza esse sistema para gestão de
conteúdo não precisa se preocupar em como a aprendizagem eletrônica será armazenada ou
processada, mas pode concentrar os esforços no conteúdo que será oferecido, como melhor
apresentá-lo e como mantê-lo atualizado.
2 - Interoperabilidade (Ibidem) é alcançada quando se consegue acoplar um sistema a
sistemas de software de outras origens, compartilhando dados e, nesse caso, conteúdo.
Segundo Heng [HEN 2002] esse conteúdo de múltiplas origens deve funcionar de forma
satisfatória em diferentes sistemas de aprendizado.
9
3 - Usabilidade, segundo Peters (Ibidem), é o esforço necessário para aprender, operar,
realizar entradas de dados e interpretar saídas. Acessar conteúdos e aprender precisa ser uma
tarefa fácil.
4 - Reusabilidade é a possibilidade de os módulos de um sistema poderem ser usados em
outras aplicações ou em diferentes contextos [PET 2001] [HEN 2002]. Nesse estudo, pode-se
substituir a palavra módulo por conteúdo de aprendizagem.
5 – Ser acessível significa que o componente precisa está disponível para reuso ou
importação. Pode está localizado em um ambiente remoto e que facilmente possa ser
distribuído para diferentes localizações [SCO 2004]. A palavra componente pode ser
substituída por conteúdo.
6 – Ser durável significa ter a possibilidade de acompanhar a tecnologia de informática,
permitindo mudanças, sem custos de re-projeto, reconfiguração ou recodificação [SCO 2004].
Um conteúdo, no tocante a tecnologia, não perde sua validade. Mesmo que seu interior não
seja atualizado, há uma garantia que sempre poderá ser acessado.
Tal modelo descreve: "como se fazer" e "como se executar" cursos baseados na Web. Assim,
ao se construir um LMS em conformidade com o modelo SCORM, é permitido aos usuários
acesso, simplificado e padronizado, a cursos de alta qualidade desenvolvidos em todo o
mundo seguindo esse conceito [PWA 2005], sem a necessidade de maiores readaptações
técnicas [EIR 2003].
Com o SCORM é possível então construir um LMS capaz de procurar, importar, compartilhar,
reusar e exportar conteúdos de aprendizado de modo padronizado [RHA 2004]. Segundo
Heng [HEN 2002] muitas instituições têm desnecessariamente reescrito conteúdos para
aprendizagem. O ideal, no processo de construir novos cursos, seria obter conteúdos de outras
instituições e reuni-los aos criados na própria instituição. Para isso, o conteúdo deve ser,
então, fragmentado em pequenas partes conhecidas como objetos de aprendizagem. Esses são
vistos atualmente como uma das soluções para resolver problemas de compartilhamento de
conteúdo [ROS 2002].
10
Criar rotinas para produzir esses conteúdos, de forma articulada e usando amplamente
guidelines4, são atualmente estados da arte em e-learning [SCO 2004].
4.2 Objetos de aprendizagem
Como o SCORM visa à usabilidade e reusabilidade de conteúdo, esse modelo foi estruturado
com base em objetos de aprendizagem ou de conhecimento (Ver detalhes no tópico ).
Um objeto de aprendizagem é um fragmento inteligível de conteúdo capaz de ser
recombinado, usado e reusado, para formar um conteúdo mais abrangente: um curso [HEN
2002]. Esse curso, por sua vez, pode ser parte de um conteúdo mais abrangente ainda e assim
sucessivamente. Objetos de aprendizagem são conhecidos também como “instructional
objetcts” [SCO 2004].
Esse conceito é considerado um dos avanços mais promissores na criação de soluções para e-
learning [ROS 2002]. Um objeto, então, é o menor “bloco” de informação independente e
com significado para quem aprende. Essa unidade de componente de aprendizado, uma vez
criada e disponibilizada, pode ser reorganizada, aproveitada e alterada facilmente por uma
ampla gama de ferramentas de desenvolvimento, sem a dependência de um fornecedor ou
técnica específica [ERI 2003].
Tal “bloco” (ou componente) pode ser um objeto texto, uma mídia (vídeo, áudio), gráficos,
animações, avaliações. Rosenberg [ROS 2002] exemplifica isso da seguinte forma:
Uma maneira fácil de pensar nos objetos de aprendizado / conhecimento é
imaginar uma página que você desenvolverá em seu site da Web. Você acessa
as informações dos bancos de dados e os arquivos de documentos e cola o
conteúdo no site. Para enfatizar o que significa, você vai a um arquivo de clip
art, corta um gráfico que salienta seu ponto de vista e cola também. Talvez
você também acesse uma planilha que foi preenchida por um colega e cole-a
no documento. Você pode adicionar um arquivo de áudio ou de vídeo ou links
para outros sites da Web. No final, você construiu alguma coisa nova com
objetos de conteúdo já existente de um ou mais repositórios. Ao mesmo
tempo, outras pessoas podem estar utilizando os mesmos objetos para outros
4 Segundo Shneiderman [SHN 1998] guidelines são diretivas (ou diretrizes) desenvolvidas por muitas organizações que ajudam a promover consistência e padronização entre múltiplos projetos de uma mesma categoria de aplicação.
11
objetivos (dentro das leis autorais). Parece muito com o gerenciamento do
conhecimento! (p. 163).
Outro fator importante a ser avaliado é a granularidade do conteúdo [HEN 2002]. É a
preocupação que se deve ter quanto ao tamanho de cada objeto de conhecimento, ou seja, qual
deve ser o tamanho do menor “bloco” ou “grão”. Uma das abordagens é quanto menor
melhor, visto que usuários geralmente precisam “garimpar” grande quantidade de informação
para poder obter o que desejam (ibidem). Objetos de aprendizagem maiores são de difícil
reuso, enquanto os menores não. Heng também afirma: “A Pedagogia sugere que o ideal para
uma lição é um tempo entre cinco e vinte minutos. Ao usar objetos de aprendizado de menor
tamanho possível, a personalização do material torna-se mais fácil” (p. 3). Isso é muito bom
para o aprendizado (ibidem).
Uma das aplicações desse conceito de objeto de aprendizagem (ou aprendizado) aconteceu na
Integrated Project System (IPS) [IPS 2005]. Rosenberg [ROS 2002] relata o exemplo dessa
empresa que atua na área de treinamento de gerenciamento de projetos. Ao implantar cursos
na Web, dividiu os seus conteúdos em objetos de aprendizagem reutilizáveis, utilizando-os
para vários objetivos.
Os objetos podiam ser reunidos em cursos de treinamento on-line, mas também podiam ser
utilizados para criar componentes de gerenciamento de conhecimento ou ferramentas de
suporte ao desempenho. E, ao vincular o sistema a um modelo de competências, os aprendizes
conseguiam receber apenas o conteúdo de que precisavam e no formato adequado para eles.
Dessa maneira, a propriedade intelectual da IPS podia ser utilizada para vários objetivos e
ainda oferecer o grau de personalização que os alunos desejavam. A flexibilidade da
tecnologia de objetos de aprendizado, ou seja, sua habilidade em selecionar, reunir e fornecer
conteúdo relevante nos termos definidos pelos usuários, resultou em uma a adição
significativa ao modelo de negócios atual da IPS. (p. 163).
Para Heng [HEN 2002], os objetos de aprendizagem muito se assemelham à usabilidade,
reusabilidade e interoperabilidade dos blocos LEGO (Figura 1) [LEG 2005].
12
Figura 1. Componentes LEGO.
Com esses blocos LEGO pode-se construir vários tipos de formas e figuras. Uma caixa
contendo muitos desses blocos com uma grande variedade de formas, tamanhos e cores, e o
uso da imaginação, permite uma gama de construções diferentes. O conceito LEGO é muito
diferente do conceito puzzle (quebra-cabeça) [PUZ 2005], no qual cada peça encaixa apenas
em um único lugar e o trabalho completo forma sempre a mesma figura. Objetos de
aprendizagem são o LEGO do aprendizado eletrônico [HENG 2002]. Pode-se, então, chamar
esse modelo de aprendizagem orientada a objeto.
4.3 Orientação à Objeto
Os objetos de aprendizagem, em linhas gerais, têm suas raízes no conceito da Análise e
Programação Orientação a Objeto. Uma classe é um tipo de dado definido pelo usuário, ou
seja, pelo programador ou analista [SEB 2000]. Um objeto é uma instância, ou ocorrência, da
classe [DEI 2001].
Esse conceito de classes foi introduzido com a linguagem SIMULA [SIM 2005] em 1967 e
Smalltalk [SMT 2005] em 1980 [GHE 1998]. Duas linguagens de programação bastante
difundidas que atualmente carregam a bandeira da orientação a objeto são C++ [GCC 2005],
criada em 1980, e Java [JAV 2005] criada em 1990 [SEB 2000].
Vantagens da Orientação a Objeto relativas ao conceito de objetos de aprendizagem [SEB
2000]:
Permite abstração, ou seja, representar entidades do mundo real. Um objeto de
aprendizagem é uma abstração do conhecimento que se deseja disponibilizar.
É um recurso contra a complexidade. Um meio de tornar programas grandes e/ou
complicados mais manejáveis. Um conhecimento vasto dividido em objetos menores é
mais fácil de ser manipulado.
13
Permite maior produtividade porque permite reutilização de código. Esse recurso é
disponibilizado com o conceito de herança.
Novos tipos são criados a partir de tipos já existentes, herdando suas funcionalidades, e, se
necessário, modificando-as [GHE 1998]. Softwares são então construídos a partir de
O CAM é um conjunto de três especificações descritas a seguir: LOM, XML "binding e
IMS Content Packaging Specification.
A primeira é especificação chamada LOM (Learning Object Metadata), ou Metadados para
Objetos de Aprendizagem é um dicionário de tag5 que é usado para descrever o conteúdo de
aprendizado [RHA 2004] e representá-lo [SCO 2004]. O metadata (metadados), segundo
Heng [HEN 2002] descreve o objeto de aprendizagem, especificando a sintaxe e a semântica
dos atributos mínimos requeridos, bem como o proprietário do objeto, critérios de
distribuição.
Além do metadados, o CAM também contém uma segunda especificação chamada XML
"binding" utilizado para as tags do metadados. Define como codificar as tags para que
possam ser lidas pelo computador [RHA 2004].
A terceira especificação presente no CAM é o IMS Content Packaging Specification. Tal
especificação para conteúdo do pacote define como empacotar ou reunir o conjunto de objetos
de aprendizagem, seu metadados e a informação sobre como o conteúdo foi montado para ser
distribuído, ou seja, compartilhado entre sistemas de aprendizado [RHA 2004]. Essa
especificação é que possibilita a interoperabilidade [SCO 2004]. O conteúdo desse pacote
pode ser um curso, um módulo do curso ou uma lição do módulo [SCO 2004].
O pacote (Content Package) é um arquivo “zipado” [WZP 2005] contendo: (1) todos os
arquivos necessários para o aprendizado (Physical Files) e (2) um XML manifest (Manifest
File). Esse último é um arquivo em formato XML [XML 2005] que define todo o conteúdo de
aprendizado (objetos de aprendizagem) presente no pacote e a relação entre esses
componentes [RUS 2004] [SUA 2005]. Quando o pacote é importado para o ambiente
SCORM, as informações desse arquivo são utilizadas para preencher as tabelas TBCourseInfo
e TBItemInfo, que serão detalhadas no tópico a seguir. O LMS utiliza essas informações para
apresentar o conteúdo. No Anexo I encontra-se o conteúdo de um arquivo XML manifest
chamado imsmanifest.xml criado com um Editor de curso para o padrão SCORM durante a
execução da metodologia. A Figura 3 apresenta a estrutura básica do pacote SCORM.
5 Tag é um termo genérico para a definição de um elemento de linguagem [WHA 2004].16
Figura 3. Estrutura Básica de um pacote SCORM.
O RTE provê a comunicação entre o conteúdo de aprendizado e o gerenciador, o LMS [SCO
2004]. Através dos recursos disponibilizados por esta Application Programming Interface
(API - Interface de Aplicação de Programação)6, desenvolvida em Java Server Pages (JSP)
[JSP 2004], o aprendiz pode ter acesso ao conteúdo do LMS [RHA 2004]. No Anexo II está o
conteúdo do arquivo viewCourses.jsp, que permite ao aprendiz acessar um curso disponível
(previamente importado e registrado) no ambiente. Arquivos como esse ficam armazenados
no caminho adl\admin, adl\import e adl\runtime quando o ambiente é instalado. A Figura 4
mostra, em execução, a opção da API para escolha de um curso.
6 API são métodos predefinidos pelo sistema operacional do computador ou por uma aplicação. Os programadores podem escrever mais facilmente aplicações fazendo apenas requisições ao sistema operacional ou a uma aplicação por meio desses métodos [WHA 2004].
17
Figura 4. API viewCourses.jsp em execução.
O SN armazena um conjunto de regras de seqüência e gerencia o processo de navegação do
aprendiz. A partir dessas regras, é formada uma Árvore de Atividades (Activity Tree),
mostrada na Figura 5, que proporciona a interação do aprendiz com o LMS [SCO 2004].
18
Figura 5. Árvore de Atividades do Ambiente SCORM.
Por manter as regras e a navegação separadas do conteúdo dos objetos, o conteúdo pode ser
reusado de novas e diferentes formas, suportando muitas estratégias diferentes de instrução
[ADL 2004].
19
Árvore de
Atividades
4.6 Classes SCORM
Para realização da pesquisa o modelo SCORM 20047 foi “baixado” e instalado8. Dois cursos
foram importados para o modelo, identificados como “Course-1” e “Course-2”.
Além da literatura encontrada, apresentada no tópico anterior, necessitou-se de um maior
aprofundamento desse modelo. Isso se deu através do processo de reengenharia de software.
A reengenharia de software é executada com o objetivo de obter uma melhor compreensão de
um sistema existente, obtendo uma representação em um nível de abstração maior do que o
código-fonte [PRE 1995]. Possibilita a reconstrução ou reimplementação do sistema sob um
novo formato. Parte-se, então, de um sistema existente, analisando-o de forma a identificar
seus componentes e suas inter-relações, recuperando informações e estruturas úteis como
modelo de dados, requisitos funcionais e algoritmos [PET 2001].
A aplicação da reengenharia possibilitou entender do funcionamento do modelo SCORM,
chegando-se a descrição do modelo de dados, representado pelo diagrama de classe
(Diagrama 1), exibido no padrão UML [UML 2005]. O diagrama apresenta as classes
SCORM e os relacionamentos entre elas. A compreensão desses elementos básicos presentes
no diagrama, a saber, classes e atributos, é por demais relevante para essa pesquisa, porque
possibilita entender como são armazenados os objetos de aprendizagem.
7 Modelo SCORM encontra-se em http://www.adlnet.org/index.cfm?fuseaction=SCORDown, opção CTS1_3STSetup.exe.
8 Instalado em http://200.164.233.156:8080/adl/runtime/LMSMain.htm20
RES-A51BF8C4-0D0A-069F-64DE-950F5BACD067Launch Type Title
/adl/CourseImports/Course-2/index.html asset Conectividade de Banco de Dados Java/adl/CourseImports/Course-2/oquejdbc.html asset 1. O que e JDBC?/adl/CourseImports/Course-2/estudode.html asset 2. Estudo de Caso/adl/CourseImports/Course-2/registra.html asset 3. Registrando o Banco de Dados/adl/CourseImports/Course-2/consulta.html asset 4. Consultando Dados/adl/CourseImports/Course-2/atualiza.html asset 5. Lendo, Inserindo e Atualizando dados/adl/CourseImports/Course-2/dicionario.html asset Dicionario/adl/CourseImports/Course-2/bibliogr.html asset Bibliografia
22
O atributo Type contém duas entradas possíveis: o Sharable Content Objects (SCOs – Objetos
de Conteúdo Compartilhável) e Assets. Um Asset pode ser um link para um conteúdo físico:
texto, imagem, som, página Web, como na Figura 6. O SCO é um conjunto de um ou mais
Assets (Figura 7) e representa uma unidade lógica de aprendizado ou módulo [RUS 2004].
Figura 6. Opções de objetos do tipo asset.
Figura 7. SCO é um conjunto de asset´s.
A classe TBUserInfo () armazena os usuários do ambiente, sua identificação (UserID,
“admin”), o sobrenome (LastName, “admin”), o primeiro nome (FirstName, “John”), se tem
status de administrador (Admin, True), a senha (Password, “admin”) e se é um usuário ativo
A classe TBUserCourseInfo (Tabela 4) armazena os cursos que estão registrados para um
usuário específico identificando o usuário do curso (UserID, “admin”) e o curso registrado
para esse usuário (CourseID, “Course-1”). Um usuário pode registrar vários cursos e um
curso pode ser registrado por vários usuários.
Tabela 4. Conteúdo da Tabela TBUserCourseInfo.
UserID CourseIDadmin Course-1admin Course-2
No Anexo III encontra-se o script completo obtido da base de dados SCORM.
24
5 PROBLEMA
Como a tarefa de gestão de conteúdos é complexa, o problema abordado nesse presente
trabalho é o identificar e validar as necessidades dos usuários professores e alunos quanto à
manipulação de componentes de aprendizagem e de suas partes em ambientes virtuais de
ensino. Deseja-se saber o que implementar para atender essas necessidades de forma simples
e completa e como isso pode ser feito. A pergunta central é a de saber: quais e como atender
as necessidades de um sistema de manipulação de componentes de aprendizagem? Que
tarefas são realizadas pelos professores? E pelos alunos?
A análise de competidores, no próximo capítulo, auxiliará na identificação de ambientes
virtuais de ensino que possuam gestão eficaz de conteúdo, bem como requisitos para o
ambiente a ser proposto nesse estudo.
25
6 ANÁLISE DE COMPETIDORES DE LMS DISPONÍVEIS
Além da literatura sobre ambientes de gestão de conteúdo, a quantidade de ambientes do tipo
LMS nos permite realizar uma análise desses como forma de identificar seus pontos fortes e
fracos. Esse procedimento é conhecido como Análise de Competidores. Segundo Michael
Porter [POR 1991], em seu livro Estratégia Competitiva, os objetivos de uma Análise de
Competidores, são descrever:
O que o competidor está fazendo;
A estrutura/tecnologia do competidor;
As estratégias de competição;
A posição/situação do competidor no mercado;
Os pontos fortes e fracos do competidor;
Em relação ao objeto em questão a analise de competidores:
Ajuda a destacar características que o distinguem dos competidores;
Fornecer metodologia para auto-análise;
Mário Figueira [AN2 2005] comenta que:
Existem atualmente perto de uma centena de fornecedores de sistemas de gestão da formação online, quase todos de origem americana... a lista de LMS é enorme. É urgente a realização em Portugal de um estudo independente que compare as vantagens e inconvenientes de cada um dos LMS disponíveis no mercado português indicando quais são os mais adequados e para que fins.
26
6.1 Critérios para Análise Competitiva de LMS
Essa análise está baseado no tópico 3.2.1 Características Básicas de um LMS, que norteou os
critérios para a escolha dos ambientes (há uma grande quantidade desses), bem como as
características que foram observadas nesses competidores.
Os critérios para escolha desses ambientes virtuais de ensino foram:
Ser de acesso livre, ou seja, possuir um cadastro gratuito para se fazer um curso;
Suporte ao modelo SCORM, ou seja, permitir importação e registro de conteúdo do
curso nesse padrão.
A análise desses ambientes surge como fonte geradora de requisitos. Outros requisitos
também foram obtidos através da observação do uso (apresentada em 7.2 Observação dos
usuários, página 47). As características observadas em cada competidor foram:
Permite reutilização de parte do curso registrado;
Registra o caminho que o aluno fez (navegação) ao realizar o curso;
Permite que o aluno registre notas (observações) pessoais, ao realizar o curso, próximo
a um ponto (módulo, lição, seção e/ou parágrafo);
Permite que o aluno tire dúvidas com o professor clicando exatamente no ponto que
gerou a dúvida;
Os pontos fortes e fracos estão listados após a análise de cada ambiente competidor.
O Moodle é sistema Gerenciador de Cursos (Course Management System – CMS) [MOO
2005]. Esse ambiente auxilia educadores a criar cursos online, e é baseado na pedagogia
social construtivista. A licença desse ambiente é open source9 desenvolvido em PHP [PHP
2005]. Apresentando-se em diversas línguas, inclusive em português, o Moodle é utilizado em 9 Um software é geralmente classificado como open source quando o seu código fonte fica disponível para uso e modificação. Geralmente são programas desenvolvidos com colaboração pública [WHA 2004].
27
várias partes do mundo, em diversas universidades, escolas, empresas e, também,
individualmente por professores.
O Moodle analisado foi instado10 num ambiente Linux com banco de dados MySQL [MYS
2005]. O Moddle suporta o modelo SCORM. Com o uso da opção Escolher ou atualizar um
pacote SCORM, o Moodle (Figura 8) importou o pacote do curso Java e JDBC criado
(scormjdbc.zip).
Figura 8. Moodle: Registro de um curso SCORM no ambiente.
As Figura 9 e 10 trazem a tela do Moodle executando o curso no formato SCORM.
Figura 9. Moddle: Tela principal do Curso modelo SCORM.
Figura 10. Moodle: Execução de uma lição do curso SCORM.
Pontos Fortes:
Registro e Importação fácil de um curso modelo SCORM pelo professor;
Navegação fácil de um curso modelo SCORM por parte do Aluno;
Fácil Alteração de um pacote de curso modelo SCORM pelo professor;
Pontos Fracos:
Não permite que partes do curso sejam reaproveitadas por outro curso;
Não há opção para o aluno deixar anotações pessoais próximo a um ponto específico;
Não há opção para o aluno enviar dúvidas para o professor a partir de um ponto
específico do curso;
Ambiente também não registra o caminho que o aluno deixou ao fazer o curso
SCORM.
6.3 Open LMS
O Open LMS [OLM 2005] é um ambiente criado utilizando as tecnologias: Servlet, JSP,
JavaBeans [JVB 2005] e Jakarta Struts Application Framework [STR 2005], com banco de
dados MySQL.
29
Dentre as opções disponíveis na tela principal (Figura 11), destaca-se a opção Instrutor Tools
porque contem o item Course Builder (Figura 12). Essa ferramenta é responsável pela criação
e manutenção de cursos para tal ambiente.
Figura 11. Open LMS: Tela principal.
Figura 12. Open LMS: Course Builder.
A Figura 13 apresenta o ambiente executando um curso modelo SCORM.
30
Figura 13. Open LMS: Execução de curso modelo SCORM.
6.4 Outros Ambientes
Outros ambientes também se enquadram em algumas características citadas acima. Também
declaram ser apenas compatíveis com o modelo SCORM. Essa afirmação se encontra no
repositório Sourceforge [FOR 2005] ou na página oficial de cada ambiente. São eles:
Avatal Learn Station [ALV 2005];
a-LMS Learning Management System [ALM 2005];
DoceboLMS [DLM 2005];
ILIAS open source [ILI 2005];
Lotus Learning Management System [LOT 2005].
Sumatra System 3 [SS3 2005];
6.5 Resultados da Análise de Competidores
Analisou-se aqui ambientes – amostra representativa internacional - com relação à gestão de
conteúdo. Diante da complexidade das tarefas relacionadas à gestão e reutilização de 31
conteúdos detectou-se ausência de ambientes que tratem o problema de gestão ao nível de
uma manipulação fina de componentes de aprendizagem e de suas partes. Eles apenas se
limitam a importar pacotes SCORM e executar os cursos nesse padrão. Não há opção nesses
ambientes para reaproveitamento de cursos ou partes deles, usando ou não objetos de
aprendizagem. Não há também interação utilizando esses objetos, como registro e resposta de
dúvidas em um determinado item do curso. Isso também foi notado por Ramalho quando
menciona que o LMS fornece pouca ou nenhuma política de produção de conteúdos [RAM
2005].
6.5.1 Requisitos Gerais abordados nessa pesquisa
A partir do resultado da análise de competidores e informações apresentadas nos capítulos
anteriores, propõe-se um ambiente de gestão de conteúdo, baseado no conceito de objetos de
aprendizagem, atendendo aos seguintes requisitos gerais:
[REQG01] Permitir reutilização, no mesmo ambiente, de um objeto de aprendizagem
SCORM. Em conformidade com a quarta característica básica de um LMS,
gestão de conteúdo, levantada no tópico 3.2 SISTEMAS DE GESTÃO DE
CONTEÚDO.
[REQG02] Permitir rastrear os caminhos percorridos pelo usuário aprendiz ao manusear os
materiais de um componente, mantendo um registro da partes dos objetos de
aprendizagem que foram utilizados para isso. Em conformidade com a primeira
característica básica de um LMS, o controle das atividades.
[REQG03] Oferecer ao aluno aprendiz uma interface que lhe permita registrar uma dúvida
em determinado objeto de aprendizagem (tópico), endereçando essa dúvida para o
professor. Essa interface deve permitir também que o aluno tome ciência da
resposta da dúvida. Em conformidade com a terceira característica básica de um
LMS, a interatividade. Isso viabiliza o registro de dúvidas por parte do aprendiz e
respostas por parte do instrutor/professor, possibilitando um maior envolvimento
do aprendiz.
32
[REQG04] Oferecer indicações visuais (símbolos) para que um aluno, em caso de dúvida em
um determinado objeto de aprendizagem, sinalize para um professor (ou tutor) de
forma que esse reconheça essa dúvida e possa respondê-la.
33
7 METODOLOGIA DE DESIGN INTERATIVO CENTRADA NO
USUÁRIO
Este tópico aborda quais os objetivos gerais e específicos da proposta e que meios foram
utilizados para atingi-los.
Os meios adotados visam proporcionar a criação de um ambiente útil para o usuário. Todo o
projeto é centrado no usuário e isso requer a fundamentação teórica, não muito comum ao
escopo da Ciência da Computação, como conhecimento de ciências humanas [LEI 2001].
Pressman [PRE 1995] em sua obra Engenharia de Software evidencia isso:
A insatisfação do cliente com o sistema ‘concluído’ ocorre muito freqüentemente. Os projetos de desenvolvimento de software normalmente são levados a efeito apenas com um vago indício das exigências do cliente. A comunicação entre o cliente e o desenvolvedor de software freqüentemente é muito fraca. (p. 23).
Embora afirmando que o sistema é para o usuário, os desenvolvedores descobrem, somente
quando o tudo está “pronto”, que o produto não resolve os problemas do usuário. Por outro
lado, o usuário também precisa participar do projeto. Às vezes, imaginam que uma declaração
geral dos objetivos é suficiente para que se comece o desenvolvimento do produto,
informando os detalhes mais tarde [PRE 1995]. E realmente se torna tarde quando se percebe
que usuários e desenvolvedores não falavam do mesmo produto.
Esses são problemas conceituais (ou essenciais), ou seja, ocorrem no momento da concepção
do software, enquanto se está levantando especificações/requisitos [PET 2001], ficando a
essência do software comprometida.
Essa metodologia provê uma “cuidadosa comunicação entre o cliente e o desenvolvedor”
[PRE 1995], provendo um refinamento iterativo dos requisitos [PET 2001], levando em
consideração as habilidades dos usuários e o contexto onde eles estão envolvidos [LEI 2001].
34
7.1 Objetivos
7.1.1 Geral
Entender as necessidades dos usuários (professores e alunos), quando utilizam ambientes
virtuais de ensino. Essas necessidades estão relacionadas com atividades de gestão e
manipulação de conteúdo organizado em forma de componentes de aprendizagem.
7.1.2 Específicos
Modelar a prática de professores e alunos quanto à criação, gestão, reutilização e
manipulação de componentes de aprendizagem em um ambiente virtual de ensino.
Realizar uma prototipagem rápida, por meio da construção de cenários baseados na
revisão da literatura e na análise de competidores, para propor soluções que facilitem
essa tarefa.
Criar protótipos iniciais, de baixa fidelidade, do ambiente visando validar sua interface
e funcionalidade junto ao usuário.
Realizar testes de usabilidade com usuários de versões iniciais dos protótipos do
sistema de gestão de conteúdo para ambientes de EaD.
Construir novos cenários envolvendo os protótipos a partir dos resultados de testes de
usabilidade.
Adotou-se uma metodologia de design interativo, segundo a qual os problemas e necessidades
dos usuários foram resolvidos por aproximações sucessivas em ciclos de design, envolvendo
etapas de análise da prática dos usuários, prototipagem e testes de usabilidade. A Figura 14
apresenta as etapas principais dessa metodologia, descritas a seguir.
35
Figura 14. Etapas principais da metodologia.
7.2 Observação dos usuários
A produção de artefatos úteis para usuários requer que os projetistas obtenham e entendam os
requisitos dos usuários [MIL 1999]. Esses requisitos são os recursos de um produto, o fluxo
de informações, comportamentos e atributos [PET 2001].
A observação é uma pesquisa feita na área de trabalho, analisando situações com o objetivo
de compreender o contexto da atividade do usuário, descrevendo ambiente e interações [MIL
1999], estudando-se pessoas na realização de tarefas no seu cotidiano [BAR 1999]. O
resultado dessa pesquisa ajudará o projetista a levantar os requisitos do usuário [MIL 1999]
para o objeto em questão, propondo melhorias e mudanças efetivas, passando a entender o
usuário, seu ambiente e como interage com ele.
Tal atividade consistiu em analisar usuários utilizando um curso no formato ADL_ SCORM,
observando seus comportamentos ao aprender à distância, suas dificuldades, acertos e
decisões tomadas no decorrer do processo.
7.2.1 Procedimentos
Para levantar os requisitos e testar se esses foram ou não atendidos, a observação de usuários
se deu em dois momentos.
36
Observação
dos
Usuários
Construção
dos Cenários
Criação dos
protótipos
Testes de
Usabilidade
7.2.1.1 Observação Parte 1
Os usuários (alunos) foram observados utilizando o ambiente SCORM, tal qual foi instalado.
Portanto, não há recursos de envio de dúvidas. Esses mesmo alunos foram observados em um
segundo momento, após a criação do protótipo contemplando a gestão de conteúdo com o
recurso para tirar dúvidas.
Procedimentos da Parte 1
Para alcançar essa etapa do processo foram seguidas as seguintes tarefas:
1. Criação e instalação de um curso no modelo SCORM;
2. Escolha dos alunos para participar da observação segundo alguns critérios descritos no tópico participantes;
3. Realização da observação dos usuários;
4. Transcrição das observações dos alunos, levantando requisitos a partir da análise das informações colhidas.
Criação e instalação de um curso no modelo SCORM
O curso com o título Conectividade de Banco de Dados Java (disponível no SCORM
instalado) consiste em instruir o usuário como acessar um banco de dados por meio da
linguagem Java. Contém apenas um módulo dividido em:
1. O que é JDBC?
2. Estudo de Caso;
3. Registrando o Banco de Dados;
4. Consultando Dados;
5. Lendo, Inserindo e atualizando Dados;
6. Dicionário;
7. Bibliografia.
O Curso foi criado com o Microsoft FrontPageExpress [FPE 2005]. Utilizou-se o editor de
cursos open source para o formato SCORM chamado Reload (Reusable eLearning Object
Authoring & Delivery) [REL 2005] [SUA 2005], Figura 15, para criar e empacotar de forma
37
fácil e produtiva os arquivos necessários para que o reconhecimento do curso pelo SCORM.
Dentre esses arquivos está o XML manifest (estudado no tópico 4.5 Arquitetura do SCORM
2004). O pacote criado possui o nome scormjdbc.zip.
Figura 15. – Uso do Reload para criação do curso modelo SCORM.
Os requisitos mínimos exigidos para o curso criado são:
Windows Básico;
Modelagem (UML);
Banco de Dados Relacional;
ODBC (Open Database Connectivity);
SQL (Structured Query Language);
POO (Programação Orientada a Objeto);
38
Java Básico.
Os recursos exigidos são:
Intel Pentium II/450 MHZ ou melhor, 256 MB RAM;
Windows: 9x, XP, 2000 ou 2003;
J2SDK;
Microsoft Access 97 ou 2000;
Participantes
Foram escolhidos três alunos do curso de Ciência da Computação da Faculdade de Ciências
Aplicadas e Sociais de Petrolina – FACAPE [FAC 2004]. Levou-se em consideração o
conhecimento dos alunos em: (1) Windows Básico, (2) modelagem de sistemas, (3) conceitos
de banco de dados, (4) acesso ao banco de dados via ODBC, (5) comandos SQL, (6)
Programação Orientada a Objeto e Java. Apenas alunos a partir do 5º período poderiam
atender à maioria dos requisitos. O resultado dessa seleção estão resumidos na Tabela 5.
Tabela 5 - Características dos usuários que participaram dos testes.
Identificação Período Windows
Básico
Modelagem Banco de
Dados
ODBC SQL POO e Java
Aluno A 5º Sim Sim Sim Não Não Sim
Aluno B 6º Sim Não Não Não Não Sim
Aluno C 10º Sim Sim Sim Não Sim Sim
Material
Todos os alunos, em momentos diferentes, utilizaram para realizar o estudo uma máquina
com o sistema operacional Windows XP, com acesso à Internet e já configurada com o:
J2SDK, Editor de Texto para Java e Microsoft Access. Todos foram colocados diante do
ambiente ADL SCORM já preparado para o estudo.
Transcrição
39
Os registros obtidos dos alunos estão intercalados no texto em formato itálico e foram
colhidos após o trabalho de observação. Esse resultado está com o título “Resultados da
Observação – Parte 1”.
Os requisitos levantados por meio da observação são identificados assim: REQO (REQuisito
de Observação) ou REQM (REQuisito de Material). Eles serão mais bem detalhados no item
Resultados da Observação.
7.2.1.2 Observação Parte 2
Os mesmos alunos, que tiveram seus relatos registrados na primeira etapa da observação,
foram novamente observados, utilizando um protótipo funcional com o recurso para tirar
dúvidas.
Procedimentos da Parte 2
Para alcançar a segunda etapa da observação foram seguidas as seguintes tarefas:
1. Instalação do protótipo funcionando com recurso para tirar dúvidas;
2. Desenvolvimento de tarefas de observação dos alunos;
3. Avaliar se os requisitos levantados na primeira etapa da observação dos alunos foram
contemplados.
7.3 Cenários
Cenários são textos ou narrativas sobre pessoas e suas atividades [CAR 2000], criadas com o
intuito de apresentar o conceito de novos produtos. Essa construção textual permite inseri-los
dentro de uma situação plausível mesmo que hipotética, identificar potenciais problemas,
antecipar necessidades e até propor soluções alternativas para os problemas levantados [BØD
2000].
Com a técnica de cenários, problemas de interação podem ser identificados antes mesmo do
início da implementação da solução, evitando que um artefato seja implantado com
debilidades que só serão detectadas quando o usuário estiver utilizando. Assim, consegue-se
provocar novas idéias ou avaliar os protótipos.
40
Existem vários tipos de cenários. Segundo Bødker [BØD 2000], cenários positivos e
negativos podem ser criados, contendo extremos do trabalho cotidiano do usuário.
Apresentando esses cenários aos usuários, podem refletir sobre sua prática e informar o que se
espera e o que não se espera da solução que está sendo construída [CAR 2000]. Cenários
podem ser utilizados, então, como veículos de comunicação entre membros da equipe de
desenvolvimento e usuários. Os elementos característicos de um cenário são [CAR 2000]:
O ambiente: descreve um estado inicial para o episódio a ser descrito, descrevendo tanto o
ambiente fisicamente, quanto às pessoas nele presentes.
Atores ou agentes: uma ou mais pessoas com algum objetivo específico, interagem com o
ambiente influenciando e sendo influenciados.
O roteiro: seqüência de ações e eventos, o que fazem os atores e que mudanças acontecem
no ambiente. No decorrer do roteiro, decisões são tomadas pelo ator e esse pode ou não
alcançar seus objetivos.
A partir das dificuldades identificadas por meio da revisão da literatura, análise de
competidores e observações dos usuários, foram elaborados cenários sobre a prática de alunos
e professores, utilizando ambientes contendo gestão de conteúdo. Buscou-se, nos cenários,
envolver e analisar os requisitos levantados.
Os cenários de Gestão de Conteúdo com Ambientes de Ensino à Distância foram construídos
em dois momentos.
7.3.1 Cenários Parte 1
Foram criados cenários de situação atual, ou seja, antes da criação dos protótipos, após a
observação dos usuários. Tais cenários, segundo Bødker [BØD 2000], descrevem situações
específicas do domínio que está sendo pesquisado, ou seja, como o usuário executa suas
tarefas num determinado momento. São muito úteis também na comunicação entre projetistas
(designers) e engenheiros de softwares porque auxiliam na criação de soluções, bem no
alcance de uma melhor usabilidade no artefato final. Cenários foram aqui utilizados como
uma etapa da implementação técnica (ou modelagem), apresentando ou situando um problema
[BØD 2000].
41
A construção de cenários, no primeiro momento, tem como objetivo, então, descrever
situações que poderão ser vividas pelos usuários (professor e aluno) de LMS cuja solução não
contemple os requisitos levantados para gestão de conteúdo (reutilização de objetos de
aprendizagem e recurso para tirar dúvidas). Os dois cenários são:
Cenário 1.1 - Criação de curso por parte do professor;
Cenário 1.2 - Realização de um curso por parte do aluno.
7.3.2 Cenários Parte 2
Foram criados cenários de situação futura, ou seja, após a prototipagem. Esses cenários,
segundo Bødker [BØD 2000], são utilizados para avaliação de protótipos, assegurando sua
devida qualidade [ROY 1995]. Contêm, em seus roteiros, situações nas quais o usuário lida
com o futuro artefato, representado por protótipos.
Os cenários construídos, nessa etapa, descrevem usuários realizando suas tarefas de
aprendizagem à distância utilizando um artefato que contemple os requisitos de gestão de
conteúdo levantados. Os dois cenários são:
Cenários 2.1 - Criação de curso por parte do professor;
Cenários 2.2 - Realização de um curso por parte do aluno.
7.4 Prototipagem de baixa fidelidade
Essa etapa da metodologia visa criar parte do protótipo de um ambiente virtual de ensino –
Amadeus_MM. O Projeto AMADeUs baseia-se no princípio de que a avaliação do
aprendizado multi-dimensional é importante para a construção de um melhor
desenvolvimento do estudante. Visa oferecer suporte para o aluno e também para o professor
num processo de aprendizagem, colocando, em contato, alunos com alunos e alunos com
professores, mediando esse processo. O ambiente baseia-se na idéia de fluxo de trabalho, que
permite visualizar e avaliar o que está sendo feito em diferentes estágios do projeto. A idéia é
prover ferramentas para avaliação de tarefas, monitoração de grupos, interação e avaliação do
processo de aprendizado.
42
A prototipagem permite que se crie componentes selecionados do sistema, sem todas as
funcionalidades desejadas, com o objetivo de avaliar, com os usuários finais, partes do
ambiente [PRE 1995]. Essa avaliação dar-se-á baseada nos requisitos já levantados, evitando,
assim, incorrer em problemas essenciais ou conceituais [PET 2001].
Prototipagem é prática comum de fabricação, design de produtos, engenharia e
desenvolvimento de software que tem se mostrado útil para economizar tempo, dinheiro, pois
evita o re-trabalho [ROS 2002]. Segundo Pressman [PRE 1995] softwares que usem de telas
dinâmicas e tenham forte interação com o ser humano são bons candidatos à prototipagem.
A cada avaliação do usuário final, o protótipo vai sendo aprimorado. Isso provê condições
para que o usuário possa tomar decisões quanto às suas exigências em tempo oportuno,
sugerindo alterações que atendam melhor às suas necessidades [PRE 1995]. O protótipo
revela, assim, a estrutura conceitual do produto, permitindo, ao desenvolvedor, testar a sua
consistência e aceitação com os usuários [PET 2001].
Ainda que a implementação de um protótipo não seja prática, computacionalmente falando,
pode-se criar protótipos em papel, que descrevam a interação humano-máquina, usando
storyboard. Storyboard´s representam telas do sistema (podendo conter textos narrativos),
descrevendo a interação entre a máquina e o usuário [PRE 1995]. O usuário, ao avaliar as
telas, conforme solicitado em roteiros pré-definidos, têm uma perspectiva do funcionamento
do software. São protótipos de baixa fidelidade [SNY 2003].
Protótipos foram gerados com base nos requisitos gerais (REQG). Em seguida foram
realizados testes de aceitação. Os usuários avaliaram os protótipos em papel, fazendo
observações. Os protótipos funcionais, implementados por meio de linguagem de
programação, foram utilizados pelos usuários que foram observados utilizando-os. Suas
observações foram úteis no tocante à funcionalidade e à usabilidade. A esse processo dá-se o
nome de design iterativo centrado no usuário.
Os protótipos 1, 2 e 3 cobrem os requisitos REQG02, REQG03 e REQG04. O protótipo 4
cobre o requisito REQG01.
Após a criação do protótipo 3, esse foi submetido à nova observação (parte 2) por parte dos
mesmos alunos escolhidos na observação parte 1.
43
Tanto o protótipo 3, quanto o protótipo 4 foram envolvidos na etapa Cenários parte 2, como já
descrita anteriormente.
7.5 Análise das tarefas e Teste de usabilidade dos protótipos
Segundo Leite [LEI 2001], a tecnologia deve ser empregada para aumentar, em vez de
substituir, as habilidades dos usuários. O objetivo da usabilidade é explorar ao máximo as
habilidades dos usuários, criando ambientes de trabalho mais eficazes e produtivos.
Além de minimizar o esforço dos usuários para utilizar o produto, a usabilidade busca,
principalmente, a qualidade da interação do ambiente com os usuários [LEI 2001]. A interface
do ambiente surge, então, como um aspecto crucial para se atingir sucesso com sistemas de
gerência de conhecimento.
Os menores problemas de usabilidade podem desmotivar os usuários, afetando o uso e o
sucesso do ambiente proposto [NAT 2005].
Segundo Leite [LEI 2001], o teste de usabilidade é a oportunidade para verificar se:
Facilmente o usuário aprende a utilizar os recursos do produto;
O produto exige tempo e esforços mínimos para se realizar uma tarefa (desempenho);
Há flexibilidade e o usuário tem a possibilidade de utilizar o sistema de forma
inteligente e criativa, realizando um maior número de tarefas com as mesmas funções
e comandos do sistema, ou realizando tarefas que não estavam previstas pelos
desenvolvedores;
Há produtividade, ou seja o usuário é mais produtivo do que seria se não utilizasse
o sistema.
Para realizar o teste de usabilidade foi utilizada a Análise de Tarefa.
A Análise da Tarefa é muito essencial para o design do sistema. Essa análise procura
identificar os objetivos do usuário, suas tarefas, que estratégias utiliza para alcançar esses
objetivos, como o usuário lida com emergências, que ferramentas utiliza, que problemas ele
encontra [NIE 1993] [IBM 2001].
44
Para uma implementação eficaz das ações disponíveis para o usuário, dentro do ambiente,
deve-se entender como o usuário realiza suas tarefas no seu universo real. Dessa forma, o
projetista pode então ter uma visão da aplicação sob a perspectiva do usuário, ou seja, um
modelo das tarefas do usuário executando a aplicação [LEI 1999]. Assim o projetista pode,
por exemplo, analisar a freqüência de uma tarefa e decidir por prover ao usuário um “wizard”
para que ele realize aquela tarefa de forma mais confortável [IBM 2001].
As tarefas macros, ou de alto nível, são decompostas em tarefas intermediárias até se chegar a
passos mínimos e individuais. As tarefas estão, portanto, hierarquicamente montadas de um
nível mais alto para um nível mais baixo [SHN 1998].
Após o estudo dessa decomposição, o projetista pode criar representações metafóricas para a
interface. O usuário precisa reconhecer nas opções disponíveis na interface, os passos que ele
mesmo daria ao realizar uma tarefa sem o uso da interface.
A definição da quantidade de passos que o usuário precisa executar para realizar uma
determinada tarefa deve ser feita de modo cuidadoso. O usuário pode ficar frustrado com uma
interface que exija dele uma grande quantidade de passos para realizar algo [SHN 1998].
Porém, uma quantidade de passos reduzida de forma inadequada pode comprometer a
utilidade da ferramenta. A escolha mais apropriada é uma tarefa difícil [SHN 1998], sendo
auxiliada pelo teste de usabilidade.
Para a análise da tarefa utilizou-se o Euterpe, que é uma ferramenta útil na implementação do
método de análise de tarefa, usado para modelar ambientes nos quais pessoas interagem com
o uso de sistemas [GTA 2004]. Essa ferramenta permite que se realize a análise de tarefa de
forma hierárquica.
Os elementos na análise da tarefa são [VEE 1998]:
1. Agentes – pessoas que se relacionam com a tarefa. Por exemplo: indivíduos, grupo de
indivíduos e componentes de softwares. Agentes não identificam indivíduos específicos,
mas classes de indivíduos com uma determinada característica. Exemplo: professor,
aluno;
2. Objetivo - o que o agente intenciona fazer ou alcançar. Por exemplo: Enviar uma dúvida;
45
3. Tarefa – seqüência de etapas ou passos que o agente precisa realizar para alcançar um
objetivo. Essas tarefas podem ser fracionadas em sub-tarefas, e essas, por sua vez, em sub-
tarefas e assim por diante;
4. Ação - o último passo a ser realizado na seqüência de tarefas e sub-tarefas. Por exemplo:
mover, mudar, desligar, clicar;
5. Objeto – Algo relevante no que está sendo analisado como: mensagens, senhas, labels
(rótulos), representações gráficas, botões etc. Objetos são manipulados no nível da ação,
ou seja, é onde seu estado é alterado;
6. Ambiente – situação do meio, no qual estará descrito como se encontrava antes e como se
encontra depois da execução da tarefa por parte do agente. Exemplo: alterações gráficas
em objetos.
Foi realizada a análise da tarefa dos protótipos 3 e 4.
46
8 RESULTADOS
Após a execução da metodologia, descreve-se os resultados obtidos em cada etapa.
8.1 Resultados da Observação Parte 1
Os alunos selecionados foram observados e alguns requisitos de ambiente foram levantados
com esse procedimento. O requisito abordado nesse estudo recebeu a identificação REQO
(REQuisito de Observação). Os requisitos, REQM (REQuisito de Material), não serão
tratados nesse estudo, serão referenciados na Tabela 6 na qual breves soluções são propostas.
8.1.1 Requisitos de Observação e de Material
1. [REQM01] Presença de Conceitos básicos (ou dicionário). Alguns usuários preferem
absorver os conceitos necessários para desenvolver o curso antes de realizá-lo, como o
Aluno A que “Clicou no hipertexto UML que o levou ao Dicionário. Verificou o que
havia escrito sobre o tópico e clicou no hiperlink UML que o levou à página oficial da
UML...”. O mesmo usuário requisitou que o dicionário precisa ser bem “detalhado para
ajudar ao aluno”. O Aluno C declarou que precisa “ter uma boa divulgação da presença
do dicionário”.
2. [REQM02] Opção que permita Visão Geral. Alguns usuários preferem ter um overview
de todo o curso para terem idéia de tudo que aprenderão, a exemplo do Aluno A que
analisou, rapidamente, a página inicial. Ao ser questionado do porquê declarou: “Fiquei
curioso por não conhecer o tema”. O Aluno B sempre olhava de forma geral cada tópico
antes de iniciá-lo.
3. [REQM03] Disponibilização de material de curso completa e em partes. Enquanto
alguns usuários preferem ir “baixando” o material à medida que fazem o curso, outros
preferem baixar todo o material de uma única vez. O Aluno A declarou: “Seria muito
melhor uma opção para baixar todo o material. Pouparia muito tempo. Mas a opção de
baixar partes do material deve ser mantida”. O material a ser “baixado” também precisa
vir pronto para o aluno utilizar. Assim declarou o Aluno A: “O banco de dados já criado e
os programas fontes já digitados e prontos só para baixar também ajudaram bastante”.
47
Mas há também usuários, como o Aluno B, que declararam: “Na realidade, prefiro eu
mesmo digitar à medida que vou fazendo o curso. Aprendo mais assim”. O Aluno B
resolveu baixar todo o material, mesmo com vários cliques, e executar tudo previamente e
declarou: “Resolvo fazer assim para ter a certeza de que vou investir tempo em algo que
vai de fato funcionar. Não gosto de perder tempo estudando algo que não funciona
depois. Era melhor até que houvesse uma forma de baixar só os executáveis (os .class
nesse caso). Por que aí nem preciso compilar fontes, só executar e ver se está tudo
funcionando”. O aluno C declarou também: “Seria muito bom ter, também, a opção para
baixar tudo”.
4. [REQM04] Organização do curso. Alguns usuários seguiram à risca as orientações do
curso, de forma que só criarão alguma pasta se o curso assim pedir. Assim declarou o
Aluno A: “Se tivesse essa orientação no curso, criaria uma pasta imediatamente”. Como
o curso não deixava isso claro, o mesmo Aluno A declarou: “Tenho o costume de baixar
na Área de Trabalho e organizar depois”. E foi isso que fez. O Aluno C declarou, ao ser
questionado sobre a não criação de uma pasta: “O curso não pediu...”.
5. [REQM05] Coerência. O texto do curso e o material disponível para ser “baixado” pelo
aluno precisam ser idênticos, senão gera desconforto e dúvida. Dois alunos observam isso,
como fez o Aluno A: “Em seguida clicou sobre o arquivo ‘baixado’ que acionou o
Microsoft Access. Conferiu o interior do banco de dados, vazio a princípio, e verificou
que a estrutura é a mesma que a apresentada no curso”. O Aluno C também sentiu
dificuldades porque, ao executar o exemplo, detectou que nenhum registro foi mostrado.
Tentou novamente e obteve a mesma resposta negativa. O texto explicativo mostra uma
tela com registros, porém o banco de dados fornecido estava vazio.
6. [REQM06] Presença de pré-requisitos. O curso precisa ser bastante claro quanto ao
nível de conhecimento necessário para o aluno. O Aluno A declarou: “Nunca usei o
Microsoft Access”. Precisa-se, previamente, informar ao aluno quais ferramentas serão
necessárias e qual o nível de conhecimento em cada uma delas. Tal nível de conhecimento
deve ser mais claro do que termos: “básico”, “médio” ou “avançado”. Necessita-se de
informações do tipo: O aluno deve conhecer para a “ferramenta X” os recursos de abrir
novo documento, salvar, formatar etc. Essa situação fica clara na declaração do Aluno B:
“Senti dificuldades com o java porque não continuei estudando e praticando após a
48
disciplina de Programação Orientada a Objeto. Por isso me compliquei um pouco com
controle de exceção e a criação da GUI”. O Aluno A declarou também: “A lista de pré-
requisitos me ajudou a ter uma idéia do que deveria já saber”.
7. [REQM07] Informações sobre ambiente no qual o curso foi criado. Informar em qual
máquina e sistema operacional o curso foi criado também é importante, bem como as
variações que o aluno pode encontrar ao usar outros sistemas operacionais. O Aluno A, ao
realizar o tópico “3. Registrando o Banco de Dados”, não conseguiu registrar o banco de
dados no curso proposto. Abriu o Painel de Controle, voltou ao curso para ver mais
instruções e voltou para o painel de controle. Executou essa operação várias vezes,
ficando completamente perdido. Ele não encontrou a opção Fontes de dados (ODBC) que
o curso orientava estar no Painel de Controle porque, no Windows XP, essa opção fica
numa sub-opção chamada Ferramentas de Sistema. O curso não mencionava esse detalhe
no texto explicativo. O Aluno C declarou: “Deveria haver informações no curso para
Sistemas Operacionais diferentes”. O Aluno B também não conseguiu cumprir esse item.
8. [REQM08] Presença de telas. Alguns usuários preferem seguir telas a seguir textos
explicativos. O aluno A realizou os passos do curso orientando-se mais pelas telas do que
pelos textos explicativos.
9. [REQM09] Telas com resultados. Alguns usuários, como o Aluno A, preferem “...
estudar todo o material e depois baixar os exemplos”. É necessário, portanto, que telas de
resultados das tarefas do curso sejam disponibilizadas para que o aluno possa comparar
resultados corretos com os que ele irá obter.
10. [REQM10] Granularidade. O curso precisa ser dividido em partes pequenas para formar
o seu todo. Tópicos muito extensos não são apreciados pelo aluno. Como declarou o
Aluno B: “Achei também o tópico ‘Lendo, Inserindo e atualizando Dados’ muito grande.
Devia ser reorganizado em tópicos menores”.
11. [REQO01] Presença de opções para tirar dúvida. Quando não conseguiu realizar a
tarefa do item 7 [REQM07], o Aluno A ao ser questionado sobre o que deu vontade de
fazer diante da situação de dúvida, respondeu: “Não gostaria de resolver isso por e-mail
porque a resposta pode demorar muito. Prefiro um meio online que possa me dar uma
resposta mais instantânea”. Foi perguntado ao Aluno A se, em uma aula tradicional,
49
levantaria a mão, respondeu afirmativamente e com muita expressão. Na mesma situação
o aluno B declarou: “Num curso tradicional levantaria a mão imediatamente”. Ao sentir
dúvida, mais adiante no processo de estudo e ao ser questionado, o Aluno A declarou “...
É difícil tirar dúvidas e continuo sentindo a necessidade de alguém online para socorrer”,
“Esse formato de curso precisa de um professor online”. O Aluno C declarou “Senti a
necessidade de um professor num bate papo instantâneo”. O aluno tinha a informação
disponível, mas sentiu necessidade da instrução.
Meios para tirar dúvidas requisitados:
E-mail;
Bate papo online;
Professor presencial.
A Árvore de Atividades demonstrou ser muito útil para acompanhamento do curso, mostrando
sempre onde o aluno se encontrava. Esse recurso já faz parte do modelo SCORM. A árvore
poderá servir também como indicador de progresso para marcar onde o aluno ficou para
quando quiser interromper o curso e retornar depois. No momento da observação do Aluno A,
a conexão caiu por cinco minutos. O aluno ficou um pouco impaciente. Ao voltar a conexão,
o aluno se perdeu e demorou um pouco para encontrar onde havia parado. Precisa-se ter
também uma opção para exibir e ocultar a Árvore de Atividades quando o usuário precisar.
Dessa forma o aluno ganhará mais espaço para fazer o curso. O Aluno B arrastou as barras
verticais, diminuindo a área com a Árvore de Atividades e ganhando espaço na área de
visualização do curso.
Outras declarações:
Aluno A - “O fato de fazer o curso dessa maneira, em vez de usar um livro, é melhor
porque já encontro tudo num único lugar”. “Apesar de achar o assunto complicado
aprendi muito”. “Estava com receio de não conseguir”.
Aluno B - “Como deu tudo certo, fiquei muito satisfeito com isso”.
50
Aluno C – “Aprendi o suficiente para realizar o mesmo processo com outra base em
um outro estudo de caso. Depende agora só da modelagem e de novos comandos SQL.
Apesar do assunto, e código fonte, serem complicados entendi a conexão. Estou muito
satisfeito”.
A Tabela 6 sugere soluções para os REQM (REQuisito de Material). Esses requisitos estão
em conformidade com a quarta característica básica de um LMS levantada no tópico 3.2
SISTEMAS DE GESTÃO DE CONTEÚDO, no tocante a organização dessas informações de
forma que o aluno encontre facilmente o que precisa.
Tabela 6. Sugestões para tratamento de Requisitos de Material (REQM).
Requisito Solução proposta
REQM01 O professor pode fazer um dicionário a
partir de objetos de aprendizagem com
termos e sua devida explicação, de forma
que possam ser reutilizados
REQM02 A Árvore de Atividades pode auxiliar nesse
ponto, porque mostra os tópicos do curso.
Pode-se implementar uma opção para
expandir todos os objetos de aprendizagem
(nós) da árvore e recolhê-los.
REQM03 Ao criar o curso, o professor pode colocar
links disponibilizando o material a ser
“baixado” no decorrer do curso. Um link
geral, no começo e/ou final do curso, pode
ser disponibilizado para baixar tudo de uma
única vez. Esses materiais podem ser objetos
de aprendizagem reutilizáveis.
REQM04 O professor deve evitar suprimir pequenos
passos que julgue que o aluno conheça. Pode
também listar passos gerais, para usuários
51
experientes e, para cada passo geral, mostrar
sub-passos necessários para que alunos
iniciantes possam completar a atividade.
Esses passos gerais podem ser passos gerais,
objetos de aprendizagem maiores, contendo
sub-passos, objetos de aprendizagem
menores.
REQM05 O professor deve ter o cuidado de
disponibilizar o material para download,
contendo o mesmo conteúdo exposto no
curso.
REQM06 Disponibilizar de forma clara e detalhada os
requisitos necessários para a realização do
curso. Esses requisitos podem ser objetos de
aprendizagem reutilizáveis.
REQM07 O professor precisa deixar claro qual
ambiente utilizou na criação do curso. Uma
lista de ambientes e ferramentas pode ser
criada em forma de objetos de
aprendizagem, para que seja recombinada e
reutilizada. Sempre que possível,
orientações diferentes podem acompanhar o
material, orientando o aluno, caso ele use
um ambiente ou ferramenta equivalente ao
utilizado no curso.
REQM08 O professor pode colocar telas e textos
explicativos. Podem ser objetos de
aprendizagem diferentes e combinados para
formar a explicação. Pode-se oferecer ao
aluno opção de ter ambos, telas e textos, ou
52
apenas um ou outro.
REQM09 Além do REQM08 (telas explicativas) esse
requisito pode ser atendido, colocando telas
mostrando resultados finais de atividades.
Assim, o aluno pode ver como ficará o
ambiente/ferramenta após a execução dos
passos, recurso muito útil quando não se tem
a ferramenta instalada para se observar
resultados. Essas telas também podem ser
objetos de aprendizagem contendo estados
finais de processos, que também podem ser
reutilizados.
REQM10 Os objetos de aprendizagem atendem
perfeitamente a esse requisito. O curso é
montado com pequenos objetos que,
reunidos, formam objetos maiores. Os
objetos, grandes e pequenos, podem ser
reutilizados.
Nota-se que a necessidade do requisito geral REQG03, presença de meio para retirar
dúvida, foi confirmado pelo requisito de observação REQO01.
8.2 Cenários Parte 1
8.2.1 Gestão de Conteúdo – Situação Atual
Serão aqui criados dois cenários cujo objetivo é descrever a situação atual, ou seja, usuários
(professor e aluno) utilizando LMS sem que os requisitos levantados nessa pesquisa, como
reuso de objetos de aprendizagem e recurso para tirar dúvidas, estejam presentes nesses
ambientes.
53
8.2.1.1 Cenário 1.1 - Criação de curso por parte do professor
Este cenário descreve uma situação na qual um professor utiliza um ambiente sem o requisito
REQG01 (reutilização de conteúdo).
Ator: Professor, cujo objetivo é criar um novo curso.
Ambiente: Ambiente Virtual de Ensino com suporte ao modelo SCORM. Há um computador
conectado à Internet executando um Ambiente Virtual de Ensino utilizado para intermediar o
processo de ensino à distância. O professor está devidamente cadastrado no ambiente.
Roteiro: O professor deseja criar um novo curso no ambiente. Verifica que partes do novo
curso já existem em outros cursos, no mesmo ambiente, de sua propriedade ou de propriedade
de outros professores. Para realizar essa montagem, precisa de um editor de cursos SCORM,
como o Reload e, também, dos arquivos originais de cada curso. Com esse conteúdo, ele
poderia remontar o curso no editor, criar um novo pacote e importar no ambiente. Porém o
professor não dispõe dos originais dos cursos dos outros professores. Resolve, então, refazer
todo o curso, aproveitando os seus arquivos originais e criando o conteúdo que já existia no
curso de outros professores. Não houve como reutilizar nem o seu próprio material de forma
fácil e produtiva.
8.2.1.2 Cenário 1.2 - Realização de um curso por parte do aluno
Este cenário descreve uma situação na qual um aluno utiliza um ambiente sem os requisitos
REQG03 e REQG04 (recursos para tirar dúvida).
Ator: Professor e Aluno.
Ambiente: Ambiente Virtual de Ensino. Há um computador conectado à Internet executando
um Ambiente Virtual de Ensino. Esse ambiente é utilizado para intermediar o processo de
ensino à distância. O professor e o aluno estão devidamente cadastrados no ambiente.
Roteiro: Aluno escolhe um curso, modelo SCORM, que deseja realizar. Na tela principal,
apresenta a Árvore de Atividades, à esquerda, e a tela de conteúdo, à direita. À medida que
clica nos itens da árvore, o conteúdo vai sendo apresentado. Em um determinado tópico, não
consegue entender o conteúdo. O ambiente não oferece opção para tirar dúvida. Procura um e-
mail para pedir ajuda e não encontra no ambiente. Consegue o endereço para contatos em suas
54
anotações pessoais e envia um e-mail explicando a dúvida e em qual tópico ela está. Aguarda
ansioso pela resposta. Resolve dar uma pausa no curso enquanto não remover essa dúvida.
Professor recebe e-mail de dúvida de aluno e acessa o ambiente. Não consegue descobrir com
rapidez de qual curso e de qual item específico é aquela dúvida. Precisa vasculhar o material
para descobrir isso. Quando encontra, recorre a ferramenta de e-mail para responder a dúvida
do aluno. O ambiente não registra nada disso e, futuramente, a mesma dúvida pode se repetir
para outro ou até para o mesmo aluno. Professor não tem, no ambiente, um histórico de
dúvidas de alunos, o que dificulta a avaliação do rendimento e interesse deles.
Resultado destes Cenários
O ambiente deve prover facilidade para que o usuário, ainda que novato, use os recursos do
sistema. Tanto professores devem sentir conforto no processo de reuso de objetos de
aprendizagem, quando alunos devem sentir facilidade para registrar suas dúvidas e obter suas
respostas. A interface deve permitir que os usuários visualizem e naveguem pelo
conhecimento.
8.3 Prototipagem de baixa fidelidade
Tarefa para os protótipos 1, 2 e 3: Ciclo de Registro de Dúvida.
Ator: Aluno e professor do curso
Objetivo: Realizar um curso e registrar uma dúvida para o professor
Descrição: O aluno clica no item da Árvore de Atividades com o botão auxiliar do mouse.
Aciona o menu de contexto e registra a dúvida. Quando a dúvida é respondida pelo professor,
o aluno aciona o menu de contexto e registra a ciência da resposta. Seu percurso vai sendo
registrado sem que esse perceba.
Sub-tarefas:
Registro de Percurso pelo sistema;
Registro de Dúvida pelo Aluno;
55
Registro de Resposta da Dúvida pelo Professor;
Registro de Ciência da Dúvida pelo Aluno.
Sucesso da tarefa: Exibição da mensagem “Dúvida Registrada com Sucesso”.
Falha: Quando o campo obrigatório do texto da dúvida deixa de ser preenchido, exibe-se a
mensagem “Campo dúvida não preenchido”.
Esses protótipos visam atender aos requisitos: REQG02, REQG03 e REQG04.
8.3.1 Protótipo de Baixa Fidelidade 1 – Geração de dúvidas
O protótipo 1 foi criado montando telas sobre as próprias telas do ambiente ADL SCORM.
As telas montadas foram impressas para avaliação dos usuários. Visa a descrever os passos
necessários para o registro de dúvida por parte do aluno [REQG03]. As Figura 16 e 17
mostram os protótipos criados.
Figura 16. Protótipo de baixa fidelidade 1: Registrando Dúvida.
Figura 17. Protótipo de baixa fidelidade 1: Dúvida Enviada.
56
8.3.2 Protótipo de baixa fidelidade 2 – Geração de dúvida
Após observações do usuário ao primeiro protótipo, criou-se o protótipo 2, inteiramente
funcional, ou seja, não há apenas telas estáticas, mas um completo acesso ao banco de dados
SCORM em processos de leitura e gravação.
Como os códigos fonte necessários para criar um protótipo funcional não estavam 100%
disponíveis para alteração no modelo SCORM adquirido, esse protótipo foi implementado
com componentes Java:
JApplet para permitir execução via browser;
JTree que mostra o curso em forma de Árvore de Atividades;
JEditorPane que mostra o conteúdo do curso em formato HTML.
Em destaque (português e negrito) no Diagrama 2, as alterações necessárias na base SCORM
para implementação desse protótipo.
57
Diagrama 2. Alterações no Diagrama de Classe do modelo SCORM.
Esta classe/label auxilia na exibição dos ícones de identificação “!” e “?” na árvore de
atividades.
/* Copyright (c) 2003 Sun Microsystems, Inc. All Rights Reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions
are met:
-Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
-Redistribution in binary form must reproduct the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the distribution.
Neither the name of Sun Microsystems, Inc. or the names of contributors
may be used to endorse or promote products derived from this software
without specific prior written permission.
This software is provided "AS IS," without a warranty of any kind. ALL
EXPRESS OR IMPLIED CONDITIONS, REPRESENTATIONS AND WARRANTIES, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE OR NON-INFRINGEMENT, ARE HEREBY EXCLUDED. SUN AND ITS LICENSORS SHALL NOT
BE LIABLE FOR ANY DAMAGES OR LIABILITIES SUFFERED BY LICENSEE AS A RESULT OF OR RELATING TO USE, MODIFICATION OR DISTRIBUTION OF THE SOFTWARE OR ITS DERIVATIVES. IN NO EVENT WILL SUN OR ITS LICENSORS BE LIABLE FOR ANY LOST REVENUE, PROFIT OR DATA, OR FOR DIRECT,
126
INDIRECT, SPECIAL, CONSEQUENTIAL, INCIDENTAL OR PUNITIVE DAMAGES, HOWEVER CAUSED AND REGARDLESS OF THE THEORY
OF LIABILITY, ARISING OUT OF THE USE OF OR INABILITY TO USE SOFTWARE, EVEN IF SUN HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
You acknowledge that Software is not designed, licensed or intended for
use in the design, construction, operation or maintenance of any nuclear
"Duvida.DateTimeCiente FROM Duvida where UserId = '" + this.userId + "' AND " + "CourseID = '" + this.nomeCurso + "' AND " +"ItemIdentifier = '" + ItemIdentifier + "' AND DateTimeCiente Is null and DateTimeDuvida Is not null");
String data, data2;
try
{if (this.resultSet != null)
{boolean moreRecords = this.resultSet.next();
if (moreRecords ) {
data=this.resultSet.getString(1);
if (data != null)
{data2 = this.resultSet.getString(2);
if (data2 != null)
{this.duvidaRespondida = true;}
else
{this.duvida = true;}
} }// if
}}
catch (SQLException se)
{}
if (this.duvida)
{setIcon(duvidaIcon);}
else
{ if (this.duvidaRespondida)
{setIcon(duvidaRespondidaIcon);}
else
{setIcon(null);}}
this.selected = selected;
return this; }
public void paint(Graphics g) {
Color bColor;129
Icon currentI = getIcon();
if(selected)
bColor = SelectedBackgroundColor;
else if(getParent() != null)
bColor = getParent().getBackground();
else
bColor = getBackground();
g.setColor(bColor);
if(currentI != null && getText() != null) {
int offset = (currentI.getIconWidth() + getIconTextGap());