SciELO - Scientific Electronic Library Online

 
 número27Panorama das políticas públicas na educação brasileira: uma análise das avaliações externas de sistemas de ensinoEuropean and Latin American Higher Education Betwwen Mirrors: Conceptual Framewoks and Policies of Equity and Social Cohesion índice de autoresíndice de assuntosPesquisa de artigos
Home Pagelista alfabética de periódicos  

Serviços Personalizados

Journal

Artigo

Indicadores

Links relacionados

  • Não possue artigos similaresSimilares em SciELO

Compartilhar


Revista Lusófona de Educação

versão impressa ISSN 1645-7250

Rev. Lusófona de Educação  no.27 Lisboa set. 2014

 

ARTIGOS

 

Do Modelo 3C de Colaboração ao Modelo 4C: Modelo de Análise de Processos de Desenvolvimento de Software Educativo

From the 3C Collaboration Model towards a 4C Model: An Analysis Model for Educational Software Development Processes

Du Modèle de Collaboration 3C vers un Modèle 4C: Un Modèle d’analysedes Processus de Développement de Logiciels Éducatifs

Desde el Modelo de Colaboración 3C hacia un Modelo 4C: An Analysis Model for Educational Software Development Processes

 

António Pedro Costa*, Maria João Loureiro** & Luís Paulo Reis***

 

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

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

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

 

RESUMO

A melhoria de processos de desenvolvimento de software pressupõe uma equipa composta por elementos altamente motivados, com muito boa capacidade de trabalho e com elevada experiência. Este tipo de equipa permite a implementação de ferramentas e técnicas que ajudem a melhorar a comunicação, a coordenação e a colaboração e cooperação, minimizando assim as falhas decorrentes dos processos de desenvolvimento. Acreditando nestes princípios surgiu o modelo 4C como uma melhoria do modelo 3C de colaboração. Este modelo foi inicialmente proposto para analisar a Metodologia Híbrida de Desenvolvimento Centrado no Utilizador (MHDCU) usada no desenvolvimento do recurso educativo Courseware Sere – O Ser Humano e os Recursos Naturais. O modelo 4C tem como objetivo analisar e propor melhorias a processos de desenvolvimento de software, essencialmente educativo. Este estudo descreve o modelo 3C de colaboração e a sua evolução para o modelo 4C. Para isso apresenta o processo de recolha e de análise dados, bem como a técnica que foi preconizada para análise dos dados recolhidos tendo por base o desenvolvimento do recurso educativo Courseware Sere. O modelo 4C permitiu identificar melhorias à MHDCU, ajustando os métodos atuais de desenvolvimento e implementando novos métodos do Design Centrado no Utilizador.

Palavras-chave: modelo 3C de Colaboração; modelo 4C; metodologia híbrida de desenvolvimento centrado no utilizador; courseware Sere; software educativo.

 

ABSTRACT

Software process improvement requires a team composed by highly motivated members, good working capabilities and large experience. This type of team allows the implementation of tools and techniques that help to improve communication, coordination and collaboration and cooperation, thus minimizing failures resulting from the development process. Believing on these principles the 4C model emerged as an improvement of the 3C collaboration model. This model was proposed to analyze the Hybrid Methodology for User Centered Development (HMUCD) used to develop the educational resource Courseware Sere - The Human Being and Natural Resources. The 4 model objective is to analyze and propose improvements to educational software development processes. In this study we describe the 3C collaboration model and its evolution to the 4C model. For this we present the data collection and analysis process as well as the techniques used for data analysis and used on the development of the educational resource - Courseware Sere. The 4C model allowed us to identify improvements to HMUCD by adjusting the current development methods and implementing new methods of User Centered Design.

Keywords: 3C collaboration model; 4C model; hybrid methodology for user centered development; courseware sere; educational software.

 

RÉSUMÉ

