Desenvolvimento de Software Educativo: A Coordenação como Fator Crítico de Sucesso

Educational Software Development: Coordination as the Critical Success Factor

António Pedro Costa¹, Luís Paulo Reis², Maria João Loureiro³

¹ Ludomedia e CIDTFF - Centro de Investigação Didática e Tecnologia na Formação de Formadores DE/UA- Departamento de Educação, Universidade de Aveiro, Aveiro, Portugal.E-mail: pcosta@ludomedia.pt

² EEUM/DSI - Escola de Engenharia da Universidade do Minho, Dep. Sistemas de Informação, LIACC – Laboratório de Inteligência Artificial e Ciência de Computadores, Guimarães, Portugal. E-mail: lpreis@dsi.uminho.pt

³ CIDTFF - Centro de Investigação Didática e Tecnologia na Formação de Formadores DE/UA- Departamento de Educação, Universidade de Aveiro, Aveiro, Portugal. E-mail: mjoao@ua.pt

RESUMO

Palavras-Chave: Modelo 4C; Metodologia Híbrida de Desenvolvimento Centrado no Utilizador; Courseware Sere; Coordenação.

ABSTRACT

In software development, coordination allows organizing the team by negotiating/assigning tasks to be performed by a certain order in order to meet the proposed objectives. Coordination is also responsible for managing conflicts associated with attitudes of competition, disorientation, problems of hierarchy and diffusion of responsibility. This work is based on the 4C model dimensions: Communication, Coordination, Cooperation and Collaboration. It is based on the analysis of the interactions between the multidisciplinary team members, that developed the educational resource Courseware Sere - "The Human Being and Natural Resources” concerning the "Coordination" dimension. The results achieved allowed us to detect limitations of Hybrid User Centered Development Methodology used for this courseware development as well as to implement tools to improve the coordination activities.

Keywords: 4C Model; Hybrid User Centered Development Methodology; Courseware Sere, Coordination.

1. Introdução

Associado aos processos de desenvolvimento, têm sido aplicadas diferentes técnicas de gestão de projetos reconhecendo que, a necessidade de estimar cronogramas e orçamentos é muito importante, e que a coordenação destes recursos se torna tanto mais crítica quanto maior for o projeto e a complexidade do mesmo. As abordagens teóricas para avaliação e a melhoria dos processos de desenvolvimento de software, tais como, o Capability Maturity Modeling e a ISO 15504 (2004), identificam práticas de referência para a gestão da engenharia de software e quando as mesmas devem ser aplicadas, levando as organizações a compreender, a controlar e a melhorar os processos de desenvolvimento (Costa, Loureiro, & Reis, 2014).

Em projetos em que o desenvolvimento de software é feito envolvendo equipas multidisciplinares, o seu sucesso depende do desempenho dos elementos da equipa, como sucede em qualquer projeto que envolva interação entre pessoas (Moe, Dingsøyr, & Dybå, 2010). As equipas que trabalham colaborativamente, aumentam a possibilidade de obterem melhores resultados do que se os seus elementos atuassem de forma individual, uma vez que: i) é possível rentabilizar o mesmo trabalho com base no esforço e competências de cada elemento (Fuks et al., 2008) e ii) os elementos podem identificar antecipadamente inconsistências e falhas que decorrem durante o processo de desenvolvimento. É nesta dinâmica que as atividades de coordenação se tornam essenciais ao sucesso de desenvolvimento de um software educativo.

A Metodologia Híbrida de Desenvolvimento Centrado no Utilizador foi o primeiro processo analisado pelo modelo 4C. A MHDCU foi utilizada no desenvolvimento do recurso educativo Courseware Ser_e – “O Ser Humano e os Recursos Naturais”. Trata-se de um processo de desenvolvimento simples, iterativo e incremental que tem como “alicerces” princípios do Design Centrado no Utilizador (DCU), especificados na International Organization for Standardization 9241-210 (ISO9241-210, 2010) – Ergonomics of Human-System Interaction (210: Human-centred design for interactive systems). Na sua base encontra-se a estrutura disciplinada de processos de desenvolvimento, bem como práticas e valores dos métodos ágeis de desenvolvimento de software. O processo é constituído por 4 fases principais: planeamento, design, implementação e manutenção/operação. A prototipagem e a avaliação são realizadas de modo transversal a todo o processo (Costa, 2012a).

Seguidamente será descrito o modelo 4C dando enfâse à dimensão coordenação (segunda secção). Posteriormente, apresentamos o processo metodológico (terceira secção) e respetivo modelo de categorias da dimensão coordenação. Finalmente a análise interacções da dimensão coordenação (quarta secção) e as conclusões (quinta secção).

