Metodologias de Desenvolvimento para a Construo de Objetos de Aprendizagem

Srgio Vincius de S Lucena, Diogo Bortolini Departamento de Cincia da Computao Universidade do Estado de Santa Catarina (UDESC) Joinville, SC Brasil
{sergioviniciuss,diogo.bortolini}@gmail.com

Resumo. Objetos de Aprendizagem(OAs) so construdos a todo momento por diversas organizaes e, como em todo processo de desenvolvimento de software, o uso de uma metodologia de desenvolvimento se faz cada vez mais necessrio. Considerando o OA como um produto de software, diversas organizaes esto buscando padronizar o desenvolvimento destes artefatos digitais, adotando metodologias j disponibilizadas ou adaptando-as s suas necessidades e recursos. Este artigo apresenta algumas destas metodologias que so aplicadas no desenvolvimento de Objetos de Aprendizagens e realiza uma anlise comparativa para identificar se o mtodo tradicional ou gil. Palavras-chave: metodologias de desenvolvimento, desenvolvimento gil, objetos de aprendizagem. Abstract. Learning Objects (LOs) are built all time by several organizations and, as in every software development process, the use of a development methodology is more and more essential. By considering the LO as a software product, several organizations are looking forward to standardize the development of these digital artifacts, adopting methodology already available or adapting them to their needs and resources. This article presents some of these methodologies which are applied in the development of LOs. Keywords: development methodologies, agile development, learning objects.

1.

Introduo

Com os avanos das tecnologias de informao e comunicao (TICs), o crescimento da Internet e o aumento da facilidade de acesso mesma, o uso do computador para fins educacionais tem crescido bastante e se tornado uma grande alternativa para investimento educacional. O uso de recursos educacionais digitais (OAs) surge como soluo avanada no sentido de facilitar o processo de ensino-aprendizagem. Nesse contexto, o conceito de OA surge, e definido por Willey (2000), como sendo qualquer recurso digital reutilizvel que possa ser usado no auxilio aprendizagem. O desenvolvimento destes recursos, os quais podem ser considerados como produto de software, assim sendo, pode se d com o uso um processo de desenvolvimento para garantir que o mesmo seja composto de uma srie de caractersticas e atenda convenientemente as necessidades de sua demanda. Trabalhando nesse sentido, diversas entidades esto aplicando metodologias da engenharia de software para a confeco destes artefatos. Este artigo apresenta um estudo de caso das metodologias utilizadas por instituies, e est organizado de maneira que a seo 2 traz definies de objetos de aprendizagem e suas caractersticas; a seo 3 aborda exemplos de metodologias tradicionais, geis e alternativas; a seo 4 apresenta casos de metodologias aplicadas na construo de OAs, seguida da seo 5 que faz uma anlise comparativa dessas metodologias apresentando as semelhanas. Para finalizar, so feitas as consideraes finais para este trabalho na seo 6 e so apresentadas as referncias na seo 7.

2.

Objetos de Aprendizagem

Na literatura h diversas definies para Objetos de Aprendizagem. O IEEE(2002) define OA como sendo qualquer recurso digital, ou no, que possa ser usado, reutilizado e referenciado no suporte ao ensino, em diferentes contextos. Como pode-se notar, a definio citada na seo anterior por Wiley se assemelha bastante definio do IEEE, sendo a principal diferena, o fato de Wiley restringir o OA a recursos digitais. Neste sentido, adotou-se esta mesma definio, limitando assim o OA para abord-lo dentro de uma viso informatizada. Os Objetos de Aprendizagem tm sua origem na idia do LEGO, em que possvel trabalhar com blocos e montar uma certa estrutura. A partir das mesmas peas utilizadas para formar esta estrutura, possvel reorden-las de