L’amélioration des processus de développement de logiciels présuppose une équipe avec des éléments profusément motivés et ayant une bonne capacité et expérience. Ceci permet la mise en œuvre d’outils et de techniques qui aident à améliorer la communication, la coordination et la collaboration et coopération, minimisant ainsi les faillites dues aux processus de développement. Le modèle 4C est, ainsi, apparu en tenant compte de ces principes et a été adapté à partir du modèle de collaboration 3C afin d›analyser et de proposer des améliorations aux processus de développement de logiciels éducatifs. Le modèle 4C a été proposé pour analyser la méthodologie hybride de développement centrée sur l›utilisateur (MHDCU) utilisée pour développer le logiciel éducatif Courseware Sere - l›Être humain et les Ressources Naturelles. Dans cette étude, nous décrivons le modèle de collaboration 3C et son évolution vers le modèle 4C. Pour cela, nous présentons le processus pour collecter et analyser les données ainsi que la technique qui a été recommandée pour l’analyse de données recueillies ayant comme base l’élaboration du logiciel pédagogique Courseware Sere. Le modèle 4C a permis d’identifier les améliorations par rapport à l’ MHDCU en ajustant les méthodes actuelles de développement et implémentant de nouvelles méthodes de  design  centrées sur l’utilisateur.

Mots-clés: modèle 3C; modèle 4C; méthodologie hybride de développement centrée sur l›utilisateur; Courseware Sere; logiciel éducatif.

 

RESUMEN

La mejoría de procesos de desenvolvimiento de software presupone un equipo compuesto por miembros altamente motivados, con gran capacidad de trabajo y una gran experiencia. Esto permite la implementación de herramientas y técnicas que ayudan a mejorar la comunicación, coordinación, colaboración y cooperación, minimizando fallas correspondientes a procesos de desarrollo. Creyendo en estos principios surgió el modelo 4C como una mejoría del modelo 3C de colaboración. El modelo, fue propuesto para analizar la Metodología Híbrida de Desarrollo Centrado en el Utilizador (MHDCU) usada para desenvolver el recurso educativo Courseware Sere – El Ser Humano y los Recursos Naturales. El modelo 4C tiene el objetivo de analizar y proponer mejorías de procesos de desarrollo del software educativo. En este estudio describimos el modelo 3C de colaboración y su evolución para el modelo 4C. Para esto presentamos los procesos de busca y análisis de datos, bien como la técnica que fue preconizada para analice de los datos recogidos teniendo por base el desarrollo del recurso educativo Courseware Sere. El modelo 4C permitió la identificación de mejorías à la MHDCU, ajustando los métodos actuales de desenvolvimiento y implementando nuevos métodos de Desarrollo Centrado en el Utilizador.

Palabras clave: análisis de interacción; modelo 4C; metodología híbrido centrado en el usuario; courseware sere; software educativo.

 

 

1. Introdução

A melhoria de processos de desenvolvimento de software, usualmente, é caraterizada por ser um trabalho de equipa e contínuo, necessitando de investimento, de planeamento e dedicação, de um esforço consistente e persistente, de conhecimento do processo existente e de uma definição de objetivos claros para a melhoria dos mesmos. De acordo com Fantina (2005, p. 3) o ciclo de melhoria de processos de desenvolvimento de software, além de outros, é constituído pela análise dos processos e identificação das áreas chave para melhoramento.

Neste âmbito, com a finalidade de propor melhorias à Metodologia Híbrida de Desenvolvimento Centrado no Utilizador (MHDCU) (Costa, Loureiro, & Reis, 2010), propôs-se identificar os pontos fortes e as fragilidades da mesma, através de análise das interações que decorreram entre os elementos da equipa multidisciplinar durante a conceção do Courseware Sere – O Ser Humano e os Recursos Naturais (Sá et al., 2010). Alguns princípios desta metodologia foram definidos com base no estudo de Guerra, tais como, constituição de uma equipa multidisciplinar, avaliação formativa por parte de professores e peritos. Na continuidade, neste estudo, foram utilizados além dos anteriores, outros princípios e procedimentos em que se baseia esta metodologia de desenvolvimento (Costa; & Costa, 2013; Costa et al., 2010).