2. A Coordenação no Modelo 4C

Malone e Crowston (1994) definem coordenação como “managing dependencies between activities” sendo gerida por mecanismos de coordenação. Os mecanismos podem ser ubíquos (encontrados em muitos processos) ou variáveis (podem gerir muitos tipos de dependências). O trabalho cooperativo, de acordo com (Acuna, Gómez, & Juristo, 2009), exige um esforço suplementar de coordenação da equipa multidisciplinar, de forma a evitar que os fatores do comportamento, que surgem através da interação, tais como, conflitos, a coesão, a cooperação e a comunicação, levem a falhas.

A coordenação (ver Figura 1) organiza a equipa atribuindo tarefas para serem realizadas por determinada ordem, dentro de um determinado intervalo de tempo e cumprindo os objetivos inicialmente propostos (Raposo, Magalhães, Ricarte, & Fuks, 2001). A coordenação envolve ainda a articulação das diferentes tarefas, levando às ações necessárias para o trabalho cooperativo. As tarefas devem ser assumidas como um compromisso individual ou da equipa.

Os elementos de perceção são fundamentais para a coordenação da equipa. Com estes, é possível conhecer em que fase está o projeto e o que cada elemento está executar em determinada fase. Os elementos de perceção permitem transmitir ou provocar mudanças de forma a gerar um novo compromisso, controlando a qualidade do projeto com respeito aos objetivos previamente estabelecidos, evitando a duplicação de esforços. Como sugere a teoria da mente coletiva (Weick & Roberts, 1993), quando os membros da equipa mantêm a perceção do papel de cada um através da interação empenhada, maior será a garantia do bom desempenho da equipa (McChesney & Gallagher, 2004).

As informações são essenciais para o coordenador verificar se existem conflitos de interesse que prejudiquem a equipa e para identificar a capacidade e experiência de cada elemento da equipa multidisciplinar.

A Coordenação é uma das dimensões do modelo 4C. O modelo 4C (Figura 3) foi uma adaptação do modelo 3C de colaboração (Figura 2) que, por sua vez, surgiu na década de 90 e tem sido disseminado por diversos autores, tais como, Denise (1999), Borghoff & Schlichter (2000), Blois & Becker (2002) e essencialmente por Fuks e colaboradores (Fuks et al., 2005; Fuks et al., 2008; Pimentel et al., 2008). O modelo 3C tem sido usado para diferentes finalidades, tais como, classificar ferramentas colaborativas (Borghoff & Schlichter, 2000), para análise de interfaces com utilizadores e para avaliação de aplicações colaborativas (Neale, Carroll, & Rosson, 2004).

O modelo 4C difere do modelo 3C de colaboração pelo facto de se considerar que os conceitos de colaboração e cooperação são distintos. A fig. 3 bem como a descrição de cada componente do modelo 4C é a versão já com as alterações propostas incluídas.

O modelo 4C está assente em três pilares, que se descrevem sucintamente:

- Comunicação: partilha de informação e partilha de pontos de vista sobre o processo de desenvolvimento, essencialmente sobre as soluções de projeto (protótipos programados, documentos e protótipos em imagem). Nos compromissos, os elementos da equipa combinam as tarefas a executar, dependendo o sucesso na realização das tarefas definidas da sua autodisciplina. Os compromissos podem ser definidos a uma escala temporal, em que o elemento define uma data ou período para realização de determinada tarefa, ou não. A comunicação funciona como o contributo espontâneo emitido por um ou vários elementos da equipa multidisciplinar (emissores), sendo o seu impacto refletido pelos restantes elementos (recetores) através das interpretações/perceções e (re)ações.

- Colaboração e Cooperação: tarefas que a equipa multidisciplinar desenvolve em conjunto (colaborativamente) ou individualmente (cooperativamente) mas com um objetivo comum, através de um espaço partilhado. Na colaboração e cooperação é normal que se contribua ou solicite feedback sobre as soluções de projeto apresentadas (protótipos ou documentos), estando este na maioria das vezes associado à discussão (através de sugestões, da concordância/discordância e da formulação de perguntas) de soluções de projeto. A concordância pode ser total ou parcial com ressalvas. A discordância pode ser complementada com um argumento ou apresentada uma proposta alternativa. A clarificação é um fator essencial da colaboração e cooperação, permitindo o esclarecimento ou explicação de situações pouco claras ou problemas. A persistência dos elementos da equipa multidisciplinar é demonstrada na realização das tarefas, nas sugestões e nas novas soluções de projeto.