forma a montar uma nova estrutura, diferente da anterior, trabalhando assim o conceito de reusabilidade, o qual uma caracterstica forte empregada aos OAs. Observando do ponto de vista de suas caractersticas, os OAs tm suas caractersticas subdivididas em duas classificaes: tcnicas e pedaggicas. As caractersticas tcnicas, segundo Ferlin (2009), preocupam-se com as dimenses de padronizao, classificao, armazenamento, recuperao, transmisso e reutilizao dos OAs, por exemplo. O significado de cada uma das caractersticas tcnicas descrito a seguir: Acessibilidade: O OA deve ser disponibilizado na internet de maneira que possa ser acessado facilmente, dentro de um Repositrio ou Ambiente e-learning, por exemplo. Adaptabilidade: diz respeito ao potencial de um objeto de aprendizagem ser adaptvel a qualquer ambiente de ensino. Classificao: Remete catalogao dos objetos de aprendizagem, ajudando-os na identificao, de modo a facilitar o trabalho dos mecanismos de busca. Nesta caracterstica, ressalta-se o uso de padres de metadados. Granularidade: diz respeito forma que um objeto de aprendizagem pode ser agrupado em conjunto maiores de contedos, de maneira que facilite a reusabilidade. Interoperabilidade: diz respeito possibilidade de utilizao do OA em qualquer plataforma envolvida, ou seja, repositrio, sistema operacional e navegador web. Reusabilidade: diz respeito potencialidade de um objeto ser usado em diferentes temticas e para diferentes propsitos na aprendizagem, no exclusivamente para o qual foi planejado inicialmente. a caracterstica tcnica principal.

J no que diz respeito s caractersticas pedaggicas, Menezes et al (2006) pontuam que estas destacam-se por ter a responsabilidade da criao dos OAs, visando facilitar o trabalho dos professores e alunos, consequentemente buscando como meta a construo do conhecimento. Tais caractersticas so as seguintes: Afeto/Desejo: Remete ao envolvimento do estudante no processo de aprendizagem e o fato do mesmo se deixar afetar pela prpria vontade, estimulando o desejo de aprender e explorar o objeto de aprendizagem (RAMOS E SANTOS, 2006). Autonomia: a questo de tornar os estudantes autnomos, fornecendo recursos que permitam ao estudante ter a capacidade de tomar iniciativa, decises. A autonomia d enfase interatividade e ao controle do aprendiz, encorajando-o explorao e o envolvimento (LOISELLE, 2002). Cognio: Remete s demandas colocadas na memria do aprendiz durante a instruo. No caso da instruo baseada na web, o termo cobre tanto o processo mental necessrio para acessar e interpretar as telas, cones e objetos, como o processo dedicado para processar real contedo da instruo (TAROUCO, 2003) Cooperao: Relaciona-se com a caracterstica da interatividade pois, se um objeto de aprendizagem for interativo, ou seja, apresentar simulaes e testes de hipteses, provavelmente ele estar contribuindo para uma aprendizagem cooperativa, nos quais seus usurios, inclui-se o professor, precisaro trocar idias e trabalhar coletivamente sobre o conceito apresentado (RAMOS E SANTOS, 2006). Interatividade: O OA deve promover o envolvimento do estudante com o contedo de alguma forma, podendo ver, ouvir ou mesmo responder a algum evento em resposta a uma interao com o prprio objeto.

Apresentadas as caractersticas que um OA pode ter, faz-se necessrio o uso de uma metodologia para a construo do mesmo, visando garantir que essas caractersticas sejam garantidas no Objeto. importante salientar tambm que as caractersticas que vo compor o objeto podem variar, de acordo com o tipo de objeto que ser criado (animao, pdf, pgina HTML), pois em alguns casos o OA no ser dotado de todas estas caractersticas. O principal estabelecer o foco do mesmo e garantir que ele seja reusvel e tenha carter pedaggico. Assim, a adoo de uma metodologia ir facilitar o processo de construo destes artefatos digitais e, nesse sentido, a seo a seguir introduzir as metodologias existentes na engenharia de software.

3.

Metodologias de Desenvolvimento

A Engenharia de Software, segundo Neto apud Pressman (2004), se divide em camadas as quais tem como principal objetivo a qualidade final do produto gerado, e como maneira de chegar at ela, o aperfeioamento do processo de desenvolvimento. Este se baseia na criao de documentos, artefatos e marcos capazes de representar o contexto do software, levando em considerao recursos, prazos, ferramentas, restries e outros aspectos que envolvem o desenvolvimento de um produto de software. Sommerville, 2007, pontua que uma metodologia de desenvolvimento um conjunto de atividades que leva produo de um produto de software. O autor ressalta ainda que, embora exista uma grande variedade de processos de software diferentes, algumas atividades fundamentais so comuns a todos eles, como especificao do software, projeto e implementao, validao e, por fim, evoluo. As metodologias de desenvolvimento so classificadas por muitos autores em dois grupos: o das tradicionais e o das geis.