A MHDCU também teve por base princípios dos métodos ágeis, tais como, manutenção da simplicidade, isto é, foi desenvolvido o essencial de forma a responder aos requisitos atuais. A equipa (essencialmente os programadores) procurou corrigir e melhorar o código do software continuamente e a entrega foi incremental, dado que cada ecrã do software era independente dos outros ecrãs. Desta forma, enquanto uma solução era testada/validada/avaliada antes do incremento outras eram desenvolvidas com base nos requisitos.

O Courseware Sere integra várias tipologias de software (simulações, inquérito, pesquisa,…) com actividades didácticas especificadas em guiões de exploração, tanto para o professor, como para os alunos. Como se depreende a partir dos seus propósitos (promover a compreensão do impacte que a actividade humana tem sobre os recursos naturais e sensibilizar de que o futuro da Humanidade passará pela adopção de atitudes e comportamentos mais conscientes e responsáveis, nomeadamente no que respeita às fontes de energia utilizadas, em particular o petróleo e a floresta), visa uma abordagem à relação entre a actividade humana e a exploração dos recursos naturais, bem como das consequências ambientais, sociais e económicas desta exploração (Sá et al., 2010).

Para avaliar o processo de desenvolvimento foi usado o Modelo 4C adaptado do Modelo 3C de Colaboração que surgiu na década de 90 e tem sido disseminado, além de outros autores, por Fuks e colaboradores (2005). A partir deste Modelo foram definidas as categorias e subcategorias para análise do processo desenvolvimento preconizado pela MHDCU.

Na próxima secção apresentamos as principais implicações da melhoria de processos de desenvolvimento de software. Na secção 3 descreve-se o Modelo 3C de Colaboração e na secção 4 o Modelo 4C. Posteriormente, na penúltima secção, é descrito o processo que permitiu definir o modelo 4C e, finalmente, apresentam-se as conclusões.

 

2. Melhoria de Processos de Desenvolvimento de Softwar

Baddoo & Hall (2003) afirmam que um dos problemas, subjacentes à medida do impacto do Software Process Improvement, se prende com o facto não se ter dado muita atenção ao fator humano na execução destes processos, de forma a perceber o que leva profissionais desta área a ficarem desmotivados quando são envolvidos nesses processos. Tendo em vista compreendê-los expõe-se resumidamente os obstáculos à implementação do Software Process Improvement:

  • Resistência: um dos principais obstáculos à introdução de qualquer nova prática, é ausência de vontade dos profissionais que realmente a pode usar e implementar;
  • Inércia: o profissional quanto mais recorre a determinadas práticas, mais estas se enraízam, o que pode dificultar a adoção de outras práticas;
  • Experiência Negativa: uma experiência anterior menos positiva, por exemplo, na exploração de novas ferramentas ou técnicas, pode fazer com que os profissionais não demonstrem abertura à melhoria das suas práticas.

Os profissionais de desenvolvimento de software podem resistir às mudanças de prática percebendo que estas são uma ameaça à sua autonomia, não tendo a perceção dos benefícios destas mudanças, por falta de evidências concretas. É, consequentemente, importante que estes percecionem quais são os benefícios diretos antes de se integrarem no Software Process Improvement. Como referem Baddoo & Hall (2002), os profissionais não irão usar as novas práticas ou métodos se não for evidente que estas os ajudarão. É recorrente, muitas destes métodos e práticas serem impostos, sem existir a preocupação de consultar previamente os profissionais que as poderão colocar em prática. Uma outra barreira evidenciada são as pressões dos clientes que, normalmente servem de barreira ao Software Process Improvement, visto que as empresas têm que dar resposta às pressões comerciais “provocadas” pelos clientes.