- Coordenação: a coordenação organiza a equipa, negociando/atribuindo tarefas para serem realizadas por determinada ordem, de forma a cumprir os objetivos propostos. A coordenação tem ainda a responsabilidade de gerir conflitos associados a atitudes de competição, à desorientação, a problemas de hierarquia e à difusão de responsabilidade. Compete-lhe preparar a equipa multidisciplinar para o trabalho colaborativo e cooperativo, através da preparação de ações (pré-articulação), na execução de tarefas (insistência) e gerindo as interdependências, tendo em conta que a execução de uma tarefa afeta outras tarefas e todo o processo de desenvolvimento. Uma caraterística de interdependência é a reciprocidade, que significa que os elementos da equipa são mutuamente interdependentes (Molleman, Nauta, & Jehn, 2004).

3. Processo Metodológico

Inúmeras vezes e por diferentes motivos (geográficos, de agenda, entre outros) as tarefas que constituem o desenvolvimento de software educativo poderão necessitar de ocorrer à distância. Surgem assim novos desafios aos processos de desenvolvimento de software, que necessitam de ferramentas que permitam a interação entre os elementos da equipa multidisciplinar. A utilização de software colaborativo, normalmente designado como groupware, tem sido explorado dado integrar diferentes ferramentas de comunicação, de coordenação e de colaboração e cooperação.

De suporte a estas atividades foi utilizado como software colaborativo (groupware) a plataforma Learning Management System (LMS) moodle (moodle é um software livre, de apoio à aprendizagem, que funciona num ambiente virtual). Apesar de esta plataforma não ter sido desenvolvida especificamente para a gestão de projetos de desenvolvimento de software educativo, a mesma foi essencial para a interação entre os elementos da equipa multidisciplinar, disponibilização de versões de software, debate de ideias, entre outros (Costa et al., 2010c). A seleção desta plataforma em detrimento de outra deveu-se à familiaridade e conhecimentos que o Gestor de Projeto detinha sobre a mesma.

Os fóruns permitiram que as interações ficassem organizadas e disponíveis para serem revisitadas, podendo ter levado os elementos da equipa a usar esta ferramenta em detrimento de outras. Além disso, a utilização dos fóruns permitiu a disponibilização e discussão das soluções de projeto e perceber o fluxo de posts submetidos pelos diferentes elementos da equipa multidisciplinar, evidenciando-se uma excelente ferramenta para as atividades de Coordenação.

Seguidamente apresenta-se parte da análise estatística descritiva bem como análise de conteúdo da dimensão coordenação (Costa et al., 2014).

4. Análise da Dimensão Coordenação

Análise Estatística Descritiva

Por forma ajudar a compreensão da análise efetuada à dimensão coordenação, considera-se ser importante perceber o grau de envolvimento dos elementos da equipa multidisciplinar, de forma a poder analisar e discutir os resultados em torno de evidências, quantificando assim os posts submetidos e, fundamentá-las, embora com algumas ressalvas decorrentes do referido envolvimento. Duim, Anderssin & Sinnema (2007) designam como Free Riders os elementos de uma equipa multidisciplinar desmotivados/pouco participativos no processo de desenvolvimento. Os mesmos autores afirmam que a falta de interesse ou a falta de competências sociais são dois dos fatores que caracterizam estes elementos. Por outro lado, a falta de interesse, a que se referem não se coaduna com um dos valores dos métodos ágeis: a responsabilização e a autodisciplina, caraterísticas que os elementos de uma equipa multidisciplinar devem ter (Sommerville, 2007).

A figura 4 apresenta a autoria dos 292 posts submetidos pelos elementos da equipa multidisciplinar, ao longo do processo de desenvolvimento do Courseware Ser_e.

 

]]> Dos 292 posts submetidos, 53,1% (150 posts) são da autoria do Gestor de Projeto. Os Designers-Ilustradores (A e B) bem como os Programadores (A e B) envolveram-se minimamente ou não se envolveram (no caso do Designer-Ilustrador B), na discussão das soluções de projeto através dos fóruns disponibilizados no moodle (3,4% o que equivale a 10 posts). A falta de interesse foi um dos fatores que, no decorrer do desenvolvimento do Courseware Ser_e, levaram à pouca interação por parte do Programador A e do Designer-Ilustrador B, elementos que acabaram por ser substituídos no projeto. A pouca participação na discussão das soluções de projeto, por parte dos designers e dos programadores, pode prender-se também com o facto de terem uma disponibilidade restrita para o projeto, como acima indicado.