3.1 Metodologias Tradicionais

As metodologias tradicionais surgiram em um contexto de desenvolvimento de software extremamente diferente do atual, relacionado apenas com um mainframe e terminais burros (ROYCE, 1970). Seu uso direcionado para projetos de grande porte, com uma equipe grande de desenvolvedores, e possui nfase no processo e controle do progresso do projeto. Nas subsees a seguir seguem alguns exemplos de metodologias que se enquadram nesta definio.

3.1.1 Modelo em Cascata

De acordo com Sommerville (2007), a metodologia em cascata considera as atividades fundamentais do processo, abrangendo especificao, desenvolvimento, validao e evoluo. Ela representa estes tpicos como etapas de processo disjuntas. Devido ao seu encadeamento de uma fase com a outra, este modelo adquiriu a nomenclatura de modelo em cascata ou ciclo de vida de software. As principais etapas deste processo so as seguintes: Anlise de requisitos: Os servios, restries e objetivos do sistema so definidos atravs de consulta aos usurios do sistema. Eles so definidos detalhadamente e servem como uma especificao de sistema. Projeto de sistema de software: O processo de projeto de sistema divide os requisitos em sistemas de hardware ou de software. Ele define uma arquitetura geral do sistema. Esta etapa envolve a identificao e a descrio das abstraes fundamentais do sistema de software e seus relacionamentos Implementao e teste de unidade: Durante esse estgio, o projeto de software realizado como um conjunto de programas ou unidades de programa. O teste unitrio envolve a verificao de que cada unidade atende sua especificao. Integrao e teste de sistema: As unidades individuais de programa ou os programas so integrados e testados como um sistema completo, visando garantir que os requisitos estabelecidos anteriormente foram atendidos. Aps esta etapa, o sistema liberado para o cliente. Operao e manuteno: Normalmente a etapa mais longa. O sistema colocado em operao. A manuteno envolve a correo de erros no detectados nas etapas anteriores deste processo, no aprimoramento da implementao das unidades de sistema e na ampliao dos servios de sistema medida que novos requisitos so identificados.

Figura 1: modelo em cascata. Fonte: SOARES (2004)

3.1.2 Rational Unified Process (RUP)

O RUP definido por Vasco, Vithoft e Estante (2009), como uma metodologia iterativa de desenvolvimento, a qual adaptvel, podendo ser customizada para diversos tipos e tamanhos de produtos e projetos de software. Essa metodologia identifica cada ciclo de desenvolvimento do projeto em quatro fases, cada uma com respectivos marcos de finalizao definidos (denominados milestones). Os milestones indicam o progresso do projeto, e so usados como base para decises para continuar, abortar ou mudar o rumo do projeto. Ainda segundo os autores, as quatro fases do RUP so: 1. Incio: o escopo do desenvolvimento determinado, ocorrendo o levantamento de uma viso do produto final a partir de um caso de uso definido. 2. Elaborao: nessa fase realizado o planejamento de atividades e recursos necessrios, onde so definidas funcionalidades e a arquitetura a ser desenvolvida. 3. Construo: nessa fase ocorre a implementao do software (construo do cdigo). Em projetos grandes, esta fase pode ser segmentada em vrias iteraes, visando diviso em partes menores e mais facilmente gerenciadas. 4. Transio: o produto passado aos usurios. Nesta fase se d o treinamento dos usurios e possveis mantenedores, alm d avaliao do produto (beta-testing).

Figura 2: Fases do RUP. Fonte: VASCO, VITHOFT e ESTANTE (2009)

1.

2. 3. 4. 5. 6.

De acordo com Sommerville (2007), so recomendadas seis melhores prticas fundamentais nessa metodologia: Desenvolver o Software iterativamente: planejar os incrementos do software com base nas prioridades do cliente e desenvolver e entregar antes as caractersticas de sistema de maior prioridade no processo de desenvolvimento; Gerenciar requisitos: documentar explicitamente os requisitos do cliente e manter acompanhamento das mudanas desses requisitos. Analisar o impacto destas sobre o sistema antes de aceit-las; Usar arquiteturas baseadas em componentes: estruturar a arquitetura de um sistema com componentes; Modelar o software visualmente: usar modelos grficos de UML para apresentar as vises tanto esttica quanto dinmica do software; Verificar a qualidade do software: garantir que o software atenda aos padres de qualidade da organizao; Controlar as mudanas do software: utilizar um sistema de gerenciamento de mudanas, alm de procedimentos e ferramentas de gerenciamento de configurao.

