Do SCORM ao Experience API (a.k.a. Tin Can API)

Entenda o que são e onde podem nos levar esses padrões da Educação a Distância.

Entenda o que são e onde podem nos levar esses padrões da Educação a Distância.

Se você é desenhista instrucional ou envolvido com educação a distância já deve ter ouvido falar em SCORM. E como a maioria, pode não compreender bem do que se trata. Pode parecer estranho estarmos falando em SCORM quando já existe um padrão mais recente, o Experience API (xAPI), que pretende substituí-lo. Ocorre que provavelmente ainda iremos conviver por muito tempo com o SCORM e o xAPI (também conhecido como Tin Can API). Então acredito que valha a pena entendermos o contexto e tentarmos projetar o que venha a ser o novo paradigma em EaD.

Apesar dos chamados TBC´s (treinamentos baseados em computador) evoluírem bastante, apresentando recursos multimídia sofisticados, seu desenvolvimento e uso através de programas proprietários, com conteúdo e mecanismos de navegação intimamente acoplados a esses programas, impedia ou dificultava a reutilização de conteúdo.

Um objeto de aprendizagem (OA) feito para um ambiente virtual de aprendizagem (AVA) - aqui usamos AVA como sinônimo de LMS (Learning Managed System, em português, Sistema de Gestão de Aprendizagem) - feito por uma empresa não era aproveitável por um AVA de outra instituição, o que forçava cada núcleo de aprendizagem a desenvolver independentemente os mesmos conteúdos instrucionais.

A importância dos padrões de indústria.
O custo de se integrar um novo produto em um contexto é
significativamente menor se esse produto segue padrões estabelecidos.
Esse panorama levou várias entidades a criarem especificações para diferentes áreas da tecnologia dos Objetos de Aprendizagem. Entre outras entidades, podemos citar:

• [accordion]
• ARIADNE 
• (Alliance of Remote Instructional Authoring & Distribution Networks for Europe) - Grupo que trabalha no desenvolvimento de ferramentas e metodologias para a produção, gestão, e reutilização de elementos pedagógicos suportados por computador. Apresenta relevantes contributos na área dos metadados;
• DCMI
• (Dublin Core Metadata Initiative) - Dedica-se à pesquisa e promoção de normas para metadados, desenvolvendo vocabulários especializados que facilitem a busca de objetos de aprendizagem por sistemas automáticos;
• AICC
• (Aviation Industry Computer-Based Training Committee) - Composta por diversas entidades de profissionais de formação que desenvolvem pesquisa na área da formação suportada pela tecnologia, para a indústria da aviação. Tem um importante papel no desenvolvimento de especificações para a interoperabilidade de conteúdos de formação;
• IMS
• IMS Global Learning Consortium (Instructional Management System) - Consórcio entre entidades várias nas áreas da educação, comércio e administração central que pesquisa na área da interoperabilidade para o e--Learning, procurando desenvolver e disponibilizar especificações que facilitem a distribuição online de atividades educativas (localização e uso de conteúdos de formação), registo de caminhos de aprendizagem, desempenhos e troca de registros entre diferentes sistemas de gestão de aprendizagem.

O governo dos EUA, através do seu Departamento de Defesa (DoD), uniu-se à indústria de tecnologia para iniciar o movimento pela adoção de um padrão único para os sistemas de educação a distância. O DoD, juntamente com Gabinete para a Política da Ciência e Tecnologia da Casa Branca (OSTP - White House Office of Science and Technology Policy) criou a ADL Initiative - Advanced Distributed Learning.

A ADL definiu como missão fornecer acesso à mais alta qualidade na educação e treino, desenhada para as necessidades individuais, distribuída de forma econômica em qualquer momento e para qualquer lugar, como resposta às necessidades de educação do governo, da indústria e da academia. Procura assim estimular o desenvolvimento de ferramentas; de sistemas de gestão de aprendizagem; e o mercado para este tipo de produtos. É neste contexto que surge o SCORM – Sharable Content Object Reference Model, como modelo de referência.

Apagar as luzes

Clique     Retroceder    Avançar   Espaço /    /   F

SCORM Demystified
Desde então, as especificações e padrões do SCORM visam a interoperabilidade, acessibilidade e reusabilidade de conteúdo de aprendizado.

 