Associado à coordenação surge o papel do Gestor de Projeto. Das soluções de projeto submetidas, 77,5% dos posts (100 posts) foram da autoria do Gestor de Projeto (figura 5a)). Esta percentagem, evidencia uma vez mais, uma maior envolvência por parte do Gestor de Projeto, apesar da existência de dois Designers-Ilustradores, elementos da equipa multidisciplinar responsáveis pelo desenvolvimento técnico dos protótipos em imagem. Uma vez que estes elementos pouco interagiram nos fóruns, essa responsabilidade recaiu no Gestor do Projeto (figura 5b)).

 

No que respeita à submissão de documentos (guiões e outros textos), existiu uma maior envolvência por parte dos dois investigadores e dos dois peritos da equipa multidisciplinar. Da figura 5a) conclui-se que estes quatro elementos submeteram 22,5% dos documentos (29 posts) e que o Gestor do Projeto disponibilizou 31,8% (41 posts) dos documentos (figura 5b)).

O papel ou responsabilidade do Gestor de Projeto não passou apenas por garantir a execução das tarefas, alocando recursos por um determinado período de tempo. Como acima referido, o Gestor de Projeto foi o elemento mais interventivo e dinâmico. Atendendo à caraterização dos elementos da equipa relativamente à disponibilidade para o desenvolvimento do Courseware Sere, o facto do Gestor de Projeto ser o único elemento a tempo inteiro no projeto, pode justificar a sua maior envolvência.

Análise de Conteúdo

A dimensão “Coordenação” no modelo proposto abrange a execução de tarefas (única categoria desta dimensão) e está orientada para o trabalho realizado pelo Gestor de Projeto ou elementos que assumam este papel (tabela 1). Segundo Ribeiro (2007), as tarefas numa fase inicial envolvem, normalmente, a definição de requisitos e a caraterização do software, ou seja, definem o âmbito do trabalho a desenvolver em termos de dimensão e da complexidade.

 

]]> A dimensão “Coordenação” compreende a pré-articulação (18 referências) de ações de forma a “orientar” a colaboração e cooperação. A pré-articulação, à semelhança do que é descrito no método ágil Extreme Programming, como planeamento incremental (Beck, 2000), facilita a apresentação de forma célere de um plano global, que evolui durante o ciclo de vida do projeto, sendo flexível, e alterando com a implementação de funcionalidades, respondendo a mudanças.

Ao longo do processo de desenvolvimento do courseware, a pré-articulação permitiu, como sugerem (McChesney & Gallagher, 2004), que a equipa tivesse conhecimento do que cada elemento estava/ia executar, potenciando o seu bom desempenho, tal como é evidenciado nas seguintes referências.

“Assunto: Re: Ecrãs

Enviado: Gestor de Projeto, segunda-feira, 9 de junho de 2008, 11:47

Programador-A, Designer-Ilustrador A e Designer-Ilustrador B, coloquei na pasta de Material em Formato Vetorial, a versão 6.2.

(…) Designer-Ilustrador B está a fazer o MovieClip. (…) Designer-Ilustrador A está a fazer as ilustrações para as animações da FASE 2. (…) Designer-Ilustrador A as melhorias/alterações que ainda faltam nos ecrãs devem ser enviadas o quanto antes, para o Programador A efetuar as alterações. (…)”

A pré-articulação também teve como propósito identificar objetivos e distribuir tarefas para serem realizadas pelos elementos da equipa multidisciplinar, como evidenciam as seguintes referências:

“Assunto: Re: Ecrãs

Enviado: Gestor de Projeto, segunda-feira, 9 de junho de 2008, 11:47

(…)Programador-A, é necessário começar a animar, por exemplo o ecrã da escolha das personagens, o ecrã da escolhas das fases, o ecrã da entrada... (…) Investigador em Didática das Ciências, era importante que os textos desta legenda ficassem mais pequenos.

]]> (…) Investigadora em Didática das Ciências e Tecnologia Educativa e Investigadora em Didática das Ciências não se esqueçam dos textos. (…)”

“Assunto: Re: Ilustrações para animações da Fase II - Cenário 1

Enviado: Gestor de Projeto, quinta-feira, 10 de julho de 2008, 12:30

(…) Ilustrador-Designer A convém ler os textos que a Investigadora em Didática das Ciências e Tecnologia Educativa fez para a descrição das animações (ver o wiki que se encontra no espaço da FASE 2). (…) Perito em Didática das Ciências, seria importante que verificasse a alteração dos textos da Fase 2 (ver textos).(…)”

“Assunto: Re: Pegada Ecológica

Enviado: Gestor de Projeto, terça-feira, 13 de janeiro de 2009, 16:02

(…) Investigador em Didática das Ciências e Tecnologia Educativa e o Investigador em Didática das Ciências: Adaptar a tabela seguinte de forma que se possa representar por Planetas:

(…) Fazer os textos de introdução e conclusão da Pegada Ecológica;

(…) O Guião de Exploração Didática - Professor deverá ser alterado pela Investigadora em Didática das Ciências e Tecnologia Educativa e a Investigadora em Didática das Ciências e ser enviado para a Perita em Tecnologia Educativa e Perito em Didática das Ciências.

(…) Perita em Tecnologia Educativa e Perito em Didática das Ciências: Verificar novamente as questões da Pegada Ecológica, mencionando neste espaço quais as questões em que o utilizador poderá escolher como resposta, mais do que uma opção.(…)”

]]> Algumas tarefas não foram atribuídas diretamente a um ou mais elementos da equipa multidisciplinar. Nestas, era importante o envolvimento da maioria ou de todos elementos da equipa, numa articulação concertada e criativa, promovendo assim o trabalho colaborativo. As seguintes referências são exemplos deste tipo de situações:

“Assunto: Ecrãs Fase II

Enviado: Gestor de Projeto, quarta-feira, 21 de maio de 2008, 11:11

(…) É necessário preparar os textos de apoio/ajuda para o Ecrã 1 desta FASE, em que o aluno/professor irá perceber o que se pretende nesta FASE.(…) Relativamente à descrição dos 6 (seis) cenários, será necessário também, preparar os textos de apoio o quanto antes.(…)”

“Assunto: Re: Ilustrações para animações da Fase II - Cenário 1

Enviado: Gestor de Projeto, quinta-feira, 10 de julho de 2008, 12:30

(…) Está em anexo a versão 2 do Ecrã 1 (América Norte) para que seja aprovada pela equipa de projeto.(…)”

“Assunto: Re: Dossiers de Exploração Didática - FASE 1

Enviado: Gestor de Projeto, quarta-feira, 28 de janeiro de 2009, 17:32

(…) Pedia que tentassem ler este guião antes da próxima reunião de forma que a mesma seja mais produtiva possível. (…)”

]]> No desenvolvimento do courseware, não foi dada muita relevância ao fator tempo. Partiu-se do pressuposto que os elementos da equipa multidisciplinar eram autodisciplinados e executariam as tarefas da forma mais célere possível. Contudo, quando tal não sucedida, essencialmente o Gestor de Projeto, submetia posts de insistência (28 referências), que foram também codificados na categoria coordenação, apelando à realização das tarefas.

A subcategoria interdependência (48 referências) na realização das tarefas foi uma atividade essencialmente gerida pelo Gestor de Projeto, realçando assim, uma vez mais, a reduzida alternância de coordenação no decorrer do processo de desenvolvimento (ver tabela 2).

 

Uma caraterística da interdependência é a reciprocidade, o que significa que os elementos da equipa são mutuamente interdependentes (Molleman et al., 2004). A subcategoria interdependência foi dividida em dois indicadores: interdependência direcionada e interdependência geral. Na interdependência direcionada, os posts eram submetidos ao conhecimento de todos os elementos mas, no seu conteúdo, continha palavras/frases que os direcionavam apenas para determinado(s) elemento(s) da equipa multidisciplinar, como exemplificado a seguir.

“Assunto: Re: Manchas Florestais

Enviado: Perito em Didática das Ciências, domingo, 18 de janeiro de 2009, 22:06

(…) Peço à Investigadora em Didática das Ciências e Tecnologia Educativa para consultar um docente do Depart. de Biologia da UA ou UP para confirmar as designações das várias florestas.(…)”

Tendo em conta o acima ilustrado, pode associar-se a interdependência direcionada à divisão ou atribuição de tarefas e, por conseguinte à pré-articulação e ao trabalho cooperativo, ou seja, a execução de tarefas de modo individual em que o seu resultado será a base de trabalho de outro elemento (podendo ser o elemento anterior), ocorrendo iterações até ao incremento na solução global.

Na interdependência geral, um ou vários elementos aguardam por feedback dos outros elementos da equipa multidisciplinar para avançar com a execução de determinada tarefa. Esta interdependência geral também pode ter lugar quando um dos elementos necessita de feedback de parte ou de todos os elementos da equipa multidisciplinar.

]]> “Assunto: Re: Ecrãs Fase II

Enviado: Gestor de Projeto, domingo, 25 de maio de 2008, 18:15

Interfaces_Fase2_vers2.pdf

Boa tarde, é necessário que deixem ficar as Vossas opiniões relativamente aos Ecrãs da Fase 2.(…)”