O autor ainda explica as nove disciplinas do RUP da seguinte forma: 1. Modelagem de negcios: uso de casos de uso de negcios para modelar os processos de negcios; 2. Requisitos: identificao dos agentes que interagem com o sistema, e os casos de uso so desenvolvidos para modelar os requisitos de sistema; 3. Anlise e Projeto: aqui criado e documentado um modelo de projeto, utilizando-se de modelos de arquitetura, modelos de componente, modelos de objeto e modelos de sequncia;

4. Implementao: os componentes de sistema so implementados e estruturados em subsistemas de implementao; 5. Teste: um processo iterativo o qual realizado em conjunto com a implementao. Ele segue o trmino desta; 6. Implantao: uma verso criada, distribuda aos usurios e instalada; 7. Gerenciamento de configurao e mudanas: uma disciplina de apoio para gerenciar as mudanas do sistema; 8. Gerenciamento de projetos: outra disciplina de apoio, para gerenciar o desenvolvimento do sistema; 9. Ambiente: essa disciplina est vinculada com a disponibilizao de ferramentas apropriadas de software para a equipe de desenvolvimento.

3.2 Metodologias geis

As metodologias geis so tidas como alternativa aos mtodos tradicionais. Elas so um esforo na tentativa de desviar o foco do processo em si, buscando destaque na contribuio dos integrantes do projeto. Para tanto, criou-se uma Aliana gil, onde foi estabelecido o Manifesto gil (Agile Manifesto, 2004), cujos conceitos chave so: Indivduos ou interaes, ao invs de processos e ferramentas; Software executvel ao invs de documentao; Colaborao do cliente ao invs de negociao de contratos; Respostas rpidas a mudanas, ao invs de seguir planos. Segundo Sommerville (2007), os mtodos geis permitem que a equipe de desenvolvimento se concentre no software somente, em vez do seu projeto e documentao. O autor aponta ainda que estes mtodos contam com uma abordagem iterativa para especificao, desenvolvimento e entrega de software, e afirma tambm que eles foram criados com foco em apoiar aplicaes de negcios nas quais os requisitos de sistema mudam rapidamente durante o processo de desenvolvimento. Eles destinam-se a entregar um software rapidamente aos clientes, que podem ento propor novos requisitos e mudanas a serem includas nas iteraes posteriores do sistema. Isso pode ser bastante interessante na questo do desenvolvimento de OAs, pensando num feedback do usurio para verificar se os objetos esto favorecendo a aprendizagem. A seguir esto exemplos de metodologias geis.

3.2.1 Extreme Programming (XP)

Segundo Souza apud Beck (2004), o XP um mtodo gil voltado para equipes pequenas e mdias que desenvolvem softwares que se baseiam em requisitos vagos e que se modificam rapidamente. uma abordagem deliberada e disciplinada, voltada para o desenvolvimento de software. De acordo com Neto (2004), essa metodologia se enquadra nas metodologias geis caracterizando-se desde o foco principal na satisfao do cliente at resumir que as mudanas nos requisitos sempre vo ocorrer, levando isso em considerao. Vasco, Vithoft e Estante (2009) ressaltam ainda que as iteraes do XP costumam ser curtas, provendo constantes verses do produto ao cliente, o qual tece comentrios promovendo assim um feedback que serve para realimentar novas iteraes. Eles afirmam ainda que o objetivo do XP tornar o projeto flexvel, reduzindo o custo a possveis mudanas. Sendo assim, eles detalham as fases desta metodologia, separando-as em 6 fases: 1. Explorao: o cliente escreve cartes de estrias, cada um com uma funcionalidade desejada para a primeira verso (release). 2. Planejamento: nessa etapa so definidas as prioridades entre as estrias, junto com o cliente. Os programadores fazem a estimativa de esforo e cronograma para cada uma das estrias. 3. Iteraes para Release: nessa fase ocorrem vrias iteraes at a primeira verso ser completada. Na primeira iterao criado o sistema com toda a arquitetura, e nas iteraes seguintes sero adicionadas as funcionalidades de acordo com as prioridades estabelecidas anteriormente. 4. Validao para produo: aqui so realizados testes extensivos e verificaes para validar o software para uso em ambientes de produo. 5. Manuteno: depois da primeira verso pra produo, ocorrem novas edies do sistema com novas funcionalidades. 6. Morte: quando no h mais histrias a serem implementadas e o cliente est satisfeito com o cdigo.

