Critérios de Avaliação Negociados e Avaliação pelos Colegas, no Trabalho de Grupos de Projeto em Engenharia de Software: Um Estudo de Caso

Ian Utting
Laboratório de Computação da
Universidade de Kent em Canterbury, UK
e-mail: LA. Utting@ukc.ac.uk

Tradução de Paulo dos Santos Ferreira
e-mail: psf@uol.com.br

Há muitos anos, o programa do segundo ano do curso básico de Engenharia de Software ministrado aos alunos de Ciência da Computação da Universidade de Kent (UKC) vem incluindo uma parcela substancial de trabalho em grupo na elaboração e implantação de projetos de software. Esta característica acentuou-se, nos anos recentes, passando a abranger o tratamento de diversos assuntos de crucial importância para o desenvolvimento do estudante e para a formação de profissionais capazes de pensar e agir.

Aqui são analisados os problemas com que se defrontaram, tanto docentes quanto estudantes, na implementação desse aprimoramento do aprendizado em grupo e nessa experiência educacional, e descritas as soluções que se revelaram positivas. O mérito dessa abordagem é estabelecido inicialmente em termos da mudança de atitude dos estudantes em relação ao subseqüente trabalho de projeto, que passa a ser menos constrangedor, e depois em confronto com seu resultado didático proclamado: o aprimoramento do desempenho técnico e profissional.

1 Introdução

A exemplo do que ocorre em todo o Reino Unido com relação à maioria dos cursos de graduação em Ciência da Computação, a Universidade de Kent em Canterbury (UKC) mantém — como parte do programa do segundo dos três anos do curso de graduação — uma disciplina de desenvolvimento de projeto de software que envolve a atuação de pequenos grupos na elaboração e implementação de tais projetos. Em nosso caso, este projeto foi primordialmente desenvolvido como apoio à unidade central de engenharia de software. Mais raramente, o programa do último ano do curso de graduação em Ciência da Computação da UKC também inclui a realização de um projeto em grupo.

Ao longo destes últimos anos, verificou-se não apenas um aumento do número de alunos como também uma crescente sofisticação do tipo de trabalho empreendido no tocante ao projeto do último ano do curso. Para fazer frente a tais circunstâncias, foram adotadas algumas estratégias tendentes a aumentar o proveito do projeto para os alunos, quer em termos do resultado técnico do trabalho, quer no que concerne ao alcance do possível incentivo à reflexão a respeito do seu próprio amadurecimento como profissinais atuantes na engenharia de software.

Foram particularmente aprimorados os aspectos do trabalho relativos a:

• Distribuição e formação dos grupos.
• Estabelecimento de objetivos técnicos e não-técnicos dentro do contexto da matéria ensinada. Tais objetivos são utilizados tanto para orientar a prática quanto como base para a avaliação
• Análise crítica dos progressos alcançados, tanto próprios quanto alheios, num esquema moderado de auto-avaliação e avaliação pelos colegas.

Embora a avaliação considere o trabalho do grupo, comprovou-se a possibilidade de detectar variações quanto ao esforço individual, mediante um novo método baseado em questionários, desenvolvido pioneiramente na universidade de Exeter.

Muitas das técnicas aqui descritas foram definidas em um projeto nacional sobre "Trabalho Efetivo de Projeto em Ciência da Computação" (projeto EPCoS), do qual o autor participou. Os objetivos desse projeto são: "Indentificar, explicitar e sistematizar as melhores práticas no tocante a métodos e técnicas de projeto para estudantes de Ciência da Computação, com o fito de tornar o conhecimento e a experiência existentes prontamente acessíveis para o estabelecimento de padrões mínimos quanto aos graduados em Ciência da Computação" (Fincher, 1998).

2 Atribuições dos grupos

Criteriosa partilha de escassos recursos para atender a requisitos conflitantes. Esta é a principal lição que se pretende ver aprendida pelos estudantes com este trabalho de projeto. Assim, permitimos que eles selecionem grupos e atribuam tarefas a si mesmos, mas colocamos diversos obstáculos em seu caminho.

O projeto que os estudantes empreendem tem mudado com o tempo, mas sempre envolve a elaboração de um pequeno sistema de software, dando maior atenção aos processos de desenvolvimento empregados do que ao resultado final. Os sistemas são em geral bem especificados (às vezes formalmente, por exemplo, em Z) e são muito facilmente desmembráveis em duas metades. Cada grupo de alunos desenvolve uma das metades do sistema, integrando seu trabalho com o de outro grupo, responsável pelo desenvolvimento da outra metade.

