Do Modelo 3C de Colaboração ao Modelo 4C: Modelo de Análise de Processos de
Desenvolvimento de Software Educativo
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.1Modelo 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
softwarecolaborativo, 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.2Modelo 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 distintos
1
. 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 CoursewareSere, 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.1Recolha 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 moodlecomo 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.2Aná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 poststendo 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 CoursewareSerepretende-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 webQDA
2
(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
9126
4
, 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.