Figura 3: Fases do XP. Fonte: VASCO, VITHOFT e ESTANTE (2009)

3.2.2 SCRUM
O SCRUM, segundo Arajo et al apud Schwaber (2004) um mtodo gil que busca uma forma emprica de lidar com o caos, em detrimento a um processo bem definido. De acordo com Maral (2007), essa metodologia envolve 3 papis distintos: 1. Product owner: o cliente, o responsvel por definir o que o produto, fornecendo suas caractersticas e funcionalidades. Tem o papel tambm de aprovar ou no o resultado do trabalho realizado. Possui a preocupao de obter lucro com o produto desenvolvido. responsvel tambm por definir a data de entrega do produto e, quando necessrio, alterar as prioridades e caractersticas do produto. 2. Scrum Master: atua prximo do product owner, tendo como responsabilidade a aplicao do mtodo, ele tem que garantir que a eficincia da equipe, buscando que esta seja funcional e produtiva. Outro papel o de fazer um acompanhamento do que est sendo realizado e remover qualquer impedimento que possa ocorrer no desenvolvimento dos Sprints, alm de proteger a equipe de interferncias externas e excesso de otimismo. 3. Scrum Team: a equipe, o conjunto de pessoas que possui responsabilidade de desenvolver e entregar os Sprints realizados. Esta equipe deve ser disciplinada, auto-gerenciada, multi-funcional e ter comprometimento com um objetivo em comum. Geralmente so formadas pro grupos de 5 a 9 pessoas. O SCRUM se d em trs etapas, basicamente: Planejamento: aqui definida uma nova funcionalidade requerida pelo sistema, baseando-se no conhecimento do sistema como um todo. Desenvolvimento: desenvolvimento dessa nova funcionalidade, atendendo aos prazos previstos, aos requisitos exigidos e qualidade. Atravs destes itens, definido o trmino desta etapa. Encerramento: preparao para a entrega do produto persistindo as atividades de teste de caixa branca, teste de caixa preta, documentao do usurio, treinamento e marketing.

Na sequncia, a seo 4 apresenta trs metodologias desenvolvidas especificamente para a construo de Objetos de aprendizagem. 4. Metodologias Aplicadas na Construo de OAs

Em meio ao estudo de metodologias geis e tradicionais, surgem as metodologias desenvolvidas para construo de objetos de aprendizagem. Assim, abaixo sero descritas de maneira suscinta trs metodologias para a construo de OAs, para posterior anlise.

4.1 Metodologia RIVED-UENF

Segundo Santos et al (2008), a metodologia estabelecida para construo de OAs por esta entidade se divide em 3 etapas: 1. Planejamento ou Modelagem: produo de documentos de especificao pela equipe pedaggica (design pedaggico, mapa de conceito, mapa de cenrio, roteiro e mapa navegacional) 2. Desenvolvimento: o OA comea a ser produzido nesta etapa, por uma equipe tcnica, que se baseia no roteiro e nos mapas de cenrio e navegacional, de acordo com as especificaes feitas por uma equipe de domnio. Em

paralelo, o Guia do Professor (GP) construdo pela equipe de domnio. Este guia possui informaes sobre o funcionamento do OA e serve para orientar os professores sobre como utiliz-los com os alunos. 3. Validao: a equipe de domnio atua nesta etapa de modo a verificar se o OA est de acordo com o planejamento, para decidir a necessidade de possveis correes. So analisados aspectos de navegabilidade, interatividade e design. Assim, de posse dos comentrios e observaes feitas pela equipe de domnio, a equipe tcnica realiza as alteraes necessrias.

4.2 Metodologia MACOBA.

