Dentre as diferentes propostas metodológicas para desenvolvimento de software, educativos ou não, apresentaremos aqui o “design participativo” (ROCHA; BARANAUSKAS, 2003).
Inspirados nessa metodologia, alguns autores (GOMES; WANDERLEY, 2003; GOMES; PADOVANI, 2005; PERRY, 2005) indicam caminhos para desenvolvimento de software educativo em diferentes trabalhos e pressupõem, como o nome já diz, uma participação ativa dos usuários do sistema ao longo da sua implementação.
Segundo Rocha e Baranauskas (2003, p. 136), o design participativo caracteriza-se:
pela participação ativa dos usuários finais do software ao longo de todo ciclo de design e desenvolvimento. Mais do que serem usados como fontes de informação ou serem observados em sua rotina de trabalho, ou no uso do produto, os usuários finais trazem contribuições efetivas em todas as fases do ciclo de design e desenvolvimento, que refletem suas perspectivas e necessidades. A participação do usuário não é restrita aos estágios de testes de protótipos ou avaliação, mas acontece ao longo do processo de design e desenvolvimento.
Partindo dos pressupostos acima, trabalhos como os de Perry (2005), de Gomes e Wanderley (2003) e de Gomes e Padovani (2005) destacam a importância da participação dos usuários no desenvolvimento de software ou jogos educativos em diferentes momentos do seu desenvolvimento. Perry (2005) utiliza-se de uma metodologia participativa e desenvolve um software educativo focado no conteúdo “equilíbrio químico”. A autora destaca a importância da “especialista de 15 Não gostaríamos, aqui, de discutir as diferentes especificidades das teorias utilizadas na Ciência da
Computação. Escolhemos fazer uma breve discussão sobre “design participativo”, pois, como veremos mais adiante, baseamo-nos em aspectos de tal teoria para desenvolvermos o jogo computacional educativo com os/as estudantes e professora da escola.
domínio”, ou seja, da educadora, ao longo do processo de desenvolvimento e experimentação do sistema. Para essa autora, a presença da especialista em educação é mais determinante para o processo de desenvolvimento que a dos outros colaboradores (designer, programadores, roteiristas, etc.).
Os usuários, nos contextos dos software e/ou jogos educativos, são estudantes e professores/as e o objetivo desses estudos é trabalhar com a participação efetiva desses usuários, de preferência no seu ambiente natural, ou seja, na escola, na sala de aula.
Um trabalho inspirado na metodologia do design participativo precisa ser, acima de tudo, um trabalho colaborativo. Perry (2005, p. 60), ao iniciar a descrição da sua metodologia de desenvolvimento de software educativo inspirada no design participativo, afirma que ela tem como maior objetivo “ser participativa, no sentido de oferecer a todos os membros da equipe chances iguais de colaborar com o projeto”.
Chamaremos a atenção para o trabalho colaborativo (PASSOS et. al., 2006), pois entendemos que tal abordagem se aproxima das metodologias de desenvolvimento de jogos computacionais as quais têm como base o design participativo, uma vez que ele requer uma formação de grupos compostos por diferentes profissionais, por estudantes, professores, designers, programadores, entre outros.
A formação de um grupo que seja efetivamente colaborativo é, ao nosso entendimento, essencial para a concretização do jogo. Assim, buscamos em Passos et al. (2006, p. 202) a concepção de colaboração a qual corrobora o trabalho de Johnston e Kairschner (1996), ou seja:
A colaboração não pode ser imposta, ela deve ser construída. Ela é construída dentro de relacionamentos nos quais os indivíduos sentem vontade de compartilhar suas diferenças e, ao contrário das formas típicas de autoridade atribuídas aos papéis e relacionamentos institucionais, busca por formas mais inclusivas de envolver múltiplas perspectivas e fala através das questões da confiança, mutualidade e eqüidade. Estabelecer relacionamentos leva tempo. Os projetos podem parecer ineficientes e sem foco, especialmente no começo, porque os aspectos relacionais devem ser considerados, bem como as metas e procedimentos do projeto.
realmente colaborativo. Ao longo de nossos estudos, percebemos algumas dificuldades em utilizar tais abordagens. Dentre elas destacamos:
− o fato de que atividades com os usuários são pouco estruturadas, por respeitar a interação e por muitas vezes revelar situações não previstas anteriormente. Isso se dá por se tratar de seres humanos, que pensam, agem, opinam, etc. "simplesmente inserir o usuário no processo não basta para assegurar o sucesso" (PERRY, 2005, p. 45);
− a dificuldade de formarmos um grupo realmente colaborativo, pois "estas atividades interferem em seu trabalho, em seus compromissos (dos usuários)" (PERRY, 2005, p. 46);
− o custo e tempo disponível para o projeto. Perry (2005, p. 46) também afirma que "o envolvimento extensivo de usuários no processo pode encarecer e talvez atrasar o desenvolvimento”.
Perry (2005, p. 69) desenvolveu sua pesquisa com uma equipe muito pequena “composta por um especialista em educação (que acumulou a função de especialista em estatística e foi o autor do projeto educacional) e por um designer (que acumulou a função de programador)”. Porém, a todo momento a autora ressalta a importância da colaboração entre os integrantes dessa equipe (PERRY, 2005, p. 13).
A Ciência da Computação também utiliza-se de “métodos etnográficos de design de interfaces” (ROCHA; BARANAUSKAS, 2003, p. 142) para o desenvolvimento de software. As autoras indicadas chamam a atenção para métodos etnográficos, como a “observação participante”, “o registro em vídeo” e citam o “trabalho pioneiro de Suchman (1987)”, o qual “propõe que o ideal para a investigação da tecnologia em uso é aquele em que a atividade de trabalho ocorre naturalmente em cenários construídos pelos próprios participantes” (ROCHA; BARANAUSKAS, 2003, p. 143).
Entende-se que esses métodos citados acima facilitam na captação da “densidades de detalhes” (ROCHA; BARANAUSKAS, 2003, p. 144) os quais revelam algumas necessidades dos usuários ao manipular o sistema. Gomes e Wanderley (2003, p. 10), na tentativa de desenvolver um software educativo que permita “aos alunos a resolução de problemas no campo das estruturas aditivas a
partir do uso de representações criadas pelo usuário”, destacam a importância de aproximar o software às necessidades dos usuários.
Para Gomes e Padovani (2005, p. 4) “o entendimento das necessidades do usuário é visto como um fator de sucesso para o desenvolvimento de um produto”. Ou seja, a partir das necessidades dos/as estudantes e professores/as é que podemos pensar nos requisitos16 do sistema. Para isso coloca-
se imprescindível a participação dos/as colaboradores, estudantes e professores/as desde as primeiras fases do desenvolvimento ou no que Perry (2005, p. 37) determina como o “projeto pedagógico”.
No sentido de aproximar cada vez mais esses software com as necessidades da sala de aula, Gomes e Padovani (2005, p. 4), numa perspectiva da Teoria da Atividades de Leontiev, criticam algumas prioridades dos software baseados em Hinostroza e Mellar (2001):
os designers de softwares educativos priorizaram as questões relacionadas com a aprendizagem em detrimento das atividades de ensino, e isto seria uma das causas das dificuldades que os professores sentem ao tentarem incorporar estes materiais às suas atividades em sala de aula.
No contexto da Educação o pesquisador e a pesquisadora afirmam que a partir da análise da estrutura das atividades que ocorrem em sala de aula
é possível gerar requisitos para as aplicações de forma a adequá-las. Após a análise da estrutura das atividades, procedemos novamente com a análise de necessidades associadas a cada uma das dimensões da atividade. Identificamos, assim, necessidades relacionadas: aos usuários (user needs), as regras (rules needs), a comunidade (community needs), a divisão do trabalho (work needs), ao objeto (object needs).
Ressalta-se, aqui, além da importância já dita da participação dos/as estudantes e professores/as no processo de construção de softwares ou jogos educativos, numa perspectiva do trabalho colaborativo, um olhar especial para as possibilidades de entendermos esse desenvolvimento como uma atividade a qual 16 A Engenharia de Software é uma disciplina da Engenharia que “se ocupa de todos os aspectos da produção de software, desde os estágios iniciais de especificação do sistema até a manutenção desse sistema, depois que ele entrou em operação” (SOMMERVILLE, 2003, p. 5). Nesse processo de produção de software, uma fase muito importante é o que os autores chamam de “elicitação de requisitos”. Os requisitos são “as descrições das funções e das restrições de um sistema” e o processo de elicitar, descobrir, analisar, documentar e verificar as funções e as restrições é chamada de “engenharia de requisitos” (ibid., 2003, p. 82)
permite a análise de tais necessidades.
Numa dimensão maior, as necessidades que nos motivam a investigar as novas tecnologias e o ensino da Matemática estão associadas à problemática apontada acima: o não diálogo entre escola e sociedade atual. Tal necessidade objetivou-se materialmente no motivo de desenvolver um jogo computacional com os estudantes e tal desenvolvimento foi mediado por atividades orientadoras de ensino.
Segundo Moretti (2007, p. 85), “um sujeito encontra-se em atividade quando o objeto de sua ação coincide com o motivo de sua atividade”, no nosso caso, o objeto da nossa ação é o jogo computacional mediado pela atividade orientadora. Discutiremos as definições de tais objetos no próximo capítulo.
CAPÍTULO 3 – ATIVIDADES ORIENTADORAS DE ENSINO E JOGOS