Universidade de Coimbra

Histórico da Especificação SCORM

• [accordion]
• SCORM 1.0
• A primeira versão do SCORM, lançada no ano 2000, apoiou-se nas especificações da AICC CMI001 (Computer-Managed Instruction) que definia as bases de comunicação entre os AVAs e os conteúdos. Todavia, apesar dos esforços da ADL, quem já tentou migrar de plataforma sabe que as coisas não são tão simples como se apregoa. O SCORM 1.0 não continha uma especificação totalmente implementável, mas trazia uma pré-visualização do trabalho que viria. Ele continha os principais elementos que se tornariam a base de SCORM. Em particular, é especificado como o conteúdo deve ser empacotado (pacotes de conteúdo), como o conteúdo deve se comunicar com um AVA (tempo de execução) e como o conteúdo deve ser descrito (metadados). Cada uma dessas áreas foi descrita em uma especificação em separado denominada "livro". Por não haver implementações significantes, o SCORM 1.0 é considerado irrelevante atualmente. Servindo apenas para registro histórico.
• SCORM 1.1
• Publicado em janeiro 2001, a SCORM 1.1 foi a primeira versão real e implementável de SCORM. A ADL sentiu a necessidade de rever diversos aspectos do seu modelo, retirando algumas funcionalidades, suportadas pelo AICC CMI mas muito pouco usadas, e alterando a abordagem a outras. Foi entregue como uma especificação implementável e fornecedores comerciais começaram a adotá-lo. Estas adoções iniciais revelaram que a ideia do SCORM era válida, mas que ainda havia muitos detalhes a serem trabalhados para se tornar uma implementação suficientemente robusta para ser generalizada.
  Obs.: Há ainda um legado das implementações SCORM 1.1. Se você estiver projetando um OA para o mais ampla e absoluta compatibilidade possível, o SCORM 1.1 vale a pena ser considerado.
• SCORM 1.2
• Lançado em outubro 2001, o SCORM 1.2 foi o apogeu da padronização. O SCORM 1.2 incorporou todas as lições aprendidas com a adoção precoce do SCORM 1.1 e entregou uma especificação robusta e implementável. A ADL adota a especificação IMS CP (Content Package) que representa um salto técnico muito importante para a distribuição dos conteúdos. Utilizando o XML, a IMS CP define uma estrutura de empacotamento dos conteúdos muito flexível, passível de fáceis extensões com a adição de novas funcionalidades, sem perda de compatibilidade com versões anteriores. Fornecedores que adotaram o SCORM 1.2 perceberam uma redução de custos dramática em função da maior interoperabilidade do conteúdo.
  Obs.: O SCORM 1.2 foi amplamente adotado e é ainda o carro-chefe da indústria. Todos os fornecedores de e-learning devem tornar seus produtos compatíveis com o SCORM 1.2 pois ele deve persistir ainda por um longo tempo.
• SCORM 2004 "1ª edição"
• Em janeiro 2004 surgiu a primeira das quatro edições do SCORM 2004. O SCORM 1.2 foi muito bom, mas ainda tinha algumas ambigüidades que precisam ser reforçadas. Também faltou ao SCORM 1.2 um seqüenciamento e especificação de navegação que permitisse que o fornecedor de conteúdo especificasse como era permitida ao aluno sua progressão entre SCOs. A falta de uma especificação de seqüenciamento significou que a maioria do conteúdo no SCORM 1.2 fosse produzido como um SCO único e monolítico em vez de criados com granularidade, com vários SCOs reutilizáveis. O SCORM 2004 abordava esses dois problemas. Agora seria possível a um autor de conteúdo, por exemplo, poder dizer que "um aluno não pode fazer um teste final, até que tenha completado todo o material didático".
  Obs.: A especificação de seqüenciamento na primeira versão do SCORM 2004 teve alguns problemas fundamentais e não era totalmente implementável.
