Corpus

A construção do Corpus aconteceu em dois momentos que foram unidos nas análises: processo de desenvolvimento e processo de uso. No primeiro momento, inserimos- nos numa disciplina de Engenharia de software. Acompanhamos quatro equipes ao longo do processo de desenvolvimento de um software (trabalho final da disciplina). O produto advindo desta atividade de elaboração foi seguido até o momento de uso, ou seja, depois do produto gerado, acompanhou-se seu uso, fazendo também registros videográficos e análise das ações de usuários em atividade com o software.

As equipes de desenvolvimento de software foram escolhidas a partir da disciplina Engenharia de Software (IN953), oferecida pelo programa de Pós-Graduação em Ciências da Computação - Centro de Informática da UFPE. Entre os objetivos da disciplina, alguns nos interessaram particularmente: trabalhar os processos de engenharia de software para open

Open Source Software (OSS) é uma inovação nas cenas de desenvolvimento de

software, aparecendo em meados da década de 90 e atraindo até hoje um certo número de profissionais. Os OSS são softwares cujos códigos são abertos, com poucas limitações sobre possíveis modificações e uso por terceiros, permitindo inspeção e reuso de códigos de programação a partir de algum tipo de “licença open source” (Crowston e Scozzi, 2002). Cada projeto é produto de uma comunidade compreendendo alguns desenvolvedores distribuídos geograficamente, colaborando através da internet ou outras vias, para buscar interação e satisfação pessoal no desenvolvimento de software. O fato de essas comunidades serem organizações virtuais e o acesso do conhecimento individual estar disperso numa rede como a internet, mantendo juntos um certo número de desenvolvedores para o rápido desenvolvimento de um produto, facilitaria nossa aproximação e engajamento para uma compreensão de tais práticas.

É importante mencionar que a discussão sobre usabilidade em comunidades open- source não é ainda forte o bastante, tal qual apontam Nicholson e Twidale (2006). Há mesmo uma escassa participação de especialistas em usabilidade engajados nessas práticas. Porém, as equipes constituídas na disciplina analisada (IN953), estavam inseridas dentro de centros ou empresas mais amplas, como o C.E.S.A.R. (Centro de Estudos Avançados do Recife), havendo membros que estavam atentos às questões que envolvem o usuário.

Para atingir os objetivos da disciplina, os alunos participaram de atividades de aula, leituras, práticas e experimentos reais. Durante o período letivo (4 meses), deveriam montar e executar “fábricas de softwares”.

A partir dos conhecimentos advindos de nossa imersão como pesquisadores na disciplina, podemos definir fábrica de software como uma organização habitada por pessoas engajadas em um esforço comum, cujo trabalho é organizado em um sentido ou outro na direção desse esforço: o desenvolvimento de softwares. Uma certa padronização é usada para

coordenação e formalização dos trabalhos, sendo a sistematização importante. Porém, há várias opções para as configurações de fábricas particulares, por isso, no caso, cabia aos alunos escolher, adaptar e/ou construir as configurações de suas fábricas4. Diferentes perspectivas puderam orientar na condução dessa escolha (Aaen, Botcher e Mathiassen, 1997).

Havia em média 12 aluno(a)s por equipe. Estas pessoas se enquadravam em diferentes papéis de acordo com suas habilidades: gerentes de projeto, programadores, arquitetos e engenheiros de software, designers, entre outros. Cada time poderia contar com colaboradores externos, prática comum a tais processos de desenvolvimento, o que foi verificado em quase todas as equipes.

Os softwares a serem desenvolvidos eram solicitados por clientes reais que apresentaram requisições para problemas reais. Isso levou as fábricas a lançarem propostas de projetos de desenvolvimento a fim de solucionarem os problemas, comprometendo-se a entregar “protótipos” ao longo do período (uma vez por semana) especificando as funcionalidades e eficiências desses protótipos.

Em suma, os alunos vivenciaram situações de desenvolvimento, as quais exigiam tomadas de posição e resolução de problemas típicos aos contextos de desenvolvimento de software, pois os processos de desenvolvimento nasceram com problemas reais para os quais as equipes identificaram soluções, testaram, revisaram e transformaram códigos, documentaram o processo e apresentaram protótipos de softwares aos clientes. Apresentaram seus resultados também às outras equipes e aos professores em seminários ao longo do período.

De acordo com orientações iniciais dos professores, e com os conteúdos discutidos nas aulas, uma abordagem fundamental às equipes foi que as mesmas deveriam

4_{O termo fábrica pode ter uma conotação controversa por associá-lo à produção em massa de produtos} industrializados, o que não é o caso, principalmente em se tratando de software livre.