As mensagens de insistência (28 referências) podem ser uma repetição de uma mensagem de pré-articulação ou interdependência que é submetida/enviada por ausência de feedback dos destinatários. Na referência seguinte, o Gestor de Projeto insistiu no feedback dos elementos da equipa multidisciplinar, de forma a que Designer-Ilustrador B pudesse continuar a ilustração dos cenários (exemplo de interdependência). O primeiro post, enviado a 2 de junho de 2008, é exatamente igual ao que se apresenta nesta referência (segundo post), enviado a 23 de junho de 2008.

“Assunto: Re: Ecrãs Fase II

Enviado: Gestor de Projeto, segunda-feira, 23 de junho de 2008, 02:20

Boa noite, deixo ficar esta mensagem tendo em vista recolher a Vossa opinião sobre a forma como irão surgir as animações da Fase II. Passo a descrever as imagens abaixo apresentadas.

Quando o utilizador escolhe no Planisfério África, surge o 1º ecrã, que passará em 3 segundos para o 2º ecrã. Sendo assim:

O tipo de ilustração adequa-se ao que é pretendido?

]]> Era necessário saber isto o quanto antes, para o Designer-Ilustrador B poder ilustrar os 5 cenários que faltam. (…)”

A maioria das mensagens de insistência foi enviada quando um ou vários elementos não contribuíram para resolução da situação ou problema. As referências seguintes evidenciam mensagens de insistência cujo enfoque se rendia com a validação de soluções de projeto, mais especificamente no que respeita ao manual de utilização do courseware:

“Assunto: Re: Introdução e Manual de Utilizador

Enviado: Gestor de Projeto, sexta-feira, 16 de janeiro de 2009, 16:22

Introd_MUtilizador_vers2.5_.doc

(…) Pedia que voltassem a rever o documento que segue em anexo.(…)”

“Assunto: Re: Introdução e Manual de Utilizador

Enviado: Gestor de Projeto, domingo, 25 de janeiro de 2009, 23:57

ManualUtilizador_vers3_.doc

Pedia que verificassem o Manual do Utilizador de forma a poder terminar paginação do mesmo.(…)”

]]> “Assunto: Re: Introdução e Manual de Utilizador

Enviado: Gestor de Projeto, quinta-feira, 29 de janeiro de 2009, 10:54

ManualUtilizador_vers3.2_.doc

Bom dia, pedia a todos que verificassem o Manual do Utilizador. (…)”

Pode ocorrer ausência de feedback, por partes dos elementos da equipa, por diferentes motivos: não se identificam como responsáveis pela realização da tarefa; falta de disponibilidade por estarem a realizar outras tarefas; ou considerarem que o seu contributo não é necessário.

O excesso de posts com atribuição de tarefas, a alteração de soluções de projeto, entre outros, pode levar ao surgimento de conflitos. Esta subcategoria definida dentro da categoria tarefas, está dividida em quatro indicadores: competição, desorientação, problemas de hierarquia e a difusão da responsabilidade (Acuna et al., 2009). Nos 292 posts analisados, apenas extraímos dois estratos que evidenciam situações de conflito: desorientação (1ª referência) e difusão da responsabilidade (2ª referência) respetivamente.

“Assunto: Re: Ecrãs Fase II

Enviado: Designer-Ilustrador A, terça-feira, 3 de junho de 2008, 03:05

(…) vou desenhar pandas, ursos, floresta, tipos a cortar árvores?(…) isso não ficou esclarecido...está muito em fase embrionária. (…) as animações não podem ser feitas assim. eu não consigo...(…) Mas não sei mais concretamente o que hei-de desenhar para compor uma animação para cada um dos cenários...(…)”

“Assunto: Re: Pegada Ecológica

]]> Enviado: Perito em Didática das Ciências, sexta-feira, 23 de janeiro de 2009, 16:28

(…) Quanto à validação de peritos (das áreas "científicas" mais focadas no courseware) face à falta de tempo, proponho já o compromisso de, depois, com uma versão completa, pedir (e pagar, o que penso que será a LudoMedia) a 2 peritos (um deles eu tenho já uma ideia face à qualidade do que faz a este nível) a revisão e na 2ªedição incluir na ficha técnica (ver como se fez nos guiões didáticos do PFEEC do 1º CEB) o nome destes dois revisores científicos. (…) Bem, isto não é discutível, nem calendarizável. (…)”

Considera-se que a ausência de conflitos do tipo problemas de hierarquia e competição pode ser positiva. Contudo, pode também ser um indicador de pouco envolvimento na discussão de soluções de projeto, não contribuindo ou marcando posições que levem ao surgimento de conflitos. Um conflito provocado e controlado pode ser um fator impulsionador para que elementos com reduzida participação se envolvam mais no projeto. Por outro lado, os conflitos quando descontrolados e mal geridos podem levar ao término de um projeto (Acuna et al., 2009).

 

