U TFORDRINGER FOR ELEVMEDVIRKNING I KLASSEROMMET

Depois de conhecer as estratégias usadas pelos professores para as questões de negociação de configuração de espaços (e as actividades dinamizadas para operacionalizar essas estratégias), procurei apresentar-lhes uma “nova ferramenta” para mediar este tipo de problema: mundos virtuais com sistemas de controlo de versões. Para esse efeito, um primeiro protótipo, bastante genérico, foi concebido e apresentado (que será descrito, bem como os demais protótipos desenvolvidos, no próximo capítulo). Referi, na introdução deste capítulo, que pode ser feito um paralelo entre esta fase de proposta de soluções (do método de Engenharia de Adrion) e a análise de requisitos (dos métodos de desenvolvimento de software). Este pormenor é importante uma vez que há que reflectir em pelo menos duas questões:

a) Se há uma nova ferramenta que é proposta, vinda “de fora” do contexto escolar, e ataca a problemática por uma forma que o professor “não pediu”, o que pode significar a palavra “requisitos”?

b) Como podem tomar forma esses requisitos?

Estas questões podem ser abordadas colocando a tónica dos requisitos na perspectiva da solução em vez de na perspectiva do problema. Nas palavras de Zave (1997):

“Requirements engineering is the branch of software engineering concerned with the real-world goals for functions of and constrains on software systems. It is also concerned with the relationship of these factors to precise specifications of software behavior, and to their evolution over time and across software families.43”

Os maiores desafios da engenharia dos requisitos advêm de estes serem normalmente observações informais do mundo real que, sendo vagos e imprecisos na sua natureza requerem uma transformação numa linguagem especificada matematicamente (Yen & Tiao, 1997 ; Zave, 1997) e o de muitas vezes os requisitos entram em conflitos uns com os outros (Yen & Tiao, 1997). Zave (1997) propôs assim um esquema para classificar requisitos que ajuda a lidar com a heterogeneidade dos tópicos desta ciência: usar

43

“A engenharia de requisitos é o ramo da engenharia de software que se preocupa com os objectivos do mundo real para funções e constrangimentos dos sistemas de software. Preocupa-se também com a relação destes factores a especificações precisas de comportamento do software, e da sua evolução ao longo do tempo e nas famílias de software”

Capítulo 7: Modelo Teórico de uma Solução Informática

133

apenas duas dimensões ortogonais em confronto – problemas versus contribuições para soluções - sacrificando a precisão em detrimento da facilidade de aplicação. Considerei esta classificação interessante porque ela parece reflectir as questões e reflexões acima indicadas.

Com efeito, a primeira destas dimensões – o problema – pressupõe um conhecimento tão preciso quanto possível do problema e das tarefas para o resolver. Ou seja, e na problemática desta tese, o trabalho do investigador poder-se-ia limitar a implementar uma solução tecnológica com base na realidade e contexto actual. Esta seria a abordagem a tomar se o professor insistisse na sua estratégia de abordar a realidade e requeresse um mediador tecnológico à medida dessa estratégia. Esta abordagem, centrada no problema, pode ser negativa pois, desencorajaria o desenvolvimento alternativo de soluções para os problemas, ou comparar soluções diferentes para o mesmo problema (Zave, 1997).

Ortogonalmente vem a outra dimensão - a da solução - e baseia-se na ideia de que a melhor solução para um problema pode tornar certas tarefas desnecessárias. Nesta abordagem pretende-se caracterizar as formas como a investigação pode contribuir para resolver problemas (Zave, 1997) e está de acordo com as propostas de Marcos (2005), que apela aos métodos criativos na fase de criação de novos objectos em engenharia do software conforme já referido.

Esta foi a dimensão que conduziu a minha “análise de requisitos”: focando-me na dimensão da “solução” (ou nova solução) foi proposta uma nova forma de abordar o problema e, deste modo, os requisitos da solução já não têm em conta a problemática “antiga” (visto esta ser mudada pela presença do actor tecnológico no contexto), mas sim uma “nova problemática”. Analisar requisitos do ponto de vista da solução parece estar em harmonia com os pressupostos iniciais em que me fundamentei e que defendem que engenharia não deve ser só aplicação de conhecimento, mas também produção de conhecimento, uma vez que o tecido da realidade social onde a tecnologia actua é irremediavelmente alterado.

Entra então aqui a Teoria da Actividade. Como referi, é possível estudar o impacto de uma nova tecnologia focando a investigação nas novas actividades possibilitadas pela mediação oferecida por essa tecnologia. Por outras palavras, quando um professor descreve as actividades que gostava de conduzir quando se apropria de um software do

Capítulo 7: Modelo Teórico de uma Solução Informática

134

tipo “mundo virtual com mecanismos de controlo de versões” está a dar ao investigador os requisitos a que a solução deve respeitar para que a nova actividade se dê.

Assim sendo, e como se pode depreender do raciocínio do parágrafo anterior, a análise de requisitos foi conduzida pedindo aos professores que me descrevessem as actividades idealizadas quando abordassem a problemática, usando como estratégia a mediação tecnológica da nova ferramenta (o novo actor no contexto). Esta análise descritiva foi então objecto de uma especificação formal (um modelo teórico) do qual resultou a implementação do protótipo final que responda às necessidades dessas actividades. É importante referir também que o facto de os professores conseguirem idealizar actividades a realizar com o protótipo, descrevendo ao investigador essas mesmas actividades, não constitui ainda uma validação da tecnologia ou protótipo porque, e como referi anteriormente:

a) É o contexto cultural onde a tecnologia é introduzida que condiciona o seu uso, tanto quanto as próprias propriedades da tecnologia (Bach & Stark, 2001)

b) As práticas sociais que se desenvolvem à volta do uso de uma tecnologia dizem- nos mais sobre o seu efeito do que suposições baseadas apenas nas propriedades da tecnologia propriamente dita (BijKer, 1997; Giddens, 1984).

Desta forma, há que separar a descrição das actividades “teóricas”, idealizadas pelos professores (e que serviram nesta investigação para a análise de requisitos e

construção de um modelo teórico) e a descrição das actividades “práticas”, aquando

do uso real do protótipo em contextos escolares (e que serviram para validar o

protótipo através das mesmas linhas metodológicas da Teoria da Actividade).

Assim, apresenta-se na secção seguinte, e em simultâneo, o resumo das actividades propostas por estes dois professores e as consequências que estas imprimiram ao modelo teórico, que é apresentado então no final deste capítulo, na secção 5.

Capítulo 7: Modelo Teórico de uma Solução Informática

135