Para os alunos do curso de engenharia de software, esta é a segunda experiência de trabalho em grupo. Antes de se lançarem a ela, eles já se haviam dedicado, durante cerca de 10 semanas, ao estudo de casos envolvendo questões profissionais, divididos em grupos de aproximadamente 12 alunos cada um (Fincher & Utting, 1998). O fato de estes (grandes) grupos terem sido formados com uma finalidade completamente diferente — a de refletir a respeito de responsabilidades profissionais (não-técnicas) e elaborar um curto relatório semanal do grupo — torna interessante a tarefa de dividir recursos entre as duas metades do desenvolvimento do projeto. Num estudo dos fatores que afetam a escolha dos alunos quanto à forma de desmembrar os grandes grupos anteriores e reagrupar seus integrantes em grupos menores, Thom (1998) observou que, a despeito dos ensinamentos dados em aula sobre distribuição de recursos, o fator mais influente na escolha dos alunos foi o quanto eles "gostavam" dos demais membros do grupo. Apesar disso, numa pesquisa a respeito da experiência adquirida pelos alunos neste trabalho e de sua relevância para os projetos do último ano do curso, a "experiência de trabalho em grupo" e a "atribuição de tarefas aos membros do grupo" foram as vantagens mais freqüentemente citadas como resultado decorrente da participação neste trabalho de projeto.

3 Negociando objetivos de projeto e critérios de avaliação

Tem sido freqüentemente observado que os estudantes estão intensamente concentrados no desenvolvimento de software como atividade de codificação. Isto é particularmente problemático no ensino de engenharia de software, em que as limitações quanto à disponibilidade de tempo e de esforço por parte do aluno dificultam o desenvolvimento de software de porte e complexidade suficientes para reclamar a utilização das técnicas que estão sendo ensinadas. Levantamentos concernentes ao emprego do tempo na UKC sugeriram que, trabalhando a partir de uma simples especificação de um pequeno programa, os alunos do último ano de Ciência da Computação escrevem 15 linhas de código por hora de avaliação. Considerando que o tempo total disponível por curso é de 120 horas, isso significa que, mesmo sem fazer nada senão codificação, o aluno médio poderia produzir apenas 1800 linhas de código. Um programa desse tamanho dificilmente requer o tipo de técnicas de desenvolvimento e de administração de projeto adequado para grandes sistemas. Somos assim forçados a tolher os alunos, compelindo-os ao uso de técnicas aparentemente menos apropriadas, para podermos proporcionar-lhes (pelo menos alguma) experiência prática nesse campo, antes que avancem em direção a sistemas nos quais o uso de tais técnicas será crítico.

No momento de iniciar o módulo de projeto deste curso os alunos já se haviam familiarizado com os princípios básicos da administração do desenvolvimento de software. Isto nos permitiu negociar com eles (de maneira bastante abstrata) os tipos de tarefa que deveriam empreender para completar com êxito o projeto, e identificar os produtos do projeto nos quais se constataria a evidência de que tais tarefas haviam sido completadas. Como parte desse processo, conduzido na forma de uma discussão em grupo, nós também consideramos os pesos relativos das diferentes tarefas definidas (tanto em termos de porte quanto de complexidade), o que levou ao estabelecimento do peso que seria atribuído a cada tarefa na avaliação. Embora o resultado dessa discussão varie (marginalmente) de ano para ano, um resultado típico é mostrado na Tabela 1.

Tabela 1: Critério de avaliação com ponderações

Damos a seguir um exemplo de descrição da evidência que pode ser encontrada para essas atividades e onde encontrá-la:

Gestão e garantia da qualidade

Evidências destas atividades serão encontradas principalmente nos registros das reuniões de projeto e também na documentação fornecida quanto à Garantia da Qualidade.

Deverá ser especialmente evidente que:

• Foram definidas as responsabilidades dos integrantes do grupo quanto aos aspectos ligados à qualidade.
• Foram efetuadas verificações quanto à qualidade dos produtos que o projeto pode fornecer e foram documentados os resultados de tais verificações.
• Foram estabelecidos padrões (para codificação e documentação) e foi verificada a aderência a tais padrões.
• Gestão da configuração e controle do código fonte foram utilizados, onde aplicável, pa-ra manter em registro os diferentes códigos e as diferentes versões de documentos e para identificar os responsáveis pelas modificações.