Conclusões

A coordenação do projeto tem que estar sensibilizada para diferentes situações. Por exemplo, os autores Duim, Anderssin & Sinnema (Duim, Andersson, & Sinnema, 2007) designam como Free Riders os elementos de uma equipa multidisciplinar desmotivados/pouco participativos no processo de desenvolvimento. Os mesmos autores afirmam que a falta de interesse ou a falta de competências sociais são dois dos fatores que caraterizam estes elementos. Por outro lado, a falta de interesse, a que se referem não se coaduna com um dos valores dos métodos ágeis: a responsabilização e a autodisciplina, caraterísticas que os elementos de uma equipa multidisciplinar devem ter (Sommerville, 2007).

A falha de compromissos e o pouco envolvimento, conduziu a que durante o processo de desenvolvimento o Designer-Ilustrador A e o Programador A fossem dispensados/substituídos do projeto. O Designer-Ilustrador B deu continuidade ao projeto, acumulando os papéis e responsabilidades do Designer-Ilustrador A. Este processo foi facilitado pelo facto deste colaborador já ser um elemento da equipa multidisciplinar. O Programador B foi contratado para substituir o Programador A, tendo sido necessário algum tempo para que se integrasse na equipa multidisciplinar.

 

Referências

Acuna, S. T., Gómez, M., & Juristo, N. (2009). How do personality, team processes and task characteristics relate to job satisfaction and software quality? Information and Software Technology, 51, 627–639.         [ Links ]

Beck, K. (2000). Extreme Programming Explained: Embrace Change. The XP Series. Addison-Wesley. Retrieved from http://books.google.com/books?id=G8EL4H4vf7UC&dq=extreme+programming+explained+embrace+change&printsec=frontcover&source=bn&hl=pt-PT&ei=d24BS8mnHMa04QbhidWBDA&sa=X&oi=book_result&ct=result&resnum=4&ved=0CBcQ6AEwAw#v=onepage&q=&f=false        [ Links ]

Blois, A. P. T. B., & Becker, K. (2002). A Component-Based Architecture to Support Collaborative Application Design. Proceedings of the 8th International Workshop on Groupware: Design, Implementation and Use. La Serena, Chile: Springer-Verlag London, UK.         [ Links ]

Borghoff, U. M., & Schlichter, J. H. (2000). Computer-Supported Cooperative Work - Introduction to Distributed Applications (p. 509). Springer. Retrieved from http://books.google.pt/books?id=-G76znYAqqEC&pg=PA485&lpg=PA485&dq=borghoff+and+schlichter+-+computer-supported+cooperative+work&source=bl&ots=3Y0fJ7Djdl&sig=CEjqA451ZdoIlq172ocS_rNfZ-w&hl=pt-PT&ei=2xwnTYr0HMSZhQfwpdyWBQ&sa=X&oi=book_result&ct=result&resnum=1&ved=0CB8Q6AEwAA#v=onepage&q&f=false        [ Links ]

Costa, A. P. (2012a). Metodologia Híbrida de Desenvolvimento Centrado no Utilizador. Departamento de Educação e Departamento de Comunicação e Arte. Universidade de Aveiro, Aveiro.         [ Links ]

Costa, A. P. (2012b). Metodologia Híbrida de Desenvolvimento Centrado no Utilizador. Universidade de Aveiro.         [ Links ]

Costa, A. P., Loureiro, M. J., & Reis, L. P. (2009). Development Methodologies for Educational Software: the practical case of Courseware Sere. In E. and D. International Association of Technology (Ed.), International Conference on Education and New Learning Technologies (EDULEARN09). (pp. 5816–5825). Barcelona, Espanha: International Association of Technology, Education and Development (IATED).         [ Links ]

Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010a). Metodologia Híbrida de Desenvolvimento Centrado no Utilizador aplicada ao Software Educativo António. Revista Ibérica de Sistemas E Tecnologias de Informação (RISTI), 6, 1–15.         [ Links ]

Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010b). Metodologia Híbrida de Desenvolvimento Centrado no Utilizador: o caso prático do Courseware Sere. 5a Conferência Ibérica de Sistemas E Tecnologias de Informação (CISTI2010). Santiago de Compostela, Espanha: Associação Ibérica de Sistemas e Tecnologias de Informação.         [ Links ]

Costa, A. P., Loureiro, M. J., & Reis, L. P. (2014). A Importância da “Coordenação” no Desenvolvimento de Software Educativo. In A. P. Costa, L. P. Reis, F. N. de Souza, & R. Luengo (Eds.), 3o Congresso Ibero-Americano em Investigação Qualitativa (CIAIQ2014). Badajoz: Ludomedia.         [ Links ]