• SCORM 2004 2ª Edição
• Em julho 2004, era publicado o SCORM 2004 2ª Edição. Com a adoção do SCORM 2004, rapidamente se percebeu que havia alguns defeitos que teriam que ser resolvidos. A ADL respondeu rapidamente, emitindo o SCORM 2004 2ª Edição. Esta especificação foi aprovada e as implementações começaram a aparecer. Obs.: O SCORM 2004 2ª edição tem uma adoção significativa, mas ainda não chega nem perto do SCORM 1.2. Apesar dos livros do SCORM serem muito estáveis ​​em todos os SCORM 2004, o sequenciamento é uma especificação muito complicada. Fornecedores criando implementações de novos produtos devem se esforçar para incluir suporte para SCORM 2004.
• SCORM 2004 3ª Edição
• Em outubro de 2006 é lançado o SCORM 2004 3ª edição. Essa evolução foi impulsionada devido às complicações do sequenciamento e especificação de navegação. A terceira edição é em grande parte um conjunto de melhorias para a especificação de sequenciamento para remover ambiguidades e obter uma maior interoperabilidade. A grande mudança na terceira edição foi a inclusão de requisitos de interface de usuário para AVAs. Anteriormente, era o AVA que determinava a interface de usuário apropriada. Na terceira edição, uma nova linguagem foi adicionada que requer que o AVA forneça certos elementos da interface do usuário para permitir o seqüenciamento e navegação para funcionar de forma consistente em todos os sistemas. Obs.: O SCORM 2004 3ª Edição, como a 2 ª Edição, tem uma adoção significativa e fornecedores devem se esforçar para apoiá-lo. De todos as edições do SCORM 2004, a edição 3 é a mais amplamente utilizada.
• SCORM 2004 4ª Edição
• Em março de 2009 foi ao ar a 4ª edição do SCORM 2004. Esta edição contém ainda menos ambiguidades da especificação do seqüenciamento e também adiciona alguns novos recursos para a especificação de sequenciamento, que irá ampliar as opções disponíveis para os autores de conteúdo. Os novos recursos em Quarta Edição tornam a criação de conteúdos sequenciados muito mais simples. Obs.: Os novos recursos do SCORM 2004 4ª edição aumentam drasticamente a sua utilidade. SCORM 2004 4ª Edição devem ser apoiadas por fornecedores que suporte o SCORM 2004.
• Experience API
• Publicado em 26 de abril de 2013, em versão beta, o Experience API (ou xAPI, também conhecido pelo seu nome de projeto: Tin Can API) pode ser considerada a próxima geração do SCORM. É uma especificação patrocinada pela ADL e que abandona a estrutura do SCORM, baseada em web, e abraça qualquer experiência de aprendizagem, online e offline, fornecendo dados sobre ela, possibilitando uma gama muito maior de formas de relatórios. Sua primeira versão, 1.0,  está em construção.

10 anos após o lançamento do SCORM 2004
75% dos pacotes ainda eram da versão 1.2
[eFront]

Alguns conceitos-chave para o SCORM, são:

•  Assets (bens):
  A forma mais básica de conteúdo: mídia, textos, imagens, sons, páginas WEB, testes e outros que possam ser entregues através de um navegador WEB.
•  SCO – Sharable Content Object (Objeto Compartilhável de Conteúdo):
  Um conjunto de um ou mais Assets. Dentre estes Assets deve haver um programa que fará a interface entre o objeto (SCO) e o AVA utilizado. O protocolo utilizado na comunicação objeto – AVA é definido no livro “Ambiente em Tempo de Execução”. Um SCO representa o nível mais baixo de recurso que pode ser monitorado pelo AVA. O SCORM não define o tamanho do objeto. Ele pode ser uma parte de uma lição, uma lição completa ou um curso, porém, para ser reutilizável, é interessante que ele seja pequeno o suficiente e seja independente de um contexto determinado.

O modelo de referência SCORM está dividido no que a ADL chama conceitualmente de livros. A seguir um resumo de cada livro SCORM:

Livros SCORM