A prévia negociação de tais critérios com os alunos serve tanto como incentivo para que seja compreendido o real valor de cada tarefa isolada (especialmente da "implementação"), quanto para conferir-lhes, desde o início, pronta orientação quanto à maneira pela qual seu trabalho será julgado. O alinhamento dos critérios de avaliação com a "boa prática" em engenharia de software é altamente benéfico para o processo de aprendizagem.

4 Incentivo à reflexão crítica — avaliação pelos colegas e auto-avaliação

Devido à inevitável defasagem entre a submissão do trabalho à avaliação e seu retorno, e também ao apelo dos demais deveres escolares que exigem a dedicação dos alunos, competindo pela sua atenção, até mesmo o mais bem elaborado esquema de realimentação pode facilmente perder sua relevância, pelo menos até que surja uma nova ocasião em que um trabalho semelhante deva ser executado, e nesse entretempo a compreensão do aluno acerca do que ele fez, e por que, é freqüentemente dissipada. Por essa razão, muitos estudantes concentram sua atenção na nota eventualmente obtida, e o valor da realimentação para o desenvolvimento da compreensão do seu próprio trabalho é em grande parte perdido.

Com o propósito de evitar tais problemas, instituímos o esquema de "avaliação pelos colegas" para avaliar este trabalho de projeto. Fazer com que os alunos avaliem o trabalho dos colegas é importante para o desenvolvimento de suas próprias idéias, bem como em termos da realimentação que isso lhes proporciona. A consciência de que deverão julgar o trabalho alheio de acordo com os critérios estabelecidos também contribui para mantê-los concentrados nesses critérios durante a execução de seu próprio trabalho.

O esquema adotado exige que um grupo de estudantes — ao qual foi confiada a execução de uma particular metade do projeto — se reuna e avalie o trabalho de um outro grupo nas mesmas condições, redigindo um breve relatório, bem como atribuindo notas. Um docente encarrega-se então de moderar tais notas antes de devolver o trabalho avaliado ao grupo que o executou.

Esse processo de moderação não tem revelado diferenças significativas entre as notas atribuídas pelos colegas e pelo docente, e nem tampouco uma correlação significativa entre a nota eventualmente concedida a um determinado grupo e a exatidão das notas atribuídas por esse grupo ao trabalho de outros.

Nas versões anteriores desse processo, após o retorno do trabalho com as notas havia um período durante o qual o grupo avaliado podia apelar da avaliação, convocando-se então uma reunião na qual cada grupo podia apresentar seus argumentos a favor (e contra) a avaliação, até chegar a um acordo de compromisso. Tal caminho era normalmente seguido por cerca de 15% dos grupos.

Isso decorria, em parte, da quantidade de critérios de acordo com os quais o trabalho fora avaliado — quanto maior o número de critérios, maior a margem para discordâncias quanto a detalhes — porém, mais freqüentemente, essa discordância era fruto de uma expectativa não razoável no tocante à exatidão das notas. Durante o processo de moderação, uma discrepância da ordem de ±5% na nota final era considerada aceitável — bem dentro dos limites do erro a ser esperado quando um trabalho de tal porte recebe notas de mais de um avaliador. Tal variação normalmente não é mostrada aos alunos, contando-se com sua confiança no julgamento do corpo docente.

Essa confiança claramente inexiste quando os estudantes são julgados por seus próprios colegas, mesmo que a variação observada nas notas não seja maior do que a que seria de se esperar no caso de múltiplos avaliadores docentes.

Na versão atual do processo, os grupos são solicitados a apresentar (junto com os resultados de seu projeto) uma auto-avaliação de seu próprio trabalho de acordo com o critério negociado. Isso foi instituído com o propósito de ajudá-los em suas reflexões, de ampliar sua base de julgamento do trabalho alheio e de colher subsídios para o processo de moderação. Mas teve também o efeito inesperado de reduzir — de 15% para 5% (no caso, um único grupo) — o número de grupos insatisfeitos com a nota que lhes fora atribuída pelos colegas. Este efeito foi tão marcante que mesmo a complicação adicional decorrente da concessão de um substancial prêmio em dinheiro ao grupo que apresentou o melhor projeto não provocou nenhum aumento do número de descontentes.

4.1 Nota do grupo e notas individuais