Na análise qualitativa efetuada por Baddoo & Hall (2003), em que participaram 49 profissionais da área do desenvolvimento de software, os quatro principais fatores, identificados com maior frequência, designados como desmotivadores para Software Process Improvement foram: i) a pressão ou restrições temporais; ii) a inércia; iii) a falta de recursos e iv) as pressões comerciais. Para uma pequena e média empresa as restrições temporais e a falta de recursos poderá ser um entrave à introdução de práticas que melhorem o processo.

Se para os profissionais que desenvolvem software as restrições associadas ao tempo e ao orçamento estipulado para os projetos são fatores de desmotivação, será necessário refletir sobre a utilização de determinados métodos do Design Centrado no Utilizador, tais como, estudos de campo e entrevistas a utilizadores, que, necessitam de muito tempo para a sua aplicação e consequentemente um maior investimento (Vredenburg, Mao, Smith, & Carey, 2002).

 

3. Do Modelo 3C de Colaboração ao Modelo 4C

Nesta secção descrevemos o Modelo 3C de Colaboração e o processo de adaptação deste modelo até à definição do Modelo 4C.

3.1 Modelo 3C de Colaboração

O modelo 3C de colaboração (Figura 1) surgiu na década de 90 e tem sido usado para diferentes finalidades, tal como supracitado.

 

 

A comunicação no Modelo 3C de Colaboração compreende a troca de mensagens, bem como a negociação de compromissos. A cooperação envolve o trabalho em conjunto dos elementos da equipa, através de um espaço partilhado.

Na coordenação, as pessoas, as tarefas e os recursos são geridos para lidar com conflitos de interesse e tornar a comunicação e a cooperação o mais eficiente possível. De uma forma sintetizada, a necessidade de executar tarefas origina a negociação de compromissos através da comunicação, sendo geridos pela coordenação e realizados de forma cooperativa.

O modelo 3C assenta sobre três pilares, que passamos a descrever sucintamente:

Comunicação

No desenvolvimento de software, a comunicação normalmente envolve compromissos e negociação dos mesmos. A Figura 2 representa uma ação entre o emissor que, de acordo com os seus objetivos e compromissos, redige uma mensagem para ser enviada e o recetor que, ao receber e interpretar a mensagem, pode levar a que os seus compromissos e conhecimentos sejam modificados. Para transmitir o conteúdo da informação, o emissor transmite sinais numa linguagem apropriada e percetível para a interação com o recetor, de forma que todos possam perceber a mesma. Para transmitir a mensagem, é utilizada a ferramenta de comunicação através da qual se processa a interação.

 

 

Quando os elementos de uma equipa comunicam, normalmente, concentram-se no Nível da Argumentação, negociando compromissos e a responsabilização ou papéis nas tarefas. A comunicação será bem-sucedida se o objetivo do emissor resultar nos compromissos esperados. A única forma de se obter indícios do sucesso da comunicação é através do discurso e das ações (e reações) do recetor.

Coordenação

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 3) 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.

Cooperação

A cooperação poderá resumir-se ao trabalho que a equipa desenvolve em conjunto, com objetivo de conceber ou executar tarefas atribuídas pela coordenação (Figura 4). As tarefas passam essencialmente por desenvolver soluções de projeto, tais como, documentos e interfaces gráficas. A coordenação efetua a gestão das tarefas para atingir-se determinado objetivo (Malone & Crowston, 1990).

 

 

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.

Seguidamente apresentamos o modelo 4C. O processo metodológico que permitiu definir este modelo será apresentado e descrito na secção 4.

3.2 Modelo 4C

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 distintos1. A Figura 5 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.

• 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).

• 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.

A Tabela 1 apresenta as categorias, subcategorias e indicadores definidos para o Modelo 4C, tendo por base as dimensões anteriormente descritas.

 

 

Na secção seguinte apresentamos o processo metodológico que permitiu definir o Modelo 4C.

 