• [accordion]
• Visão Geral
• O livro Visão Geral descreve os objetivos e histórico do SCORM.
• Agregação de Conteúdo
• O livro Modelo para Agregação de Conteúdo (CAM – Content Agregation Model) descreve como agregar objetos de aprendizado de modo a tornar possível o intercâmbio dos mesmos com outros sistemas. Os Assets e SCO são descritos através de metadados. O próprio Conteúdo Agregado é descrito por metadados. Um conteúdo agregado pode ser um curso completo, um módulo de um curso, uma lição ou simplesmente um conjunto de objetos de aprendizado. No processo de agregação pode-se, opcionalmente, descrever a estrutura (sequenciamento e detalhes de navegação) dos componentes. O arquivo XML que descreve um Conteúdo Agregado chama-se “manifesto”.
• Ambiente em tempo de execução
• Um objeto de aprendizado deve interagir com o AVA. As regras desta interação são definidas neste livro. O AVA deve possuir um API (Application Program Interface) que estará pronta a responder a solicitações dos SCOs. Assim, um SCO ao iniciar sua execução, envia uma mensagem de inicialização. No transcorrer de sua execução, o SCO poderá solicitar informações ao AVA como, por exemplo, o nome do estudante e poderá passar informações ao AVA como, por exemplo, a pontuação em um teste, o tempo que o aluno levou para executar uma tarefa. Ao terminar a execução, o SCO deverá enviar uma mensagem de término. Como este diálogo do SCO com o AVA deve transcorrer é objeto deste livro. A obediência ao padrão SCORM garante que um determinado curso possa ser executado em diversos AVAs, de diversos fabricantes, desde que estes sigam o padrão SCORM.
• Sequenciamento e Navegação
• Este livro descreve como um conteúdo que siga o padrão SCORM deve ser sequenciado seja através de escolha do aluno seja pelo próprio sistema. o SCORM também descreve como um AVA deve interpretar as regras de sequenciamento. Este livro foi incluído na versão 1.3 do SCORM.

A documentação do SCORM pode ser encontrada em http://www.adlnet.org.

As diferenças entre SCORM e xAPI (baseado nas limitações do SCORM que o xAPI tenta suplantar):

Limitações SCORM

• [accordion]
• SCORM é dependente de um navegador (browser)
• SCORM depende de um navegador web. Isto significa que é impossível rastrear experiências de aprendizagem ou desempenho no trabalho que acontecem fora de um navegador da web usando SCORM
  Exemplos: um manequim para simular ressucitação, uma simulador de voo, etc.
• SCORM é dependente de uma conexão de Internet
• SCORM é geralmente dependente de uma conexão de Internet constante. Isto significa que é extremamente difícil de controlar aprendizagem desconectado ou experiências de desempenho de trabalhos usando SCORM. Embora haja alguns poucos aplicativos padrão SCORM offline, algum até pode funcionar bem, mas a maioria deles são tipicamente instáveis (o SCORM apenas não se destina a ser usado desta forma).
• Um conteúdo SCORM deve ser usado em um AVA 
• A maioria de nossa aprendizagem certamente deve estar fora do AVA. Assim, a maioria de nossas experiências de aprendizagem mais valiosas não estão sendo rastreadas hoje.
• SCORM só pode rastrear um único aluno 
• Isto significa que é impossível rastrear a aprendizagem baseada em equipes usando SCORM.
• SCORM só pode controlar poucas coisas
• SCORM só pode controlar um número limitado de coisas, ou seja, a conclusão, o tempo gasto em curso, aprovação (passou/falhou), um único resultado geral. Isso significa que não há nenhuma maneira para o SCORM controlar qualquer coisa além de um curso ou da avaliação.

Benefícios da Experience API

• [accordion]
• O xAPI pode acompanhar qualquer experiência, em qualquer lugar
•  Não estamos mais dependentes de um navegador da Web, ligação à Internet constante ou um AVA, a fim de realizar e controlar nossas experiências. Isso abre um mundo de oportunidades para as organizações e instituições que precisam treinar seus povos. Organizações vai agora serão capazes de completar os seus AVAs aprendendo com as experiências de aprendizagem vivenciadas fora do AVA, e usar seus AVAs como o repositório central de todos os seus registros de aprendizagem, se optar por isso. Alguns podem decidir acabar com seus AVA inteiramente e substituí-los por soluções focadas em xAPI.
• O xAPI usa uma estrutura de declaração simples
• O xAPI usa uma estrutura simples de declaração, flexível, mas robusta para rastrear experiências. "Eu fiz isso" (substantivo, verbo, objeto) é o núcleo de todas as declarações de xAPI.
  Exemplos: 'Ana participou Moodle Moot 2016'. "Ana ressuscitou CPR manequim". "Ana fechou um negócio $30,000 SCORM Engine'. Esta estrutura simples nos permite rastrear qualquer experiência em qualquer contexto.
