Estilo de interação para autorregulação da aprendizagem em ambiente de ensino

66
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

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

Transcript of Estilo de interação para autorregulação da aprendizagem em ambiente de ensino

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/

59

APÊNDICE

DIAGRAMA DE CASO DE USO 01.

60

DIAGRAMA DE CASO DE USO 02.

DIAGRAMA DE CASO DE USO 03.

61

DIAGRAMA DE CASO DE USO 04.

62

DIAGRAMA DE CASO DE USO 05.

DIAGRAMA DE CASO DE USO 06.

63

DIAGRAMA DE SEQUENCIA A.

DIAGRAMA DE SEQUENCIA B.

64

65

Assinaturas

_______________________________________ Alex Sandro Gomes

Orientador

_______________________________________ Hélder Manoel Lima e Silva

Aluno