4. Processo Metodológico

A MHDCU foi a primeira metodologia analisada tendo por base o Modelo 4C. Pretendia-se compreender os pontos fortes e as fragilidades da MHDCU. A gestão do processo de desenvolvimento do recurso desenvolvido, o Courseware Sere, foi suportada pela plataforma LMS moodle, que serviu de groupware. A utilização do moodle permitiu registar as interações (através dos fóruns) dos elementos da equipa multidisciplinar durante o processo de desenvolvimento.

4.1 Recolha de Dados

Como referido, para a recolha de dados foi usado o moodle e a observação das interacções entre os elementos da equipa multidisciplinar como descrevemos seguidamente.

 

Moodle como Groupware (Registos de Interações)

Com a necessidade de gerir o projeto e conseguir concentrar a maioria da informação sobre o mesmo, a equipa multidisciplinar que desenvolveu o Courseware Sere, decidiu criar uma disciplina na plataforma moodle para funcionar como groupware. Ambicionava-se desta forma, facilitar o processo de colaboração e cooperação, de coordenação e essencialmente de comunicação entre os elementos envolvidos no projeto. A Figura 6 apresenta as ferramentas utilizadas tendo por base as dimensões do Modelo 4C.

 

 

Observação Participante

A técnica utilizada foi a observação das interações no decurso do Trabalho Colaborativo e Cooperativo Não Presencial entre os elementos da equipa multidisciplinar, especificamente interações decorrentes dos posts submetidos através dos fóruns disponibilizados.

Esta técnica apresentou como vantagens a apreensão dos comportamentos e acontecimentos no próprio momento em que se produziram; recolha de material não suscitado pelo investigador, portanto, espontâneo; e um maior grau de autenticidade dos acontecimentos, em comparação com os documentos escritos ou as respostas dadas a inquéritos. Porém, pode acarretar alguma dificuldade relacionada com a subjetividade inerente à interpretação das observações (Cohen, Manion, & Morrison, 2007).

A observação realizada neste estudo caracteriza-se por ser participante (direta), envolvendo a recolha de dados diretamente pelo próprio investigador, sem a intervenção dos sujeitos observados na produção da informação procurada (Ary, Jacobs, Sorensen, & Razavieh, 2010). Assim sendo, apesar do papel dos sujeitos observados na produção da informação recolhida, o investigador classificou esta observação como participante (direta), pois considerou que deteve um acesso às interações entre os elementos semelhante ao acesso dos próprios: consistiu essencialmente na leitura dos posts submetidos.

São exemplos de meios de observação, as grelhas, o guião ou roteiro-registo, o bloco de notas, e a máquina de filmar, entre outros, cuja adequação depende do fenómeno que se pretende observar (Ary et al., 2010). No caso estudado, como anteriormente referido, foi utilizada a plataforma moodle como instrumento de observação. A plataforma facilitou a recolha, dado ter permitido recolher uma elevada quantidade de dados, continuadamente ao longo do tempo. Comparativamente a outros meios (tais como os registos vídeo ou áudio), dispensou a realização de transcrições, o que facilitou o trabalho do investigador.

4.2 Análise de Dados

Uma parte considerável da qualidade final de um software educativo deve-se ao seu processo de desenvolvimento. Esta premissa, reforça a importância de se analisar os processos de desenvolvimento.

A análise de conteúdo é uma técnica de análise de dados utilizada para estudar o comportamento humano de uma forma indireta, através da análise dos textos produzidos. A análise de conteúdo pode ser efetuada a documentos, a transcrições de entrevistas, a artigos, a imagens, vídeos, entre outros. Esta técnica permite fazer uma descrição objetiva, sistemática e quantitativa ou qualitativa do conteúdo das interações, tendo por objetivo a sua interpretação (Cohen et al., 2007; Gray, 2004).

Seguidamente iremos apresentar o processo proposto para análise de dados tendo por base o modelo 4C.

