Design
Capítulo 5: Design de um Objeto de Aprendizagem
Autoria: Juliana Cristina Braga; Roberta Kelly A. de França.
Esta unidade inicia com a definição da etapa de arquitetura de um OA, seguida pelos diferentes esboços (artefatos) do mesmo que podem ser produzidos durante o seu desenvolvimento. Finalmente, é apresentado o resumo do conteúdo desta unidade.
Boa leitura!
5.1. O design de um OA
A etapa de Design da metodologia INTERA é a atividade do ciclo de vida1 em que os requisitos do OA são analisados, para transformar os resultados das fases anteriores (Contextualização e Requisitos) em artefatos capazes de serem facilmente interpretados pela equipe de desenvolvimento do OA. Por isso, ela representa um importante momento de alcançar a qualidade de todo o processo e do resultado final. As questões a serem analisadas incluem como o OA será projetado, passando pela definição das melhores tecnologias que serão utilizadas e pela avaliação da decomposição e modularização do OA, sempre que possível, em pequenos entes independentes e reutilizáveis.
Para que o objetivo dessa etapa seja alcançado, duas atividades principais devem ser cumpridas: a) Análise e Esboço do OA e b) Design do OA. Nesse curso, será dada ênfase à primeira atividade. Apesar disso, uma descrição mais abrangente de ambas será realizada a seguir. O foco na primeira atividade se deve ao fato de que você, cursista, poderá atuar ativamente nela; a segunda atividade,
1 ‘Ciclo de vida’ de um OA corresponde a todo o processo de concepção do projeto do OA: a
definição da ideia, o desenvolvimento (etapas do processo que inclui testes), utilização e manutenção do OA.
em geral, é realizada por uma equipe com conhecimentos mais técnicos de informática.
5.1.1. Análise e Esboço do OA
O Esboço do OA tem como produto um artefato que exibe o rascunho ou delineamento do OA a ser produzido. Para que esse esboço seja feito da maneira mais adequada possível, a primeira ação do analista é trabalhar com os requisitos levantados, transformando-os em um documento de especificação de requisitos.
Transpondo a definição utilizada na Engenharia de Software (glossário de engenharia de software do IEEE [IEEE 610.12-90]) para a Educação, em especial para o desenvolvimento de OA, o documento de especificação de requisitos deve detalhar o contexto pedagógico e o perfil do alunado que utilizará o objeto em seu processo de aprendizagem. Além disso, ele inclui todos os requisitos levantados (funcionais, didático-pedagógicos e não funcionais) e todas as pessoas relacionadas ao desenvolvimento do OA. Ou seja, ele engloba quais são os objetivos do OA a serem desenvolvidos, quais são as tarefas/atividades fundamentais para que alcance seus objetivos pedagógicos, suas características não funcionais e de qualidade técnica. Este documento circulará entre todos da equipe, como se fosse a formalização de um “acordo” estabelecido. Portanto, ele deve ser produzido em linguagem natural e incluir todos os artefatos da etapa anterior.
Com este documento de especificação finalizado, o processo de esboço do OA torna-se uma tarefa mais segura para quem o produzirá. O esboço é um artefato bastante relevante, pois faz a ponte com o objeto do campo do ideal e o objeto que pode ser produzido, considerando as condições da equipe, o cronograma, o orçamento e os recursos tecnológicos. Além disso, à medida que o OA é esboçado o entendimento sobre esse OA aumenta. É muito comum aprimorar ou mudar os requisitos durante o processo de esboço do OA, uma vez que ele é iterativo. Isso significa que não há problemas em mudar ou melhorar os requisitos, e por sua vez, o documento de especificação de requisitos. O importante é que esses requisitos fiquem claros antes que o desenvolvimento do OA se inicie.
Sendo assim, é importante que o demandante saiba expressar seus interesses tanto técnicos quanto pedagógicos para com o OA que será desenvolvido; neste sentido, a etapa de requisitos tem também este papel de propor esta reflexão ao demandante. Caso contrário, o OA produzido pela equipe de desenvolvimento poderá não condizer com aquilo que o demandante imaginou. Contudo, a ausência de requisitos é quase tão prejudicial quanto a produção de artefatos de requisitos em uma linguagem muito técnica, visto a interdisciplinaridade
dos integrantes da equipe. Veja esta problemática ilustrada de forma divertida na Figura 1:
Figura 1 - Problemas na fase de desenvolvimento de OAs.
Fonte: própria.
Este exemplo, como dito, apresenta de forma divertida um dos problemas que podem ocorrer no processo de levantamento dos artefatos de requisitos. Outro problema que ocorre com frequência é a produção de artefatos que não condizem com o tipo do objeto a ser produzido. Isto porque existem vários tipos de esboços que podem ser gerados nessa etapa, e estes variam de acordo com o tipo de OA a ser produzido, com o tipo e qualidade dos requisitos levantados, bem como com a necessidade de análise a ser feita sobre o OA.
Na sessão seguinte, serão apresentados os diferentes tipos de esboços para os diversos tipos de OAs. Porém, antes de iniciar a leitura da próxima seção, lembre-se de que um esboço é considerado um artefato na metodologia INTERA e, portanto, será referenciado como tal ao longo do texto.
5.2. Diferentes tipos de artefatos para cada tipo de OA
A criação do esboço do OA evidencia a relação da etapa de Análise e Design com a etapa de Levantamento de Requisitos, pois, neste momento, cada artefato produzido anteriormente deverá ser utilizado para confecção deste esboço e avaliação dos interesses iniciais com relação aos resultados alcançados até aqui. A seguir, são apresentados e definidos exemplos dos principais tipos de esboços (artefatos) utilizados para o desenvolvimento de um OA.
1) Mapa de atividades: trata-se de um artefato complementar muito valioso para a transposição de uma disciplina presencial para a modalidade online, pois trata da representação da ementa de um curso. Um mapa de atividades fornece todas as informações necessárias para que sejam criadas nas ferramentas do Ambiente Virtual de Aprendizagem (AVA) as atividades ou tarefas planejadas para acontecer durante o curso virtual (FRANCO, 2007). Do ponto de vista da avaliação pedagógica, é um artefato fundamental para que o professor visualize os resultados que espera alcançar em cada atividade e, para isso, seja capaz de estabelecer temas e subtemas de cada aula, planejar a distribuição da carga horária entre as aulas, definir as formas e tipos dos exercícios e da avaliação, planejar atividades com eventos interativos assíncronos, como fóruns de discussão, e síncronos, como chats, webconferência etc. (FRANCO, 2007; RODRIGUES, FRANCO e BRAGA, 2006).
Recomendação de uso: o mapa de atividades é comumente recomendado para OAs do tipo cursos ou aulas menores e específicas. Ele também pode ser utilizado para OA do tipo software de simulação que trabalhe com a apresentação de dois ou mais conceitos ou atividades.
Exemplo: A Figura 2 mostra um mapa de atividades de um curso de gestão pública e elaboração de projetos. Esse curso pode ser considerado um OA de alta granularidade.
Figura 2 - Exemplo de esboço de um Mapa de Atividades.
Fonte: própria.
2) Sumário Executivo: este artefato representa de maneira objetiva o conteúdo do OA, e
por isso deve ser capaz de atrair a atenção para a potencialidade do assunto a ser tratado pelo mesmo. Ele conduz ao entendimento sobre o objeto, porque apresenta seu conteúdo principal de forma linear; porém, não é incomum que este artefato seja alterado conforme a progressão da compreensão e dimensão sobre o OA.
Recomendação: Utiliza-se para a apresentação de OA do tipo curso ou aula e
recomenda-se que este artefato não tenha mais que quatro laudas.
Exemplo: um Sumário Executivo pode ser apresentado como uma lista topicalizada dos principais assuntos tratados no objeto. O exemplo a seguir foi produzido durante o desenvolvimento deste curso de Objetos de Aprendizagem (Figura 3):
Figura 3 - Exemplo de esboço de um Sumário Executivo.
Fonte: própria
3) Esboço de um Roteiro: um roteiro é a representação textual das imagens e cenas de um filme, novela etc. Isto significa que ele é a tradução em palavras de um arquivo áudio visual (vídeo). Esta tradução deve ser completa, incluindo a descrição das ações, falas, cenários, características físicas e de expressões das personagens etc. (WATTS, 1990). Sendo assim, sua importância se dá na riqueza de detalhes que devem levar a compreensão do “o que” e “para que” está se elaborando tal detalhamento.
Este detalhamento, por sua vez, deve possibilitar a execução do arquivo áudio visual por qualquer pessoa responsável pelo seu desenvolvimento, mesmo que sem a presença do demandante ou autor da ideia inicial. Os roteiros são utilizados de forma bem detalhada pelos profissionais de produção de vídeo, mas para vídeos educacionais, como é o caso dos OAs, um com menor detalhamento e nível técnico pode ser suficiente para expressar o que o professor gostaria. Chamamos de protótipo do roteiro aquele roteiro menos detalhado.
Recomendação: Muito utilizado para objetos de aprendizagem do tipo vídeo, mas podem ser usados em OAs do tipo animações também.
Exemplo: Veja a seguir diferentes tipos de esboço de roteiro de acordo com o tipo de ao (Figuras 4-5):
Figura 4 - Exemplo de esboço de um roteiro para OA do tipo software.
Fonte: O Objeto de aprendizagem produzido a partir desse roteiro foi uma animação em flash que
Figura 5 - Exemplo de roteiro do tipo slides para um OA do tipo curso online.
Fonte: própria. Exemplo de artefato produzido em software para produção de slides.
4) Storyboard: pode ser definido como a história contada através de desenhos que seguem a mesma lógica cronológica dos acontecimentos, de acordo com as ações dos seus personagens. “Lembra uma história em quadrinhos sem balões” e assume três funções na etapa de arquitetura: 1) ajuda os criadores a visualizar a estrutura do filme e discutir a sequência dos planos, os ângulos, o ritmo, a lógica do filme, as expressões e atitudes dos personagens; 2) ajuda a apresentar o roteiro para os responsáveis pela aprovação e liberação de verbas; 3) orienta a produção do filme, lembrando aos realizadores o que realmente foi aprovado pelo patrocinador ou cliente.” (SPACCA, acesso em 10/05/2012). Um storyboard não precisa ser produzido por um desenhista profissional, podendo ser um desenho simples feito pelo idealizador do OA. No entanto, talvez se faça necessária a adoção do artefato “roteiro”, por este conter as falas e a descrição textual das personagens e cenários do OA.
Recomendação: Muito utilizado para produção de vídeos, quadrinhos e software de animações.
Figura 6 - Exemplo de storyboard.
Fonte: Preece, 2005.
4) Protótipo: trata-se do modelo funcional do OA a ser desenvolvido. Permite que as partes interessadas façam experiências com um modelo do OA final, ao invés de somente discutirem representações abstratas dos seus requisitos. Os protótipos suportam o conceito de elaboração progressiva. Quando suficientes ciclos de coletas de feedback forem realizados, os requisitos obtidos do mesmo estarão completos para se partir para fase de desenvolvimento ou construção. O protótipo representa o OA que está finalizado, mas não disponível, servindo apenas para testes. Após os testes e aprovação do protótipo, ele deverá ser disponibilizado.
Recomendação: muito utilizado para OAs do tipo software de animações.
Exemplo: Veja a seguir diferentes tipos de protótipos, de acordo com o tipo de ao (Figuras 7-10):
Figura 7 - Prototipação de um OA do tipo exercício feito manualmente.
Fonte: própria. Exemplo de artefato produzido no papel, durante a elicitação de trabalho em grupo.
Figura 8 - Exemplo de protótipo para um OA do tipo software.
Figura 9 - Exemplo de protótipo para um OA do tipo software.
Figura 10 - Protótipo feito em software de produção de slides para um OA do tipo software.
Fonte: conteúdo retirado da página http://exercicios-de-portugues.blogspot.com.br/2011/05/bainha-de-mielina-biologia.html. Exemplo baseado no OA disponível em:
http://objetoseducacionais2.mec.gov.br/bitstream/handle/mec/2742/mielina.swf?sequence=1
Observe pelos exemplos que esboçar um Objeto de Aprendizagem independe da plataforma ou linguagem em que ele será desenvolvido. Essa independência e facilidade permitem que o OA seja idealizado e esboçado até mesmo pelo maior responsável por sua concepção, que é o demandante. Lembrando que, na maioria das vezes, o demandante é leigo em informática, e o esboço do OA facilita extrair da mente dele suas ideias e refleti-las em um papel ou imagem de maneira a ser bem compreendida pela equipe de desenvolvimento. Portanto, o esboço possui duas grandes vantagens: 1) permitir que o demandante e o analista entendam e aprimorem os requisitos do ao e 2) permitir que a equipe de desenvolvimento compreenda melhor as ideias que estão na mente do demandante do OA e, consequentemente, produzir um OA dentro das expectativas iniciais.
5.2.1 Designer do OA
Após o esboço do OA, é necessário realizar o seu design. O termo Design foi originado da Ciência da Computação, e é definido pelo Glossário de Termos de Engenharia de Software [IEEE 610.12-90] como sendo "o processo de definição da arquitetura, componentes, interfaces e outras características de um sistema ou componente do sistema".
No contexto desse curso, o designer de um OA deve descrever como o OA pode ser decomposto e organizado em componentes pequenos e reutilizáveis, e como serão as interfaces (ou conexões) entre esses componentes. Nessa fase, ocorre a decomposição e modularização OA de grande porte em uma série de pequenos entes independentes e reutilizáveis.
Para que o designer seja bem sucedido, é necessário compreender os requisitos do OA e o contexto onde ele se enquadra. Cada tipo de OA exige um design diferente, como por exemplo, o design de um vídeo seria simplesmente decompô-lo em vídeos menores, de forma que cada componente possa ser reaproveitado em diferentes contextos. Já o design de um software exige a sua modularização em pequenos objetos, sendo necessários conceitos avançados na área da computação.
O grande desafio dessa etapa é modularizar o OA de maneira que os conceitos contidos em cada módulo sejam entendidos de forma independente dos demais. Para esse curso, não detalharemos mais essa etapa. É suficiente saber que a divisão de um OA em pequenos componentes é considerada importante na metodologia INTERA, fato comprovado por existir uma etapa específica para que isso seja realizado sem parcimônia.
5.3 Resumo
A finalidade de analisar os requisitos e posteriormente esboçar o OA é a de ajudar na melhor compreensão do OA, em vez de dar início ao seu desenvolvimento sem a construção dos artefatos apresentados nesta unidade. Vimos que cada tipo de objeto exigirá uma arquitetura diferente. Por isso estudamos nesta unidade esboços do tipo: mapa de atividades, roteiro, storyboard e prototipação.
Referências Bibliográficas
BLOG LINKEI: Disponível em: http://www.linkei.net/publicacao. Acesso em 26/06/2012.
FRANCO, Lúcia Regina Horta Rodrigues; BRAGA, Dilma Bustamante. Planejando um curso de EaD para Web. Itajubá: UNIFEI, 2007. Disponível em:
http://www.ead.unifei.edu.br/novolivrodigital/geralLivro.php?codLivro=50&codCap=11 4. Acesso em: 21/07/2012.
MEDEIROS, L. Gomes, A, S. Alves, C. Caparica, F. Uso de StoryBoards para a Documentação dos Requisitos no Desenvolvimento Distribuído de Software. Disponível em: http://www.cin.ufpe.br/~asg/publications/files/WDDS_Final.pdf. Acesso em: 23/07/2012.
MOREIRA, Marco Antônio. Mapas conceituais e aprendizagem significativa. Adaptado e atualizado, em 1997, de um trabalho com o mesmo título publicado em O ENSINO, Revista Galáico Portuguesa de Sócio-Pedagogia e Sócio-Lingüística, Pontevedra/Galícia/Espanha e Braga/Portugal, N° 23 a 28: 87-95, 1988. Publicado também em Cadernos de Aplicação, 11(2): 143-156, 1998. Revisado e publicado em espanhol, em 2005, na Revista Chilena de Educação Científica, 4(2): 38-44.
Disponível em: http://www.if.ufrgs.br/~moreira/mapasport.pdf
NEaD-UNIFEI – NÚCLEO DE EDUCAÇÃO A DISTÂNCIA - UNIVERSIDADE FEDERAL DE ITAJUBÁ (UNIFEI). Entendendo o Mapa de Atividade, a Matriz de Design Instrucional e o StoryBoard. Disponível em:
http://www.ead.unifei.edu.br/teleduc/cursos/diretorio/atividades_3189_13///Entenden do_Matriz_DI.pdf. Acesso em: 05/07/2012.
NIENOW, Angélica Luísa; BEZ, Marta Rosecler. Ferramenta de Autoria para o Desenvolvimento de Material Pedagógico para a Área da Saúde. Universidade Feevale.
PREECE, J. Rogers,Y. Sharp, H. Design de interação: além da interação homem-computador. Artmed: Porto Alegre, RS, 2005.
RODRIGUES, Alessandra; FRANCO, Lúcia Regina Horta Rodrigues; BRAGA, Dilma Bustamante. Abordagens teórico-pedagógicas e os cursos via web. Itajubá: UNIFEI, 2006. Disponível em:
http://www.ead.unifei.edu.br/novolivrodigital/geraLivro.php?codLivro=51&codCap=11 9. Acesso em: 01/06/2012.
SOUZA, Maria de Fátima C. de; CASTRO-FILHO, José A. de; ANDRADE, Rosana M.C. Desenvolvendo objetos de aprendizagem utilizando modelos arquiteturais/ Universidade Federal do Ceará.
SPACCA. Disponível em: http://www.spacca.com.br/educacao/storyboard.htm. Acesso em: 10/05/2012.
STANDARDS COORDINATING COMMITTEE OF THE COMPUTER SOCIETY OF THE IEEE. IEEE Std. 610.12-90: Glossary of Software Engineering Terminology. 1990. Disponível em: http://www.idi.ntnu.no/grupper/su/publ/ese/ieee-se-glossary-610.12-1990.pdf . Acesso em 26/06/2012.
WATTS, Harris. On Camera: o curso de produção de filme e vídeo da BBC. São Paulo: Summus, 1990.