Fuentes et al (2008) descreve esta metodologia como sendo composta pelas 5 etapas descritas abaixo: 1. Exigncia: professores aumentam sua experincia com o processo de planejamento. Os padres nesta etapa so as orientaes para os professores (designer instrucional) 2. Anlise: nesta etapa, implementada UML como uma forma inovadora de reaproveitamento de padres de casos de uso e padres de diagramas de seqncia para a aprendizagem colaborativa. 3. Design e desenvolvimento: o designer tecnolgico customiza os padres de frames e seleciona servios de comunicao como wikis, fruns, chats, etc. 4. Implementao: responde organizao do cenrio de aprendizagem. Neste nvel, os elementos so atividades, sequncias, funes, etc. Esta etapa se baseia no modelo do IMS- Learning Design incorporando a estrutura e as atividades de colaborao. 5. Avaliao: considera um processo de reviso geral sobre a aplicao de padres corretos para se ter certeza sobre a aplicao do processo colaborativo.

Figura 4: fases da metodologia MACOBA Fonte: FUENTES ET AL (2008)

4.3 Metodologia de OAs para o Auxlio ao Processo de Aprendizagem para

as reas de Cincias e Matemtica do Ensino Mdio (MOA-RS)
Esta metodologia foi proposta atravs de um estudo realizado em escolas situadas no Rio Grande do Sul. importante salientar que a sua estrutura no representa um processo seqencial e nem todos os itens citados so obrigatrios. (SILVA et al, 2008) Concepo: essa etapa necessria para registrar o momento de sua criao, atravs de uma representao textual e grfica do objeto. Autoria de OAs para aprender: essa etapa pode desencadear outras trs etapas que no so seqenciais, mas se relacionam internamente. So elas: projeto dos OAs; desenvolvimento de projetos de aprendizagem; programao (programas ou interfaces grficas). A etapa de concepo precede esta etapa. Publicao do OA: os objetos so publicados em repositrios, onde podem ser identificados atravs de metadados.

A seo a seguir aborda uma anlise comparativa entre as atividades de cada metodologia abordada anteriormente, excluindo as tradicionais e justificando a excluso das mesmas.

5.

Anlise entre as Metodologias

Conforme apontado por Silva et al (2008), os princpios que os mtodos geis seguem so mais convenientes para uma metodologia focada em construir OAs, sendo destacados por estes autores, trs, entre os doze princpios geis, os quais se contrapem aos mtodos tradicionais:
Alteraes nos requisitos so bem vindas, mesmo que tardiamente no desenvolvimento. Processos geis suportam a mudana, para a vantagem competitiva do cliente. Entrega de software frequentemente, de poucas semanas a poucos meses, com preferncia para a escala de tempo mais curta. Os especialistas no negcio e os desenvolvedores devem trabalhar juntos diariamente durante o projeto.

Assim, foram descartadas as metodologias tradicionais, e realizou-se um comparativo entre as demais metodologias apresentadas anteriormente. Nesse contexto, Gagne (2005) apud Koohang e Harman (2007) afirma que as disciplinas bsicas do processo de design instrucional so anlise, design, desenvolvimento, implementao e avaliao (originando o acrnimo em ingls ADDIE). Assim, as metodologias sero comparadas tendo como base estas etapas.

Mtodo
XP SCRUM RIVED MACOBA MOA-RS

Anlise Atividade
clientes escrevem cartes com as estrias (contem os requisitos). so definidos os product backlog (lista de requisitos). documentos de especificao produzidos pela equipe pedaggica. os requisitos so feitos atravs do uso de UML. equivale fase de concepo.

Mtodo
XP SCRUM RIVED MACOB A MOA-RS

Design Atividade
prope que seja realizado em paralelo escrita das estrias, mas no d sugestes de como realizar esta etapa. sugere que se faa um projeto geral do sistema baseando-se nos itens do product backlog (requisitos), mas no sugere nenhuma tcnica para se aplicar. os documentos de especificao gerados na etapa anterior so submetidos a outras equipes de produo de OAs para obteno de feedback. padres de frames so customizados e servios de comunicao como wikis, fruns, chats, etc. so selecionados pelo designer tecnolgico. equivale fase de autoria de objetos para aprender.

Desenvolvimento

Mtodo
XP SCRUM RIVED MACOBA MOA-RS