Análise de conteúdo

Neste estudo, a análise de conteúdo seguiu os seguintes etapas: 1) Organização da Análise; 2) Exploração do Material e 3) Análise dos Resultados (Bogdan & Biklen, 1994). A nível metodológico seguiu-se um procedimento de categorização e as unidades de análise foram construídas com base na adaptação da estrutura básica de análise de conteúdo de Coehen, Manion & Morrison (2007) e Bardin (2013) tal como representa a Figura 7.

 

 

a. Organização da análise

Uma vez definido o corpus, que se apresentou ser adequado como fonte de recolha de dados, e representativo do objeto em estudo (pertinência), todos os elementos do conjunto foram considerados (exaustividade). Considerou-se que a amostra selecionada era representativa do universo em estudo (representatividade) (Bardin, 2013).

Na análise de conteúdo realizada partiu-se dos seguintes pressupostos:

  • As expressões usadas pelos elementos da equipa multidisciplinar no estudo representam de modo substancial as suas ideias;
  • A mesma ideia (ou ideias semelhantes) pode ser expressa através de palavras ou frases diferentes;
  • Os elementos são sinceros no que dizem, dado o seu envolvimento no estudo ser voluntário e anónimo.

Para a análise do processo de desenvolvimento do Courseware Sere foram analisados 292 posts tendo por base duas orientações:

• a análise estatística descritiva foi definida como unidade de registo a totalidade do post, pretendendo-se efetuar um enquadramento geral relativamente ao número de posts enviados, que elementos da equipa multidisciplinar enviaram os posts e com que frequência, quem submetia posts com soluções de projeto (protótipos em imagem, documentos e protótipos programados);
• A análise de conteúdo recai sobre factos e interpretações, sendo as unidades de registo definidas a frase ou conjunto de palavras (Bardin, 2013).

 

Identificação das dimensões, categorias, subcategorias e indicadores

Com a análise do processo de desenvolvimento do Courseware Sere pretende-se compreender os pontos fortes e as fragilidades da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador (Costa et al., 2010), através das interações ocorridas em ambiente não presencial (fóruns), por parte dos elementos da equipa multidisciplinar. Para isso, adotou-se uma perspetiva “nomotética”, em que parte das categorias e subcategorias foram previamente estabelecidas pela revisão da literatura (Bardin, 2013; Cohen et al., 2007) tendo por base o modelo 3C de colaboração e da sua adaptação para o que se designa como modelo 4C.