estar organizadas em processos de desenvolvimento geograficamente distribuído. Isso implicava o relacionamento dos membros através de diferentes canais para compartilhamento e desenvolvimento da interação no desenvolvimento do produto, como listas de discussão, sites, blogs, reuniões virtuais, etc., sem um necessário encontro presencial.

Acompanhamos as aulas antes, durante e depois da formação das equipes. Houve um simultâneo acompanhamento minucioso de quatro destas equipes, durante o desenvolvimento de seus respectivos softwares (atividade regular da disciplina).

A escolha do corpus e acompanhamento das equipes durante uma disciplina acadêmica deu-se principalmente pelos prazos exigidos no programa da disciplina, tornando o tempo do processo de desenvolvimento apropriado para a pesquisa, já que alguns processos de desenvolvimento podem ter “tempo de vida” bastante amplo.

Estando o foco da pesquisa centralizado no processo de desenvolvimento e uso, e nas múltiplas vozes que permeiam esse diálogo desenvolvedor-usuário, não acarretou qualquer problema o fato de este processo acontecer durante um processo mais amplo de ensino-aprendizagem, desde que, não sendo este o foco do estudo, foram descartados para análise qualquer aspecto relacionado ao ensino ou à relação professor-aluno, como questões sobre notas e outras pendências referentes à avaliação do(a)s aluno(a)s. Aspectos que, eventualmente, apareciam também em seus discursos. Uma outra característica da disciplina que favoreceu nosso acesso às comunicações dos desenvolvedores entre si deveu-se ao caráter

distribuído do processo nas fábricas.

Os registros escritos e áudio-visuais foram colhidos a partir de filmagens de aulas, filmagens de reuniões presenciais, registro de encontros em reuniões virtuais (em que faziam uso de recursos como o Messenger), inserção e acompanhamento de listas de discussão para a coleta dos emails enviados/recebidos. As aulas, reuniões e listas envolviam, muitas vezes, além dos membros das equipes, os clientes (pois como dissemos a simulação das fábricas

envolveu clientes reais), alguns colaboradores externos que se agregavam à equipe, o monitor (aluno da disciplina em período anterior) e os dois professores que conduziram o planejamento da disciplina.

O momento de uso, por mais que muito do uso já seja percebido nas ações dos desenvolvedores com programas, foi focalizado em torno de atividades de usuários finais com os softwares cujas origens e desenvolvimentos acompanhamos nas fábricas. Muitos dos usuários de OSS são os próprios desenvolvedores, mas dados que nossos interesses eram, também, os usos por terceiros, tivemos que fazer uma triagem e selecionar aqueles softwares que continham especificidades referentes à interface e/ou se estendiam para além dos próprios interesses de desenvolvedores, visando usuários pertencentes a outras práticas. Priorizamos para essas análises o produto advindo do desenvolvimento em duas fábricas:

- “Cooper Software Factory”: esta fábrica empenhou-se no desenvolvimento de uma infraestrutura Web 2.0, de cooperação para o trabalho em softwares, com um grau de simplicidade no uso e na programabilidade, agregando várias funções. Não havia propriamente um “cliente”, pois a proposta foi lançada por um dos professores da disciplina. Os clientes eram usuários potenciais que, em larga medida, podemos especificar como contendo aquelas pessoas que trabalham com desenvolvimento de software.

- “Trend”: esta fábrica trabalhou sobre um projeto já existente, cujo software Project Management Knowledge – PMK (Torreão, 2005) já possuía alguns protótipos e requeria desenvolvimento. A cliente que buscou a fábrica, portanto, possuía muito conhecimento do produto, por ser de sua autoria, e sua voz serviu-nos também como “voz de desenvolvedor”, já que assim se posicionava num momento primeiro. PMK (Project Management Knowledge) é um ambiente de aprendizagem que se combina com um agente inteligente, Virtual Intelligent Companion for Tutoring and Reflection – VICTOR, para prover suportes de aprendizagens a estudantes no desenvolvimento de projetos.

Escolhemos usuários cujo perfil se enquadrasse, em certa medida, ao perfil de “usuário final” pressuposto pelos desenvolvedores e para o qual tivesse sido desenvolvido o programa. Acompanhamos as atividades de uso e videografamos as mesmas, permanecendo no local do uso enquanto a atividade se dava.

A relação entre desenvolvedor e usuários mostrou-se, portanto, um fenômeno valioso para os estudos sobre cognição, para compreendermos o funcionamento de mecanismos complexos como estes que possibilitam a interação humana em contextos cada vez mais repletos de tecnologia. Como decorrência desta pesquisa, vemos contribuições para aquelas áreas interessadas na produção de sentidos pelos seres humanos em atividades complexas e complementares como desenvolvimento e uso de artefatos tecnológicos.