Continuando a minha série de entradas sobre a implementação do SCORM em um LMS, esta entrada discute algumas das vantagens e desvantagens do padrão. O texto se resume a apresentar as dificuldades sem entrar em muitos detalhes de implementação. Assim, é mais uma introdução às questões que a implementação envolveu. Em outras entradas eu discutirei pontos específicos dessas implementações.
Vantagens
-
Possibilita a integração de objetos de aprendizado de fontes diversas em um ambiente comum.
Essa é a maior vantagem do SCORM que consiste no aproveitamento de cursos de fontes e formatos diversos dentro de um único LMS. Isso é conseguido através da API geral e um formato de distribuição comuns que o SCORM fornece aos cursos, permitindo que estes registrem e recuperem seus dados de maneira relativamente genérica tornando-os auto-configuráveis e extensíveis.
-
Fornece um modelo de dados comum.
Esse modelo de dados fornece benefícios tanto para os cursos, que podem ser desenvolvidos de maneira independente do LMS a que destinam, e para o LMS, que pode obter dados dos objetos de aprendizado de maneira uniforme.
-
Fornece uma maneira comum de empacotamento de conteúdo.
Isso facilita a distribuição de cursos, já que os dados podem ser empacotados da maneira que for mais conveniente para o seu criador e descritos através de um manifesto que especifica como o mesmo deve ser usado, mas que ainda deixa ampla liberdade para os implementadores.
Desvantagens
-
O padrão é relativamente imaturo.
Embora já esteja em sua segunda revisão (1.2), as mudanças entre essas revisões mostram que o mesmo ainda não atingiu uma forma estável. As mudanças projetadas para as próximas revisões e versões também ressaltam essa instabilidade.
Essa instabilidade implica na possibilidade de mudanças drásticas que invalidem o investimento no mesmo em um determinado período. (Essa situação compara-se, em parte, à implementação do padrão XSL que mudou drasticamente entre os rascunhos iniciais e a versão final.)
Uma área em que a imaturidade do padrão é revelada de maneira mais gritante é na parte de navegação entre os módulos que eventualmente compõem um curso. A versão 1.2 não implementa nenhuma forma de navegação ou tratamento da seqüência de administração de um curso.
-
O padrão é totalmente baseado em um ambiente Web (leia-se navegador).
Essa limitação força uma dependência em certas condições e tecnologias que impedem, de certa forma, a criação de soluções mais sofisticadas. Um exemplo desse problema é a dependência de uma API baseada em JavaScript. Isso impede que o padrão seja usado em locais onde a mesma não possa existir dessa forma a não ser uma integração com um interpretador JavaScript seja desenvolvida.
Além disso, pela própria necessidade de garantir o máximo de compatibilidade entre plataformas, os formatos de arquivos que podem ser usados em um curso ficam restritos ao menor denominador comum (HTML e Flash em geral) e o uso de tecnologias do lado servidor é efetivamente impossível.
-
O padrão coloca um ênfase muito grande no lado cliente dos objetos de aprendizado (pelo próprio modo como foi formulado).
Dois problemas resultam desse fato. O primeiro é a possibilidade de brechas na segurança das aplicações. O segundo é a limitação da integração de recursos do lado servidor já que os objetos de aprendizado devem ser independentes do LMS onde serão usados.
-
O padrão apresenta uma dependência da tecnologia atual que pode desaparecer ou ser substituída nos próximos anos.
Há, inclusive, problemas atuais com a combinação tecnológica usada. A API precisa se comunicar com o servidor e não existe uma maneira comum de fazer isso. Tornar-se necessário então recorrer a múltiplos mecanismos, o que complica e enfraquece a implementação.
-
A segurança da API só pode ser garantida de maneira limitada já que precisa ser acessada pelo navegador e pode ser manipulada externamente por conseqüência.
Embora o padrão possua provisões incipientes para atividades e avaliações que requerem registro, o fato de serem primariamente baseadas no lado cliente levanta uma série que questões e problemas quanto à segurança, transporte dos dados e fraudes.
Essas provisões para avaliações são extremamente limitadas e não há indicação quanto a serem tratadas em versões próximas do padrão. Além disso, a necessidade de usar uma API que é visível pela navegador torna o tráfego das informações existentes em uma avaliação muito vulnerável à manipulação.
Conclusão
Embora aparentemente apresente mais desvantagens do que vantagens, a implementação do padrão SCORM possui amplos benefícios para um LMS. As dificuldades podem ser resolvidas com algumas concessões e embora impliquem em limitações na realização de determinados cursos não tornam o investimento nulo. Só a primeira vantagem acima já mais do que compensa todo o investimento para muitas empresas.
Nas próximas entradas em analisarei alguns aspectos específicos da implementação, explorando a resolução de algumas das dificuldades listadas acima.