b. Exploração do Material O processo de exploração do material consistiu na administração sistemática das decisões tomadas durante a Organização da Análise e foi suportado pelo software de apoio à análise qualitativa webQDA2 (http://www.webqda.com).

Cada unidade de registo foi analisada pelo investigador, tendo em conta as subcategorias/indicadores definidos, e foi associada à categoria com a qual apresentava um maior grau de concordância. Desta forma, a codificação permitiu, através do tratamento dos dados, atingir uma melhor representação do seu conteúdo. A categorização forneceu uma representação simplificada dos dados, ou seja, passagem de dados em bruto para dados organizados. Por fim, “construiu-se” um conjunto de inferências sobre o que incidiu os dados organizados.

c. Análise de Resultados Na exploração do material, o corpus foi segmentado em unidades de registo e de contexto e distribuídas pelas dimensões e categorias estabelecidas anteriormente (Bardin, 2013). Com base nestes dados procedeu-se a operações estatísticas simples, tais como, o fluxo de interações entre os elementos da equipa multidisciplinar, fluxo mensal de mensagens durante o período de desenvolvimento do recurso, a quantidade de posts com soluções de projeto (protótipos em imagem, documentos e protótipos programados), com a finalidade de sustentar a análise de conteúdo efetuada a posteriori.

 

5. Conclusões

Sendo o desenvolvimento de software uma atividade imprevisível é necessário um método adaptável para controlar esta imprevisibilidade (Abbas, et al., 2008). Relativamente ao desenvolvimento de software educativo, os processos iterativos e incrementais, associados a procedimentos de prototipagem, incluindo ferramentas de avaliação e monitorização nas diferentes fases, são uma forma eficiente de um processo se adaptar à mudança constante de requisitos e da tecnologia (Costa et al., 2010). Concorda-se também, com a norma ISO 92412103, quando descreve que é essencial que os utilizadores, ou um grupo representativo dos mesmos, estejam envolvidos no processo de desenvolvimento, para que possam durante as tarefas identificar requisitos que devam ser incluídos nas especificações do software. Tal como sucede na Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, este feedback poderá surgir através da avaliação das soluções de projeto, suportada normalmente pelo desenvolvimento de protótipos.

As metodologias que tenham por base os pressupostos do Design Centrado no Utilizador, bem como as práticas e os valores dos métodos ágeis de desenvolvimento (Sommerville, 2007), requerem elementos na equipa multidisciplinar com determinado perfil. Desta forma, seria pertinente como melhoria do Modelo 4C, além da redefinição e possível inserção de novas categorias ao modelo apresentado, acrescentar uma nova dimensão ao modelo 4C, competências, passando este a designar-se como Modelo 5C (Comunicação, Coordenação, Colaboração e Cooperação e Competências).

O facto de existir comunicação, coordenação e colaboração e ainda cooperação entre os elementos da equipa, não garante que os mesmos tenham as competências necessárias para este fim. Desta forma, para a melhoria contínua de metodologias que tenham por base pressupostos do Design Centrado no Utilizador, bem como a “mediação” das métricas definidas pela norma ISO/IEC 91264, que no decorrer do desenvolvimento do courseware serviram de base ao desenvolvimento de instrumentos (inquéritos por questionário) de avaliação técnica e didática, seria relevante analisar as competências dos elementos da equipa multidisciplinar de forma assegurar a qualidade do processo de desenvolvimento e do software educativo (Beaver & Schiavone, 2006).

Na sequência do acima referido, aplicar ou desenvolver uma ferramenta que permitisse identificar e compreender (na fase inicial do processo) as caraterísticas de cada elemento da equipa multidisciplinar (ao nível das competências sociais, das capacidades técnicas e do conhecimento sobre as atividades a realizar, entre outros) face às especificidades do software educativo a desenvolver, poderia facilitar o seu desenvolvimento. Os métodos ágeis defendem que os elementos de uma equipa acreditam nas suas capacidades, demonstrando respeito e responsabilidade, com base no estabelecimento da confiança e garantia da qualidade de trabalho (Robinson & Sharp, 2004). Desta forma, a técnica definida por Young, Edwards, Mcdonald & Thompson (2005) designada por “reportory grid analysis” é uma possibilidade a explorar, dado identificar boas caraterísticas de personalidade dos elementos de equipas de desenvolvimento que utilizam o método ágil Extreme Programming.

 

Referências Bibliográficas

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.

Ary, D., Jacobs, L. C., Sorensen, C., & Razavieh, A. (2010). Introdution to Research in Education (8a ed.). Belmont, CA, USA.: Wadsworth.         [ Links ]

Baddoo, N. (2002). Software Process Improvement Motivators : An Analysis using Multidimensional Scaling, 93–114.

Baddoo, N., & Hall, T. (2003). De-motivators for software process improvement: an analysis of practitioners’ views. Journal of Systems and Software, 66(1), 23–33.

Bardin, L. (2013). Análise de Conteúdo. (3a Ed.) (Extra Cole). Lisboa: Edições 70.         [ Links ]

Beaver, J. M., & Schiavone, G. A. (2006). The Effects of Development Team Skill on Software Product Quality . ACM SIGSOFT Software Engineering Notes, 31(3).         [ Links ]

Bogdan, R., & Biklen, S. (1994). Investigação Qualitativa em Educação - Uma introdução à teoria e aos métodos. Colecção Ciências da Educação. Porto: Porto Editora.         [ Links ]

Cohen, L., Manion, L., & Morrison, K. (2007). Research Methods in Education (6a ed., p. 463). London and New York: Taylor & Francis Group.         [ Links ]

Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010). 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.

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.

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