Atividade
modelagem e programao para cada conjunto de cartes com estrias, em vrias iteraes. os requisitos abordados no sprint Backlog so desenvolvidos. Durante cada sprint, ocorrem reunies rpidas, diariamente, para que os envolvidos fiquem informados sobre os progressos e dificuldades. a produo do OA por uma equipe tcnica, de acordo com as especificaes feitas por uma equipe de domnio. equivale sua etapa de implementao equivale fase de autoria de objetos para aprender.

Mtodo
XP SCRUM RIVED MACOBA MOA-RS

Implementao Atividade
programadores implementam o especificado nos cartes de estrias que compem a iterao corrente os requisitos abordados no Sprint Backlog para a Sprint corrente so implementados equivale etapa de desenvolvimento, onde o OA produzido utiliza o IMS-LD como base, incorporando a estrutura e as atividades de colaborao, para organizar o cenrio de aprendizagem.

Mtodo
XP SCRUM RIVED MACOBA MOA-RS

Avaliao Atividade
a cada iterao, o mdulo desenvolvido pode ser colocado em uso e gerar um feedback para realizar as alteraes necessrias. No prope uma etapa especfica para isso. o cliente avalia o sistema no ltimo dia da Sprint. Sugere ainda um acompanhamento com o cliente, para garantir a qualidade do produto. verificado se o OA est de acordo com o planejamento. So analisadas caractersticas como navegabilidade, interatividade e design. A equipe de domnio avalia e a tcnica realiza as alteraes. faz um processo de reviso geral sobre a aplicao dos padres corretos para ter garantias sobre a aplicao do processo colaborativo no dispe de uma etapa de avaliao embutida no seu processo

Aps esta comparao, percebe-se a imaturidade da metodologia MOA-RS, visto sua desorganizao perante as fases do modelo ADDIE. Alm deste detalhe, ela no apresenta uma etapa de avaliao, que um fator importantssimo, pois necessrio verificar se o OA possui tanto caractersticas tcnicas como pedaggicas, para garantir que o mesmo seja aplicado no processo de ensino-aprendizagem. A metodologia MACOBA merece destaque pelo uso de tcnicas de especificao em UML, utilizando-se de diagramas de sequncia e casos de uso, entre outros, para descrio bem feita do objeto. A metodologia RIVED tambm se destaca, separando papis entre uma equipe tcnica e uma pedaggica, o que facilita a produo do OA, delegando equipes especializadas para cada etapa do desenvolvimento. A seguir so feitas as consideraes finais para o presente artigo.

6.

Consideraes finais

Metodologias da engenharia de software podem ser utilizadas na produo de objetos de aprendizagem. O uso de metodologias tradicionais para este feito no muito conveniente, posto que estas metodologias so mais aplicadas a projetos de longo prazo, o que se contrape ao desenvolvimento de OA, que deve demandar prazos curtos. Alm deste fator, a resposta rpida a feedbacks tem peso grande em favor adoo de propostas geis nesse desenvolvimento. Ao realizar a comparao entre as metodologias apresentadas, com a recomendada como padro por Gagne (2005) apud Koohang e Harman (2007), possvel perceber que as propostas focadas em desenvolver OAs possuem vrias caractersticas bem semelhantes com as geis, se adequando ainda ao modelo ADDIE. Merecem destaque as metodologias MACOBA e RIVED. Entretanto, percebeu-se que a metodologia apresentada pelos autores Silva et al (2008), apesar de ser classificada por eles como uma metodologia para a construo de OAs, no deve ser seguida a risca, pois no uma metodologia completa e no garante que um produto final seja gerado, visto que neste mtodo, o processo de aprendizagem do aluno priorizado em relao ao produto final. Os autores deste artigo no recomendam o seu uso para a obteno de um OA, mas sugerem que pode ser aproveitada a idia de etapas no seqenciais para a construo do OA, no caso de a equipe de desenvolvimento ser composta apenas por uma pessoa, por exemplo. Outro ponto que merece destaque a importncia de uma etapa de avaliao nestas metodologias, pois nessa etapa que se verifica se o produto final gerado se adqua s caractersticas de um OA. A participao de uma equipe pedaggica e uma equipe tcnica, destacada na metodologia RIVED fundamental para a produo destes artefatos digitais.

7. Referncias
AGILE MANIFESTO. Disponvel em http://agilemanifesto.org/, acesso junho, 2010 ARAUJO, A. R. S.; SILVA J. M.; MITTELBACH, A. F.; SCRUM: Novas Regras do Jogo, V Brazilian Symposium on Computer Games and Digital Entertainment. 2006