Costa;, A. P., & Costa, E. B. (2013). Contributos para o Desenvolvimento de Software Educativo tendo por base Processos Centrados no Utilizador. EM TEIA | Revista de Educação Matemática E Tecnológica Iberoamericana, 4(2), 1–15.         [ Links ]

Crowston, K. (1994). The Interdisciplinary Study of Coordination. Computing Surveys, 26(1), 87–119.         [ Links ]

Denise, L. (1999). Collaboration vs. C-Three (Cooperation, Coordination, and Communication). Innovating, 7(3). Retrieved from http://www.practitionerresources.org/cache/documents/646/64621.pdf        [ Links ]

Duim, L. van der, Andersson, J., & Sinnema, M. (2007). Good Practices for Educational Software Engineering Projects. Proceedings of the 29th International Conference on Software Engineering. Minneapolis, USA: IEEE Computer Society.         [ Links ]

Ellis, C., Gibbs, S., & Rein, G. (1991). Groupware: Some Issues and Experiences. Communications of the ACM, 34(1), 38–58.         [ Links ]

Fuks, H., Raposo, A., Gerosa, M. A., Pimentel, M., Filippo, D., & Lucena, C. (2008). Inter- and intra-relationships between communication coordination and cooperation in the scope of the 3C Collaboration Model. 2008 12th International Conference on Computer Supported Cooperative Work in Design, 148–153. doi:10.1109/CSCWD.2008.4536971        [ Links ]

ISO15504. (2004). Information technology - Process assessment. Part 1 - Concepts and Vocabulary.

ISO9241-210. (2010). Ergonomics of Human-System Interaction (210: Human-centred design for interactive systems). Geneva: International Standards Organisation.

McChesney, I. R., & Gallagher, S. (2004). Communication and co-ordination practices in software engineering projects. Information and Software Technology, 46(7), 473–489. doi:10.1016/j.infsof.2003.10.001        [ Links ]

Miguel, A. (2003). Gestão de Projectos de Software. Engenharia de Software (p. 498). FCA - Editora de Informática.         [ Links ]

Moe, N. B., Dingsøyr, T., & Dybå, T. (2010). A teamwork model for understanding an agile team: A case study of a Scrum project. Information and Software Technology, 52, 480–491.         [ Links ]

Molleman, E., Nauta, A., & Jehn, K. A. (2004). Person-job ?t applied to teamwork: a multi-level approach. Small Group Research, 35, 515–539.         [ Links ]

Neale, D. C., Carroll, J. M., & Rosson, M. B. (2004). Evaluating computer-supported cooperative work: models and frameworks. (A. C. M. Press, Ed.)ACM Conference on Computer Supported Cooperative Work . New York.         [ Links ]

Pimentel, M., Fuks, H., & Lucena, C. J. P. (2008). Um Processo de Desenvolvimento de Sistemas Colaborativos baseado no Modelo 3C?: RUP-3C-Groupware, 35–47.

Raposo, A. B., Magalhães, L. P., Ricarte, I. L. M., & Fuks, H. (2001). Coordination of collaborative activities: A framework for the definition of tasks interdependencies. In 7th International Workshop on Groupware (CRIWG 2001) (pp. 170–179). Darmstadt, Alemanha.         [ Links ]

Ribeiro, N. (2007). Multimédia e Tecnologias Interactivas. (2a Edição Actualizada, Ed.)Tecnologias de Informação (p. 478). Lisboa: FCA - Editora de Informática.         [ Links ]

Sá, P., Guerra, C., & Costa, A. P. (2012). Development of digital educational resources for education for sustainable development: the Courseware Sere. In B. Lazar (Ed.), XIV IOSTE - International Organization for Science and Technology Education. Bled: Eslovénia.         [ Links ]

Sá, P., Guerra, C., Martins, I. P., Loureiro, M. J., Costa, A. P., & Reis, L. P. (2010). Desenvolvimento de Recursos Didácticos Informatizados no Âmbito da Educação para o Desenvolvimento Sustentável. O Exemplo do Courseware Sere. Revista Eureka Sobre Enseñanza Y Divulgación de Las Ciencias, 7, 330–345.         [ Links ]

Sommerville. (2007). Software Engineering (8 Eda., p. 840). Boston: Addison Wesley.         [ Links ]

Weick, K. E., & Roberts, K. H. (1993). Collective mind in organisations: heedful interrelating on ?ight decks. Administrative Science Quarterly, 38, 357–381.         [ Links ]

Recebido / Recibido: 11/3/2014

Aceitação / Aceptación: 16/8/2014