Dillenbourg, P., Baker, M., Blaye, A., & O’Malley, C. (1995). The Evolution of Research on Collaborative Learning. In Learning in humans and machines. Towards an interdisciplinary learning science (pp. 189–211). London: Pergamon.

Fantina, R. (2005). Practical Software Process Improvement. Norwood: Artech House.         [ Links ]

Fuks, H., Raposo, A. B., Gerosa, M. a., & Lucena, C. J. P. (2005). Applying the 3C Model To Groupware Development. International Journal of Cooperative Information Systems, 14 (02n03), 299–328.

Gray, D. E. (2004). Doing Research in the Real World. Londres: Sage Publications.         [ Links ]

Malone, T. W., & Crowston, K. (1990). What is coordination theory and how can it help design cooperative work systems? Proceedings of the 1990 ACM Conference on Computer-Supported Cooperative Work - CSCW ’90, 357–370.

McChesney, I. R., & Gallagher, S. (2004). Communication and co-ordination practices in software engineering projects. Information and Software Technology, 46(7), 473–489.

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

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. Groupware, 2001. Proceedings of 7th International Workshop on Groupware (CRIWG 2001) (pp. 170–179). Darmstadt, Alemanha.

Robinson, H., & Sharp, H. (2004). The characteristics of XP teams, in Extreme Programming and Agile Processes in Software Engineering. Lecture Notes in Computer Science, 3092, 139–147.

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.

Sommerville. (2007). Software Engineering (8a ed.). Boston: Addison Wesley.         [ Links ] Vredenburg, K., Mao, J.-Y.,

Smith, P. W., & Carey, T. (2002). A survey of user-centered design practice. Proceedings of the SIGCHI Conference on Human Factors in Computing Systems Changing Our World, Changing Ourselves - CHI ’02, (1), 471.

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

Young, S. M., Edwards, H. M., Mcdonald, S., & Thompson, J. B. (2005). Personality Characteristics in an XP Team : A Repertory Grid Study, 1–7.

 

Data de submissão: Janeiro 2014
Data de avaliação: Abril 2014
Data de publicação: Setembro 2014

 

Notas

1 Na literatura é recorrente os termos colaboração e cooperação surgirem como sinónimos. Na realidade são conceitos diferentes, existindo apenas um fator que é análogo: os elementos trabalham para atingirem um objetivo comum. Para Dillenbourg, Baker, Blaye & O’Malley (1995) o trabalho cooperativo é ... accomplished by the division of labor among participants, as an activity where each person is responsible for a portion of the problem solving..., sendo o trabalho colaborativo ...mutual engagement of participants in a coordinated effort to solve the problem together. De forma complementar a Dillenbourg, Michael Schrage no livro Shared Minds define a colaboração como um ... process of shared creation: two or more individuals with complementary skills interacting to create a shared understanding that none had previously possessed or could have come to on their own. Collaboration creates a shared meaning about a process, a product, or an event. In this sense, there is nothing routine about it. Something is there that wasn’t there before. A definição de Michael Schrage acrescenta à de Dillenbourg que o trabalho colaborativo, além de envolver vários elementos, implica que as suas competências sejam complementares.

2 Software desenvolvido pelo Centro de Investigação Didática e Tecnologia na Formação de Formadores da Universidade de Aveiro e pela empresa Esfera Crítica.

3 Norma da International Standards Organisation sobre Ergonomics of Human-System Interaction (210: Human-centred design for interactive systems).

4 Norma da International Standards Organisation para a Avaliação da Qualidade de Produtos do Software.