• Os dados que o xAPI rastreia pretendem ser portáteis
• Ao contrário do SCORM, Os dados que o xAPI rastreia pretendem ser portáteis. Demonstrações xAPI são enviadas e armazenadas em um Learning Record Store (LRS), que pode ser integrado com um AVA. O LRS é projetado para armazenar estas declarações, mas também é projetado para distribuir estas declarações para outros sistemas que possuem suporte para a Lata API, ou seja, mais LRS, um AVA, uma ferramenta de comunicação, um sistema de gestão de RH, um Sistema de Gestão de Talentos, etc.
• Organizações também podem usar o xAPI para controlar o suporte ao desempenho
• Como o xAPI pode ser usado para rastrear qualquer experiência, em qualquer lugar, as organizações podem também usá-lo para controlar o suporte ao desempenho e o desempenho no trabalho. Esse deve ser o Santo Graal do Big Data. Quando uma organização está acompanhando sua aprendizagem / formação, suporte ao desempenho e desempenho no trabalho usando a mesma linguagem, eles serão capazes de determinar a eficácia de seus programas de treinamento e medir ROI.

O xAPI propõe a abstração da frase “I did this”  (Eu fiz isso – tradução livre) de uma forma simples e flexivel. Podemos encaixar neste contexto aprendizados via Mobile, simuladores, jogos, redes sociais e até atividades do mundo real, todo esse nicho é suportado pelo xAPI.

Qualquer tipo de interação de uma pessoa com outros objetos (ou outras pessoas) é reconhecido pelo xAPI como uma experiência de aprendizado e tudo isso fica registrado no LRS no formato de “Substantivo, Verbo, Objeto”. Para ilustrar:

LRS recebe seus dados de diversas experiências. [tincanapi.com]
Dessa forma, os dados do LRS ficam disponiveis para outros sistemas como os AVA’s, entre outros:

LRS serve de fonte dos dados para vários sistemas. [tincanapi.com]

Um único registro guardado no LRS é chamado de Statement e ele representa exatamente a experiência obtida por aquela interação. Analisando o Statement abaixo podemos separar em “Ana” é o ator praticante da ação, “escreveu” é o verbo e “Post no blog” é a atividade (ou objeto).

[{
   “actor”: “Ana”,
   “verb”: “escreveu”,
   “object”: “Artigo no Bracad”
}]

Nesse Statement Generator você poderá gerar facilmente vários Statements na sua forma mais realista.

[{
        "actor": {
            "mbox": ["mailto:ana@bracad.com.br"],
            "givenName": ["Ana"],
            "familyName": ["Jolie"]
    },
        "verb": "created",
        "object": {
            "id": "http://www.example.com/tincan/activities/ed5fca87",
            "objectType": "Activity",
            "definition": {
                "name": {
                    "pt-BR": "Artigo no Bracad"
                },
                "description": {
                    "pt-BR": "Um hipertexto no blog Brasil Acadêmico na forma de um post."
                }
            }
        }
}]

Um exemplo de funcionamento desses Statements pode ser visto nessa demonstração. Um vídeo do YouTube (incorporado em uma página usando javascript e e o iframe API do YouTube) tem as interações do usuário (como abertura, pausa e retomada)  sendo enviadas para um LRS em tempo real (o que pode ser visualizado nesse Statement Viewer).

Isso mostra o potencial futuro para relatórios do xAPI, uma vez que o SCORM não reporta e rastreia as interações do usuário nesse nível de detalhe (coletando apenas dados do tipo completou/falhou ou uma nota geral da atividade) além de não conseguir importar dados de atividades de fora do AVA.

É importante salientar que existem muitas outras especificações além do SCORM e xAPI (Uma comparação entre SCORM e Common Cartridge pode ser vista aqui, por exemplo) com seu lugar na indústria de EaD e com possibilidade até de tomar o lugar do SCORM. O SCORM é uma tentativa muito boa de padronizar toda a indústria e xAPI tenta ser aberto o suficiente para abarcar todas as formas atuais de experiência de aprendizagem (e com isso, não se tornar dependente de tecnologia). Mas como o SCORM até hoje é uma promessa, só o tempo dirá se o xAPI cumprirá seu propósito.

Alexandre Gomes
Analista de Sistemas e Especialista em EaD

[Visto no Brasil Acadêmico]