BECK, K. Programao Extrema Explicada. Bookman, 1999. FERLIN, J. Repositrio de Objetos de Aprendizagem para a rea de Informtica In: Trabalho de Concluso de Curso Universidade do Estado de Santa Catarina UDESC, 2009 FUENTES, L. M.; ARTEAGA, J. M.; RODRGUEZ, F. A.. A Methodology for Design Collaborative Learning Objects. Eighth IEEE International Conference on Advanced Learning Technologies, 2008 KOOHANG, A. and HARMAN, K., Learning Objects and Instructional Design. Santa Rosa, Informing Science Press, p. 267-279. Disponvel em <http://books.google.com.br/books?hl=ptBR&lr=&id=DOZFrbLt1CUC&oi=fnd&pg=PA253&dq=Structure+of+Storyboard+for+Interactive+Learning+Objects+Developme nt+%2Baddie&ots=QmethH6dz6&sig=hYnNnDuLK7BcSUDJ1ib4GWkSiGE#v=snippet&q=addie&f=false> acesso jun 2010 LOISELLE, J. A explorao da multimdia e da rede internet para favorecer a autonomia dos estudantes universitrios na aprendizagem. In: Alava, Sraphin (Org.). Ciberespao e formaes abertas: rumo a novas prticas educacionais? Trad. Ftima Murad. Porto Alegre: Artmed. 2002 LTSC IEEE. Standard for Information Technology: Education and Training Systems - Learning Objects and Metadata, 2002. Disponvel em: <http://ltsc.ieee.org/wg12/>. Acesso em: jan 2009. MENEZES, C. S. ; LIRA, A. F. ; FERRETI, C. ; LINDNER, E. L. . ODAI - Objetos digitais para aprendizagem interacionista. In: Simpsio Brasileiro de Informtica na Educao - SBIE, 2006, Braslia. Anais do Simpsio Brasileiro de Informtica na Educao, 2006. NETO, O. N. S.. Anlise Comparativa das Metodologias de Desenvolvimento de Softwares Tradicionais e geis. In: Trabalho de Concluso de Curso. Universidade da Amaznia UNAMA, 2004. PRESSMAN, R. S., Engenharia de Software, 5 Ed., Makron Books, 2002. RAMOS, A. F.; SANTOS, P. K. A Contribuio do Design Instrucional e das Dimenses da Educao para o Desenvolvimento de Objetos de Aprendizagem. In: XXVI Congresso da So ciedade Brasileira de Computao, Campo Grande, MS. Anais do XXVI Congresso da Sociedade Brasileira de Computao. P. 1-8, 2006. ROYCE, W.W. Managing the Development of Large Software Systems: Concepts and Techniques. Proc. IEEE Westcon, Los Angeles,CA. 1970. SANTOS; N. S. R. S.; RAPKIEWICZ, C. E.; WIVES, L. K. . O Processo Produtivo de Objetos de Aprendizagem numa Unidade do RIVED/Fbrica Virtual: Problemas e Solues. XXVIII Encontro Nacional de Engenharia de Produo ENEGEP. 2008. SCHWABER K., Agile Project Management With Scrum, Microsoft Press, 2004. SOARES, M. S.. Comparao entre Metodologias geis e Tradicionais para o Desenvolvimento de Software . INFOCOMP (UFLA. Impresso), v. 3, p. 8-13, 2004. TAROUCO, L. M. R.; GRANDO, A. R. C. da S.; KONRATH, M. L. P. Alfabetizao visual para a produo de objetos educacionais. Revista Novas Tecnologias na Educao, Porto Alegre - RS, v. 1, n. 2, 2003. VASCO, C. G.; VITHOFT, M. H.; ESTANTE, P. R. C. .Comparao entre metodologias RUP e XP. In: Progra ma de psgraduao em Informtica Aplicada. Pontifcia Universidade Catlica do Paran PUCPR, 2009. WILEY, D. A. Connecting learning objects to instructional design theory: A definition, a metaphor, and a taxonomy . In D. A. Wiley (Ed.), The Instructional Use of Learning Objects: Online Version. 2000. Disponvel em: <http://reusability.org/read/chapters/wiley.doc>.