View
27
Download
0
Embed Size (px)
DESCRIPTION
Ao participar de formações presenciais ou à distância, alunos encontram dificuldades para organizar ou autorregular seu próprio aprendizado. Neste trabalho, adotamos práticas do Design de Interação para conceber interfaces que ajudem os alunos a declarar e monitorar suas metas de aprendizagem. Os resultados obtidos apontam para uma complexidade da tarefa e rebuscadas interfaces de mediação. Após a revisão teórica, foram elicitados requisitos que tentam introduzir os benefícios da autorregulação da aprendizagem em um ambiente virtual de aprendizado colaborativo
Citation preview
Universidade Federal de Pernambuco Centro de Informática
Graduação em Ciência da Computação
HÉLDER MANOEL LIMA E SILVA
ESTILOS DE INTERAÇÃO PARA AUTORREGULAÇÃO DA
APRENDIZAGEM EM AMBIENTES DE ENSINO
TRABALHO DE GRADUAÇÃO
Recife
05 de Julho de 2011
HÉLDER MANOEL LIMA E SILVA
ESTILOS DE INTERAÇÃO PARA AUTORREGULAÇÃO DA
APRENDIZAGEM EM AMBIENTES DE ENSINO
TRABALHO DE GRADUAÇÃO
Orientador: Alex Sandro Gomes
Recife
05 de Julho de 2011
Trabalho apresentado ao Programa de Graduação em Ciência da Computação do Centro de Informática da Universidade Federal de Pernambuco como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação.
AGRADECIMENTOS
Ao Professor Alex Sandro Gomes, pela disponibilidade,
orientação precisa e motivação.
Aos colegas colaboradores, companheiros de estudo e
compartilhamento de informações.
Sem a curiosidade que me move, que me
inquieta, que me insere na busca, não
aprendo nem ensino.
Paulo Freire
SUMÁRIO
AGRADECIMENTOS .............................................................................................................. 2
SUMÁRIO ............................................................................................................................... 4
LISTA DE FIGURAS ............................................................................................................... 7
LISTA DE TABELAS ............................................................................................................... 8
RESUMO................................................................................................................................. 9
CAPÍTULO 1_INTRODUÇÃO ................................................................................................ 10
CAPÍTULO 2_ESTADO DA ARTE ........................................................................................ 12
2.1 MOTIVAÇÃO ................................................................................................................................. 12
2.2AUTORREGULAÇÃO DA APRENDIZAGEM.................................................................................... 12
2.2.1 Aprendizado ...................................................................................................................... 13
2.2.2 Metacognição .................................................................................................................... 13
2.2.2.1 Autorregulação: aspectos teóricos .................................................................................. 15
2.2.2.2 Autorregulação on line ................................................................................................... 17
2.2.2.3 Redes Sociais e Autorregulação .................................................................................... 17
CAPÍTULO 3_MÉTODO ........................................................................................................ 19
3.1 Objetivo Geral ................................................................................................................................ 19
3.2 Objetivos Específicos ..................................................................................................................... 19
3.3 Cenários ........................................................................................................................................ 19
3.4 Procedimentos ............................................................................................................................... 21
3.5 Resultados ..................................................................................................................................... 22
3.5.1 comparação com sistemas similares .......................................................................................... 22
3.5.1.1 qOrganizer .......................................................................................................................... 22
3.5.1.2 Google Calendar ................................................................................................................. 23
3.5.1.3 atépassar ............................................................................................................................ 24
3.5.1.4 Schoolbinder ....................................................................................................................... 24
3.5.1.5 Doodle ................................................................................................................................ 25
3.5.1.6 rememberthemilk ................................................................................................................. 26
3.5.2 Personas e Cenários ................................................................................................................. 27
3.5.2.1 Contexto e Personas ............................................................................................................... 27
3.5.3 ATIVIDADE 1: PROFESSOR CRIA O CALENDÁRIO DE AULAS DE UM CURSO ...... 28
3.5.3.1 Descrição da atividade ............................................................................................................ 28
3.5.3.2 Cenário atual .......................................................................................................................... 28
3.5.3.3 Necessidades do usuário ........................................................................................................ 29
3.5.3.4 Cenário futuro com a solução .................................................................................................. 29
3.5.3.5 Cenários futuros caricaturados ................................................................................................ 30
Cenário positivo (plus scenario) ....................................................................................................... 31
Cenário negativo (minus scenario)................................................................................................... 31
3.5.3.6 Requisitos do produto ............................................................................................................. 32
Requisitos funcionais: ..................................................................................................................... 32
Requisitos não-funcionais: .............................................................................................................. 33
3.5.4 ATIVIDADE 2: ALUNO ESTIMA E DECLARA HORÁRIO DE ESTUDO ....................... 33
3.5.4.1 Descrição da atividade ............................................................................................................ 33
3.5.4.2 Cenário atual .......................................................................................................................... 34
3.5.4.3 Necessidades do usuário ........................................................................................................ 34
3.5.4.4 Cenário futuro com a solução .................................................................................................. 34
3.5.4.5 Cenários futuros caricaturados ................................................................................................ 35
Cenário positivo (plus scenario) ....................................................................................................... 35
Cenário negativo (minus scenario)................................................................................................... 36
3.5.4.6 Requisitos do produto ............................................................................................................... 37
Requisitos funcionais: ....................................................................................................................... 37
Requisitos não-funcionais: ................................................................................................................ 38
3.5.5 ATIVIDADE 3: ALUNO USA ALGUM RECURSO ......................................................... 38
3.5.5.1 Descrição da atividade ............................................................................................................ 39
3.5.5.2 Cenário atual .......................................................................................................................... 39
3.5.5.3 Necessidades do usuário ........................................................................................................ 40
3.5.5.4 Cenário futuro com a solução .................................................................................................. 40
3.5.5.5 Cenários futuros caricaturados ................................................................................................ 41
Cenário positivo (plus scenario) ........................................................................................................ 41
Cenário negativo (minus scenario) .................................................................................................... 32
3.5.5.6requisitos do produto: ............................................................................................................... 42
Requisitos funcionais: ....................................................................................................................... 42
Requisitos não-funcionais: ................................................................................................................ 43
3.5.6 ATIVIDADE 4: PROFESSOR MONITORA AS ATIVIDADES DOS ALUNOS .................. 44
3.5.6.1 Descrição da atividade ............................................................................................................ 44
3.5.6.2 Cenário atual .......................................................................................................................... 44
3.5.6.3 Necessidades do usuário ........................................................................................................ 44
3.5.6.4 Cenário futuro com a solução .................................................................................................. 45
3.5.6.5 Cenários futuros caricaturados ................................................................................................ 46
Cenário positivo (plus scenario) ........................................................................................................ 46
Cenário negativo (minus scenario) .................................................................................................... 46
3.5.6.6 Requisitos do produto: .............................................................................................................. 47
Requisitos funcionais: ....................................................................................................................... 47
Requisitos não-funcionais: ................................................................................................................ 47
3.5.7ATIVIDADE 5: ALUNO MONITORA E AJUSTA SEU PRÓPRIO DESEMPENHO ......... 47
3.5.7.1 Descrição da atividade .............................................................................................................. 47
3.5.7.2 Cenário atual ............................................................................................................................ 48
3.5.7.3 Necessidades do usuário .......................................................................................................... 48
3.5.7.4 Cenário futuro com a solução .................................................................................................... 49
3.5.7.5 Cenários futuros caricaturados .................................................................................................. 49
Cenário positivo (plus scenario) ........................................................................................................ 49
Cenário negativo (minus scenario) .................................................................................................... 50
3.5.7.6 Requisitos do produto ............................................................................................................... 50
Requisitos funcionais: ....................................................................................................................... 50
Requisitos não funcionais: ................................................................................................................ 51
3.5.8 ATIVIDADE 6: SINCRONIZAÇÃO COM O APLICATIVO ANDROID ............................ 51
3.5.8.1 Descrição da atividade ............................................................................................... 51
3.5.8.2 Cenário atual ............................................................................................................ 51
3.5.8.3 Necessidades do usuário .......................................................................................... 52
3.5.8.4 Cenário futuro com a solução ................................................................................... 52
3.5.8.5 Cenários futuros caricaturados ................................................................................. 52
Cenário positivo (plus scenario) .......................................................................................... 53
Cenário negativo (minus scenario) ...................................................................................... 53
3.5.8.6 Requisitos do produto ............................................................................................... 53
Requisitos funcionais: ......................................................................................................... 53
Requisitos não-funcionais: .................................................................................................. 54
CONCLUSÃO E TRABALHOS FUTUROS ............................................................................ 55
APÊNDICE ............................................................................................................................ 59
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................................................... 56
LISTA DE FIGURAS
FIGURA 01: Fases do Processo de Auto-Regulação da Aprendizagem (Zimmerman,
2002)
FIGURA 02: Tela do qOrganizer. Fonte: http://qorganizer.sourceforge.net/
FIGURA 03: Tela do Google Calendar. Fonte: www.google.com/calendar
FIGURA 04: Tela do atépassar. Fonte: http://atepassarconcursos.com.br/
FIGURA 05: Tela do Schoolbinder. Fonte: http://www.myschoolbinder.com/
FIGURA 06: Tela do Doodle. Fonte: http://doodle.com/
FIGURA 07: Tela do rememberthemilk. Fonte: www.rememberthemilk.com/
LISTA DE TABELAS
TABELA 01: Síntese das variáveis/características que interferem na aprendizagem
autorregulada. (Veiga Simão, 2006)
TABELA 02: Parâmetros de apoio para os estudantes autorregulados (Melo, 2010).
TABELA 03: Tabela de critérios versus competidores.
TABELA 04 – Tabela com as necessidades identificadas, referentes à Atividade 01.
TABELA 05 – Tabela com as necessidades identificadas, referentes à Atividade 02.
TABELA 06 – Tabela com as necessidades identificadas, referentes à Atividade 03.
TABELA 07 – Tabela com as necessidades identificadas, referentes à Atividade 04.
TABELA 08 – Tabela com as necessidades identificadas, referentes à Atividade 05.
TABELA 09 – Tabela com as necessidades identificadas, referentes à Atividade 06.
RESUMO
Ao participar de formações presenciais ou à distância, alunos encontram
dificuldades para organizar ou autorregular seu próprio aprendizado. Neste
trabalho, adotamos práticas do Design de Interação para conceber interfaces que
ajudem os alunos a declarar e monitorar suas metas de aprendizagem. Os
resultados obtidos apontam para uma complexidade da tarefa e rebuscadas
interfaces de mediação. Após a revisão teórica, foram elicitados requisitos que
tentam introduzir os benefícios da autorregulação da aprendizagem em um
ambiente virtual de aprendizado colaborativo.
10
Capítulo 1_INTRODUÇÃO
Segundo Zimmerman (Zimmerman, 2002), há um consenso de que todos
os estudantes podem ser treinados a tornarem-se mais autorregulados em seus
processos de aprendizagem. Estratégias cognitivas como repetição, organização,
elaboração, planejamento e auto-monitoramento são decisivas na aquisição de
conhecimento. É possível o estudante vir a si próprio como agente de seu
comportamento e acreditar que o aprendizado é um processo pró-ativo e, a partir
daí, ser capaz de alcançar os resultados esperados.
Numa era de muitas opções de divertimento e distração, música, TV, celular
e internet, grande parte dos estudantes não tem nenhuma estratégia específica de
estudo, não planeja horários e não define metas para eles próprios, seguindo
apenas padrões vagos de auto-avaliação que não tem precisão para melhorar seu
desempenho acadêmico. Apesar disso, eles não procuram ajuda para não
parecerem “pouco inteligentes” nem tão pouco material suplementar para ajudá-
los porque “já tem muita coisa para estudar”. Eles ficam angustiados com os
“estudos de última hora” e tem pouca auto-confiança de se sair bem nas
avaliações (Zimmerman, 2002).
Pesquisas na área de educação têm analisado estudantes como esses e
tentado desenvolver processos nos quais eles podem ser ajudados. Definir metas
e estratégias de estudo, gerenciar o tempo, exercitar a auto-avaliação e auto-
motivação, procurar ajuda e demonstrar interesse pela tarefa, estes são
considerados pontos-chaves na aquisição de conhecimento e conseqüentemente
no bom desempenho dos estudantes (Zimmerman, 2002).
Nos últimos anos, as pesquisas mostram claramente como a
autorregulação pode levar ao sucesso acadêmico, porém, poucos professores
11
atualmente tentam preparar seus alunos para aprender a aprender. Dentro deste
ambiente, o que se vê é um ritmo acelerado de avanços tecnológicos e sociais. Os
dispositivos móveis vem se popularizando cada vez mais e, neste cenário, as
universidades e centros de pesquisa do país e do mundo tem procurado se
esforçar em busca de inovações e melhorias para o processo de aprendizado
(Albuquerque, 2010). As tecnologias de computação móvel se encontram em
franca evolução, a computação está se tornando cada vez mais ubíqua e
pervasiva (Myers e Beigl, 2003). O uso de redes sociais nesses aparelhos tem
crescido substancialmente. Professores e estudantes estão começando a explorar
o potencial dos blogs, sites de compartilhamento de mídia e redes sociais de
terceiros, apesar de eles não terem sido concebidos propriamente para fins
educacionais. São eminentes os potenciais benefícios educacionais desses
sistemas, apesar de todo esse potencial ainda não ser explorado. Isso ainda
depende do quão fácil as comunidades incorporam esses benefícios em suas
práticas educacionais (Zimmerman, 2002).
A partir deste contexto este trabalho se propõe a realizar um primeiro
esforço para conceber uma ferramenta de apoio ao processo de autorregulação
que adota a internet e aplicação para dispositivos móveis como plataforma.
Como método de design, foi definido o seguinte processo:
1. Análise dos requisitos a partir da literatura sobre o fenômeno de
autorregulação da aprendizagem.
2. Elaboração de cenários futuros com soluções a partir dos cenários
atuais da rede social REDU.
3. Idealização e elicitação de requisitos a partir dos cenários criados.
12
Capítulo 2_ESTADO DA ARTE
2.1 Motivação
Nos últimos anos, pesquisas tem mostrado o crescimento do uso das redes
sociais entre os jovens. Estas pesquisas demonstram que os usuários dessas
redes dedicam um tempo considerável neste ambiente. Eles passam horas
compartilhando textos, músicas, vídeos e fotos. Segundo Melo (Melo, 2010),
aproximadamente 60% dos usuários de redes sociais nos Estados Unidos já leu
alguma discussão relacionada à educação no ambiente dessas redes. Por outro
lado, tem-se observado o avanço da tecnologia pessoal e a utilização de
dispositivos móveis com os mais diversos propósitos, desde o simples acesso a
redes sociais até o uso com objetivos educativos. Ao mesmo tempo, várias
pesquisas mostram o potencial promissor da autorregulação da aprendizagem.
Este contexto nos leva a questões como: de que forma as redes sociais podem
ajudar os estudantes a se tornarem autorregulados? Como aproveitar o potencial
das redes sociais e dos dispositivos móveis na educação?
2.2 Autorregulação da aprendizagem
O termo autorregulação da aprendizagem é definido como o processo em
que os sujeitos estabelecem objetivos e desenvolvem estratégias para alcançá-
los, possibilitando que a aprendizagem aconteça de forma mais efetiva (Veiga,
2004a). Para isto, é preciso que a aprendizagem se fundamente na reflexão
consciente e na compreensão do significado dos problemas que surgem,
13
decidindo as ações numa espécie de diálogo consigo mesmo. Ela é fator com
potencial determinante para atuação dos educadores, sejam eles profissionais que
atuam com alunos da escola básica, acadêmicos ou estudantes-trabalhadores já
inseridos no mercado de trabalho. Atualmente, é grande o investimento que as
organizações fazem para que as pessoas estejam atualizadas e se mantenham
constantemente aprendendo (Frisson, 2007).
2.2.1 Aprendizado
Durante muito tempo, as investigações no que diz respeito à aprendizagem
se concentravam nos fatores cognitivos e motivacionais como os mais importantes
do sucesso escolar, porém, a partir dos anos 70, um terceiro fator tem sido
também levado em consideração nas pesquisas, os processos metacognitivos que
coordenam as aptidões cognitivas envolvidas na memória, leitura e compreensão
de textos (Ribeiro, 2002). Com a falta de bons resultados em alguns estudos que
focavam apenas nos aspectos cognitivos do aprendizado e com o objetivo de
promover o uso de estratégias ou mudanças nas técnicas já utilizadas, alguns
autores chegaram à conclusão de que os alunos com melhores resultados
escolares são mais aptos tanto na utilização de estratégias cognitivas como
também na regulação do seu processo cognitivo (metacognição), ou seja,
observou-se que os estudantes eficientes na execução de tarefas acadêmicas
possuíam também capacidades metacognitivas bem desenvolvidas, pois
mostraram compreender bem a finalidade da tarefa e planejar sua realização.
(Zimmerman, 2002)
2.2.2 Metacognição
Apesar de sua reconhecida importância, não existe uma definição precisa
de metacognição na literatura. John Flavell (Flavell, 1979), um dos primeiros
pesquisadores da área, definiu da seguinte maneira:
14
Em qualquer tipo de transação cognitiva com um ambiente humano ou não-
humano, podem ocorrer uma série de atividades de processamento de informação.
Metacognição refere entre outras coisas, ao monitoramento ativo e conseqüente
regulação e orquestração de processos em relação aos objetos cognitivos ou
dados sobre os quais eles atuam, geralmente a serviço de alguma meta concreta
ou objetivo. (Flavell, 1979. p232)
A metacognição diz respeito, entre outras coisas, ao conhecimento do
próprio conhecimento, a avaliação, a regulação e a organização dos próprios
processos cognitivos. Ela desempenha um papel importante na comunicação,
compreensão de leitura, aquisição de linguagem, atenção, autocontrole, memória,
auto-instrução, escrita, resolução de problemas e desenvolvimento da
personalidade (Flavell, 1979). Há também evidências de que habilidades
metacognitivas diferenciam os estudantes com alta capacidade de aprendizado
dos estudantes considerados iniciantes nesse quesito (Kruger and Dunning,
1999). Geralmente o “aprendiz iniciante” não avalia bem sua própria compreensão
principalmente porque eles ficam apressados em alcançar os objetivos enquanto
que o “aprendiz experiente” reflete e avalia a necessidade de revisar antes de
avançar mais na direção da meta estipulada. Os estudantes que demonstram uma
vasta aptidão em capacidades metacognitivas acabam por obter resultados
melhores na realização de tarefas ou exames. Eles são considerados
autorregulados porque estão continuamente mudando as estratégias de estudo e
aprendizado baseados no autoconhecimento de suas competências para garantir
o sucesso na realização das metas. As fases implícitas na teoria da
autorregulação devem estar presentes na atuação do professor, que deverá
considerar três variáveis determinantes: cognitivo/metacognitivo, motivacional e
contextual. Essa teoria, por ser um sistema auto-organizador, dirige e estimula a
ação, para que o estudante alcance uma meta pretendida por ele próprio ou,
também, poderá ser sugerida/mediada por alguém que tenha participação no
processo, neste caso o professor, e que, no decorrer do percurso, envolva
necessariamente cognições/metacognições, emoções e motivações (Tabela 01).
15
COGNITIVA E METACOGNITIVA
MOTIVAÇÃO CONTEXTO COMPORTAMENTO
Estratégias cognitivas que o sujeito pode
utilizar para aprender e completar as tarefas e
as estratégias metacognitivas
destinadas à controlar e regular a cognição.
Convicções que o sujeito tem em relação à tarefa.
O interesse que a mesma desperta, a
reação face esta tarefa, as estratégias que utiliza para controlar e regular seu afeto e motivação.
Contexto, tanto físico como
social, onde a aprendizagem
acontece.
Estratégias que o sujeito despende com a volição, o esforço, a persistência e a procura de ajuda na
realização da tarefa.
TABELA 01: Síntese das variáveis/características que interferem na aprendizagem autorregulada
(Veiga Simão, 2006)
2.2.2.1 Autorregulação: aspectos teóricos
Autorregulação do aprendizado é um tipo de estratégia metacognitiva e se
refere ao grau com o que os estudantes são capazes de metacognitivamente,
motivacionalmente e comportamentalmente participar de seus próprios processos
de aprendizagem. (Zimmerman,1989). Autorregulação não é uma habilidade
mental ou acadêmica, ao invés disso, ela é um processo diretivo pelo qual os
estudantes transformam suas habilidades mentais em habilidades acadêmicas
(Zimmerman, 2002). Tudo isso traz à tona questões como: de que maneira um
processo de aprendizado específico feito pelo estudante envolve
autoconhecimento e motivação? Como ele pode combinar esses e outros
elementos para se tornar um estudante autorregulado?
A psicologia social do aprendizado enxerga a estrutura do processo
autorregulatório em três fases cíclicas como mostra a figura 01.
16
FIGURA 01: Fases do Processo de Auto-Regulação da Aprendizagem (Zimmerman, 2002)
Para explicar resumidamente o modelo de Zimmerman: na fase de
conhecimento prévio estão embutidos os processos, as convicções motivacionais
pessoais na qual o estudante acredita que terá bons resultados, que realizará bem
sua tarefa ao definir metas com o objetivo de resolver problemas e progredir ainda
FASE DE PERFORMANCE
Auto-controle
Imagem Auto-instrução
Estratégias de Tarefas
Auto-observação
Auto-gravação
Auto-experimentação
FASE DE AUTO-REFLEXÃO
Auto-julgamento
Auto-avaliação Atribuição Casual
Auto-reação
Auto-satisfação/afeto Adaptativo/Defensivo
FASE DE CONHECIMENTO
PRÉVIO
Análise de Tarefas
Definição de metas Planejamento de
estratégias
Auto-motivação Auto-eficácia
Expectativas de resultados
Interesses/valores intrínsecos
Orientação para meta de aprendizagem
17
mais. Portanto, nesta etapa são desenvolvidas estratégias de atitude a partir das
propostas firmadas. A fase da execução, ou de performance, engloba os
processos que ocorrem durante as atividades propostas e o esforço colocado no
decorrer dos estudos, levando em consideração, no percurso de concretização da
tarefa, o autocontrole e o auto-monitoramento. A última fase, a „auto-reflexão‟
refere-se ao estudante rever o caminho percorrido, uma vez que a aprendizagem
é um processo contínuo, que requer esforço e atividade constantes (Frisson,
2007).
2.2.2.2 Autorregulação on line
No contexto da autorregulação em sistemas computacionais, existem
estudos demonstrando que a autorregulação pode ser promovida diretamente com
instruções dadas pelo professor em sala de aula e também através de sistemas
web (Kitsantas and Dabbarg, 2004, Azevedo and Hadwin, 2005; Narciss et al.,
2007). Entre as principais vantagens de um modelo de autorregulação online está
a possibilidade de adaptar esses sistemas às necessidades de cada tipo de
estudante e oferecer serviços mais individualizados (Melo, 2010). Além disso, o
aprendizado online é muito baseado na interação textual e leva o estudante a
refletir sobre o conteúdo e o processo de aprendizado (Dettore and Persico, 2008).
2.2.2.3 Redes Sociais e Autorregulação
Redes Sociais são constituídas por pessoas ou organizações e
relacionamentos entre elas em um certo domínio (Liccardi, 2007). Dentro deste
ambiente, é possível que vários indivíduos possuam metas comuns e
compartilhem determinado conjunto de atividades. Estas redes promovem
colaboração entre os seus participantes, além de possuir a característica de
encorajar as pessoas a se engajarem em aprender colaborativamente. Cassio
Melo (Melo, 2010) apresenta um conjunto de apoios aos estudantes para auxiliá-
18
los na aprendizagem com autorregulação visando o aprendizado colaborativo em
redes sociais online. Esses apoios relacionam um item de aprendizagem
autorregulada com um ou mais processos conforme ilustrado na tabela 02. Alguns
destes elementos aparecem relacionados às necessidades dos usuários
identificadas a partir dos cenários construídos posteriormente neste documento.
TABELA 02: Parâmetros de apoio para os estudantes autorregulados (Melo, 2010).
AUTO-REGULAÇÃO DO APRENDIZADO
ITEM PROCESSO APOIO AO ESTUDANTE
Que conhecimento prévio eu tenho que pode me ajudar com esta tarefa em particular?
Estabelecimento de metas Instruções de tarefas; Recursos auxiliares
Em que direção eu quero ser levado pelo meu pensamento?
Estratégia de tarefas Objetivos de aprendizado pessoais; Resultado esperado
Por que estou fazendo isto? Estabelecimento de metas Instruções de tarefas; Metas de Tarefas; Avaliação de competência
Quanto tempo tenho para completar esta tarefa?
Planejamento e Gerenciamento de tempo
Planejamento de Tarefas; Tempo estimado para conclusão; Cronômetro
Como estou executando esta tarefa?
Auto-monitoração Feedback constante sobre o progresso do usuário; Feedback do Grupo ; Comparativos sociais
Estou no caminho certo? Auto-monitoração Feedback formativo; Gráfico de performance
Como devo proceder? Seleção de estratégias Instruções de tarefas; Auxílio contextual
Quais são as recompensas em fazer isto?
Auto-motivação Mecanismo de recompensa; Comparativo social
Como me saí? Auto-avaliação Gráfico de performance; Resultado esperado; Comparativo social
Devo ajustar o passo dependendo das dificuldades?
Planejamento e Gerenciamento de tempo
Instruções de tarefas; Tempo estimado para conclusão
Quem está fazendo algo que possa me interessar?
Informação disponível para o Grupo
Fluxo de atividades; Blogging; Comparativo Social
Quais são os recursos importantes para fazer isso?
Variáveis referentes à tarefas. Variáveis referentes à pessoas
Recursos Auxiliares; Fluxo de Atividades; Fórum
19
Capítulo 3_MÉTODO
3.1 Objetivo Geral
Elicitar os requisitos iniciais para estilos de interação em plataforma Internet
e dispositivos móveis de um sistema de autorregulação da aprendizagem.
3.2 Objetivos específicos
Identificar as necessidades iniciais de usuários nos fenômenos de
autorregulação da aprendizagem;
Descrever ações e práticas do fenômeno de autorregulação da
aprendizagem;
Criar cenários de uso para identificação de requisitos para o sistema de
autorregulação da aprendizagem.
3.3 Cenários
As pessoas geralmente compreendem, com maior facilidade exemplos
retirados da vida real do que descrições abstratas. Elas podem entender e criticar
um cenário de como poderiam interagir com um sistema de software (Sommerville,
2007). Cenários na área de Interação Humano-Computador ajudam a entender e
criar sistemas computacionais que sirvam como artefatos mediadores da atividade
humana (Carroll, 2000a). Os engenheiros de requisitos podem utilizar as
informações obtidas com a observação dos cenários para formular os requisitos
reais de sistema de software (Sommerville, 2007).
20
Cenários são histórias passadas ou futuras sobre pessoas e suas
atividades, as quais permitem raciocinar sobre situações de uso de um artefato
mesmo antes destas situações acontecerem (Carroll, 2000). Estas histórias são
descrições narrativas informais. Cenários, atualmente vem sendo muito utilizados
no projeto e desenvolvimento de artefatos tecnológicos e aplicações
computacionais. Eles podem ser particularmente úteis para acrescentar detalhes a
um esboço da descrição de requisitos sendo estas descrições exemplos de
sessões de interação. Cada um deles aborda um ou um pequeno número de
possíveis interações (Sommerville, 2007). Eles podem mesmo ser usados como o
ponto de partida para projetos, descrevendo necessidades e inspirando projetistas
a satisfazê-las (o que provocaria a criação de novos cenários, agora com as
soluções futuras criadas e embutidas).
O uso de cenários permite que os projetistas tenham idéias e também
podem facilitar a comunicação entre usuários e projetistas (por sua linguagem
simples e informal) (Bødker, 2000).
Segundo Carroll (Carroll, 2000), os elementos característicos de um cenário
são:
• AMBIENTE (setting) - estabelece-se um estado inicial do ambiente onde a
atividade descrita se desenrola: alem de identificar as pessoas presentes,
caracteriza-se o ambiente fisicamente.
• ATORES OU AGENTES - aqueles que participam do episódio descrito.
Pode haver vários agentes e cada um possui objetivos. Em um cenário, é preciso
haver pelo menos um agente, com um objetivo.
•ROTEIRO (plot) - sequência de ações e eventos, representando o que os
atores fazem durante todo o episódio, o que lhes acontece e que mudanças
ocorrem no ambiente.
Os eventos descritos nos cenários podem obstruir, facilitar ou ser
irrelevantes para os objetivos dos atores.
21
3.4 Procedimentos
A seguir, serão mostrados os procedimentos de como o trabalho foi
desenvolvido. O referencial teórico em que o trabalho se baseou foi a construção
de cenários, conforme descrito na seção anterior.
Inicialmente foram construídos os cenários de acordo com a situação atual
dos usuários da plataforma REDU. A partir destes, foram identificados os
problemas e as necessidades dos usuários e foi construída uma tabela na qual as
necessidades correspondentes a cada fase da atividade são mostradas, a tabela
de necessidades dos usuários (Kujala et al., 2001).
Os cenários montados, ressaltados pelas tabelas de necessidades,
geraram a inspiraçã0 a elicitação de requisitos que pudessem encaixar-se nas
atividades. Os requisitos encontrados tentam introduzir as vantagens do uso da
autorregulação da aprendizagem dentro do ambiente educacional oferecido pela
plataforma REDU. Os requisitos foram elicitados, construindo-se três tipos de
cenários futuros. O primeiro teve a intenção de fornecer uma visão geral do
funcionamento e utilização do sistema REDU na realização de algumas atividades
da forma como está atualmente em funcionamento.
Além deste cenário futuro “padrão”, foram gerados dois outros tipos de
cenários futuros: os cenários caricaturados, positivos e negativos (Bødker, 2000).
A função dos cenários caricaturados é levar aos extremos as situações de uso dos
produtos. O cenário positivo ilustra uma situação perfeita em que acontece dentro
do esperado. Enquanto isso o cenário negativo enfatiza todos os possíveis
problemas que podem vir a acontecer. Neste trabalho, os cenários caricaturados
foram importantes para a elicitação de diversos requisitos funcionais e não-
funcionais do sistema, possibilitando seguir ao próximo passo: a descrição dos
mesmos.
22
3.5 Resultados
3.5.1 Comparação com sistemas similares
Nesta seção, serão apresentados alguns sistemas similares que podem ser
encontrados na internet. Estes produtos têm funcionalidades que fomentam, de
alguma forma, a autorregulação da aprendizagem. Os sistemas Google Calendar
e Doodle foram considerados por disponibilizar os serviços de alerta e
monitoramento que podem contribuir com aspectos metacognitivos mencionados
no capítulo 2, mesmo não tendo sido construídos a priori com propósitos
educacionais. Para comparação foram estabelecidos os critérios de avaliação
listados abaixo:
1. Declaração de metas
2. Alertas
3. Visualização do plano de estudo
4. Ajuste de metas
5. Colaboração
6. Integração com dispositivos móveis
3.5.1.1 QOrganizer
É uma ferramenta “stand-alone” consequentemente, não oferece
ferramentas de colaboração. Permite o agendamento de eventos com a opção de
notificação com antecedência configurável. Os dados podem ser guardados em
arquivos de texto ou em um banco de dados mySQL. Permite ainda que os dados
sejam importados para outro computador utilizando o protocolo FTP.
23
FIGURA 02: Tela do qOrganizer.Fonte: http://qorganizer.sourceforge.net/
3.5.1.2 Google Calendar
Não foi concebido como sistema de apoio à educação e sim, com um
propósito mais geral. Apesar disto, pode ser utilizado como ferramenta de suporte
à autorregulação, pois oferece recursos que permitem realizar planejamento e
ajuste feitos pelo próprio usuário. Apesar de estar integrado a uma rede social,
não há estímulo à colaboração na sua interface. Possui a vantagem de já estar
integrado com diversas plataformas de dispositivos móveis utilizados em larga
escala.
24
FIGURA 03: Tela do Google Calendar. Fonte: www.google.com/calendar
3.5.1.3 atépassar
Voltado para estudantes que vão prestar concursos públicos. Oferece
opções de planejamento, monitoração, ajuste e colaboração bem desenvolvidos.
Como apoio ao auto-monitoramento, possui gráficos que relacionam as metas
alcançadas com as declaradas. A interação com outros usuários do sistema é
simples e funcional, com fóruns de discussão e mural de perguntas e respostas.
Até o presente momento, não possui versão para qualquer plataforma de
dispositivo móvel.
FIGURA 04: Tela do atépassar. Fonte: http://atepassarconcursos.com.br/
3.5.1.4 SchoolBinder
Um software criado para fins educacionais. Permite definição de metas
globais e parciais com gráficos que facilitam o auto-monitoramento. O sistema
inclui ainda fóruns de discussão, chat ao vivo, compartilhamento de arquivos e
serviço de notificação via SMS.
25
FIGURA 05: Tela do Schoolbinder. Fonte: http://www.myschoolbinder.com/
3.5.1.5 Doodle
Aplicativo semelhante ao Google Calendar, podendo inclusive ser integrado
com este. É um software de uso geral cujo sistema inclui opções de agendamento
e alerta, sincronização com dispositivos móveis e criação de enquetes.
FIGURA 06: Tela do Doodle. Fonte: http://doodle.com/
26
3.5.1.6 rememberthemilk
É um sistema de gerenciamento de tarefas. Um software voltado para fins
educacionais, pessoais e profissionais, permite ainda gerenciar e monitorar metas.
Não oferece gráficos de desempenho, nem há possibilidade de colaboração numa
rede social. O software também está disponível em diversas plataformas móveis
como Android, IOS (Sistema operacional dos dispositivos móveis da Apple) e
Blackberry.
FIGURA 07: Tela do rememberthemilk. Fonte: www.rememberthemilk.com/
A tabela abaixo mostra um resumo das características destes softwares em
relação aos critérios adotados.
TABELA 03: Tabela de critérios versus competidores.
27
3.5.2 Personas e cenários
A partir da revisão de literatura, identificamos que nos fenômenos de
autorregulação de aprendizagem ocorrem inúmeras ações. Para a elaboração
deste estudo foram selecionadas as atividades relacionadas abaixo.
Atividade 1: Professor cria o calendário de aulas de um curso.
Atividade 2: Aluno estima e declara horário de estudo.
Atividade 3: Aluno usa algum recurso.
Atividade 4: Professor monitora as atividades dos alunos.
Atividade 5: Aluno monitora e ajusta seu próprio desempenho.
Atividade 6: Sincronização com o aplicativo Android.
Os diagramas de caso de uso referentes a cada atividade, encontram-se
demonstrados no apêndice deste trabalho.
3.5.2.1 Contexto e personas
Todos os cenários a seguir correspondem a um contexto de uso no qual um
professor e uma turma de alunos do ensino superior realizam atividades de
planejamento e autorregulação da aprendizagem. Personas são os personagens
que interagem com o sistema (Bødker, 2000). Neste contexto, criamos dois
professores hipotéticos: Pablo Artigas e Júlio Bandeira, e dois alunos: João da
Silva e Perez. Pablo é um professor que tem pouquíssima experiência com
Internet e não gosta de usar celular, rejeita o uso de tecnologias o quanto pode.
Trata-se de uma disciplina de um segundo período da graduação em
Administração de uma faculdade privada de nome Ribeirão. Quando do início dos
cenários, o Professor Júlio já está cadastrado no Sistema REDU, assim como
todos os seus alunos. O curso de Administração já tem seu espaço criado na
mesma plataforma, pois ele já está no segundo semestre. Estamos iniciando o
período letivo nos cenários a seguir, o professor está ajustando os materiais e a
28
agenda do curso. Veremos cenários que se estendem no tempo por
aproximadamente 15 dias a partir do planejamento inicial do professor para
mostrar como a agenda é usada para planejar e servir de instrumento à
autorregulação. Para a análise do ponto de vista do estudante, os personagens
terão as seguintes características: o primeiro, João da Silva, tem acesso à Internet
em casa e seu celular usa o SO (Sistema Operacional) Android, o segundo,
Perez, utiliza apenas a Internet na Faculdade Ribeirão. Seu celular não possui SO
Android, mas recebe SMS.
3.5.3 Atividade 1: Professor cria o calendário de aulas de um curso
3.5.3.1 Descrição da Atividade
Ambiente:
Sala dos professores da Faculdade Ribeirão.
Roteiro:
O professor poderá planejar um curso em aulas dentro da plataforma
REDU. Com o planejamento, ficarão disponíveis para os alunos o conteúdo da
disciplina e as datas com os eventos agendados pelo professor. Será possível
ainda determinar o cronograma com as datas sugeridas para cada módulo e sua
ementa. Os recursos incluídos irão sugerir o esforço em horas de estudo e a forma
de avaliação.
3.5.3.2 Cenário Atual
No roteiro deste cenário, estão referenciadas as necessidades dos
usuários, aqui denominadas NEC‟s, identificadas e mostradas na Tabela 04, na
Seção 3.5.3.3.
29
Atores:
Alunos e professores.
Roteiro
O professor efetua login no sistema REDU e cadastra um curso em um
determinado ambiente de ensino. Não é possível planejar a agenda da
disciplina estudo [NEC 1.1], nem programar atividades que deverão ser
sugeridas para os alunos ao longo do tempo [NEC 1.2]. O Professor pode
cadastrar recursos e publicar no mural da disciplina. Os alunos não são
notificados das publicações feitas pelo professor [NEC 1.3].
3.5.3.3 Necessidades do Usuário (Kujala et al., 2001)
São mostradas na tabela 04, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.3.2.
AÇÕES PROBLEMAS E POSSIBILIDADES
O professor planeja um curso em aulas
[NEC 1.1] O professor não tem a opção de
publicar a agenda da disciplina
[NEC 1.2] Não é possível programar atividades
para os alunos numa agenda
[NEC 1.3] Alunos não são notificados do
planejamento do professor
TABELA 04 – Tabela com as necessidades identificadas, referentes à Atividade 01.
3.5.3.4 Cenário futuro com a solução
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários mostradas na Tabela 04, na Seção 3.5.3.3. Quando uma dessas
necessidades é mostrada no texto, demonstra que tal necessidade está sendo
atendida.
30
Atores:
Alunos e professores.
Roteiro:
O professor Júlio cria uma nova disciplina a ser oferecida no curso de
Administração. Dentro das opções o professor inclui os módulos que
estruturam a seqüência do curso. Depois de organizar os módulos, ele
insere eventos na agenda da disciplina. A agenda é vinculada à mesma e
recebe o nome da sigla que foi atribuída quando da criação no REDU
[NEC-1.1]. Esta agenda é compartilhada com cada um dos alunos inscritos
na disciplina [NEC 1.2]. Se algum aluno for inscrito depois, ele também
passa a ter a agenda compartilhada. Em cada uma das entradas da
agenda, os campos sobre a mesma são preenchidos com o contexto onde
os materiais aparecem no REDU. O professor pode vincular um módulo à
uma entrada da agenda. Desta forma, o contexto é representado na
entrada da agenda por: ambiente, curso, disciplina e módulo [NEC-1.2]. Os
alunos inscritos no curso visualizam os dados inseridos pelo REDU na
entrada da agenda e ao clicar ele vai para o módulo correspondente [NEC-
1.2]. Assim, ele complementa o que o professor fez em sala de aula ou
realiza o que o professor de um curso à distancia está recomendando que
seja um módulo atual. Os alunos são notificados sobre cada modificação
feita pelo professor que por sua vez também receberá relatórios à medida
que os alunos visitam os conteúdos [NEC-1.3].
3.5.3.5 Cenários futuros caricaturados (Bødker, 2000)
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.3.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
31
Cenário positivo (plus scenario)
Roteiro:
O professor Júlio decide cadastrar a agenda da disciplina a ser ministrada
por ele naquele semestre [RF-1.1]. O item “Agenda” aparece no menu da
esquerda na página da disciplina. O docente preenche os campos em
seqüência de aulas informando dia e horário. A interface é a mesma do
Google Calendar. Todos os alunos matriculados tem suas contas do REDU
vinculados a uma conta GMail. Dessa forma, quando o professor conclui a
agenda do curso todos os alunos são automaticamente incluídos no
compartilhamento dessa agenda [RF-1.2]. Eles recebem a notificação de
que houve inclusão da agenda da disciplina [RF-1.3]. O professor é
habituado com essa agenda e tranquilamente relaciona todos os itens da
agenda. Ele completa a preparação da disciplina inserindo módulos e
material de apoio [RF-1.4]. Depois de finalizada a etapa de cadastro, o
professor confere na aba “Gerenciamento” o resumo da disciplina e convida
os alunos matriculados a participar do sistema REDU na opção “Membros”,
“Convidar Membros” [RF-1.5].
Cenário negativo (minus scenario)
Roteiro:
Pablo Artigas é alocado pela instituição de ensino para lecionar no curso de
Administração. O professor não é familiarizado com a interface do REDU
nem do Google Calendar. Ao preencher os campos de cadastro de uma
disciplina, ele não compreende a semântica apresentada. Ao abrir o
calendário de uma disciplina, o professor depara-se com a interface do
Google Calendar. Ele não entende que para inserir um horário ele deve
arrastar o mouse sobre a área do Calendário. Ele tenta inserir um evento no
calendário e depois de algumas tentativas ele consegue. No entanto, ele
não percebe que essa agenda será vista pelos alunos e nem sabe como
eles irão ver a mesma [RF-1.6]. Ele não percebe que pode incluir desde o
início do ano uma grande quantidade de eventos ou aulas na agenda e se
32
desmotiva deixando para depois. Depois disso, o professor convida os
alunos a participar do REDU para ter acesso à Agenda do curso e os
recursos. A maioria dos alunos não adere ao sistema e o curso segue da
maneira tradicional. Dias depois, já com o curso em andamento, o professor
decide retomar o planejamento e completa a agenda da disciplina [RF-1.7].
Apesar de receber a notificação de alteração da agenda, os alunos não
verificam de que se trata.
3.5.3.6 Requisitos do Produto
Requisitos funcionais:
[RF 1.1] Cadastrar agenda de uma disciplina: O sistema deve possibilitar o
cadastramento da agenda de uma disciplina. Automaticamente uma agenda do
Google Calendar deverá ser gerada e compartilhada com os alunos inscritos na
disciplina.
[RF 1.2] Compartilhar agenda com alunos: A agenda, ao ser cadastrada
pelo professor, deverá permitir sua visualização por todos os alunos inscritos na
mesma.
[RF 1.3] Notificar aluno: O sistema deverá notificar todos os alunos inscritos
na disciplina que houve inclusão, modificação ou remoção na agenda, além disso,
o convite feito pelo professor para participar da disciplina. As notificações deverão
ser feitas através do sistema REDU-móvel no sistema Android. Ou mensagem
SMS para quem não possuir tal sistema.
[RF 1.4] Cadastrar recurso: O sistema deverá permitir ao professor o
cadastro de recursos a serem utilizados pelos alunos inscritos na disciplina.
Recursos podem ser documentos de texto, vídeos, áudios ou links.
[RF 1.5] Convidar aluno: O sistema deverá permitir que o professor convide
alunos para a disciplina. Os alunos já deverão estar cadastrados no REDU. Ao
aceitarem o convite os alunos tem acesso automático a agenda da disciplina
[RF 1.6] Visualizar agenda: O sistema deverá possibilitar a visualização da
agenda cadastrada pelo professor. Os alunos podem ver agenda mas não podem
33
alterá-la. O professor deverá poder visualizar como a agenda será vista pelos
alunos.
[RF 1.7] Editar agenda: O sistema deverá permitir que o professor faça
modificações na agenda como incluir, alterar e remover entradas. Os alunos não
poderão fazer modificação na agenda da disciplina.
Requisitos não-funcionais:
[RNF 1.1] Plataforma Android: A parte do módulo do dispositivo móvel,
deverá ser implementada na plataforma Android de desenvolvimento.
[RNF 1.2] Plataforma Android: O sistema deverá ter agenda integrada ao
Google Calendar.
3.5.4 Atividade 2: Aluno estima e declara horário de estudo
3.5.4.1 Descrição da Atividade
Ambiente:
Aluno João da Silva na Faculdade Ribeirão estimando seu plano de estudo
para a semana.
Roteiro:
O aluno cadastrado no sistema REDU poderá definir um horário de estudo.
Neste horário, o mesmo aluno poderá propor metas de dedicação a serem
cumpridas por ele próprio. O sistema deverá notificar o aluno a cada evento
agendado com antecedência configurável pelo aluno, além disso, o aluno
inscrito em um curso poderá combinar sua agenda pessoal com a do curso
definida pelo professor.
34
3.5.4.2 Cenário Atual
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários identificadas e mostradas na Tabela 05, na Seção 3.5.4.3.
Atores:
Alunos e professores.
Roteiro:
No cenário atual da plataforma REDU não há funcionalidade que ofereça o
serviço de gerenciamento de tempo do aluno, tendo o mesmo que recorrer
a instrumentos externos.
3.5.4.3 Necessidades do Usuário (Kujala et al., 2001)
São mostradas na Tabela 05, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.4.2.
AÇÕES PROBLEMAS E POSSIBILIDADES
O aluno estima um horário de estudo
[NEC 2.1] Não existe a funcionalidade atualmente. O aluno teria que buscar em algum instrumento externo.
O aluno define o horário de estudo
[NEC 2.2] Não existe a funcionalidade atualmente. O aluno teria que buscar em algum instrumento externo.
O aluno estuda no horário pré-determinado.
[NEC 2.3] O aluno necessita perceber que está no horário que ele mesmo propôs a se dedicar àquela disciplina.
TABELA 05 – Tabela com as necessidades identificadas, referentes à Atividade 02.
3.5.4.4 Cenário futuro com a solução
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários mostradas na Tabela 05, na Seção 3.5.4.3. Quando uma dessas
35
necessidades é mostrada no texto, demonstra que tal necessidade está sendo
atendida.
Atores:
Alunos e professores.
Roteiro:
João da Silva decide usar a plataforma para organizar [NEC-2.1] seu tempo
naquele semestre. Inicialmente através do sistema de busca do site, ele
encontra as matérias nas quais ele deseja se inscrever. Depois da
confirmação dos moderadores dos cursos, o aluno já pode visualizar o
cronograma das matérias na opção “Calendário”. Ao tomar ciência do
horário das aulas, o aluno planeja seu horário de estudo, especificando o
tempo dedicado à cada disciplina [NEC-2.2] disponibilizando mais tempo às
que ele considera mais difíceis. Durante o semestre o aluno segue o
planejamento, as notificações dos eventos [NEC-2.3] o ajudam a não
esquecer os trabalhos e provas nem mesmo o material a ser estudado
regularmente.
3.5.4.5 Cenários futuros caricaturados (Bødker, 2000)
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.4.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
Cenário positivo (plus scenario)
Roteiro:
O aluno João da Silva olha a agenda criada pelo Professor Júlio na visão
de semana. Ele tem uma boa visão das atividades que ocorrerão ao longo
do período, na Faculdade e em casa. Neste horário o mesmo aluno poderá
propor [RF-2.1] um conjunto de metas de dedicação a serem cumpridas por
36
ele próprio associadas à disciplina escolhida. Ele então começa a definir
seu horário de estudo. Ao inserir horários de estudo na agenda da
disciplina, o sistema REDU compila o total de horas que foram alocadas e
associa [RF-2.2] esse total a uma meta a ser realizada no período. O
Google Calendar notifica o aluno sobre cada evento com antecedência
configurável de forma padrão pelo aluno ou pelo professor, ao ajustar o
calendário da disciplina.
João abre o menu “Calendário”. Na visualização, aparecem as datas e
horários preenchidos conforme os cronogramas dos cursos nos quais o
aluno está inscrito e com agenda pré-definida pelos respectivos
professores. O calendário deverá ser interativo de modo que permita ao
aluno definir horários [RF-2.1] como no Google Calendar. No item „‟Metas‟‟
o aluno cadastra [RF-2.3] um grupo de objetivos associado a um dos cursos
que ele está inscrito preenchendo os campos “nome do grupo de objetivo” e
selecionando uma disciplina a ser vinculada. Depois o aluno declara metas
parciais no item “checkpoints”. Ao alcançar o dia de cada meta (parcial ou
principal) o sistema pede para o aluno informar sua auto-avaliação [RF-2.4]
em relação à meta vencida no link “Data limite alcançada” – “Informar
Desempenho” com um gráfico mostrando no tempo o quanto o aluno
progrediu em relação à meta estimada. O aluno visualiza seu progresso
[RF-2.5] no estudo no botão “Visualizar desempenho”, além disso, notifica o
aluno de cada checkpoint, meta [RF-2.6] ou horário de estudo [RF-2.7]
através de alerta nos ambientes web e celular com antecedência
configurável pelo aluno na seção “Calendário”.
Cenário negativo (minus scenario)
Roteiro:
O aluno Perez, incentivado pelo professor Júlio Bandeira, decide tentar
usar a plataforma REDU para organizar seu horário de estudo. O aluno,
que trabalha e estuda, já usa um sistema de gerenciamento de tempo
sugerido pela sua empresa. No entanto, este não está integrado ao REDU.
37
Mesmo assim, o aluno aceita utilizar o sistema. vai até a agenda de uma
disciplina e reserva um horário à noite para seu estudo. No campo de
anotações do evento da agenda, o sistema já coloca algum texto sobre as
características desse evento: ambiente, curso, disciplina e professor.
completa esse campo indicando quais livros e textos ele prevê estudar
nesse momento marcado. Como seu celular não tem a aplicação Android,
ele configura a agenda para enviar-lhe um SMS com 45 minutos de
antecedência do início de cada atividade agendada. No primeiro dia de
aula, há uma alteração do horário da monitoria. Porém, seu celular
descarregou minutos antes de ele receber a notificação [RF-2.8]. Ele sai às
pressas do trabalho mas, ao chegar, descobre que a aula foi cancelada.
Durante o semestre, o aluno se depara com diversos choques de horários
entre as duas agendas provocadas por horas extras exigidas pela empresa
empregadora do aluno [RF-2.9]. Não conseguindo cumprir algumas metas,
o aluno se irrita com o sistema de notificações e acaba por abandonar o
Calendário do REDU, optando por utilizar apenas o sistema previamente
conhecido.
3.5.4.6 Requisitos do Produto
Requisitos funcionais:
[RF 2.1] Cadastrar conjunto de metas: O Sistema deverá possibilitar que o
aluno crie um grupo de metas relacionado a uma disciplina.
[RF 2.2] Calcular meta principal: Ao definir o horário de estudo o sistema
calculará a quantidade total de horas determinadas pelo aluno.
[RF2.3] Declarar meta: O Sistema deverá possibilitar que o aluno crie uma
meta e a inclua em um grupo de metas previamente criado. No cadastro da meta o
aluno indica a data final e o número de horas dedicadas aquele item até esta data.
38
[RF 2.4] Informar auto-avaliação: O sistema deverá permitir que o aluno
indique sua auto-avaliação ao chegar à data limite de uma meta. As opções
deverão ser “Satisfatório”, “Regular” ou “Insatisfatório”.
[RF 2.5] Visualizar progresso: O Sistema deverá possibilitar ao aluno
visualizar o gráfico de seu progresso das metas cumpridas em comparação com
as declaradas por ele mesmo.
[RF 2.6] Notificar aluno de data limite de meta: Notificar aluno de horário de
estudo: O sistema deverá enviar notificação para o aluno nos ambientes Android e
Web de acordo com a antecedência configurada pelo aluno de que a data final
para cumprimento de uma meta determinada por ele chegou e que ele deve
informar ao sistema se foi cumprida ou não. O sistema deve oferecer também ao
aluno a possibilidade de informar auto avaliação para aquela meta.
[RF 2.7] Notificar aluno de horário de estudo: O sistema deverá enviar
notificação para o aluno nos ambientes Android e Web de acordo com a
antecedência configurada pelo aluno de que o mesmo agendou aquele horário de
estudo.
[RF 2.8] Informar notificação perdida: O sistema deverá notificar o aluno dos
eventos que aconteceram enquanto seu celular estava desligado.
[RF 2.9] Sugerir alteração de horário: O sistema devera sugerir ao aluno,
caso o mesmo não tenha confirmado que estudou no horário previsto, que ele
transfira clicando e arrastando aquele horário de estudo para outro ponto no
calendário.
Requisitos não-funcionais:
[RNF 2.1] Plataforma Android: A parte do módulo do dispositivo móvel,
deverá ser implementada na plataforma Android de desenvolvimento.
3.5.5 Atividade 3: Aluno usa algum recurso
39
3.5.5.1 Descrição da Atividade
Ambiente:
Aluno na escola/universidade - há uma mesa e um computador.
Roteiro:
O aluno João da Silva utiliza um recurso de apoio disponibilizado pelo
professor Júlio Bandeira. Quando a tela onde se encontra o material é vista
pelo João da Silva, o REDU apresenta uma opção „Contar tempo‟.
3.5.5.2 Cenário Atual
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários identificadas e mostradas na Tabela 06, na Seção 3.5.5.3.
Atores:
Alunos e professores.
Roteiro:
No cenário atual da plataforma REDU, o aluno tem acesso aos recursos
publicados no site pelo professor: vídeos, textos, notícias e eventos
bastando visitar os cursos nos quais ele está cadastrado. Após efetuar
login, o estudante tem no menu do lado esquerdo os ambientes de ensino
nos quais está cadastrado. Selecionado o ambiente, aparecem os cursos
vinculados a ele. Depois de escolher o curso, o material de apoio é exibido
ficando à disposição do aluno. O professor não fica sabendo se os alunos
tiveram ciência [NEC-3.1] [NEC-3.2] dos recursos publicados por ele e nem
quanto tempo dedicaram ao estudo [NEC-3.3], caso o tenham feito. O
REDU, no cenário atual, não tem a funcionalidade que permita ao professor
sugerir um tempo de estudo [NEC-3.4], nem os alunos informarem ao
professor que estão utilizando os recursos disponibilizados de forma
sistemática [NEC-3.5].
40
3.5.5.3 Necessidades do Usuário (Kujala et al., 2001)
São mostradas na Tabela 06, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.5.2.
AÇÕES PROBLEMAS E POSSIBILIDADES
O professor publica um recurso
[NEC 3.1] O professor não sabe se os alunos sabem que ele publicou o recurso [NEC 3.2] O aluno não sabe que o professor publicou um recurso. [NEC 3.3] O Professor não sabe quanto tempo o aluno se dedicou ao recurso [NEC 3.4] O Professor não pode sugerir o tempo a ser dedicado pelo aluno para um recurso publicado por ele
O aluno utiliza algum recurso
[NEC 3.5] O aluno não tem como declarar quanto tempo se dedicou ao recurso. [NEC 3.6] O professor não sabe se os alunos individualmente utilizaram o recurso.
TABELA 06 – Tabela com as necessidades identificadas, referentes à Atividade 03.
3.5.5.4 Cenário futuro com a solução
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários mostradas na Tabela 06, na Seção 3.5.5.3. Quando uma dessas
necessidades é mostrada no texto, demonstra que tal necessidade está sendo
atendida.
Atores:
Alunos e professores.
Roteiro:
O aluno João da Silva é notificado [NEC-3.2] da publicação de algum
recurso feita pelo professor. O aviso sugere um prazo máximo para que o
aluno consulte o arquivo e o tempo a dedicar àquele material [NEC-3.4].
41
Depois o aluno declara no sistema de quanto tempo foi essa dedicação
[NEC-3.5]. O professor é notificado de quando o aluno utilizou o recurso e
quanto tempo se dedicou ao mesmo [NEC-3.5] [NEC-3.6].
3.5.5.5 Cenários futuros caricaturados (Bødker, 2000)
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.5.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
Cenário positivo (plus scenario)
Roteiro:
O aluno João da Silva recebe em seu celular [RF-3.1] uma notificação de
que o professor publicou um vídeo no site da disciplina e com a
recomendação que o aluno assista antes da próxima aula. Como o aluno já
estava próximo ao computador e com tempo disponível, imediatamente ele
efetua login no sistema REDU. Ao visualizar a página principal, o aluno
observa [RF-3.2] em destaque os novos recursos que foram adicionados.
Clicando na mensagem, ele acede a lista [RF-3.3] de recursos da disciplina
publicados até então. Os itens em negrito são novos e há um novo vídeo
disponível para visualização. Ele assiste ao vídeo em sua totalidade e,
automaticamente, o sistema [RF-3.4] registra que aluno assistiu ao vídeo e
em quanto tempo ele o fez. O aluno posta, a seguir, um comentário no
“mural” da disciplina e gera uma série de discussões [RF-3.5]. Os alunos
que ainda não assistiram são notificados das diversas publicações no
“mural” e se sentem estimulados a também assistirem ao vídeo. Ao final, o
professor poderá ver [RF-3.6] o gráfico dos esforços investidos pelos alunos
individualmente ou em grupo. Se o aluno usar um material que não seja
vídeo ou áudio, como uma apostila ou um livro, ele pode registrar o horário
do início e término indicando o tempo que dedicou ao estudo clicando nos
42
botões „comecei a estudar‟ e „terminei de estudar‟ [RF-3.4]. Ele pode fazer
isso na interface principal do REDU ou na interface da aplicação Android.
Dessa forma ele pode criar uma memória dos esforços que fez para cada
uma das disciplinas.
Cenário negativo (minus scenario)
Roteiro:
O aluno Perez após a primeira quinzena de aulas percebe que se
esqueceu de verificar as notificações em sua conta REDU. Quando ele o
faz, encontra diversas atividades atrasadas acumuladas nesses dias [RF-
3.8]. Posteriormente ele se esforça para conseguir se recuperar das
atividades atrasadas e entra no sistema para informar que fez as
atividades que estava devendo [RF-3.9].
3.5.5.6 Requisitos do Produto:
Requisitos funcionais:
[RF 3.1] Notificar aluno da publicação de recurso: o sistema deverá notificar
o aluno quando o professor publicar algum recurso relativo à disciplina. A
notificação deverá informar também o tempo sugerido para que o estudante se
dedique àquele recurso.
[RF 3.2] Mostrar que novos recursos foram adicionados: o sistema (web)
deverá informar quando há recurso não lido logo após o estudante efetuar login
exibindo a mensagem “Você tem recursos não lidos”.
[RF 3.3] Listar todos os recursos publicados: O sistema deverá permitir que
o aluno aceda à lista de todos os recursos publicados relativos à disciplina
selecionada.
[RF 3.4] Registrar dedicação de aluno a recurso: o sistema deverá permitir
que o aluno informe sua dedicação a cada recurso proposto. Esta informação
deverá ser detectada automaticamente caso o recurso seja um arquivo de áudio
43
ou vídeo. No caso dos demais tipos de arquivo, o aluno informará o tempo
dedicado disparando a contagem a partir do início do estudo e parando ao
finalizar.
[RF 3.5] Notificar aluno que houve comentário sobre o que ele escreveu: o
sistema deverá notificar o aluno quando algum outro ator escrever um comentário
sobre algo que o aluno tenha publicado. Esta notificação deverá ser feita por e-
mail.
[RF 3.6] Visualizar gráfico Individual: O sistema devera produzir um gráfico
do esforço do aluno semana a semana e mês a mês. O esforço do aluno é obtido
a partir do somatório dos esforços declarados em cada tarefa realizada pelo aluno
dentro do período de tempo analisado.
[RF 3.7] Visualizar gráfico da turma: O sistema deverá produzir um gráfico
do esforço de todos os alunos semana a semana e mês a mês. O esforço da
turma é obtido a partir do somatório dos esforços declarados por todos os alunos
daquela turma em cada tarefa realizada por cada um dentro do período de tempo
analisado.
[RF 3.8] Notificar atraso: O sistema deverá notificar o aluno que ele não
cumpriu a tarefa proposta pelo professor no prazo especificado. Esta notificação
deverá ser recebida através de um aviso no celular e também deverá aparecer
uma mensagem na página principal na versão web.
[RF 3.9] Informar realização de tarefa atrasada: O sistema deverá permitir
que o aluno informe a realização de uma ou mais tarefas atrasadas. O aluno
poderá ainda informar o tempo dedicado à execução daquela tarefa.
Requisitos não-funcionais:
[RNF 3.1] Plataforma Android: A parte do módulo do dispositivo móvel,
deverá ser implementada na plataforma Android de desenvolvimento.
[RNF 1.2] Rodar como serviço: O sistema deverá continuar rodando no
dispositivo móvel, mesmo após ter suas telas todas fechadas. Dessa forma, o
sistema continuará a trocar mensagens com o servidor de forma transparente ao
usuário exatamente como um serviço.
44
3.5.6 Atividade 4: Professor monitora as atividades dos alunos
3.5.6.1 Descrição da Atividade
Ambiente:
Sala dos professores da Faculdade Ribeirão.
Roteiro:
O professor poderá acompanhar o desenvolvimento de cada aluno no
decorrer do curso. Sendo possível corrigir alguma deficiência identificada através
dos relatórios e gráficos disponibilizados pelo sistema REDU. Estes documentos
podem ser gerados para uma análise individual ou da turma inteira inscrita em um
determinado curso.
3.5.6.2 Cenário Atual
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários identificadas e mostradas na tabela 07, na Seção 3.5.6.3.
Ator:
Professor.
Roteiro:
No cenário atual da plataforma REDU, não existe funcionalidade para
monitorar o desempenho dos alunos [NEC 4.1] ou da turma [NEC 4.2]. Este
acompanhamento deve ser feito utilizando os métodos tradicionais de
avaliação.
3.5.6.3 Necessidades do Usuário (Kujala et al., 200)]
São mostradas na tabela 07, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.6.2.
45
AÇÕES
PROBLEMAS E POSSIBILIDADES
O professor monitora o aluno
[NEC 4.1] O professor não tem a opção no sistema atual de verificar o esforço do aluno.
O professor monitora a turma
[NEC 4.2] O professor não tem a opção no sistema atual de verificar o esforço da turma.
TABELA 07 – Tabela com as necessidades identificadas, referentes à Atividade 04.
3.5.6.4 Cenário futuro com a solução
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários mostradas na tabela 07, na Seção 3.5.6.3. Quando uma dessas
necessidades é mostrada no texto, demonstra que tal necessidade está sendo
atendida.
Atores:
Alunos e professores.
Roteiro:
O professor, no decorrer do curso, inclui novo material para estudo no
sistema REDU. À medida que os alunos acedem o mesmo, o professor
avalia os relatórios gerados, analisando a freqüência de acesso e o tempo
que cada aluno estudou o material. Nestes relatórios está indicado a
identificação do usuário e, nos casos de arquivos de vídeo ou áudio, o
tempo de acesso. Para os demais tipos de arquivos, o aluno indicará
voluntariamente quanto tempo de estudo dedicou. O professor compara
estes dados com o desenvolvimento de cada aluno e do grupo, avaliando
se atingiu o objetivo desejado.
46
3.5.6.5 Cenários futuros caricaturados (Bødker, 2000)
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.6.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
Cenário positivo (plus scenario)
Roteiro:
Durante a disciplina, o professor decide verificar como está o empenho dos
alunos e comparar a evolução de cada um no curso. O professor pode
realizar a busca de atividades [RF-4.1] especificando as datas inicial e final
dessa busca. O sistema apresenta a lista de atividades propostas naquele
período e um gráfico de barras ao lado mostrando o percentual de alunos
que declarou ter realizado as tarefas. O professor percebe que em uma
delas há um baixo percentual de dedicação e decide repensar a didática.
Ele publica uma nova tarefa com os prazos ajustados. Depois de vencidos
os novos prazos, o professor entra no menu “Monitorar” que fica do lado
esquerdo e tem acesso à lista [RF 4.2] de alunos inscritos no curso. Esta
lista destaca com uma cor diferente o nome dos alunos que estão em
atraso com os estudos dos recursos publicados. O professor envia [RF-4.3]
mensagem para os alunos atrasados. Na semana seguinte, o professor
reavalia o relatório e verifica que os alunos se recuperaram.
Cenário negativo (minus scenario)
Roteiro:
O professor Pablo Artigas apesar do treinamento com a plataforma REDU
no início do período, não lembra [RF-4.4] de monitorar o empenho dos
alunos inscritos no curso que leciona. Todos os dados relativos aos alunos
e à turma estão à disposição do professor mas, ele acaba não utilizando-
os. Ao final do período, a funcionalidade acaba não produzindo o efeito
esperado.
47
3.5.6.6 Requisitos do Produto:
Requisitos funcionais:
[RF-4.1] Realizar busca de atividades: O Sistema deverá possibilitar que o
professor faça uma busca das atividades propostas por ele entre duas datas
especificadas. Por padrão, as datas definidas são o primeiro dia de aula e a data
atual. A resposta do sistema deverá ser uma lista com todas as atividades naquele
período.
[RF-4.2] Listar alunos: O sistema deverá permitir que o professor vinculado
à disciplina visualize a lista completa dos alunos. Nesta lista estarão destacados
os alunos com atividades em atraso.
[RF-4.3] Enviar mensagem: O Sistema deverá ter uma opção para que o
professor envie um e-mail para todos os alunos ou uma seleção deles. Esta
funcionalidade deverá ainda permitir o preenchimento automático dos
destinatários com o conjunto dos endereços de todos os alunos em dia e/ou todos
os alunos em atraso.
[RF-4.4] Notificar professor para monitoramento: O Sistema deverá notificar
o professor nos ambientes celular e web que está na data para verificar o
desempenho dos alunos na seção “Monitorar”. O aviso deverá conter um
apontador para a visualização dos gráficos de desempenho da turma.
Requisitos não-funcionais:
Não foram encontrados requisitos não-funcionais.
3.5.7 Atividade 5: Aluno monitora e ajusta seu próprio desempenho
3.5.7.1 Descrição da Atividade
Ambiente:
48
Aluno na escola/universidade - há uma mesa e um computador.
Roteiro:
O aluno poderá acompanhar seu próprio comprometimento durante o
andamento do curso, verificando inclusive se está se dedicando conforme ele
mesmo declarou no momento em que definiu seus horários de estudo e também
se está acompanhando adequadamente as atividades propostas pelo professor.
3.5.7.2 Cenário Atual
No roteiro deste cenário, estão referenciadas as necessidades dos usuários
identificadas e mostradas na Tabela 08, na Seção.3.5.7.3.
Ator:
Aluno
Roteiro:
No cenário atual da plataforma REDU, não existe funcionalidade para que o
aluno monitore a sua dedicação [NEC-5.1] [NEC-5.2]. Esse
acompanhamento teria de ser realizado através de métodos tradicionais de
auto-avaliação e controle.
3.5.7.3 Necessidades do Usuário [Kujala et al., 2001]
São mostradas na tabela 08, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.7.2.
AÇÕES PROBLEMAS E POSSIBILIDADES
O aluno monitora e ajusta seu desempenho
[NEC 5.1] Os alunos não podem visualizar no sistema metas cadastradas e cumpridas. [NEC 5.2] Os alunos não podem fazer ajustes no calendário de modo que cumpra as expectativas para o período.
TABELA 08 – Tabela com as necessidades identificadas, referentes à Atividade 05.
49
3.5.7.4 Cenário futuro com a solução
No roteiro deste cenário, estão referenciadas as necessidades dos usuários
mostradas na Tabela 08, na Seção 3.5.7.3. Quando uma dessas necessidades é
mostrada no texto, demonstra que tal necessidade está sendo atendida.
Ator:
Aluno.
Roteiro:
O aluno cadastrado no sistema REDU se mantém sempre atualizado com
os eventos encaminhados pelo professor, controla sua dedicação e tempo
disponibilizado para o estudo. Ao final de cada módulo, ele acompanha seu
desenvolvimento e analisa se as metas foram cumpridas até o checkpoint
relacionado.
3.5.7.5 Cenários futuros caricaturados [Bødker, 2000]
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.7.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
Cenário positivo (plus scenario)
Roteiro:
No decorrer do curso, o aluno João da Silva decide monitorar se está
cumprindo suas metas de acordo com o que previu anteriormente. Ele
seleciona a opção “Monitorar” [RF-5.1] no menu do lado esquerdo e a tela
mostra a lista de disciplinas nas quais ele está inscrito com cor em
destaque para as quais ele tem itens em atraso. Ao selecionar uma delas,
ele visualiza [RF-5.2] a linha do tempo da disciplina com os checkpoints das
tarefas e um aviso para aquelas que estão em aberto. Ao perceber a
defasagem e a impossibilidade de alocar mais tempo de estudo durante a
50
semana, ele decide distribuir [RF-5.3][RNF-5.1] algumas horas nos fins de
semana. Passados alguns dias, o aluno percebe claramente seu progresso
no curso em questão, decidindo fazer o mesmo para as outras disciplinas
em atraso.
Cenário negativo (minus scenario)
Roteiro:
O aluno Perez, apesar das diversas notificações via sms que ele recebe
durante o período, não consegue acompanhar as atualizações de material e
percebe que não tem idéia do quanto está atrasado no estudo do curso.
Como ele se inscreveu em muitas disciplinas, acaba deixando para verificar
seu acompanhamento [RF-5.2] quando já é tarde demais para se recuperar.
Analisando o relatório, ele descobre que dedicou menos da metade do
tempo a que tinha se proposto para o estudo. Assim, o aluno acaba o
semestre com o rendimento abaixo do desejado.
3.5.7.6 Requisitos do Produto
Requisitos funcionais:
[RF 5.1] Listar disciplinas: O sistema deverá permitir que o aluno obtenha a
lista com todas as disciplinas nas quais ele está inscrito. Nesta lista estarão
destacadas as disciplinas nas quais o aluno está com uma ou mais atividades em
atraso.
[RF 5.2] Visualizar disciplina: O sistema deverá permitir que o aluno ao
visualizar a lista de disciplinas, selecione uma delas para ver sua linha do tempo.
Ela informará as tarefas agendadas com diferenciação visual entre as que estão
pendentes e as que estão em dia.
[RF 5.3] Ajustar calendário: O Sistema deverá ter uma opção para que o
aluno realoque as atividades em atraso para outro dia e horário de sua escolha.
51
Requisitos não funcionais:
[RNF 5.1] Clicar e arrastar: O sistema deverá permitir que a alteração de
agenda ocorra de forma simples, apenas clicando e arrastando o evento para a
data desejada.
3.5.8 Atividade 6: Sincronização com o aplicativo Android
3.5.8.1 Descrição da Atividade
Ambiente:
Qualquer lugar com disponibilidade de conexão de dados para dispositivo
móvel.
Roteiro:
O sistema sincronizará a aplicação Android no intervalo informado pelo
usuário. A cada sincronização, o sistema e a aplicação Android trocam
dados sobre metas a serem realizadas e esforços efetivamente realizados.
3.5.8.2 Cenário Atual
No roteiro desse cenário, estão referenciadas as necessidades dos
usuários identificadas e mostradas na Tabela 09, na Seção 3.5.8.3.
Ator:
Aluno e professor.
Roteiro:
No cenário atual da plataforma REDU, não é possível realizar sincronização
com dispositivo de telefonia móvel.
52
3.5.8.3 Necessidades do Usuário (Kujala et al., 2001)
São mostradas na Tabela 09, as necessidades dos usuários extraídas das
fases descritas na Seção anterior. As necessidades estão rotuladas de acordo
com o cenário atual, na Seção 3.5.8.2.
AÇÕES PROBLEMAS E POSSIBILIDADES
Sincronização com dispositivo móvel
[NEC 6.1]Não é possível sincronizar com dispositivo móvel.
TABELA 09 – Tabela com as necessidades identificadas, referentes à Atividade 06.
3.5.8.4 Cenário futuro com a solução
No roteiro desse cenário, estão referenciadas as necessidades dos usuários
mostradas na Tabela 09, na Seção 3.5.8.3. Quando uma dessas necessidades é
mostrada no texto, demonstra que tal necessidade está sendo atendida.
Roteiro:
As metas cadastradas, editadas ou removidas pelo aluno na aplicação REDU
web são sincronizadas com a aplicação REDU Android em intervalo configurado
pelo usuário. As operações de inserção, edição e remoção também são feitas a
partir do celular e também acontece a sincronização para o sistema web.
3.5.8.5 Cenários futuros caricaturados (Bødker, 2000)
Nos roteiros dos cenários abaixo, estão referenciados os requisitos
identificados do sistema. Esses requisitos estão descritos na Seção 3.5.8.6. A
presença de uma referência no texto a algum requisito significa que esse requisito
foi derivado daquela parte do roteiro.
53
Cenário positivo (plus scenario)
Roteiro:
O aluno João da Silva informa ao sistema no primeiro dia de aula (segunda-
feira) que terá de estudar a disciplina Economia 1 às terças e quintas, no
período entre as 19:00h e 21:00h. Na tela de “Configuração de
sincronização” ele determina que deseja receber as atualizações a cada 30
minutos [RF 6.1]. Meia hora após o cadastro, o sistema envia ao celular de
João a notificação de que a atividade “estudar Economia 1” foi inserida por
ele nos dias e horários especificados. Na terça-feira às 18:30h, o celular
informa que ele deve começar o estudo meia hora depois. João cumpre a
tarefa e confirma que realizou o estudo no sistema REDU Android em seu
celular.
Cenário negativo (minus scenario)
Roteiro:
O aluno Perez informa ao sistema no primeiro dia de aula (segunda-feira)
que terá de estudar a disciplina de Estatística 2 às quartas e sextas, das
21:00h às 23:00h. Como não possui um celular compatível com o sistema
Android, nem consegue abrir a aplicação REDU Web durante o dia, Antônio
não é lembrado da atividade proposta por ele e se esquece de estudar a
matéria [RF 6.2]. Quando ele chega ao trabalho, já na quinta-feira e acessa
o REDU Web, percebe que perdeu o horário de estudo da disciplina no dia
anterior.
3.5.8.6 Requisitos do Produto
Requisitos funcionais:
[RF 6.1] Sincronizar com dispositivo móvel: O sistema web deverá realizar
sincronização dos dados com os dispositivos móveis conforme especificado por
cada usuário.
54
[RF 6.2] Verificar necessidade de sincronização: O sistema Android deverá
verificar se há necessidade de sincronização com o sistema web, caso haja, o
mesmo solicitará autorização ao usuário para realizar a sincronização.
Requisitos não-funcionais:
[RNF 6.1] Rodar como serviço: O sistema deverá continuar rodando no
dispositivo móvel, mesmo após ter suas telas todas fechadas. Dessa forma o
sistema continuará a trocar mensagens com o servidor, de forma transparente ao
usuário, exatamente como um serviço.
55
CONCLUSÃO E TRABALHOS FUTUROS
Inúmeros estudos mostram as limitações da educação tradicional no que se
refere ao estímulo em formar estudantes mais autônomos. O estudo de estilos de
interação para a autorregulação da aprendizagem contidos neste trabalho
propiciou a elicitação de alguns requisitos que visam introduzir alguns desses
conceitos em um ambiente colaborativo.
A metodologia empregada foi baseada em cenários das situações atuais
observadas, que permitiram identificar as necessidades dos usuários (Kujala et al.,
2001) e elaborar inovações que as satisfizessem. Os cenários mostraram-se úteis
para gerar inspirações que resultaram na elicitação de requisitos, porém, o estudo
etnográfico poderia ajudar a formular resultados mais realistas. A técnica de
cenários foi também utilizada para a visualização do desenrolar das atividades
modeladas com a introdução das funcionalidades propostas através de caricaturas
(Bødker, 2000). Foi possível ainda capturar alguns requisitos que o produto
deveria ter de acordo com as referências teóricas relacionadas à aprendizagem
autorregulada.
Entre as limitações deste trabalho está a ausência de uma pesquisa de
campo que impediu que acontecesse uma análise mais completa que poderia
incluir mais etapas como etnografia e análise da tarefa. Trabalhos posteriores
podem incluir a construção de mais cenários bem como a implementação dos
requisitos levantados para verificar o efeito das mudanças contidas nos cenários
futuros. Em outras palavras, faz-se necessário ir à realidade dos estudantes e
professores para verificar as possibilidades de uso e aceitação das inovações
idealizadas.
56
REFERÊNCIAS BIBLIOGRÁFICAS
AZEVEDO, R. and HADWIN, A. Scaffolding self-regulated learning and
metacognition–implications for the design of computer-based scaffolds.
Instructional Science, 33(5-6), 2005. p. 367–379.
BØDKER, S. Scenarios in user-centred design - setting the stage for reflection and
action. In Interacting with Computers, n. 13, 2000. p. 61–75. Elsevier Science B.V.
CARROLL, J. Five reasons for scenario-based design. In Interacting with
Computers, number 13, 2000. p. 43–60. Elsevier Science B.V.
DETTORI, G. and PERSICO, D. Detecting self-regulated learning in online
communities by means of interaction analysis. IEEE Transactions on Learning
Technologies,1(1), 2008. p.11–19.
FLAVELL, J. H. Metacognition and cognitive monitoring: A new area of cognitive
developmental inquiry. American Psychologist, 10(34), 1979. p. 906–911.
FRISON, L. M. B. Auto-Regulação da Aprendizagem. Ciência e Conhecimento
Revista Eletrônica da ULBRA São Jerônimo, vol. 2, 2007.
KUJALA, S., KAUPPINEN, M., and REKOLA, S. (2001). Bridging the gap between
user needs and user requirements. In AVOURIS, N. and FAKOTAKIS, N., editors,
Advances in Human-Computer Interaction I (Proceedings of the Panhellenic
57
Conference with International Participation in Human-Computer Interaction PC –
HCI 2001), p. 45–50. Typorama Publications.
KITSANTAS, A. and DABBARGH, N. Supporting self-regulation in student-
centered web-based learning environments. International Journal on E-Learning,
3(1), 2004. p.40–47.
KRUGER, J. and DUNNING, D. (1999). “Unskilled and unaware of it: How
difficulties in recognizing one‟s own incompetence lead to inflated self-
assessments” in MELO, C. A. Scaffolding of Self-Regulated Learning in Social
Networks. 2010. 107 f. Dissertação (Mestrado em Ciência da Computação) –
Centro de Informática, Universidade Federal de Pernambuco, Recife. 2010.
LICCARDI, I., OUNNAS, A., PAU, R., MASSEY, E., KINNUNEN, P.,
LEWTHWAITE, S., MIDY, M.-A., and SARKAR, C. The role of social networks in
students‟ learning experiences. SIGCSE Bull., 39(4), 2007. p. 224–237.
MELO, C. A. Scaffolding of Self-Regulated Learning in Social Networks. 2010. 107
f. Dissertação (Mestrado em Ciência da Computação) – Centro de Informática,
Universidade Federal de Pernambuco, Recife. 2010.
MYERS, B. A.; BEIGL, M. “Handheld computing” in: GALENO, A. S. Concepção de
Módulo para Dispositivos Móveis de Gestão da Aprendizagem Pessoal Integrado
ao Sistema de Gestão da Aprendizagem Amadeus. 2010. 101 f. Dissertação
(Mestrado em Ciência da Computação) – Centro de Informática, Universidade
Federal de Pernambuco, Recife. 2010.
NARCISS, S., PROSKE, A., AND KOERNDLE, H. Promoting self-regulated
learning inweb-based learning environments. Comput. Hum. Behav., 23(3), 2007.
p.1126–1144.
58
RIBEIRO, C. Metacognição: Um Apoio ao Processo de Aprendizagem. Psicologia:
Reflexão e Crítica, Viseu, 16(1), 2003. p. 109-116.
SOMMERVILLE, I. Engenharia de Software. 8ª ed. São Paulo: Pearson Addison
Wesley, 2007.
VEIGA SIMÃO, A. M. “O conhecimento estratégico e a auto-regulação da
aprendizagem. Implicações em contexto escolar” in: LOPES DA SILVA, A.;
DUARTE, M.; SÁ, I.; VEIGA SIMÃO, A. M. Aprendizagem auto-regulada pelo
estudante: perspectivas psicológicas e educacionais. Porto Editora: Porto, 2004a.
p.77-87.
ZIMMERMAN, B. J. Attaining self-regulation: A social cognitive perspective. In.
MELO, C. A. Scaffolding of Self-Regulated Learning in Social Networks. 2010. 107
f. Dissertação (Mestrado em Ciência da Computação) – Centro de Informática,
Universidade Federal de Pernambuco, Recife. 2010.
ZIMMERMAN, B. J. Becoming a Self-Regulated Learner: An Overview. Theory Into
Practice, Ohio, Volume 41, n. 2, Primavera de 2002.
Links:
Sistemas com características similares
http://qorganizer.sourceforge.net/
http:// www.google.com/calendar
http://atepassarconcursos.com.br/
http://www.myschoolbinder.com/
http://doodle.com/
http://www.rememberthemilk.com/