Por simplicidade, uma única nota é atribuída a cada grupo como um todo. Isto é conveniente, de um modo geral, na medida em que se supõe que todos os integrantes do grupo tenham contribuído igualmente para o êxito do projeto. Em alguns casos, no entanto, um determinado membro do grupo fracassa inteiramente em dar sua contribuição. Até há bem pouco tempo, tais casos eram resolvidos mediante uma cláusula punitiva, que facultava ao grupo a atribuição de uma nota de 0% a um (ou mais) de seus membros, com base na ausência de contribuição, conferindo assim aos integrantes do grupo um certo poder coercitivo durante a execução do trabalho. Tal decisão deve ser tomada de maneira unânime pelo grupo, inclusive pelo integrante em questão. Esta sanção draconiana foi aplicada apenas uma vez, e nesse único caso contra um aluno que, embora ainda indeciso, já estava então inclinado a abandonar o curso. Não existe, até o agora, nenhum procedimento para premiar com distinção as efetivas contribuições ao trabalho do grupo.

Com o intuito de proporcionar um recurso menos drástico para levar em conta as diferenças entre determinados alunos no que concerne ao nível de sua contribuição pessoal para o êxito do trabalho do grupo, estamos adotando (desde a primavera de 1999) um mecanismo definido no projeto EPCoS com base em experiências práticas levadas a efeito na Universidade de Exeter (Milne, 1998). Cada membro de um grupo preenche um pequeno questionário avaliando a contribuição de todos os integrantes do grupo (inclusive a sua própria) em confronto com a expectativa referente a essa mesma contribuição, tanto em relação a cada item do critério de avaliação quanto no que concerne ao trabalho do grupo como um todo. Isso permitirá identificar indivíduos cujo desempenho esteja aquém ou além do esperado, e modificar adequadamente a nota final atribuída a cada um. A intenção não é a de estabelecer grandes diferenças entre os membros do grupo, mas apenas a de reconhecer contribuições particularmente valiosas ou insuficientes, mediante uma variação de ±5 a 10% na nota, incentivando assim a aplicação de um esforço mais equânime pelos membros do grupo e amenizando eventuais ressentimentos por parte daqueles que se consideram como se tivessem "carregado" algum colega.

5 Conclusões

O trabalho de projeto descrito abrange vários aspectos do desenvolvimento dos alunos como profissinais atuantes na engenharia de software. Trata-se, basicamente, de um exemplo bastante típico, que ilustra bem a maneira pela qual esse trabalho é executado nos cursos de graduação em Ciência da Computação. Foram descritos alguns procedimentos destinados a incentivar os alunos à reflexão, levando-os a considerar, não apenas os objetivos corriqueiros da produção de software utilizável, mas sobretudo os reais objetivos do trabalho proposto:

• O uso de grupos formados com uma finalidade diferente, como forma de impor restrições quanto aos recursos disponíveis.
• A negociação dos critérios de avaliação (e da adequada ponderação) com os alunos, com base em princípios da engenharia de software expostos em aula.
• A utilização de tais critérios na orientação dos esforços dos alunos durante a execução do trabalho, de modo a desencorajar a adoção estratégias mais simples, porém inadequadas.
• O uso da auto-avaliação e da avaliação pelos colegas (do desempenho do grupo), para incentivar a reflexão a respeito do trabalho realizado e dos princípios aprendidos.
• O uso (proposto) da auto-avaliação e da avaliação pelos colegas (do desempenho individual), para individualizar as notas atribuídas ao grupo, levando em conta a diferente contribuição de cada integrante, sem recorrer ao acompanhamento detalhado do esforço individual empreendido.

6 Reconhecimento

O Projeto EPCoS é financiado pelo Conselho de Financiamento do Ensino Superior na Inglaterra (HEFCE), por meio do programa denominado "Fundo para o Desenvolvimento do Ensino e do Aprendizado".

O prêmio destinado ao grupo com melhor desempenho geral no projeto é oferecido pelos Laboratórios de Pesquisa Philips, em Redhill, no Reino Unido.

REFERÊNCIAS

________________________________________

Ian Utting é instrutor do Laboratório de Computação da University of Kent at Canterbury, no Reino Unido, e diretor do Authorized Academic Java Campus daquela universidade. Suas pesquisas focalizam a engenharia de Sistemas Distribuídos de Grande Porte e o ensino de Ciência da Computação. Leciona as disciplinas de Projeto Orientado para Objeto, Engenharia de Software e Sistemas Distribuídos. Trabalha atualmente como membro do HEFCE FDTL - projeto financiado EPCoS

O Laboratório de Computação da UKC figura entre os 10 primeiros do Reino Unido para o ensino de Ciência da Computação e tornou-se recentemente o primeiro Sun AAJC na Europa.