Universidade de Aveiro Departamento de Educação
Departamento de Comunicação e Arte2012

António Pedro
Dias da Costa

Metodologia Híbrida de Desenvolvimento Centrado
no Utilizador

Universidade de Aveiro Departamento de Educação
Departamento de Comunicação e Arte2012

António Pedro
Dias da Costa

Metodologia Híbrida de Desenvolvimento Centrado
no Utilizador
Aplicada ao Software Educativo

Tese apresentada à Universidade de Aveiro para cumprimento dos requisitos
necessários à obtenção do grau de Doutor em Multimédia em Educação,realizada sob a orientação científica da Doutora Maria João Loureiro,
Professora Auxiliar do Departamento de Educação da Universidade de Aveiro e
sob coorientação científica do Doutor Luís Paulo Reis, Professor Associado do
Departamento de Sistemas de Informação da Escola de Engenharia da
Universidade do Minho.

Apoio financeiro da FCT
Ref. SFRH/BD/41356/2007)
e do FSE no âmbito do III Quadro
Comunitário de Apoio.

Àqueles que nunca desistem.

o júripresidente

Prof. Doutor Aníbal Manuel de Oliveira Duarte
professor catedrático da Universidade de Aveiro

Prof. Doutor David Ribeiro Lamas
professor of Institute of Informatics – Tallinn University (TU) - Estónia

Prof. Doutor Luis Paulo Reis
professor associado da Escola de Engenharia da Universidade do Minho (Coorientador)

Profª. Doutora Lia Raquel Oliveira
professora auxiliar do Instituto de Educação da Universidade do Minho

Profª. Doutora Maria João Loureiro
professora auxiliar da Universidade de Aveiro (Orientadora)

Prof. Doutor Francislê Neri de Souza
investigador auxiliar da Universidade de Aveiro

agradecimentos

Aos meus pais pelo exemplo de vida.
À minha esposa pelo apoio e horas de ausência.
À Professora Doutora Maria João Loureiro por ter-me desafiado e
acompanhado nesta aventura.
Ao Professor Doutor Luís Paulo Reis pelo incentivo e amizade.
Ao Professor Doutor Francislê Neri de Souza pelas horas de discussão.
Ao Professor Doutor António Moreira pelas observações pertinentes.
A toda a equipa que colaborou no desenvolvimento do Courseware Sere – “O
Ser Humano e os Recursos Naturais”, sem o qual não seria possível realizar
este estudo.
À Universidade de Aveiro, ao Departamento de Educação e ao CIDTFF
uma palavra especial de agradecimento pelo constante apoio e incentivo.
A concretização deste trabalho só foi possível pelas condições queme disponibilizaram.
À Fundação para a Ciência e a Tecnologia, sem a qual esta investigação não
teria sido realizada.
À empresa Ludomedia – Conteúdos Didáticos e Lúdicos por ter aceite este
desafio.
Ao meu cão Shakra, pela companhia nas caminhadas de restauro de energia.
Aos alunos e professores que participaram neste estudo.
A todos aqueles que me acompanharam nos momentos de alegria e desalentoque preencheram esta caminhada, a todos os que possibilitaram a
concretização deste trabalho, o meu obrigado.

palavras-chave

Design Centrado no Utilizador, Metodologias de Desenvolvimento de Software
Educativo, Avaliação de Software Educativo, Análise de Processos deDesenvolvimento de Software Educativo.

resumoNo panorama atual do desenvolvimento de software educativo é importanteque os processos de desenvolvimento sejam adequados e compatíveis com ocontexto em que serão utilizados este tipo de recursos. Desta forma, é
importante melhorar continuamente os processos de desenvolvimento bem
como se proceder à avaliação de forma a garantir a sua qualidade eviabilidade económica.
Este estudo propõe uma Metodologia Híbrida de Desenvolvimento Centrado
no Utilizador (MHDCU) aplicada ao software educativo. Trata-se de um
processo de desenvolvimento simples, iterativo e incremental que tem como“alicerces” princípios do Design Centrado no Utilizador, especificados na
International Organization for Standardization - ISO 13407. Na sua baseencontra-se a estrutura disciplinada de processos de desenvolvimento, bemcomo práticas e valores dos métodos ágeis de desenvolvimento de software. O
processo é constituído por 4 fases principais: planeamento (guião didático),
design (storyboard), implementação e manutenção/operação. A prototipagem ea avaliação são realizadas de modo transversal a todo o processo. A
metodologia foi implementada numa Pequena e Média Empresa dedesenvolvimento de recursos educacionais, com o objetivo de desenvolverrecursos educacionais com qualidade reconhecida e simultaneamente viáveis
do ponto de vista económico. O primeiro recurso que teve por base a utilização
desta metodologia foi o Courseware Sere – “O Ser Humano e os Recursos
Naturais”.
O trabalho seguiu uma metodologia de investigação & desenvolvimento, denatureza mista, em que se pretendeu descrever e analisar/avaliar uma
metodologia de desenvolvimento de software educativo, i.e., o processo, bemcomo o produto final. O estudo é fundamentalmente descritivo e exploratório. A
metodologia de desenvolvimento do software (primeira questão deinvestigação) foi proposta, essencialmente, com base na revisão integrativa daliteratura da especialidade e com base nos resultados que emergiram das
Fases 2 e 3.
Do ponto de vista exploratório, foi avaliado, por um lado, o potencial técnico e
didático da 1ª versão do software inserido no Courseware Sere (segunda
questão de investigação), e, por outro lado, analisar os pontos fortes e asfragilidades da metodologia utilizada para o seu desenvolvimento (terceiraquestão de investigação). Como técnicas de recolha de dados recorreu-se adois inquéritos por questionário e à observação direta participante (mediadapela plataforma moodle). Quanto às técnicas de análise de dados optou-se
pela análise estatística descritiva e pela análise de conteúdo.

Os resultados indicam que o recurso desenvolvido possui qualidade técnica e
didática. Relativamente a análise da Metodologia Híbrida de desenvolvimento
Centrado no Utilizador foram propostas algumas melhorias relacionadas com oenvolvimento do utilizador e introdução de novos métodos. Apesar deidentificadas algumas limitações, este projeto permitiu que a empresa
melhorasse significativamente os processos de desenvolvimento de recursos(mesmo os que não são informatizados), bem como permitiu o aumento do seu
portefólio com o desenvolvimento do Courseware Sere.

keywords

User Centered Design, Educational Software Development Methodologies,
Educational Software Evalution, Improvement of Educational Software
Development Process.

abstract

In the current educational software development scenario it is important thatdevelopment processes are appropriate and consistent with the context inwhich such resources are used. Thus, it is important to continually improve
development processes and to perform correct evaluation processes to ensure
their quality and economic viability.
This study propose the Hybrid User Centered Development Methodology(HUCDM). This methodology is a simple, iterative and incremental
development process. The methodology is based on structured disciplined
development processes, on principles of User Centered Design (UCD)
processes, specified in the International Organization for Standardization - ISO
13407, as well as on practices and values of agile methods for softwaredevelopment. The process consists of 4 main phases: planning of educationalguidelines, storyboard design, implementation and maintenance/operation. The
prototyping and evaluation are carried out in order to cross the entire process.
The HUCDM is being implemented in a Small and Medium Enterprise (SME) of
educational resources development. The first resource that was based in thismethodology was the Courseware Sere - The Human Being and the Natural
Resources.
The work followed a research & development methodology of mixed nature,
where it was intended to describe and analyze/evaluate development
methodology for educational software, the process and the final product. The
study is primarily descriptive and exploratory. The software development
methodology (the first research question) was proposed, essentially, based ona literature integrative review and based on the results that emerged from
Phases 2 and 3.
From the exploratory standpoint, on the one hand, the technical and didactic
potential of the software first version inserted in Courseware Sere (the second
research question) was evaluated. Moreover, the strengths and weaknesses ofthe methodology used for its development (the third research question) wereanalyzed. As data collection techniques two questionnaire surveys were used
together with direct participant observation (mediated by moodle). Descriptive
statistical analysis and content analysis were used as data analysis techniques.
The results achieved indicate that the developed resource has technical anddidactic quality. Concerning the Hybrid User Centered Development
Methodology analysis improvements with user involvement and new methods
were proposed. Although some limitations were identified, this project enabled
the software company to significantly improve its resource development
processes (even those that are not computerized) and allowed to increase its
portfolio with the development of Courseware Sere.

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software EducativoÍndice12CAPÍTULO I - APRESENTAÇÃO DO ESTUDO ............................................................... 1
1.1

MOTIVAÇÃO E RELEVÂNCIA DO ESTUDO........................................................................ 2

1.2

ESQUEMA CONCEPTUAL E QUESTÕES DE INVESTIGAÇÃO DO ESTUDO ................ 4

1.3

ORGANIZAÇÃO DA TESE ....................................................................................................... 6CAPÍTULO II – ENQUADRAMENTO DO ESTUDO....................................................... 9
2.1

EVOLUÇÃO DOS MÉTODOS DE DESENVOLVIMENTO DE SOFTWARE ................... 10

2.1.1

Métodos Disciplinados.............................................................................................. 11

2.1.2

Métodos Ágeis ............................................................................................................ 13

2.1.3

Análise Comparativa dos Métodos de Desenvolvimento de Software .............. 15

2.1.4

Seleção do Método de Desenvolvimento de Software .......................................... 17

2.2 METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWARE EDUCATIVO .............. 21
2.2.1

We!Design .................................................................................................................. 22

2.2.2

Projeto Univap Virtual ............................................................................................. 23

2.2.3

Projeto Use Case ........................................................................................................ 24

2.2.4

Projeto Softvali .......................................................................................................... 26

2.2.5

Fases de desenvolvimento de software educativo e elementos a envolver....... 27

2.3 ENVOLVIMENTO DO UTILIZADOR NO DESENVOLVIMENTO DE SOFTWAREEDUCATIVO: POTENCIALIDADES E CONSTRANGIMENTOS ....................................................................... 28
2.3.1

Design Centrado no Utilizador ............................................................................... 28

2.3.2

Conceber para Crianças e Crianças como Codesigners ...................................... 36

2.3.3

Conceber para Professores e Professores como Codesigners ............................. 37

2.4 O TRABALHO COLABORATIVO EM EQUIPAS MULTIDISCIPLINARES .................... 40
2.4.1

Equipas Multidisciplinares ...................................................................................... 41

2.4.2

Modelo 3C de Colaboração ...................................................................................... 42

2.5 MÉTODOS E MÉTRICAS PARA A GARANTIA DA QUALIDADE DE SOFTWAREEDUCATIVO ............................................................................................................................................. 48
2.5.1

Normas de Qualidade (ISO) .................................................................................... 49

2.5.2

Avaliação de Software Educativo Centrada no Utilizador ................................ 53

2.5.3

Melhoria de Processos de Desenvolvimento de Software ................................... 56i2.6 SÍNTESE DO CAPÍTULO ....................................................................................................... 613CAPÍTULO III – METODOLOGIA(S) .............................................................................. 63
3.1OPÇÕES METODOLÓGICAS ................................................................................................ 64

3.2 METODOLOGIA DE DESENVOLVIMENTO DO COURSEWARE SERE ........................ 67
3.2.1

Metodologia Inicial da Empresa Ludomedia ....................................................... 67

3.2.2

Apresentação do Courseware Sere ......................................................................... 74

3.2.3

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador ................. 78

3.3 METODOLOGIA DE AVALIAÇÃO DO COURSEWARE SERE E DO SEU PROCESSO
DE DESENVOLVIMENTO ...................................................................................................................... 89
3.3.1

Técnicas de recolha de dados para a avaliação do Courseware Sere ............... 90

3.3.2

Técnicas de análise de dados para a avaliação do Courseware Sere ............... 94

3.3.3
Técnicas de recolha de dados para análise do processo de desenvolvimento
do Courseware Sere ............................................................................................................................. 95
3.3.4
Técnicas de análise de dados relativos ao processo de desenvolvimento do
Courseware Sere .................................................................................................................................. 97
3.4 DIFICULDADES METODOLÓGICAS................................................................................ 107
4CAPÍTULO IV – APRESENTAÇÃO E DISCUSSÃO DOS RESULTADOS ............. 109
4.1

FASE 2 – AVALIAÇÃO DO COURSEWARE SERE ............................................................ 110

4.1.1

Avaliação dos professores relativamente aos aspetos técnicos e didáticos ... 110

4.1.2

Avaliação dos alunos relativamente a aspetos técnicos e didáticos ............... 122

4.2 FASE 3 – ANÁLISE DO PROCESSO DE DESENVOLVIMENTO ................................... 130
4.2.1

Descrição geral sobre padrão de interação nos fóruns .................................... 131

4.2.2

Dimensão “Comunicação”...................................................................................... 140

4.2.3

Dimensão “Coordenação” ...................................................................................... 145

4.2.4

Dimensão “Colaboração e Cooperação” .............................................................. 152

4.3 SÍNTESE DO CAPÍTULO ..................................................................................................... 174
5CAPÍTULO V – CONCLUSÃO DO ESTUDO ................................................................. 175
5.1SÍNTESE CONCLUSIVA DA FASE 1 DE INVESTIGAÇÃO.............................................. 176

5.2 SÍNTESE CONCLUSIVA DA FASE 2 DE INVESTIGAÇÃO ............................................. 176
5.3 SÍNTESE CONCLUSIVA DA FASE 3 DE INVESTIGAÇÃO ............................................. 178
5.4 PROPOSTA DE MELHORIA DA METODOLOGIA HÍBRIDA DE
DESENVOLVIMENTO CENTRADO NO UTILIZADOR ................................................................... 182

ii

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

5.5 LIMITAÇÕES DE CARÁCTER INVESTIGATIVO ............................................................ 185
5.6 SUGESTÕES PARA TRABALHO FUTURO ....................................................................... 186
REFERÊNCIAS BIBLIOGRÁFICAS ....................................................................................... 189
ANEXOS......................................................................................................................................... 205

iii

Índice de Tabelas
Tabela 1 – Alguns princípios dos Métodos Ágeis, adaptado de Sommerville (2007) .................... 14
Tabela 2 – Vantagens e desvantagens dos métodos de desenvolvimento de software ................. 15
Tabela 3 – Métodos Ágeis vs. Métodos Disciplinados, adaptado de Bohem & Turner (2003) ..... 16
Tabela 4 - Fases fundamentais no desenvolvimento de software comparativamente às fases detrês metodologias de desenvolvimento de software educativo. .................................................... 28
Tabela 5 - Vantagens e Desvantagens do Design Centrado no Utilizador, adaptado de Abras,
Maloney-Krichmar & Preece (2004) ............................................................................................... 33
Tabela 6 – Envolvimento dos utilizadores no processo de desenvolvimento, adaptado de Preece,
Rogers & Sharp (2002)......................................................................................................................35
Tabela 7 – Fatores de qualidade e respetivos critérios, baseado em Seffah, et al. (2008) ........... 52
Tabela 8 - Métodos para Avaliação de Soluções de Projeto, adaptado de Maguire (2001) .......... 54
Tabela 9 - Síntese das técnicas de recolha e de análise de dados do estudo ................................. 65
Tabela 10 – Descrição das Fases do Processo de Gestão de Projetos ............................................. 71
Tabela 11 – Descrição das fases de Instrução de Trabalho Execução de Projetos de Multimédia 72
Tabela 12 – Modelo 4C para análise de processos de desenvolvimento de software educativo.104
Tabela 13 – Equipa Multidisciplinar vs. Mensagens de Pré-articulação, Interdependência e
Insistência ........................................................................................................................................148
Tabela 14 – Pontos Fortes e Fragilidades da Metodologia Híbrida de Desenvolvimento Centrado
no Utilizador .................................................................................................................................... 178
Tabela 15 – Proposta de novos métodos do Design Centrado no Utilizador (adaptado de Maguire(2001)) ..............................................................................................................................................184

iv

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software EducativoÍndice de Figuras
Figura 1 - Ciclo de Vida do Desenvolvimento de Software, adaptado de Sommerville (2007) .... 12
Figura 2 – Atividades do Design Centrado no Utilizador descritas na ISO 13407 (1999) ............ 31
Figura 3 – Papéis da criança no processo de desenvolvimento de Druin (2002) ..........................37
Figura 4 – Tipos de Design Centrado no Utilizador. ...................................................................... 38
Figura 5 – Papéis do professor no processo de desenvolvimento, adaptado de Pardo, Vetere &Howard (2005) ................................................................................................................................. 40
Figura 6 – Modelo 3C de Elis (1991) adaptado por Fuks e colaboradores (2004; 2005; 2008) . 43
Figura 7 – Modelo de Comunicação de Fuks e colaboradores (2004; 2005; 2008) .................... 44
Figura 8 – Modelo de Coordenação de Fuks e colaboradores (2004; 2005; 2008) ..................... 45
Figura 9 – Modelo de Cooperação de Fuks e colaboradores (2004; 2005; 2008) ....................... 46
Figura 10 – Matriz Computer Supported Cooperative Work (CSCW) ......................................... 48
Figura 11 – Normas ISO para o desenvolvimento de software...................................................... 49
Figura 12 – Fases do Processo de Design Iterativo, adaptado de Velsen, et al. (2008) ............... 56
Figura 13 - Níveis de Maturidade Capability Maturity Model ...................................................... 58
Figura 14 – Organização do estudo ................................................................................................. 65
Figura 15 - Fatores da Gestão de Projetos Multimédia, adaptado de Strauss (Ribeiro, 2007) .... 69
Figura 16 – Processo de Gestão de Projetos da Ludomedia ........................................................... 70
Figura 17 – Instrução de Trabalho Execução de Projetos de Multimédia ......................................72
Figura 18 – Guiões de Exploração Didática ..................................................................................... 75
Figura 19 - Exploração online do Courseware Sere .........................................................................76
Figura 20 - Exemplos de ecrãs do Courseware Sere ...................................................................... 78
Figura 21 - Metodologia Híbrida de Desenvolvimento Centrado no Utilizador ........................... 80
Figura 22 – a) Cenário da fase 2 e de uma das personagens. b) Ecrã da escolha das personagens
e um ecrã de uma atividade. c) 1º ecrã da fase 1 - petróleo e 2º ecrã da fase 2 – floresta. ........... 82
Figura 23 – Workflow do Procedimento de Verificação e Validação ............................................ 84
Figura 24 – Workflow do trabalho colaborativo e cooperativo presencial ................................... 85v

Figura 25 – Workflow do trabalho colaborativo e cooperativo não presencial ............................ 85
Figura 26 – Ambiente de trabalho do groupware (moodle) ......................................................... 86
Figura 27 – Módulos de atividades (tarefas) utilizados do moodle ............................................... 89
Figura 28 – Ferramentas utilizadas no moodle com base no modelo 4C ..................................... 96
Figura 29 – Procedimento de análise de conteúdo, adaptado de Coehen, Manion & Morrison(2007) e Bardin (2004) .................................................................................................................... 98
Figura 30 – Modelo 4C, adaptado do modelo 3C de colaboração de Fuks e colaboradores (2004;
2005; 2008) .....................................................................................................................................102
Figura 31 – Estrutura definida para a análise interpretativa ........................................................140
Figura 32 – Categorias e Subcategorias/Indicadores da dimensão “Comunicação” ...................140
Figura 33 – Categorias e Subcategorias/Indicadores da dimensão “Coordenação”.................... 145
Figura 34 – Categorias e Subcategorias/Indicadores da dimensão “Colaboração e Cooperação”.......................................................................................................................................................... 153
Figura 35 – Protótipo de um dos ecrãs da Fase II - Florestas....................................................... 153
Figura 36 – Protótipo alterado de um dos ecrãs da Fase II – Florestas, tendo por base uma
pergunta ativa. ................................................................................................................................. 154
Figura 37 – Protótipo programado do 3º Ecrã, da Fase I - Petróleo ............................................ 155
Figura 38 – Primeiro protótipo do 1º Ecrã, da Fase I - Petróleo .................................................. 165
Figura 39 – Segundo protótipo do 1º Ecrã, da Fase I – Petróleo ................................................. 166
Figura 40 – Terceiro protótipo do 1º Ecrã, da Fase I, Petróleo .................................................... 167
Figura 41 – Quarto protótipo do 1º Ecrã, da Fase I – Petróleo.....................................................168
Figura 42 – Quinto protótipo do 1º Ecrã, da Fase I – Petróleo .................................................... 171
Figura 43 – Sexto protótipo do 1º Ecrã, da Fase I - Petróleo ........................................................ 172
Figura 44 – Versão final do 1º Ecrã, da Fase I - Petróleo.............................................................. 172
Figura 45 – Versão programada do 1º Ecrã, da Fase I – Petróleo ................................................ 173
Figura 46 – Métodos do Design Centrado no Utilizador .............................................................. 183
Figura 47 – Modelo 5C: Comunicação, Coordenação, Colaboração e Cooperação e Competências.......................................................................................................................................................... 187
Figura 48 – Modelo 3C, adaptado de Fuks et al. (2005) ............................................................... 217

vi

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software EducativoÍndice de Gráficos
Gráfico 1 – Utilização (semana) das Tecnologias de Informação e Comunicação por parte dos
professores ............................................................................................................................................. 111
Gráfico 2 – Avaliação dos aspetos técnicos (botões de navegação) por parte dos professores. ........112
Gráfico 3 - Avaliação dos aspetos técnicos (navegação) por parte dos professores...........................112
Gráfico 4 - Avaliação dos aspetos técnicos (interface e navegação) por parte dos professores. .......113
Gráfico 5 - Avaliação dos aspetos técnicos (interface) por parte dos professores. ............................114
Gráfico 6 - Avaliação dos aspetos técnicos (interface/formatos) por parte dos professores. ........... 115
Gráfico 7 - Avaliação da estrutura geral (animação) por parte dos professores. ...............................116
Gráfico 8 - Avaliação da estrutura geral (menu) por parte dos professores. ..................................... 117
Gráfico 9 - Avaliação da estrutura geral (opções pré-definidas) por parte dos professores. ........... 118
Gráfico 10 - Avaliação dos aspetos didáticos (atividades – competências e autonomia) por parte dos
professores. ............................................................................................................................................119
Gráfico 11 - Avaliação dos aspetos didáticos (atividades - articulação) por parte dos professores. 120
Gráfico 12 - Avaliação dos aspetos didáticos (atividades – aprendizagem) por parte dos professores.
............................................................................................................................................................... 120
Gráfico 13 - Avaliação dos aspetos didáticos (conteúdos – adequação e pertinência) por parte dos
professores. ............................................................................................................................................121
Gráfico 14 – Frequência de utilização (por semana) do computador por partes dos alunos ........... 123
Gráfico 15 – Finalidade do uso do computador por parte dos alunos ............................................... 123
Gráfico 16 - Utilização do computador por semana vs. Navegar sem ajuda ..................................... 124
Gráfico 17 – Navegação pelo programa (botões) ................................................................................ 125
Gráfico 18 – Navegação pelo programa (localização e deteção de erros) .......................................... 126
Gráfico 19 - Desenhos das janelas (cores e imagens) ......................................................................... 127
Gráfico 20 - Adequação das atividades (interesse) ............................................................................. 128
Gráfico 21 - Adequação das atividades (envolvimento do professor) ................................................ 129
Gráfico 22 - Adequação das atividades (aprendizagem) .................................................................... 129
Gráfico 23 – Posts submetidos por elemento da equipa multidisciplinar ........................................ 133
Gráfico 24 – Posts submetidos mensalmente ..................................................................................... 134

vii

Gráfico 25 – Posts de iniciação por elemento da equipa multidisciplinar ........................................ 135
Gráfico 26 – Tipo de Solução de Projeto ............................................................................................. 136
Gráfico 27 – a) Submissão de soluções de projeto por elemento da equipa multidisciplinar b)
Submissão por tipo de solução de projeto efetuada pelo Gestor de Projeto vs. Restantes elementos............................................................................................................................................................... 139

viii

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Listagem de Anexos(* apenas em CD-ROM)
Anexo 01 - Inquérito por Questionário para Avaliação Técnica e Didática (Professores)
Anexo 02 - Inquérito por Questionário para Avaliação Técnica e Didática (Alunos)
Anexo 03 - Modelo de Análise do Processo de Desenvolvimento
Anexo 04 – Exemplo de Ata de Reunião
Anexo 05 – Fórum Notícias *Anexo 06 – Fórum Pontos Transversais *Anexo 07 – Fórum Fase I – Petróleo *Anexo 08 – Fórum Fase II – Florestas *Anexo 09 – Fórum Fase III – Energias Alternativas *ix

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

1 CAPÍTULO I - APRESENTAÇÃO DO ESTUDO

O capítulo I tem como propósito contextualizar e justificar o objeto de estudo
da investigação realizada, centrada na análise do processo de desenvolvimento e
na avaliação do Courseware Sere e está organizado em torno das seguintes secções:motivação e relevância do estudo, esquema conceptual e questões de investigação
do estudo e apresentação da organização deste documento.

1Capítulo I – Apresentação do Estudo

1.1

MOTIVAÇÃO E RELEVÂNCIA DO ESTUDO

Este estudo surgiu da necessidade sentida por uma pequena e média empresade desenvolvimento de software educativo (Ludomedia) em implementar uma
metodologia (Metodologia Híbrida de Desenvolvimento Centrado no Utilizador),de forma a que os recursos educacionais desenvolvidos pela mesma tenham
qualidade reconhecida e sejam simultaneamente viáveis do ponto de vista
económico. Muitas empresas, atualmente, ainda tomam decisões relativamente às
caraterísticas e funcionalidades que deverão ser implementadas num software,
sem envolver o utilizador (Hauser, 2007), tal como sucedia com a metodologia
anteriormente explorada pela empresa Ludomedia. Assumia-se então, que era
possível antecipar a definição dos requisitos tal como defendem as metodologias 1
tradicionais/clássicas (Abbas, Gravell, & Wills, 2008).
Para este estudo, foi organizada uma equipa multidisciplinar, constituída porelementos com competências diversas ao nível da Didática das Ciências, daTecnologia Educativa, da Gestão de Projetos, do Design e da Programação,pertencentes à Universidade de Aveiro e à Ludomedia. O recurso que teve por basea Metodologia Híbrida de Desenvolvimento Centrado no Utilizador foi o
Courseware 2 Sere – “O Ser Humano e os Recursos Naturais”, o qual na secção 3.2
se apresenta.
O facto dos pacotes de software se dirigirem, cada vez mais, a uma
multiplicidade de utilizadores, aliado à importância dos contextos de utilização,reforça a necessidade de se optar por metodologias de desenvolvimento
adequadas. Embora a seleção da metodologia dependa do ambiente em que se

1 Segundo os autores Jiang & Eberlein (2008) diferentes termos têm sido utilizados no desenvolvimento desoftware que têm o mesmo significado, porém em contextos diferentes. Neste estudo o termo “metodologias
de desenvolvimento de software educativo” é utilizado quando se refere às metodologias apresentadas nasecção 2.2 e à Metodologia Híbrida de Desenvolvimento Centrado no Utilizador. O termo métodos é utilizado
quando se refere aos métodos disciplinados ou métodos ágeis.
2

Segundo Vieira (1996) é constituído pelo software (suporte informático do recurso) e pelos guiões deexploração do aluno e do professor (que podem ou não ser informatizados).

2

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

insere o projeto e de um conjunto de variáveis que, por vezes, não se conseguem
definir antecipadamente, estas podem auxiliar o desenvolvimento de software,minimizando a incerteza e permitindo a obtenção do resultado esperado da forma
mais eficiente possível. Porém, a adoção da mesma metodologia para todos os
projetos de desenvolvimento de software, dificilmente será uma boa escolha, setivermos em consideração a diversidade de utilizadores, objetivo da utilização dosoftware e as alterações constantes da tecnologia (Toth, 2005). Assim, diferentes
tipos de software necessitam de processos de desenvolvimento também diferentes(Sommerville, 2007).
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 dedesenvolvimento 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 desoftware e quando as mesmas devem ser aplicadas, levando as organizações acompreender, a controlar e a melhorar os processos de desenvolvimento.
Pretende-se neste estudo propor e analisar a Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador compreendendo os seus pontos fortes e
as suas fragilidades. Para esse efeito, foram identificadas áreas chave para
melhorar a metodologia e refinados e introduzidos novos métodos do Design
Centrado no Utilizador, através de técnicas e ferramentas, de forma a que sejapossível reduzir o tempo e os custos de desenvolvimento, através do bomdesempenho da equipa. A necessidade de definir uma metodologia dedesenvolvimento de software educativo tem como propósito, minimizar/reduzir
erros durante o processo de desenvolvimento e garantir a qualidade do recurso em
si. Por outro lado, também permite ser um guia de orientação para todos oselementos da equipa envolvidos, possibilitando a perceção de como está a evoluir oprojeto.

3

Capítulo I – Apresentação do Estudo

Os resultados deste estudo permitiram identificar os pontos fortes e asfragilidades da metodologia adotada, assim como detetar erros e traduzir assugestões dos professores e alunos em reformulações para a fase de manutenção.
Considera-se, ainda, que os instrumentos e estratégias desenvolvidos poderão ser
potenciados, posteriormente, tanto ao nível da melhoria da Metodologia Híbridade Desenvolvimento Centrado no Utilizador, bem como na avaliação formativa dos
protótipos de futuros projetos.
Na secção seguinte explicita-se o esquema conceptual deste estudo, em que seapresentam as questões de investigação que orientam o mesmo e, posteriormente,na secção 1.3, a organização desta tese.
1.2

ESQUEMA CONCEPTUAL E QUESTÕES DE INVESTIGAÇÃO DO
ESTUDO

Ajustando os princípios de desenvolvimento de software referidos na secção
anterior, o estudo centrou-se essencialmente na proposta, avaliação e na análise doprocesso de desenvolvimento do Courseware Sere, designada como Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador. Trata-se de um processo dedesenvolvimento simples, iterativo e incremental que tem como “alicerces” os
princípios do Design Centrado no Utilizador, especificados na International
Organisation for Standardization - ISO 13407 (1999). Na sua base encontra-se a
estrutura disciplinada de processos de desenvolvimento, bem como práticas evalores dos métodos ágeis de desenvolvimento de software. O processo éconstituído por 4 fases principais: planeamento (guião didático), design(storyboard), implementação e manutenção/operação. A prototipagem e aavaliação são fases indispensáveis mas que são realizadas de modo transversal atodas as fases. A Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
tem como objetivo o desenvolvimento de recursos educacionais com qualidade
reconhecida e simultaneamente viáveis do ponto de vista económico (Costa,
Loureiro, & Reis, 2009c, 2010a, 2010b, 2010c; Costa, et al., 2009d; Costa, et al.,2009b).

4

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Com o intuito de propor uma metodologia, neste estudo, designada como
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, emergiu aprimeira questão de investigação: Quais os princípios e procedimentos a integrar
numa metodologia de desenvolvimento de software educativo? Esta questão deu
lugar à Fase 1, na continuidade do estudo realizado por Guerra (2007) o qual havia
definido alguns princípios desta metodologia, tais como, constituição de uma
equipa multidisciplinar, avaliação formativa por parte de professores e peritos(pressupostos do Design Centrado no Utilizador).
A avaliação do Courseware Sere assumiu um destaque particular neste estudo,
surgindo a segunda questão de investigação: Qual a perceção dos professores e dos
alunos relativamente aos aspetos técnicos e didáticos do Courseware Sere? Esta
questão de investigação deu lugar à segunda fase de investigação do estudo (Fase2), em que se avaliou o referido recurso relativamente aos aspetos técnicos(navegação e interação) e didáticos (conteúdos e atividades), avaliação esta
efetuada pelos utilizadores finais do Courseware Sere (alunos dos 2º Ciclo do
ensino básico e professores dos 1º e 2º Ciclos do ensino básico) e investigadoresem Tecnologia Educativa e Didática das Ciências.
A complexidade do processo de desenvolvimento do Courseware Sere, descrito
neste estudo, originou outra questão de investigação: Quais os pontos fortes e asfragilidades da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador,
aplicada ao desenvolvimento do Courseware Sere? Esta questão de investigação
demarcou a 3ª fase da investigação, em que a análise da Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador permitiu identificar os pontos fortes e asfragilidades da metodologia propondo, assim, melhorias à mesma.
Para responder às questões de investigação, optou-se por um estudo deinvestigação & desenvolvimento, de natureza mista (Bogdan & Biklen, 1994;
Carmo & Ferreira, 1998; Cohen, Manion, & Morrison, 2007), em que se pretendeu
descrever e analisar/avaliar a metodologia proposta no que respeita tanto ao
processo como ao produto final.

5

Capítulo I – Apresentação do Estudo

1.3

ORGANIZAÇÃO DA TESE

Esta tese encontra-se organizada em cinco capítulos. O capítulo I,“Apresentação do Estudo” teve como finalidade apresentar a motivação e arelevância do estudo e o seu esquema conceptual, tendo sido definidas as questões
de investigação que nortearam as três fases de investigação.
O capítulo II, “Enquadramento do Estudo”, inicia-se com uma descrição
sucinta da evolução dos métodos de desenvolvimento de software, desde família
dos métodos disciplinados até aos métodos ágeis, tendo sido efetuada uma análise
comparativa destas duas famílias. Posteriormente, apresentam-se exemplos dealgumas metodologias de desenvolvimento de software educativo que ajudaram na
definição da metodologia proposta neste estudo. Neste capítulo, enfoca-se oenvolvimento do utilizador (professor e aluno) nos processos de desenvolvimentode software educativo e o trabalho colaborativo em equipas multidisciplinares.
O capítulo III, “Metodologia(s)”, inicia-se com a justificação das Opções
Metodológicas

adotadaspara

responder

àsquestões

deinvestigação.

Posteriormente é apresentada a metodologia de desenvolvimento do Courseware
Sere iniciando-se pela descrição da metodologia que a empresa Ludomedia
utilizava inicialmente; é efetuada a apresentação do Courseware Sere (constituição
e organização) e a Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador (processo de desenvolvimento, procedimentos e técnicas que a
constituem). Para finalizar este capítulo, apresenta-se a metodologia de avaliação
do Courseware Sere e a metodologia de análise do seu processo dedesenvolvimento, sendo apresentadas as técnicas usadas para a recolha e análise
dos dados.
No capítulo IV, “Apresentação e discussão dos resultados”, procura-se
responder às questões de investigação, identificando-se os aspetos positivos enegativos da primeira versão do recurso, essencialmente o software, a partir daanálise das perceções dos potenciais utilizadores do Courseware Sere, alunos do 2º
Ciclo do ensino básico e professores dos 1º e 2º Ciclos do ensino básico, einvestigadores externos em Didática das Ciências e Tecnologia Educativa. Ainda

6

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

neste seguimento, identificam-se os pontos fortes e fragilidades da metodologia
adotada para o desenvolvimento do courseware tendo por base as categorias
definidas no modelo de análise - modelo 4C (descritas na subsecção 3.3.4).
No capítulo V, “Conclusões do Estudo”, faz-se uma síntese conclusiva de cadauma das fases de investigação, descrevem-se as limitações da investigação epropõem-se sugestões para futuras investigações, ao nível do desenvolvimento desoftware educacional. Também neste capítulo é apresentado a proposta demelhoria da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador,
com base na análise do processo de desenvolvimento do Courseware Sere.

7

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

2 CAPÍTULO II – ENQUADRAMENTO DO ESTUDO

Neste capítulo (secções 2.1 e 2.2), efetua-se uma abordagem descritiva ecronológica das metodologias de desenvolvimento de software, sendo dados
exemplos específicos de metodologias de desenvolvimento de software educativo
que serviram de base à proposta da Metodologia Híbrida de Desenvolvimento
Centrado no Utilizador. Posteriormente, na secção 2.3, descreve-se de que forma outilizador pode ser envolvido no processo de desenvolvimento de um software
educativo. Na secção 2.4, aborda-se o trabalho colaborativo em equipas
multidisciplinares tendo como orientação o modelo 3C de colaboração que,especificado, corresponde respetivamente a: comunicação, coordenação ecooperação. Na secção 2.5 efetua-se uma abordagem aos métodos e às métricas
que poderão ser tidas em consideração, com o intuito de aferir a qualidade dosoftware educativo desenvolvido. Finaliza-se o capítulo com uma síntese das
temáticas abordadas.

9

Capítulo II – Enquadramento do Estudo

2.1

EVOLUÇÃO DOS MÉTODOS DE DESENVOLVIMENTO DE SOFTWAREO desenvolvimento de software é uma atividade complexa. Muitas vezes, omesmo é desenvolvido sem ser devidamente planeado, sendo o desenvolvimento
suportado por decisões de “curto prazo” (Fowler, 2005). Esta abordagem ao
desenvolvimento poderá funcionar para pequenos pacotes de software, mas à
medida que as potencialidades do software crescem, aumenta também a
dificuldade de lhe adicionar novas funcionalidades. Complementarmente a estas
dificuldades, Shneiderman & Plaisant (2005) referem que 60% dos projetos dedesenvolvimento de software falham na definição dos objetivos. Este problema
surge, nomeadamente, porque, na maioria dos projetos, existe falta decomunicação entre os elementos da equipa de desenvolvimento ou entre oselementos da equipa e os utilizadores finais.
Tendo em conta o exposto acima, a escolha de um método “adequado” para odesenvolvimento de um software é crucial, dado poder trazer implicações ao nível
da sua qualidade 3, mas também económicas e competitivas, para as empresas dedesenvolvimento. Caso seja selecionado um método menos “adequado”, o maisprovável será o projeto ultrapassar os limites temporais, existindo falhas noprocesso de desenvolvimento e, consequentemente, problemas económicos (Toth,
2005).
Com base na literatura da especialidade consultada, nas subsecções seguintes(2.1.1 e 2.1.2), procura-se fazer uma breve resenha da evolução dos métodos dedesenvolvimento de software. Assim na subsecção 2.1.1, abordam-se os métodos
disciplinados, a que está associado o método em Cascata de Água ou ciclo devida de desenvolvimento de software (Sommerville, 2007). Segundo Larman e
Basili (2003), o desenvolvimento Iterativo e Incremental, outro método
considerado disciplinado, remonta aos anos 50, existindo exemplos concretos deprojetos nos anos 70. Posteriormente, nos anos 80 surgiram, entre outros, os
métodos em Espiral e de Prototipagem, e nos anos 90 os Métodos Ágeis, exemplos
3 A secção 2.5 aborda os métodos e as métricas para a garantia da qualidade de software educativo.

10

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

reais da integração das abordagens iterativas e incrementais que serão descritas na
subsecção 2.1.2.
No seguimento da descrição dos diferentes métodos de desenvolvimento desoftware, a subsecção 2.1.3 tem por objetivo fazer uma análise comparativa das
categorias de métodos (disciplinados vs. ágeis), apresentando uma análise dasvantagens e desvantagens dos diferentes métodos e sintetizando as principais
características das categorias. Na última subsecção, alude-se aos aspetos a ter em
conta aquando da escolha de um método de desenvolvimento de software, tendo
em vista justificar as opções de base da metodologia desenvolvida.
2.1.1 Métodos Disciplinados
O método em Cascata de Água (Figura 1) constitui-se como o processo maiscomum de desenvolvimento de software (Miguel, 2003; Sommerville, 2007). Este
método serviu de base teórica para o desenvolvimento de outros métodos, sendo,
por vezes, designado como um método genérico para o desenvolvimento desoftware (Sommerville, 2007). Promove o desenvolvimento de projetos erequisitos bem definidos e formaliza metas, documentação e resultados. Trata-se
de um método que é normalmente utilizado para pacotes de software cuja
segurança e fiabilidade são considerados críticos e onde a estabilidade do processo
de ciclo de vida é uma grande prioridade. É o método que segue sequencialmente
as fases definidas, a saber: i) requisitos do sistema; ii) requisitos do software; iii)
desenho do software; iv) programação e testes e v) operação. Avança-se para a faseseguinte, apenas quando se termina a fase atual. A maior relevância deste método
está na reunião de diversos conceitos que ainda são adotados atualmente (Miguel,2003; Sommerville, 2007) e que serviram de base à delineação da Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador, descrita na secção 3.2 (Costa,
et al., 2009c, 2010a, 2010c).

11Capítulo II – Enquadramento do Estudo

Figura 1 - Ciclo de Vida do Desenvolvimento de Software, adaptado de Sommerville (2007)

O desenvolvimento Iterativo e Incremental oferece uma boa visibilidade do
progresso em cada versão, apresentando resultados de forma mais rápida
podendo, assim, obter-se feedback por parte dos utilizadores. É necessário que agestão e os processos técnicos consigam dividir o projeto em módulos, paragarantir a evolução do projeto sem perder o controlo. Isto implica esforços
redobrados, para permitir uma boa definição dos requisitos, para criar
componentes que sirvam de alicerce e para criar a arquitetura dos módulos maiscríticos o mais rapidamente possível (Abbas, 2006; Abbas, et al., 2008; Larman &Basili, 2003).
O método de Prototipagem (Miguel, 2003; Sommerville, 2007) surgiu com opropósito de disponibilizar uma boa visibilidade dos vários problemas técnicos
encontrados e encorajar o envolvimento e feedback dos utilizadores. Os protótipos
não tinham como propósito a apresentação de versões do produto operacionais,
mas eram utilizados para explorar problemas técnicos difíceis/arriscados ou paravalidar a indefinição de alguns requisitos. Os protótipos também são muito úteis
em situações de pesquisa em que o software é mais orientado para uso pessoal.
Um exemplo é a produção de um protótipo que prove um conceito. Os produtos
resultantes não são de qualidade, pelo menos para projetos grandes, médios,
complexos e com funcionalidades críticas. A prototipagem é uma forma deexperimentação iterativa com a finalidade de se obter informação para o processo
de desenvolvimento. Este processo deve ser revisto através de um estreito trabalho
12

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativode colaboração entre o analista e os utilizadores. Sempre que existam incertezas, aprototipagem constitui uma das medidas de redução do risco. Construir um
protótipo pode ajudar a definir, por exemplo, os requisitos exatos a serem
inseridos no software ou a natureza da solução proposta. A interface do utilizador
é a parte mais sujeita à prototipagem, porque a facilidade de utilização é uma
questão da maior importância e porque definir a interface do sistema, com outilizador, é o mesmo que definir a funcionalidade do sistema (Miguel, 2003;
Sommerville, 2007).
O método em Espiral, definido como evolutivo, concilia as melhores
características do método em Cascata com a natureza iterativa do método dePrototipagem (Miguel, 2003; Sommerville, 2007). Este método introduz um
novo componente - a análise de risco. O processo é orientado para os riscos, em
vez de ser orientado para o produto. Por cada iteração à volta da espiral, sãoprogressivamente construídas versões mais completas do software. A análise derisco é inserida como uma etapa do processo de desenvolvimento, como um meiode avaliar (viabilizar) cada versão do software, para determinar se odesenvolvimento deve ou não continuar. Por exemplo, se existir um aumento
significativo do custo, a empresa ou instituição pode decidir que não faz sentido
prosseguir com o projeto (Abbas, 2006).
2.1.2 Métodos Ágeis
Flower (2005) indica que os métodos ágeis são adaptativos, por oposição
aos métodos disciplinados de desenvolvimento de software (onde se incluem
alguns métodos tradicionais/clássicos), que tentam planear uma grande parte doprocesso em detalhe e por um período alargado. Nestes últimos métodos, e como
já foi referido, o processo de desenvolvimento poderá funcionar bem até existirem
alterações, estando na sua “essência” resistir à mudança. Ao contrário, os métodoságeis “abraçam” a mudança. Tentam ser processos que se adaptam e evoluem com
a mudança, ao ponto de eles próprios se alterarem. O mesmo autor acrescenta,
ainda, que os métodos ágeis são orientados a pessoas em vez de processos e que o13Capítulo II – Enquadramento do Estudo

objetivo é definir um processo que funcione bem independentemente de quem outilize.
Para assegurar o eficaz desenvolvimento de sotfware, os métodos ágeis
enfatizam a comunicação informal e necessitam de frequente feedback através derevisões e avaliações em colaboração com os on-site customers (Paelke & Nebe,2008). Além disso, o “movimento ágil” destaca o relacionamento próximo entre oselementos da equipa de desenvolvimento, por contraposição com os processos
institucionalizados e ferramentas de desenvolvimento. Nas práticas dos métodoságeis é ainda evidenciado o “bom“ ambiente organizacional onde se desenvolve oprojeto, para além de procedimentos que impulsionem e motivem o espírito deequipa (Abbas, 2006; Dybå & Dingsøyr, 2008; Manifesto, 2001).
No livro “Engenharia de Software”, Sommerville (2007) enuncia alguns dos
princípios pelos quais se regem os métodos ágeis (Tabela 1).
Tabela 1 – Alguns princípios dos Métodos Ágeis, adaptado de Sommerville (2007)
Princípios
Envolvimento
dos
Utilizadores

Descrição
Os utilizadores são envolvidos no processo de desenvolvimento. O seu papel é
fornecer e dar prioridade aos novos requisitos do software e avaliar as iterações
do mesmo.

Entrega
Incremental

O software é desenvolvido através de incrementos com o utilizador, especificandoos requisitos para serem incluídos em cada incremento.

Orientação
para asPessoasAs competências da equipa de desenvolvimento deverão ser reconhecidas e
exploradas. Os elementos da equipa são livres para utilizar os seus próprios
métodos de trabalho sem serem prescritos processos.

Abraço à
Mudança

Espera-se que os requisitos do software sejam alterados, então o software é
concebido para aceitar estas mudanças.

Manter a
Simplicidade

Focaliza a simplicidade no desenvolvimento do software e no processo dedesenvolvimento. Sempre que possível, trabalha-se ativamente para eliminar acomplexidade do software.

O método ágil mais referenciado na literatura é o Extreme Programming,
embora existam outros, tais como, o Scrum e a família Crystal Clear (Krasteva &Ilieva, 2008).
O Extreme Programming está orientado para pequenas equipas (até 10
elementos), que pretendam desenvolver pacotes de software de forma rápida e

14

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

com mudanças constantes nos requisitos. As equipas trabalham em curtas
iterações, produzindo de modo incremental e analisando requisitos à medida queestes são descritos pelos utilizadores (clientes). Um software desenvolvido com
este método deverá, igualmente, ser simples (Abbas, 2006; Beck, 2000; Bergin,
Caristi, Dubinsky, Hazzan, & Williams, 2004; Sommerville, 2007). O Extreme
Programming assenta em quatro valores fundamentais (Beck, 2000; Keith, 2002):
Comunicação, Simplicidade, Feedback e Coragem. Tem, também, como base asinergia de um todo, onde cada um é um reforço dos outros. Além dos quatro
valores descritos, é composto por doze procedimentos/práticas que os projetos
devem respeitar (Beck, 2000; Sommerville, 2007): Planning game, Small
releases, Metaphors, Simple design, Test-first development, Refactoring, Pair
programming, Collective ownership, Continnuous integration, 40-hour week,
On-site customer e Coding standards. Muitas destas práticas já antigas, testadas ecomprovadas, são, muitas vezes esquecidas, pela maior parte dos processos.
2.1.3 Análise Comparativa dos Métodos de Desenvolvimento deSoftware
Na Tabela 2 apresentam-se as vantagens e desvantagens dos métodos dedesenvolvimento de software descritos nas subsecções anteriores e de acordo com
vários autores (Abbas, 2006; Boehm & Turner, 2003; Larman & Basili, 2003;
Miguel, 2003; Sommerville, 2007).
Tabela 2 – Vantagens e desvantagens dos métodos de desenvolvimento de software
Designação

Vantagens

Método em
Cascata(anos 70)

Funciona bem para equipas
tecnicamente mais fracas.
É produzida documentação em
cada fase.

Desvantagens
Estrutura rígida e procedimentos
inflexíveis.
Não reconhece a necessidade de retornar às
fases anteriores e corrigir erros.
Versão operacional do sistema apenas
disponível numa fase avançada.

15

Capítulo II – Enquadramento do Estudo

MétodoPrototipagem(anos 80)

Apresenta resultados sem
necessitar de toda a informação no
início do projeto.
É útil quando os requisitos mudam
rapidamente e o utilizador está
relutante em aceitar um conjunto
de requisitos.
Ajudam a definir os requisitos.

Método em
Espiral(anos 80)

As iterações iniciais do processo dedesenvolvimento são menos
dispendiosas, permitindo que as
tarefas de maior risco sejam
concebidas com menor custo.
Componente análise de risco
disponibiliza uma ferramenta demedida.

MétodosÁgeis(anos 90)

Os utilizadores (clientes) estão
envolvidos ativamente durante oprojeto.

Pode levar a falsas expetativas, isto é, outilizador muitas vezes pensa que osoftware está terminado.
Pacotes de software pobres devido ao
objetivo principal do método, odesenvolvimento rápido.
É impossível determinar com exatidão otempo que o projeto vai demorar a serdesenvolvido.
Não há forma de saber o número deiterações que serão necessárias.

Aplicação complexa, implicando muitos
anos de prática para aplicar o método com
eficácia.

Não são adequados para pacotes desoftware grandes, estáveis e com requisitos
bem definidos.
Os pedidos informais para melhorias, após
cada fase podem gerar confusão.

Na Tabela 3, apresenta-se algumas das caraterísticas dos métodos ágeis e dos
métodos disciplinados (Boehm & Turner, 2003).
Tabela 3 – Métodos Ágeis vs. Métodos Disciplinados, adaptado de Bohem & Turner (2003)
Caraterísticas
Aplicações

Métodos Ágeis

Objetivos

Retorno rápido, reposta à mudança.

Extensão

Equipas e projetos pequenos.
Turbulento, mudanças constantes,
foco no projeto.

AmbienteGestãoRelação com o Cliente

Clientes no local dedicados, foco em
incrementos prioritários.

Planeamento eControlo

Planeamento próprio e algosubjetivo, controlo qualitativo.

Comunicação

Conhecimento interpessoal tácito.

Técnicas
Requisitos

Histórias informais prioritárias,
mudanças imprevisíveis.

Desenvolvimento

Design simples, incrementos curtos,
refactoring pouco dispendioso.

Teste

Testes executáveis definem osrequisitos, testes.

PessoasMétodos Disciplinados
Previsibilidade, estabilidade,garantia elevada.
Equipas e projetos grandes.
Estável, poucas mudanças, foco no
projeto/organização.
Conforme a necessidade deinteragir com o cliente, foco em
disposições contratuais.
Planeamento documentado,
controlo quantitativo.
Conhecimento documentado
explícito.
Projeto formalizado, capacidade,interface, qualidade, necessidades
previsíveis de evolução.
Design extenso, incrementos
longos, refactoring muito
dispendioso.
Planos de teste e procedimentos
documentados.

16

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Caraterísticas
ClienteMétodos Ágeis
Dedicado, com conhecimento,
autorizado, comprometido,
disponível, colaborativo,
representativo e habilitado.

Equipa de
DesenvolvimentoÁgil, com conhecimento, disponível
e colaborativo.

CulturaConforto e capacidade através demuitos níveis de liberdade(progredindo no caos).

Métodos Disciplinados
Acesso ao conhecimento,
colaborativo, representativo ecliente habilitado, nem sempre
disponível.
Orientados para o planeamento,
competências adequadas, acesso aconhecimento externo.
Conforto e capacidade através dequadro de políticas eprocedimentos (progredindo em
ordem).

2.1.4 Seleção do Método de Desenvolvimento de Software
Como descrito nas subsecções 2.1.1, 2.1.2 e 2.1.3, existem diferentes métodosde desenvolvimento de software, cada um com as suas especificidades, vantagens
e desvantagens. Aquando da seleção de um método, importa clarificar os fatores ater em consideração nessa escolha e na definição dos princípios a adotar. Nosparágrafos seguintes clarificam-se estes aspetos de acordo com os autoresconsultados (Abbas, 2006; Abbas, et al., 2008; Beck, 2000; Bergin, Caristi,
Dubinsky, Hazzan, & Williams, 2004; Boehm & Turner, 2003; Costa, et al., 2009c,
2010a, 2010c; Dybå & Dingsøyr, 2008; Flower, 2005; Larman & Basili, 2003;
Manifesto, 2001; Miguel, 2003; Paelke & Nebe, 2008; Shneiderman & Plaisant,2005; Sommerville, 2007).
A seleção do método é influenciada por diferentes fatores, como, por exemplo,
a tipologia do software, as competências das pessoas envolvidas no seu
desenvolvimento ou o tamanho da equipa e do próprio software. Estes fatores
devem ser cuidadosamente analisados antes de se optar por determinado método
em detrimento de outro. No que respeita à tipologia do software, a seleção dométodo de desenvolvimento mais “adequado”, deve ter em atenção as duas
tipologias seguintes (Sommerville, 2007):• Produtos genéricos: uma equipa desenvolve um software para sercomercializado num determinado mercado, podendo os clientes/utilizadores
adquirir o mesmo;

17

Capítulo II – Enquadramento do Estudo• Produtos “feitos à medida”: são pacotes de software solicitados por
determinados clientes, em que a empresa desenvolve um software
especificamente para um cliente.
Tendo em conta que os projetos raramente podem ser caraterizados por
atributos iguais ou semelhantes, existem inúmeras possibilidades para efetuar
escolhas apropriadas ou menos apropriadas. Segundo Toth (2005) e Miguel(2003) existem três dimensões a ter consideração na seleção do método:• Infraestrutura (ambiente físico, organizativo e social): refere-se aos prérequisitos técnicos, humanos e fatores associados com o ambiente que afetam
de forma crítica o sucesso ou não do projeto. Engloba a definição da liderança
e da capacidade de gestão, da definição da equipa, da colaboração com
clientes/utilizadores e da seleção de ferramentas e tecnologias com uma
relação custo-eficiência adequadas;• Modelo do ciclo de vida de desenvolvimento: é o modelo que orienta aaproximação geral e a estratégia que a equipa seguirá para realizar o projeto;• Áreas chave do método: normalmente designadas como “práticas”, sãoprocessos e técnicas que orientam as tarefas do dia-a-dia conduzidas pelos
elementos da equipa. Inclui gestão do projeto, garantia de qualidade,requisitos de engenharia de software, arquitetura do projeto, detalhes do
projeto, verificações e validações, análise de risco, entre outros.
Além das três dimensões acima referidas, Toth (2005) acrescenta oito critérios
a ter em consideração na seleção do método:
a. Estabilidade (Maintainability): requisitos bem definidos, projetos estáveis,
normas de codificação consistentes e documentação adequada contribuem
para a estabilidade do software. Sistemas muito complexos e críticos têm
muitas vezes requisitos de estabilidade exigentes, uma vez que pressupõem
preocupações com os custos totais do seu ciclo de vida, tanto durante o seu
desenvolvimento como durante a sua aplicação. Por outro lado, para sistemas

18

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

adhoc 4 com propósitos de validação de conceitos ou para experimentação,pouco importam os estados anteriores do sistema e os efeitos dos custos;b. Domínio da Aplicação: nas aplicações de alta qualidade deve ter-se em
consideração fatores como a segurança e a fiabilidade, disponibilidade eoutros sistemas críticos; aplicações moderadas incluem aplicações denegócios; nas aplicações de baixa qualidade tecnológica estão incluídos ostestes beta, protótipos para provar conceitos e as aplicações web simples;c. Tamanho/Complexidade:

por

uma

questão

desimplicidade,consideramos que o tamanho e a complexidade são relativamente lineares eestão diretamente associados. Assume-se que projetos de software grandes ecomplexos têm pelo menos 500K de linhas de código; projetos pequenos e
simples menos de 10K de linhas de código e projetos de médio porte têm osvalores intermédios;d. Indefinição dos Requisitos: este critério é muito difícil de quantificar.
Assume-se então que os requisitos têm um grande grau de incerteza se são
apenas verbalizados ou se foram expressos em poucas páginas, com pouca
informação dos utilizadores. Entretanto, requisitos bem definidos jáenvolvem estudos, informação detalhada dos utilizadores, possivelmente já
existem protótipos e já foram escrutinados por outras entidades. Os projetos
de definição de requisitos moderados encontram-se algures no meio;e. Visibilidade do Progresso: a visibilidade do progresso pode ser alcançada
através de demonstrações e da documentação - ambos têm as suas limitações.
As demonstrações são favorecidas pelos clientes (utilizadores), mas se não
forem suportadas por outras medidas de progresso podem dar a ilusão demaior progresso do que o realmente alcançado. A documentação é maisdifícil de traduzir como progresso mas simplifica a contratação. Assim sendo,
é incentivada por aqueles com preocupações económicas e legais. Assume-se
4

Designa ciclos completos de construção de software que não foram devidamente planeados, com anecessidade de responder a uma solicitação específica.

19

Capítulo II – Enquadramento do Estudo

que demonstrações frequentes aos clientes (utilizadores), acompanhadas por
níveis razoáveis de documentação apresentam um grande grau de visibilidade
do progresso. Demonstrações pouco frequentes e documentação escassa
apresentam pouca ou nenhuma visibilidade do progresso;
f. Envolvimento dos Utilizadores: o envolvimento dos utilizadores diz
respeito às especificações e definição dos requisitos, validação dos requisitos,
verificação de protótipos, suporte descriminado do projeto e do processo
desenvolvimento, revisão das especificações e aceitação de produtos
finalizados. Utilizadores envolvidos no suporte de três ou mais destas áreas
são considerados “muito envolvidos”. Apoio marginal de apenas uma área é
considerado “pouco envolvimento”;
g. Volatilidade dos Requisitos: fator difícil de quantificar, requer uma boa
compreensão do domínio do problema, especificamente no que diz respeito à
maturidade do cliente (utilizador) e da equipa de desenvolvimento. Se osoftware não tiver precedentes ou se o problema é de uma área emergente, os
stakeholders 5 não vão ter a certeza do que vai ser alterado enquanto não forcolocado em prática. Muitas vezes, mas nem sempre, a incerteza dos
requisitos está associada com a volatilidade dos mesmos;h. Urgência: as forças de mercado colocam pressão nos projetos de software
para criar e apresentar novas funcionalidades e caraterísticas o mais
rapidamente possível. Isto cria uma grande pressão na calendarização doprojeto. A urgência deve ser moderada para projetos críticos, como asegurança das pessoas e transações comerciais, onde os erros não podem ser
tolerados.
Na sequência do exposto é importante analisar algumas metodologias dedesenvolvimento de software educativo de forma a identificar quais os critérios
com maior relevância e que foram considerados na Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador.
5 Indivíduos ou instituições que estão ativamente envolvidos num projeto ou cujos interesses possam ser

positiva ou negativamente afetados com o resultado da execução ou da conclusão do projeto.

20

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

2.2

METODOLOGIAS DE DESENVOLVIMENTO DE SOFTWAREEDUCATIVO

Feita uma resenha dos métodos de desenvolvimento de software e dado nocontexto do estudo se ter desenvolvido uma metodologia de desenvolvimento deum courseware com fins educativos, na secção seguinte apresentam-se exemplosde métodos de desenvolvimento de software educativo reportados na literatura. A
descrição dá continuidade ao estudo efetuado por Guerra (2007). A autora
apresenta algumas metodologias de desenvolvimento de software educativo,como, por exemplo, a ADIIE (análise, design, desenvolvimento, implementação eavaliação) e o Rapid Prototyping Design. Optou-se, neste estudo, por caraterizar
outras metodologias, tais como, We!Design (Triantafyllakos, Palaigeorgiou, &Tsoukalas, 2008), Univap Virtual (Bicudo, et al., 2007), Use Case (Castro &Aguiar, 1999) e o Softvali (Benitti, Seara, & Schlindwein, 2005), dado focarem os
procedimentos e técnicas exploradas na constituição das equipas e o papel doutilizador final, aspetos a que foi dado especial relevo na metodologia que sepropõe neste estudo.
Poder-se-ia alargar o leque de pesquisa a outras metodologias dedesenvolvimento de software educativo, porém não se justifica porque as quatro
metodologias supracitadas permitiram tirar algumas conclusões e serviram debase à proposta de metodologia que apresentamos na seção 3.2 e que serve detítulo a este estudo.
A semelhança do efetuado na secção anterior, na última subsecção, realiza-se
uma análise comparativa das fases das metodologias de desenvolvimento
apresentadas, contrastando-as com as fases de desenvolvimento de software
proposto por Sommerville (2007). Realça-se ainda os elementos da equipa aenvolver no desenvolvimento de software educativo.

21

Capítulo II – Enquadramento do Estudo

2.2.1 We!Design
Esta metodologia de desenvolvimento segue uma estrutura baseada no Design
Participativo (ver secção 2.3), em que alunos literados informaticamente e
designers trabalham conjuntamente no desenvolvimento de pacotes de software
educativo. Os alunos a envolver deverão ter experiência em avaliação e registo denotas/observações e estar bem adaptados às particularidades tecnológicas, sociais
e culturais de cada ambiente educacional (Triantafyllakos, et al., 2008). A
metodologia é constituída por duas fases:• Fase 1: os alunos participam em sessões de curta duração em que
formulam/evidenciam as suas necessidades, as tarefas e desenvolvem os
protótipos de interface para o software educativo em análise. Em cada sessão
de design participam três a quatro alunos e dois coordenadores. O número
reduzido de alunos, minimiza o número de possíveis conflitos entre os
mesmos e reduz o tempo para se conseguir criar uma atmosfera agradável e
informal.

Os

coordenadores

devem

ter

backgrounds

diferentes,

nomeadamente um deve ser da área educacional e o outro perito de interação
homem-computador. Os coordenadores não devem interferir no processo de
tomada de decisão por parte dos alunos. Os elementos trabalham numa sala,em torno de uma mesa utilizando um quadro branco para desenvolver
protótipos de reduzida fidelidade (este procedimento é registado em vídeo).
No início de cada sessão os coordenadores apresentam de forma sucinta a
metodologia e tentam assegurar que os alunos percebam a importância dasua participação;• Fase 2: os designers sistematicamente analisam e integram as sugestões dos
alunos. Inicialmente os requisitos sugeridos são organizados com base noconteúdo. Cada requisito é reavaliado de acordo com o número de vezes que
surgiram nas sessões e através da avaliação efetuada pelos alunos. Os
requisitos são selecionados com base nos seus rankings. No final, o software
desenvolvido é novamente apresentado aos alunos, a fim de identificar
pontos fracos ou fragilidades.

22

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

A metodologia We!Design aplica várias iterações curtas e estruturadas e, em
cada iteração, participam diferentes alunos. A relevância desta metodologia, nocontexto do presente estudo, prende-se com a especificação do papel que os alunos
podem ter no desenvolvimento de software educativo, tendo em vista que este
corresponda às necessidades dos utilizadores.
O

envolvimento

doutilizador

final

na

Metodologia

HíbridadeDesenvolvimento Centrado no Utilizador (secção 3.2) foi apenas tido em
consideração na fase de avaliação de protótipos e na 1ª versão do software deforma a reduzir-se custos e tempo de desenvolvimento (Abras, Maloney-Krichmar,& Preece, 2004).
2.2.2 Projeto Univap Virtual
Os autores do projeto desenvolvido pela Univap Virtual (2007), evidenciam anecessidade de existir um equilíbrio entre a qualidade técnica e a qualidade
pedagógica, de forma que os jogos pedagógicos não sejam “aborrecidos” e os quesão realmente atrativos sejam desprovidos de qualquer qualidade pedagógica. A
metodologia utilizada pela Univap Virtual tem por base um processo definido por
cinco fases: análise, planeamento, pré-produção, produção e pós-produção. Cada
uma destas fases é ainda dividida em várias subfases:• Fase 1, Análise: definição de objetivos e do público-alvo a quem se destina
o software, efetuando em simultâneo o levantamento dos requisitos
mínimos. Na tarefa seguinte, é definida a estratégia pedagógica e instrutiva,
em que se efetua o levantamento de informação científica sobre a temática dorecurso que se pretende desenvolver. Finalmente é definido o suporte dedistribuição;• Fase 2, Planeamento: definição do guião e descrição dos aspetos
audiovisuais é o primeiro ponto desta segunda fase. Nesta fase são ainda
definidas

asmetodologias

educacionaiseodesenvolvimento

dos

instrumentos de avaliação técnica e pedagógica;23

Capítulo II – Enquadramento do Estudo• Fase 3, Pré-produção: que envolve o desenvolvimento das personagens e
do cenário tridimensional, a definição das interfaces, a definição das
ferramentas computacionais e requisitos do sistema e novamente a avaliação
técnica e pedagógica;• Fase 4, Produção: esta fase inicia-se com desenvolvimento, modelagem e
aplicação de texturas aos elementos gráficos (modelos tridimensionais). De
seguida são concebidas as animações e produzidos os áudios e os vídeos. A
próxima tarefa passa por “ligar” os elementos anteriores integrando-os e
programando-os. Paralelamente a isto, e como acontece na fase anterior, éfeita uma avaliação técnica e pedagógica;• Fase 5, Pós-produção: é desenvolvido o manual do utilizador (cominstruções) e é efetuada a validação e os testes ao software.
A avaliação técnica e pedagógica durante o processo de desenvolvimento é um
fator importante nesta metodologia, sendo aplicada no final de cada fase. Tal comona Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, que serádescrita na secção 3.2, o foco de avaliação por parte dos utilizadores é a satisfação
e a motivação para utilizar o recurso.
2.2.3 Projeto Use Case
O Use Case de Castro & Aguiar (1999) é uma metodologia que tem por base a
constituição de uma equipa multidisciplinar (pressuposto do Design Centrado no
Utilizador) que deve envolver professores, alunos, analistas, guionistas, designers
multimédia, entre outros O processo de desenvolvimento tem sete fases principais:• Fase 1, Preparação: é formada a equipa de trabalho, a escolha dos modelosde desenvolvimento de software (esta atividade carateriza-se pela seleção demodelo(s) de desenvolvimento, utilizados no processo de construção deaplicações de uma forma mais genérica) a serem utilizados durante oprocesso e o projeto instruticional;• Fase 2, Prototipagem: nesta fase é necessário levantar os requisitos
mínimos, refletir sobre os mesmos, analisar as suas implicações e redefini-los
24

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativocom

rigor.

Esta

fase,

é

normalmente

comum

aos

métodosdedesenvolvimento de software, e implica um estudo da área educacional dosoftware a ser desenvolvido e consequentemente o levantamento dos
requisitos necessários do mesmo, para que este corresponda às necessidades
dos utilizadores. De seguida, identificam-se os requisitos mínimos e as
restrições no desenvolvimento do software. Definidos os requisitos, estes
deverão ser representados e validados pelos utilizadores;• Fase 4, Implementação: parte mecânica e com menor importância noprocesso de desenvolvimento pois, as principais as decisões são tomadas nas
fases anteriores;• Fase 5, Teste: para esta atividade foi utilizado o modelo de testes ObjectOriented Software Engineering (Jacobson, Christerson, Jonsson, &Övergaard, 1992). Nesta fase participam o analista, o programador, os
professores e os alunos;• Fase 6, Avaliação: o analista, os professores e os alunos participam nesta
fase. As diversas iterações da prototipagem evolutiva proposta no ciclo devida desta metodologia, assinalam o fim de uma versão do recurso. O número
de versões a serem entregues deverá ser acordado com o utilizador no início
do desenvolvimento, a fim de se tentar evitar um número excessivo dealterações que irão afetar o prazo de entrega. Basicamente, esta fase envolve aapresentação do recurso ao utilizador, a interação do utilizador com o recurso
e a recolha de sugestões para serem introduzidas numa próxima versão;• Fase 7, Implantação: o analista, o programador e designer multimédia,após a implantação do software, deverão ter em consideração que o mesmo
irá necessitar de manutenção e atualizações. Além disso, é necessário ter ocontrolo de versões do software e dos suportes de distribuição (por exemplo,
CD-ROM). Deverão também precaver rotinas simples de configuração egarantir o suporte técnico.
À semelhança da metodologia apresentada na subsecção 2.2.2 a avaliação
durante o processo de desenvolvimento é um fator basilar no Use Case. Além

25

Capítulo II – Enquadramento do Estudo

disso, tal como na Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador, que será descrita na secção 3.2, a prototipagem foi essencial na
produção de soluções de projeto.
2.2.4 Projeto Softvali
A metodologia utilizada para desenvolver o projeto Softvali envolveu uma
equipa multidisciplinar, constituída por profissionais da área da educação
(investigadores de psicologia e pedagogia e professores), profissionais da área da
informática, especificamente da área de engenharia de software e programadores,
designers com conhecimentos de usabilidade e por fim os professores e os alunos(Benitti, et al., 2005). O processo de desenvolvimento assentou em quatro fases
principais:• Fase 1, Conceção: teve por finalidade para definir as orientações gerais do
software. Compreendeu a definição dos objetivos de aprendizagem e
requisitos do software;• Fase 2, Elaboração/Construção: centrada na implementação do recurso,
concebida com base no modelo de prototipagem evolutiva. Abordou também
aspetos de especificação, avaliação e validação;• Fase 3, Finalização: teve como objetivo integrar as funcionalidades
concebidas visando construir o produto final. Além disso, previa uma tarefa
específica para elaborar a documentação do recurso;• Fase 4, Viabilização: destinada a viabilizar a utilização do software
educativo, atuando na preparação dos professores e fornecendo suporte,atividade que abrange a manutenção técnica e pedagógica. Nesta fasecorrigem-se os problemas encontrados e apoia-se no uso do software
educativo.
As

fases

desta

metodologia

foram“idealizadas”

baseando-senodesenvolvimento prático de pacotes de software educativo, como foi o caso do
projeto Softvali. Este projeto teve como principal objetivo o desenvolvimento de26

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

um software educativo coerente, tendo a sua conceção sido orientada por
diretrizes pedagógicas (Benitti, et al., 2005).
2.2.5 Fases de desenvolvimento de software educativo e elementos aenvolverIndependentemente da tipologia de software e do seu contexto de uso,concorda-se com Sommerville (2007), considerando que as fases fundamentais no
desenvolvimentodeum

softwaresão

comunsà

maioria

dosmétodos/metodologias, ou seja, é necessário efetuar a:• Especificação do software: na qual as funcionalidades do software e
restrições sobre o seu funcionamento devem ser definidas;• Conceção do software e implementação: fase em que é produzido o software
para ir ao encontro das especificações;• Validação do software: fase em que o recurso é validado para assegurar que éo que os clientes/utilizadores pretendem;• Evolução do software: fase em que se introduzem ajustes para responder arequisitos dos clientes/utilizadores não previstos inicialmente.
Evidencia-se que as fases que constituem as metodologias de desenvolvimentode software educativo vão-se “moldando” em torno de métodos já existentes (vertabela 4). Apesar de surgirem com designações diferentes, a análise, o design e a
implementação, são fases que se podem identificar nestes processos e que advêm
dos primeiros métodos de desenvolvimento de software (Miguel, 2003;
Sommerville, 2007). Na fase referente à análise é efetuado o levantamento dos
requisitos do software, são definidos os objetivos educacionais e o público-alvo aquem se destina o software. No processo utilizado para desenvolver o projeto
Univap Virtual, nesta fase é ainda efetuado o levantamento de informação
científica sobre a temática do recurso. No Use Case é realizado um estudo da áreaeducacional do recurso a ser desenvolvido e consequentemente o levantamento

27

Capítulo II – Enquadramento do Estudo

dos requisitos necessários, para que este corresponda às necessidades dos
utilizadores.
Tabela 4 - Fases fundamentais no desenvolvimento de software comparativamente às fases de trêsmetodologias de desenvolvimento de software educativo.
Fases de desenvolvimento(Sommerville, 2007)
Especificação

UnivapVirtualAnálisePlaneamento

Conceção e implementação

Pré-produção

Validação

Produção
Pós-produção

Evolução

Do

expostonas------

subsecções

anteriores,

Use Case

Softvali

Preparação

Conceção

Prototipagem(análise, projeto,implementação,teste e avaliação)Elaboração
construção

Implantação

realça-se

Finalização
Viabilização

ainda

que,

no

desenvolvimento de software educativo, outro fator essencial é o envolvimento do
utilizador final, alunos e professores, bem como a constituição de equipas
multidisciplinares, ambos pressupostos do Design Centrado no Utilizador que seapresentam na subsecção 2.3.1.
2.3

ENVOLVIMENTO DO UTILIZADOR NO DESENVOLVIMENTO DE
SOFTWARE EDUCATIVO: potencialidades e constrangimentos

Abordagens teóricas como o Design Centrado no Utilizador (Gulliksen, Lantz,& Boivie, 1999; Mao, Vredenburg, Smith, & Carey, 2001; Marcus, 2005), Design
Participativo (Abras, et al., 2004), Design Centrado no Aprendente (Soloway,
Guzdial, & Hay, 1994) identificam as potencialidades e os constrangimentos do
envolvimento dos utilizadores nos processos de desenvolvimento de software. As
mesmas abordagens descrevem como os utilizadores podem participar no processo
de desenvolvimento de um software educativo. Nas subsecções seguintes procurase realçar estes aspetos, dada a sua relevância no contexto do estudo realizado uma
vez que se envolveu também os utilizadores finais, professores e alunos.
2.3.1 Design Centrado no Utilizador
O Design Centrado no Utilizador serve para descrever os processos de um
projeto em que os utilizadores finais têm influência na forma como este é
28

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

conduzido. No Design Centrado no Utilizador os utilizadores podem ser envolvidos
a partir da sondagem das suas necessidades, envolvendo-os em partes específicas
do processo de desenvolvimento. Por outro lado, os utilizadores podem ter uma
maior presença, integrando a equipa, isto é, serem envolvidos no desenvolvimento
durante todo o processo (Abras, et al., 2004).
O Design Centrado no Utilizador é descrito na norma ISO 13407 (1999) Human Centered Design Process for Interactive Systems e na norma ISO/TR
18529 (2000) – Ergonomics of Human-System Interaction. Estas duas normas
descrevem uma situação ideal onde não existem quaisquer obstáculos à utilização
dos pressupostos do Design Centrado no Utilizador, excetuando a possível falta decompetências por parte da equipa de desenvolvimento (Svanaes & Gulliksen,2008). Autores como Facer & Williamson (2004), entre outros, reforçam que oDesign Centrado no Utilizador combina, entre outros aspetos, a participação doutilizador e a avaliação formativa de protótipos. De acordo com a norma ISO 13407(1999), os projetos de Design Centrado no Utilizador são regidos por quatro
princípios:a) a constituição de uma equipa multidisciplinar;b) a interação entre o utilizador e o sistema;c) o envolvimento ativo dos utilizadores;d) a iteração de soluções de projeto.
É ainda indicado que os princípios acima mencionados não são vinculativos aqualquer fase do ciclo de desenvolvimento de um software.
Para Vredenburg, Mao, Smith & Carey (2002), a correta aplicabilidade dospressupostos e métodos do Design Centrado no Utilizador depende da experiência
dos elementos da equipa. Estes investigadores, no estudo “A Survey of UserCentered Design Practice” identificaram que os indivíduos que participaram no
mesmo tinham em média 7,6 anos de experiência em Design Centrado no
Utilizador, facilitando assim a sua integração. Normalmente, as equipas são
29

Capítulo II – Enquadramento do Estudo

pequenas, constituídas por dezasseis elementos, sendo dois elementos os
responsáveis principais pela implementação do método. As atividades do Design
Centrado no Utilizador, através da aplicabilidade dos métodos podem ter um
impacto significativo no desenvolvimento de determinado software, melhorandonão só a usabilidade do mesmo mas também a sua utilidade.
De acordo com (Sommerville, 2007), a IBM percecionou a importância do
Design Centrado no Utilizador, explorando uma metodologia designada por Easeof Use. Além de ter por base pressupostos do Design Centrado no Utilizador, aEase of Use é baseada no valor mensurável para o negócio dos stakeholders,clientes e utilizadores. A Ease of Use prescreve regras e atividades para serem
executadas e produtos a serem produzidos para cada regra durante cada fase do
projeto. Toda a conceção é baseada numa compreensão completa das necessidades
dos utilizadores, dos seus objetivos, das tarefas e outros fatores, fornecidos pela
análise pormenorizada das necessidades dos utilizadores. Os projetos concetuais e
detalhados são avaliados com os utilizadores antes da implementação
(Sommerville, 2007).
No seguimento do Design Centrado no Utilizador surgiram outras abordagens
teóricas ao desenvolvimento de software como é caso do Design Centrado no
Aprendente (descrita na subsecção 2.3.3). Esta abordagem assume que todos
somos aprendentes, independentemente de ser um profissional ou um aluno.
Portanto, o foco principal do Design Centrado no Aprendente é garantir que odesign de interface é apropriado aos interesses, conhecimentos e estilos dos
aprendentes que utilizam o software (Nesset & Large, 2004).
Nos processos de desenvolvimento de software educativo, sendo evidente que
as caraterísticas dos alunos e das suas necessidades como aprendentes devem serconsideradas, é recorrente que a sua participação apenas ocorra em fasesavançadas do processo de desenvolvimento. Tal implica, que contrariamente ao
proposto, por exemplo, na metodologia We!Design, o papel dos alunos seja o deavaliador (tester) de protótipos. Estes são observados a utilizar o software eentrevistadas, a fim de se obter, por exemplo, informações sobre os seus processos
de aprendizagem e comportamentos ou sobre a usabilidade do recurso. Os
30

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

professores, por outro lado, desempenham um papel mais participativo como
informantes, fornecendo feedback sobre os desafios a propor e sobre os processos
de aprendizagem dos alunos (Soloway, et al., 1994).
- Atividades do Design Centrado no Utilizador
Na norma ISO 13407, as atividades de Design Centrado no Utilizador devem
ser entendidas de forma a criar uma declaração explícita entre o utilizador e asnecessidades organizacionais em relação à descrição do contexto de utilização
(1999). Aspetos como cooperação e comunicação entre os utilizadores e outros
elementos envolvidos, o desempenho na tarefa, a gestão da mudança, a formação
contínua, devem ser considerados a fim de se identificar requisitos pertinentes.
O ciclo de desenvolvimento do Design Centrado no Utilizador é constituído
por quatro passos essenciais que devem ser realizados de forma a incorporar os
requisitos de usabilidade no processo de desenvolvimento de software (Figura 2).
Estes passos são realizados de forma iterativa, sendo o ciclo repetido até que osrequisitos sejam satisfeitos.

Figura 2 – Atividades do Design Centrado no Utilizador descritas na ISO 13407 (1999)31

Capítulo II – Enquadramento do Estudo

O planeamento do processo centrado no utilizador deve identificar, por
exemplo, procedimentos para integrar essas atividades com outras atividades dedesenvolvimento do software (análise, testes…), objetivos apropriados para as
atividades de Design Centrado no Utilizador integradas no projeto e processos
desenvolvimento e prazos adequados para possibilitar o feedback dos elementos
da equipa multidisciplinar (avaliação formativa) ou dos utilizadores (avaliação
sumativa) e possíveis alterações ao projeto. O planeamento do Design Centrado no
Utilizador deve fazer parte integrante da metodologia de desenvolvimento,
devendo ser analisado, de forma a efetuar-se possíveis mudanças nos requisitos edeve ser atualizado para refletir a situação atual das atividades.
As quatro atividades são caraterizadas seguidamente:• conhecer e especificar o contexto de uso (Planeamento): conhecer outilizador, o contexto de utilização e as tarefas que o software deverá
permitir realizar;• especificar os requisitos do utilizador e da organização (Design): determinaros critérios de usabilidade do software relativamente às tarefas do utilizador;• produzir soluções de projeto (Implementação): possíveis soluções de projeto(design gráfico, design interativo, usabilidade) são concebidas com base no
estado da arte, na experiência e nos conhecimentos dos elementos da equipa
e dos resultados da análise do contexto de uso. O processo envolve, portanto,
as seguintes atividades:o utilizar os conhecimentos para desenvolver propostas de projeto com
os inputs da equipa multidisciplinar;o tornar as soluções de projeto mais “palpáveis” através de simulações,modelos, maquetes, entre outros;o apresentar as soluções de projeto aos utilizadores e permitir que
realizem as tarefas (ou simulem as tarefas);32

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

o alterar as soluções de projeto com base no feedback dos utilizadores e
repetir este procedimento até que as metas do Design Centrado no
Utilizador sejam satisfeitas;o gerir as iterações de soluções de projeto.
• avaliar as soluções de projeto através dos requisitos (Implementação): ausabilidade das soluções de projeto é avaliada através das tarefas realizadas
pelo utilizador.
- Potencialidades e Constrangimentos do Design Centrado no
Utilizador
Na Tabela 5 identificam-se vantagens e desvantagens do Design Centrado no
Utilizador, de acordo com Abras, Maloney-Krichmar & Preece (2004).
Tabela 5 - Vantagens e Desvantagens do Design Centrado no Utilizador, adaptado de Abras,
Maloney-Krichmar & Preece (2004)
Vantagens
Os recursos são mais eficientes, eficazes efiáveis.
Os níveis de satisfação e de expetativas
aumentam por parte dos utilizadores.
Os utilizadores desenvolvem um sentido deposse sobre os recursos.
Os recursos necessitam de menos redesign e
são integrados de forma mais rápida.
O processo colaborativo criativo gera maissoluções para os problemas de conceção.

Desvantagens
São mais dispendiosos.
Demoram mais tempo.
Pode exigir a participação de elementos
exteriores à equipa de desenvolvimento (porexemplo, etnógrafos, peritos de usabilidade) eoutras partes interessadas.
Pode ser difícil converter alguns tipos de dadospara a conceção.
O recurso pode torna-se demasiado específico
para uma utilização mais generalista, não sendo
acessível de imediato a todos os utilizadores;
desta forma fica mais dispendioso.

De acordo com as vantagens e desvantagens apresentadas na Tabela 5, nodesenvolvimento do Courseware Sere, o utilizador foi envolvido unicamente na
fase de avaliação de forma a reduzir o tempo e os custos associados.
Gulliksen, Lantz & Boivie (1999), no relatório designado “User Centered
Design in Pratice – Problems and Possibilities” identificam diferentes problemas33

Capítulo II – Enquadramento do Estudo

que ocorrem nos projetos que têm por base o Design Centrado no Utilizador, taiscomo:
1. Dificuldades de comunicação ou ausência de comunicação, por exemplo,
entre a equipa de desenvolvimento e os utilizadores, entre a gestão de projetoe os utilizadores, entre os elementos da própria equipa;
2. Falta de Competências: que capacidades e conhecimentos são necessários nodesenvolvimento de um projeto que tenha por base pressupostos do Design
Centrado no Utilizador. Por exemplo, competências sociais, conhecimentos e
capacidades técnicas sobre as tarefas a executar;
3. Atitudes: o Design Centrado no Utilizador “exige” determinada atitude dos
elementos da instituição/empresa e dos elementos da equipa de forma que oprojeto seja bem-sucedido;
4. Pouca adequação dos métodos, técnicas e ferramentas: os atuais métodos etécnicas são aplicáveis e eficientes? São as ferramentas adequadas para aparticipação do utilizador no processo de prototipagem?.
Apesar dos possíveis constrangimentos apresentados, concorda-se que nodesenvolvimento de software educativo, o envolvimento do utilizador é essencial.
Assim, pode colocar-se a questão - de que forma os utilizadores podem serenvolvidos no processo de desenvolvimento de um software educativo?
- Envolvimento de alunos e professores no Design Centrado no
Utilizador
O envolvimento de crianças e de professores no processo de desenvolvimentode um software educativo é um princípio fundamental da abordagem do Design
Centrado no Utilizador (Pardo, Vetere, & Howard, 2005). O envolvimento dos
utilizadores no processo de desenvolvimento providencia uma fonte deconhecimento sobre o contexto de utilização, sobre as tarefas e como osutilizadores tendem a trabalhar posteriormente com o software.

34

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

O grau de envolvimento dos utilizadores poderá variar consoante o papel e as
tarefas a realizar. Os utilizadores podem assumir papéis menos interventivos,
como o de verificadores (testers), como papéis mais interventivos, como o de
informadores (Nesset & Large, 2004) ou codesigners em que, os utilizadores
designados como codesigners, são encarados como membros da equipa
multidisciplinar (Preece, Rogers, & Sharp, 1994).
A Tabela 6 apresenta algumas propostas de envolvimento dos utilizadores, em
que fase do processo de desenvolvimento deverá ocorrer e que técnicas poderão serutilizadas (Preece, Rogers, & Sharp, 2002).
Tabela 6 – Envolvimento dos utilizadores no processo de desenvolvimento, adaptado de Preece,
Rogers & Sharp (2002)
Proposta
Recolha de dados sobre as necessidades e
expetativas dos utilizadores;
Avaliação de alternativas do projeto, protótipos e
produto final.
Recolha de dados relacionados com a sequência
de tarefas a ser realizada com o software.
Inclusão das partes interessadas para discutir os
requisitos do utilizador.
Recolha de dados sobre o contexto em que seráutilizado o software.
Avaliação de soluções alternativas e recolha de
informações adicionais sobre as necessidades e
expetativas dos utilizadores. Avaliação de
protótipos.
Recolha de dados quantitativos transmitidos por
critérios de usabilidade.
Recolha de dados qualitativos transmitidos pelasatisfação dos utilizadores com a utilização dosoftware.

Fase doProjetoAtravés de…
(técnicas)

No início dodesenvolvimento

Entrevistas e
Questionários

Fase inicial

Entrevistas e
Questionários

Fase inicial

Focus Groups

Fase inicial

Observação no local

Fase inicial eintermédia

Jogo de papéis,walkthroughs,
simulações e maquetas

Fase final

Testes de usabilidade

Fase final

Entrevistas e
QuestionáriosNa definição da Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador foi dado foco a avaliação de protótipos através da recolha de dados
quantitativos transmitidos por critérios de usabilidade (Costa, et al., 2010b; Costa,
et al., 2009a).

35

Capítulo II – Enquadramento do Estudo

2.3.2 Conceber para Crianças e Crianças como Codesigners
As crianças têm muito a oferecer no processo de desenvolvimento de um
software educativo, tendo estas uma perceção do mundo diferente dos adultos e
propondo ideias que estes nunca pensaram (Ruland, Starren, & Vatne, 2008). Poroutro lado, as crianças podem sugerir funcionalidades, por vezes, impossíveis deserem concebidas que, após a explicação à(s) mesmas do motivo, pode levar àinibição da criatividade. Desta forma, é importante fundamentar as expetativas
criadas pelas crianças antes de se iniciar as sessões de avaliação da usabilidade,
explicando-lhes como irá decorrer o processo. Se as mesmas não forem
previamente preparadas, muitas crianças quando entram na fase dos testes
esperam ver um software finalizado, ficando dececionadas quando são“presenteadas” com um protótipo (Hanna, Risden, Czerwinski, & Alexander, 1999;
Kelly, Emanuela, Matthew, & Janet, 2006).
Druin (1999) identifica quatro papéis (Figura 3) que uma criança poderepresentar ao envolver-se num processo de desenvolvimento de software
educativo:
1. Utilizador: as crianças são observadas enquanto realizam tarefas ou
experimentam protótipos. Esta situação pode ocorrer no início, durante ou
após a conclusão do processo de desenvolvimento através de métodos deobservação ou etnográficos;
2. Verificador (tester): as crianças são observadas enquanto testam osoftware e é-lhes solicitado feedback através de entrevistas, de questionários
e usando protocolos de registo do “pensar em voz alta” (thinking-aloud).
Normalmente o teste ocorre no final de cada fase de desenvolvimento;
3. Informador: as crianças são vistas como peritos, informando os designers
das principais questões relacionadas com a sua experiência, ajudando assim,
a desenvolver as ideias iniciais do projeto e a testar os protótipos durante odesenvolvimento;36

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

4. Codesigner: as crianças fazem parte da equipa multidisciplinar, ajudando a
identificar os problemas e as respetivas soluções para melhorar o software.

Figura 3 – Papéis da criança no processo de desenvolvimento de Druin (2002)

Sendo também, um utilizador, como poderá o professor envolver-se noprocesso de desenvolvimento de software educativo?
2.3.3 Conceber para Professores e Professores como Codesigners
Quando falamos do envolvimento do professor, surge-nos na literatura uma
variação do Design Centrado no Utilizador designada por Design Centrado no
Aprendente que, por sua vez está dividida em duas abordagens muito similares: i)
Design Centrado no Currículo e o ii) Design Centrado na Sala de Aula. Ambas,
destacam o contexto onde aprendizagem ocorre, incluindo os professores, as
crianças, o ambiente físico e cultural. Em ambas, o processo de desenvolvimento é
centrado nas aulas, sendo o papel do professor fundamental (Figura 4) (Pardo, etal., 2005).

37

Capítulo II – Enquadramento do Estudo

Figura 4 – Tipos de Design Centrado no Utilizador.

O professor durante o processo de desenvolvimento do software podedesempenhar diferentes papéis, desde utilizador, em que é observado em
atividades dinamizadas em contexto de sala de aula mediadas pela tecnologia ou
como verificador ou informador sobre as suas práticas de ensino e o seu impacto
no desempenho dos alunos. Nestes métodos, os alunos são envolvidos apenascomo utilizadores e verificadores, uma vez que as suas necessidades como alunossão definidas pelo professor e pelo currículo (Pardo, et al., 2005).
A Figura 5 apresenta os quatros papéis que o professor poderá representar (emrelação às crianças) ao envolver-se no desenvolvimento de um software educativo(Pardo, et al., 2005; Pardo, Vetere, & Howard, 2006):
1. Facilitador: os professores são os responsáveis por agendar sessões detrabalho durante o processo de desenvolvimento. Desta forma a interferência
com as atividades de sala de aula e curriculares são reduzidas. São os
professores, enquanto facilitadores, que escolhem as crianças que irãoparticipar durante o processo desenvolvimento do software e auxiliar os
investigadores a formar os grupos de crianças quando necessário (Africano,et al., 2004; Theng, Mohd-Nasir, Thimbleby, Buchanan, & Jones, 2000). A

38

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

equipa confia no conhecimento que os professores têm sobre os seus
relacionamentos, capacidades e preferências para selecionar e organizar as
crianças que irão participar no projeto;
2. Verificadores (testers): os professores avaliam as soluções de software
existentes de forma a estimar o potencial valor dos mesmos e avaliar
protótiposeprodutosem

desenvolvimento.

Sendo

os

professores

verificadores, a equipa de desenvolvimento pode recolher dados sobre as suaspráticas e experiências relativamente à utilização de outros recursos de apoio
ao ensino (Pardo, et al., 2005);
3. Informadores: os professores são vistos como tendo uma visão
incomparável sobre as práticas de aprendizagem e ensino, a que os elementos
da equipa de desenvolvimento recorrem (Scaife, Rogers, Aldrich, & Davies,
1997). A equipa procura recolher perceções sobre variadas áreas relativas àconceção e desenvolvimento de novas tecnologias. Pode-se solicitar que
descrevam o uso dos computadores na sua escola, de forma a ajudar a definir
as metas de aprendizagem, a identificar as dificuldades das crianças e as suas
capacidades. Os professores podem efetuar observações ou comentários
quanto à conformidade das tarefas de aprendizagem ou atividades em que ascrianças irão participar (nas sessões de teste ou validação), em termos declareza e adequação tendo em conta as capacidades dos alunos (Africano, etal., 2004);
4. Parceiros de Investigação: os professores podem recolher dados para aequipa de desenvolvimento, sendo o processo facilitado pela sua experiência
de contexto de sala de aula e familiaridade com as crianças ou podem darapoio às crianças durantes as sessões de desenvolvimento (Allison Druin,2002). Na realidade os professores ocupam uma posição privilegiada, poisdiariamente interagem com as crianças e observando-as a interagir entre si, oque permite capturar dados no decorrer do tempo e durante diferentes
atividades.

39

Capítulo II – Enquadramento do Estudo

Figura 5 – Papéis do professor no processo de desenvolvimento, adaptado de Pardo, Vetere &Howard (2005)

Nesta secção descreve-se sucintamente os pressupostos do Design Centrado no
Utilizador, dando uma maior relevância a um dos pressupostos: o envolvimento do
utilizador. No contexto deste estudo, considera-se também relevante perceber as
potencialidades e constrangimentos do trabalho colaborativo em equipas
multidisciplinares,

pressuposto

que

foi

consideradona

metodologia

dedesenvolvimento adotada.
2.4

O TRABALHO COLABORATIVO EM EQUIPAS MULTIDISCIPLINARES

Em projetos em que o desenvolvimento de software é feito envolvendo equipas
multidisciplinares, o seu sucesso depende do desempenho dos elementos daequipa, 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 omesmo trabalho com base no esforço e competências de cada elemento (Fuks,
Gerosa, & Lucena, 2002) e ii) os elementos podem identificar antecipadamenteinconsistências e falhas que decorrem durante o processo de desenvolvimento.

40

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Colaborativamente, a equipa pode debater ideias e resolver problemasdetetados, além de facilitar o processo criativo, surgindo mais soluções de projetopara os requisitos do software, analisando desta forma e em conjunto, as
vantagens e desvantagens, antes do incremento de novas soluções de projeto(Turoff & Hiltz, 1982). O facto de um elemento de uma equipa receber feedback
dos outros elementos aquando da disponibilização, por exemplo, de uma versão deum documento, permite que o mesmo seja mais reflexivo e pode levar ao
melhoramento do mesmo (Benbunan-Fich & Hiltz, 1999) incrementando assim aqualidade do recurso.
Na subsecção 2.4.1 descreve-se sucintamente a constituição de equipas
multidisciplinares, pressuposto do Design Centrado no Utilizado, e na subsecção
2.4.2 o modelo 3C de Colaboração.
2.4.1 Equipas Multidisciplinares
Numa equipa multidisciplinar recentemente constituída, numa fase inicial,existe a preocupação de distribuir “corretamente” as tarefas pelos elementos e se
perceber se cada um é capaz de assumir a responsabilidade ou papel nas tarefas
que lhe são conferidas ou designadas (Miguel, 2003). O mesmo autor afirma quequanto maior for a integração dos elementos da equipa, melhor será a partilha de
informação, serão facilitadas as tomadas de decisão, levando os elementos asentirem-se mais comprometidos com o projeto. O nível de confiança entre oselementos da equipa permite que os processos de comunicação sejam mais fáceis e
eficazes.
Os projetos que têm por base os pressupostos e métodos do Design Centrado
no Utilizador necessitam de diferentes backgrounds de forma a abordar diferentes
aspetos do software. As equipas podem ter um número variável de elementos e serconstituídas por utilizadores, peritos de usabilidade, gestores de projeto,engenheiros

desoftware,designers

gráficos,designersdeinteração,programadores, analistas de sistemas, comerciais, marketers, entre outros.
Contudo, quanto maior for a equipa, mais barreiras de comunicação podem surgir,
41

Capítulo II – Enquadramento do Estudo

pelo facto de elementos com diferentes competências terem perspetivas diferentes,
bem como variadas formas de ver e falar sobre o que os rodeiam (Preece, et al.,2002).
Duranteomultidisciplinares

processotantodedesenvolvimento

realizamtarefasdesoftware,asequipascolaborativamente

comocooperativamente 6. O processo de desenvolvimento envolve ainda processos decomunicação e coordenação. Estando uma das questões do estudo efetuado
relacionada com a análise do processo de desenvolvimento de um software
educativo, apresenta-se, na subsecção seguinte o modelo 3C de colaboração em
que foi baseada essa análise, embora com adaptações que serão descritas efundamentadas no capítulo 3, secção 3.3.
2.4.2 Modelo 3C de Colaboração
O modelo 3C de colaboração (Figura 6) 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 (2004;
2005; 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 (Marsic & Dorohonceanu, 2003) e para avaliação deaplicações colaborativas (Neale, Carroll, & Rosson, 2004).

6 Na literatura é recorrente os termos colaboração e cooperação surgirem como sinónimos. Na realidadesã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 é “... accomplishedby 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 coordinatedeffort to solve the problem together.” De forma complementar a Dillenbourg, Michael Schrage (1990, pp., p.
140) no livro Shared Minds define a colaboração como um “... process of shared creation: two or moreindividuals 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 aprocess, 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émde envolver vários elementos, implica que as suas competências sejam complementares.

42

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

A comunicação no modelo 3C de colaboração compreende a troca demensagens, bem como a negociação de compromissos. A cooperação envolve otrabalho 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 anegociação de compromissos através da comunicação, sendo geridos pela
coordenação e realizados de forma cooperativa.

Figura 6 – Modelo 3C de Elis (1991) adaptado por Fuks e colaboradores (2004; 2005; 2008)

O modelo 3C assenta sobre três pilares, que passamos a descreversucintamente:•

Comunicação

No desenvolvimento de software, a comunicação normalmente envolve
compromissos e negociação dos mesmos. A Figura 7 representa uma ação entre oemissor 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. Paratransmitir 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 decomunicação através da qual se processa a interação.
43

Capítulo II – Enquadramento do Estudo

Figura 7 – Modelo de Comunicação de Fuks e colaboradores (2004; 2005; 2008)

Quando os elementos de uma equipa comunicam, normalmente, concentramse 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 dosucesso da comunicação é através do discurso e das ações (e reações) do recetor.
•

Coordenação

Malone e Crowston (1994, p. 101) 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, deacordo com (Acuna, Gómez, & Juristo, 2009), exige um esforço suplementar decoordenação da equipa multidisciplinar, de forma a evitar que os fatores docomportamento, que surgem através da interação, tais como, conflitos, a coesão, acooperação e a comunicação, levem a falhas.
A coordenação (ver Figura 8) 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,

44

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

levando às ações necessárias para o trabalho cooperativo. As tarefas devem serassumidas como um compromisso individual ou da equipa.

Figura 8 – Modelo de Coordenação de Fuks e colaboradores (2004; 2005; 2008)

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 elementoestá 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 decada um através da interação empenhada, maior será a garantia do bomdesempenho da equipa (McChesney & Gallagher, 2004).
As informações são essenciais para o coordenador verificar se existem conflitosde interesse que prejudiquem a equipa e para identificar a capacidade eexperiência de cada elemento da equipa multidisciplinar.

45

Capítulo II – Enquadramento do Estudo•

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 9). 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 (T. W. Malone &Crowston, 1990).

Figura 9 – Modelo de Cooperação de Fuks e colaboradores (2004; 2005; 2008)

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 dedesenvolvimento de software, que necessitam de ferramentas que permitam ainteração entre os elementos da equipa multidisciplinar. A utilização de software
colaborativo, normalmente designado como groupware, tem sido explorado dado

46

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

integrar diferentes ferramentas de comunicação, de coordenação e de colaboração
e cooperação.
- Software Colaborativo (groupware)
O desenvolvimento de software é essencialmente um trabalho colaborativo e
cooperativo, em que o mesmo é realizado por diferentes pessoas (com diferentes
papéis) e suportado por diferentes ferramentas (Saeki, 1995; Serçe, et al., 2010).
Com o avanço tecnológico estas ferramentas podem estar disponibilizadas num
ambiente distribuído (proporcionado pela internet), facilitando a partilha de
informação e a comunicação entre os elementos de uma equipa (Serçe, et al.,2010). Um espaço online disponibilizando um conjunto de ferramentas diversas
pode designar-se como groupware, aplicação que pode ser agrupada de acordo
com a sua funcionalidade genérica, nas seguintes categorias, entre outras:• sistemas de comunicação (fóruns, chats);• espaços de partilha de informação (mediaspaces);• coordenação de processos (workflow).
O trabalho colaborativo a distância é muitas vezes designado como Computer
Supported Cooperative Work (Castro & Aguiar, 1999; Saeki, 1995). Trata-se de um
conceito que aborda a forma como o trabalho em equipa pode ser auxiliado pelas
Tecnologias de Informação e Comunicação, de forma a melhorar o desempenho na
execução das tarefas (Wallace, Scott, Stutz, Enns, & Inkpen, 2009). Os espaços
Computer Supported Cooperative Work podem ser caraterizados (Figura 10)
atendendo à:• distância geográfica dos elementos da equipa (remota ou localmente);• forma de comunicação (síncrona ou assíncrona).

47

Capítulo II – Enquadramento do Estudo

Figura 10 – Matriz Computer Supported Cooperative Work (CSCW)

Uma das grandes promessas do Computer Supported Cooperative Work estáno suporte aos processos de desenvolvimento de software, dada esta modalidadede trabalho em equipa poder integrar todas as fases (análise, planeamento,
implementação,validação

everificação

emanutenção).

As

equipasmultidisciplinares podem colaborar e cooperar e desenvolver os projetos de forma
dinâmica e organizada, podendo melhorar a sua produtividade (Serçe, et al.,2010).
2.5

MÉTODOS E MÉTRICAS PARA A GARANTIA DA QUALIDADE DE
SOFTWARE EDUCATIVO

A qualidade do software educativo, pode ser garantida desde o início do ciclode desenvolvimento do software dependendo, em grande parte, das competências
dos elementos da equipa multidisciplinar e da avaliação efetuada pelos utilizadores
finais. O papel da avaliação no desenvolvimento de software tem tanta
importância que a International Standards Organisation - ISO definiu uma sériede práticas disseminadas em diferentes normas, que se descrevem na subsecção
seguinte (2.5.1). Na subsecção 2.5.2 dar-se-á enfase à avaliação de software
educativo tendo por base métodos do Design Centrado no Utilizador e na

48

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

subsecção 2.5.3 abordar-se-á os fatores inerentes à melhoria de processos dedesenvolvimento de software.
2.5.1 Normas de Qualidade (ISO)No panorama internacional, as atividades associadas ao desenvolvimento desoftware são de reconhecida importância, o que levou a International Standard
Organisation (ISO) a definir um conjunto de normas. Na Figura 11 apresenta-se
algumas dessas normas e em que fase do ciclo de vida de um software as mesmas
devem ser contempladas.

Figura 11 – Normas ISO para o desenvolvimento de software

As normas que apresentamos abrangem os processos de ciclo de vida e dedesenvolvimento, bem como avaliação de pacotes de software:• ISO 15504 (2004): é uma evolução da ISO 12207 integrando níveis decapacidade de cada processo de desenvolvimento de software;• ISO 13407 (1999): Human Centered Design Process for Interactive Systems
é a norma que define os princípios de Design Centrado no Utilizador;• ISO 9126 (1999): diz respeito à qualidade de produto de software. Define seis
métricas para avaliação de um software;49

Capítulo II – Enquadramento do Estudo• ISO 14598 (1998): define o processo de avaliação da qualidade do software.
Neste processo de avaliação, a identificação das necessidades dos utilizadores
é perspetivada como um meio para garantir a qualidade de utilização,podendo esta qualidade ser aferida através das métricas definidas na norma
ISO 9126.
As

normassupracitadas

sendointegradas

numa

metodologia

dedesenvolvimento de software, influenciam e caraterizam os processos eprocedimentos da mesma. Desta forma, a qualidade do software pode ser vista
como um conjunto de caraterísticas que devem ser alcançadas para que o recurso
responda aos requisitos dos utilizadores. Dentro deste contexto, a norma ISO 9126
(1999) estabelece um modelo com as seguintes componentes:• Processo de Desenvolvimento: cuja qualidade influencia a qualidade dosoftware que irá ser concebido e é influenciado pela natureza do recurso
desenvolvido;• Produto: compreende os atributos de qualidade do software. Estes
atributos de qualidade podem ser divididos entre atributos internos e
externos. Estes diferenciam-se pela forma como são aferidos e em conjuntocompõem a qualidade do recurso em si;• Qualidade de Uso: consiste na aferição da qualidade do software nocontexto específico (físico e social) de utilização. Esta é, também, a qualidade
percebida pelo utilizador.
Um sistema de qualidade do software deve garantir dois objetivos
fundamentais:• Incorporar a qualidade: com base nas ferramentas utilizadas e nas
metodologias de desenvolvimento de software;• Preservar a qualidade: quando efetuadas alterações ao software devem
procurar-se manter o nível de qualidade da versão anterior.

50

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

A norma ISO 9126 integra ainda seis dimensões que devem ser tidas em
consideração na aferição da qualidade de uso de um software, nomeadamente:a. Usabilidade: que diz respeito a um conjunto de atributos que determinado
software deverá conter de forma a que os utilizadores consigam atingir osseus objetivos com eficiência, eficácia e satisfação de uso em determinado
contexto de utilização;As métricas para avaliar a Usabilidade são:o Eficácia: precisão e perfeição com que os utilizadores atingem os
objetivos;
o Eficiência: recursos despendidos relativamente à precisão e perfeição
com que os utilizadores atingem os objetivos;
o Satisfação de uso: conforto e atitudes positivas relativas ao uso do
software;o Contexto de utilização: que compreende os utilizadores, as tarefas, os
equipamentos (hardware, software e materiais), o ambiente físico esocial em que o software é utilizado;
b. Funcionalidade: evidência de que o conjunto de funções do recurso atende àsnecessidades explícitas e implícitas para a finalidade a que se destina oproduto. Entende-se como necessidades explícitas as apresentadas na
definição do produto e as implícitas, aquelas que não são apresentadas mas
são necessárias para o bom funcionamento do produto;c. Fiabilidade: evidência de que o desempenho do recurso se mantém ao longo
do tempo em condições estabelecidas;
d. Eficiência: evidência de que os recursos utilizados e os tempos despendidossão compatíveis com o nível de desempenho requerido para o produto;

51

Capítulo II – Enquadramento do Estudo

e. Manutenção: facilidade para efetuar correções, atualizações e alterações aorecurso;f. Portabilidade: possibilidade de utilizar o produto em diversas plataformas
com pequeno esforço de adaptação.
Para compreensão efetiva das dimensões (fatores de qualidade) apresentadas,a Tabela 7 apresenta algumas caraterísticas associadas e possíveis questões para a
sua aferição (Seffah, Mohamed, Habieb-Mammar, & Abran, 2008).
Tabela 7 – Fatores de qualidade e respetivos critérios, baseado em Seffah, et al. (2008)
Fatores deQualidade

Critérios

Possível questão

Compreensível
Facilidade deaprendizagem
Eficiência de uso
Satisfação subjetiva
Adequação
Precisão
Interoperabilidade
Segurança

É fácil compreender a temática do software?
É fácil de aprender a utilizar?
Qual a velocidade de execução?
O utilizador evidência conforto e atitude
positiva para o uso?
Propõe-se a fazer o que é adequado?
Faz o que foi proposto de forma correta?
Interage com os sistemas especificados?
Evita acesso não autorizado aos dados?

Fiabilidade(É imune aerros/falhas?)

Maturidade
Tolerância a erros
Recuperabilidade

Com que frequência apresenta erros?
Ocorrendo erros, como reage?
É capaz de recuperar dados em caso de erro?

Eficiência
(É rápido?)

Tempo
RecursosUtilização

Qual o tempo de resposta?
Quais os recursos utilizados?

Análise de erros
Alteração de capacidade(s)Estabilidade
Teste de capacidades
Adaptabilidade
Possibilidade de instalação
Conformidade
Possibilidade desubstituição

É fácil detetar um erro quando ocorre?
É fácil de alterar ou adaptar?
Existe risco associado às alterações?
É fácil testar quando se efetua as alterações?
É de fácil adaptação em outros ambientes?
É possível instalar em outros ambientes?
Está de acordo com os padrões deportabilidade?
É possível substituir por outro software?

Usabilidade(É fácil deutilizar?)
Funcionalidade(Satisfaz asnecessidades?)Manutenção
(É fácil dealterar?)Portabilidade(É fácil de utilizar
noutroambiente?)

Os critérios definidos pelas normas estão essencialmente orientados paraquestões técnicas. Porém, para que um software educativo seja de qualidade énecessário que ocorra aprendizagem. Carvalho (2005) afirma que para isso
suceder tem que se ter em consideração três fatores que se condicionam
mutuamente: a qualidade científica, pedagógica e técnica; a familiaridade do

52

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

utilizador com o sistema informático (literacia informática) e com o conteúdo(conhecimentos prévios) e por fim, o desejo que o utilizador tem de aprender.
Tendo por base as métricas definidas nas normas atrás descritas, é necessário
que as mesmas sejam aferidas. Na subsecção seguinte, aborda-se de que forma seprocessa a avaliação de software educativo, tendo por base pressupostos e
métodos do Design Centrado no Utilizador.
2.5.2 Avaliação de Software Educativo Centrada no Utilizador“O termo avaliação designa um juízo de valor acerca de um determinado programa
informático, o que implica uma análise e observação aprofundada sobre a utilização
em contexto de um determinado programa por meio de medidas e metodologias
quantitativas e qualitativas.” (Ramos, Teodoro, Maio, Carvalho, & Ferreira, 2005)

O desenvolvimento de software educativo de qualidade implica uma avaliação
formativa dos protótipos concebidos, pelas equipas, durante o processo dedesenvolvimento (Coutinho & Chaves, 2001; Gomes, 2000; Loureiro, 2002). A
importância de se proceder à avaliação do software educativo prende-se com
várias razões, entre as quais: a inevitabilidade da sua utilização em contexto
educativo; a “facilidade” que existe, atualmente, na sua produção; a capacidade
económica das empresas produtoras; e a homogeneidade das equipas que os
desenvolvem que pode levar à produção de software de qualidade duvidosa(Ramos, et al., 2005).
Loureiro & Pombo (2006) indicam que ao definir a avaliação, é fundamental
que se distinga que tipo de avaliação se vai efetuar. Na senda de Squires e
McDouglas (1997), a avaliação pode ser:a. Formativa: deverá ser efetuada durante a fase de desenvolvimento de forma a
efetuar-se testes técnicos, analisar-se a conformidade do recurso aos
objetivos, verificar-se a adequação ao público-alvo, entre outros;53

Capítulo II – Enquadramento do Estudo

b. Conjetural:

deverá

serrealizadaumaanálise

por

parte

de

professores/especialistas, antes da utilização do recurso com o público-alvo etendo em conta esse mesmo público;c. Interpretativa: efetuada após a utilização do recurso para verificação da sua
eficiência ou não relativamente à aprendizagem e consequentemente com
vista à formulação de juízos relativos à qualidade das aprendizagens que orecurso proporciona e das competências que permite desenvolver. A
avaliação interpretativa deve incluir a avaliação do processo de aprendizagem
e dos produtos da aprendizagem.
Independentemente do tipo de avaliação e seguindo um dos pressupostos do
Design Centrado no Utilizador, a avaliação de recursos educativos, dificilmente,será mensurável se não fossem envolvidos os utilizadores finais.
- Avaliação Centrada no Utilizador
A Avaliação Centrada no Utilizador serve três objetivos: servir de suporte à
tomada de decisões, detetar problemas e verificar a qualidade do software (Dejong& Schellens, 1997). Estes objetivos fazem da Avaliação Centrada no Utilizador uma
valiosa ferramenta para as equipas multidisciplinares, porque justifica os seus
esforços, melhorando o software e apoiando a equipa de desenvolvimento nas
tomadas de decisão relativamente à versão do software a implementar (Velsen,
Geest, Klaassen, & Steehouder, 2008).
Sendo uma das atividades do Design Centrado no Utilizador, a avaliação dassoluções de projetos, efetuada com base nos requisitos do utilizador, apresenta-se
na Tabela 8, alguns métodos para a avaliação de soluções de projeto de Design
Centrado Utilizador e uma breve descrição dos mesmos.
Tabela 8 - Métodos para Avaliação de Soluções de Projeto, adaptado de Maguire (2001)
MétodoAvaliação participativa(Participatory
Evaluation)(Monk, Wright, Haber, &Davenport, 1993)

Descrição
O utilizador explora o software através de tarefas definidas ou
livremente.
Estas tarefas são solicitadas e observadas por um avaliador.
É um meio para identificar os problemas dos utilizadores e “malentendidos” relacionados com o software.

54

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Workshop de avaliação
(Evaluation Workshop)
Avaliação passo-a-passoou discussão (Evaluation
walkthrough or
Discussion)(Nielsen, 1993)
Avaliação assistida(Assisted Evaluation)

Avaliação Heurística(Heuristic Evaluation)(Nielsen, 1992)

Controlled User Testing(Bevan & Macleod, 1994)
Questionários deSatisfação (Satisfaction
questionnaires)
Avaliação da Carga
Cognitiva (assessing
cognitive workload)
Incidentes críticos(critical incidents)(Carroll, Koenemann,
Rosson, & Singley, 1993)
Experiência pósentrevistas (postexperience interviews)(Preece, et al., 1994)

É uma forma de avaliação participativa, em que os utilizadores e aequipa de desenvolvimento se reúnem e os utilizadores exploram osoftware para a realização de tarefas pré-definidas.
Uma sessão intensa de testes com os utilizadores poderá produzir
resultados de forma rápida.
O walkthrought é um processo de se desenvolver um software “passoa-passo” obtendo paralelamente feedback por parte dos utilizadores.
Útil quando é necessário feedback pormenorizado em determinada
fase do processo de desenvolvimento. Previamente, deverá ser
decidido quais os aspetos ou tarefas que serão tidos em consideração
em cada etapa de avaliação.
O utilizador é convidado a realizar uma séria de tarefas enquanto éobservado por um perito que regista os problemas detetados, ações deinteresse e comentários do utilizador.
Permite ter a ideia como os utilizadores conseguem trabalhar com osoftware com o mínimo de ajuda, bem como receber feedback dos
utilizadores.
Um ou mais peritos em usabilidade testam o protótipo do software e
identificam potenciais problemas que os utilizadores poderão
enfrentar quando interagirem com o mesmo.
Como primeiro passo deve-se identificar os problemas mais graves do
software antes dos utilizadores testarem o mesmo.
Esta abordagem também poderá ser aplicada a um software existentecomo base para o desenvolvimento de um novo software.
Os utilizadores testam protótipos do software em situações
controladas, executando tarefas representativas e fornecendo
feedback.
Mostra como funciona um protótipo do software quando exposto ao“uso real”.
Captam impressões subjetivas formadas pelos utilizadores, com basena experiência com o software ou novo protótipo.
Forma rápida e económica para medir a satisfação do utilizador.
Avaliação do esforço mental que o utilizador despende enquantoutiliza um protótipo ou um software já disponibilizado/existente.
Utilização de um questionário ou métricas fisiológicas.
Útil em ambientes em que o utilizador do software está sobre pressão.
Situações críticas que resultam em erros e problemas de utilização são
registados.
Útil para identificar funcionalidades do software que se “destacam”
que podem provocar erros/problemas.
Os utilizadores fornecem feedback sobre o atual software que estão autilizar ou após testarem um novo software.
Via rápida e económica para obter feedback subjetivo por parte dos
utilizadores.

Segundo Velsen et al. (2008), dependendo da fase em que se encontra oprojeto, a avaliação pode servir para diferentes propósitos. Na fase inicial, em que
ainda não existe nenhum software, a avaliação providência informações de apoio à
tomada de decisão, numa fase intermédia e através da apresentação de protótipos,
permite detetar problemas. Numa fase final, já com uma versão completa do
software, permite aferir a qualidade (ver Figura 12).
55

Capítulo II – Enquadramento do Estudo

Figura 12 – Fases do Processo de Design Iterativo, adaptado de Velsen, et al. (2008)

De referir que a opção tem por base o equilíbrio custo-benefício. Por exemplo,
um dos métodos mais importantes e que normalmente não é utilizado é o método
“Análise de Requisitos do Utilizador”, talvez por ser um dos métodos que, segundo
Maguire (2001), comparativamente a outros métodos, necessita de mais tempo(normalmente 15 dias) para a sua implementação.
Como evidenciado na Figura 12, para aferir a qualidade de um software
educativo, é importante que a avaliação decorra ao longo de todo o processo. Desta
forma, pode deduzir-se que quanto mais “refinado” e adequado for o processo dedesenvolvimento e de avaliação melhor será a qualidade do software.
2.5.3 Melhoria de Processos de Desenvolvimento de Software
A melhoria de processos de desenvolvimento de software (software process
improvement) pressupõe elementos de uma equipa motivados para e com
capacidade e experiência, que permitam implementar 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.
Usualmente é caraterizado 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 deobjetivos claros para a melhoria dos mesmos.
56

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

De acordo com Fantina (2005, pp., p. 3) o ciclo de melhoria de processos dedesenvolvimento de software é constituído pelos seguintes pontos:
1. Analisar os processos;
2. Identificar as áreas chave para melhoramento;
3. Obter a concordância de todos os stakeholders;
4. Criar, documentar e implementar os novos processos;
5. Formar os elementos que irão utilizar os novos processos;
6. Monitorizar o progresso;
7. Rever os processos de forma contínua, conforme as necessidades.
Por motivos temporais e de exequibilidade, no âmbito deste estudo apenas
abordou-se os dois primeiros pontos.
- Capability Maturity Model
O Capability Maturity Model, foi desenvolvido pelo Instituto de Engenharia
de Software da Universidade Carnegie Mellon. Através de práticas de referência,
este modelo não diz o que deve ser feito mas que práticas devem ser
implementadas para melhorar o processo de desenvolvimento de software. O
Capability Maturity Model descreve as fases de maturidade por que passam asorganizações

ou

equipasenquanto

evoluemnos

seus

processos

dedesenvolvimento de software, através da avaliação contínua, da identificação deproblemas e de ações corretivas (Humphrey, 1987, 1998). O percurso de melhoriaé definido por cinco níveis de maturidade representados na Figura 13.

57

Capítulo II – Enquadramento do Estudo

Figura 13 - Níveis de Maturidade Capability Maturity Model

Nível 1 - Inicial (caótico, adhoc, “heroísmo” individual): este nível
constitui o ponto de partida para a utilização de um novo processo. A
instituição/equipa não trabalham sobre um ambiente estável necessário para odesenvolvimento e manutenção do software. Os cronogramas e o orçamento são
frequentemente alterados ou esquecidos por não terem por base uma estimativa
realística. O desempenho é medido basicamente em função da competência e“heroísmo” dos elementos da equipa. O processo de desenvolvimento do softwareé imprevisível, já que é constantemente alterado no decorrer do projeto. Osmaiores problemas com os quais se defrontam as instituições/equipas são
problemas de gestão e não técnicos;
Nível 2 - Repetível: o processo é gerido de acordo com métricas previamente
definidas. Caraterizado pela existência de um processo efetivo (planeado e gerido)
do projeto de software onde o controlo sobre os procedimentos, compromissos etarefas são bem fundamentados. Neste nível ainda não existe preocupação com oprocesso de engenharia de software. O planeamento e a coordenação de novos
projetos são baseados na experiência obtida em projetos similares, que tenhamsido desenvolvidos com sucesso. Um fator relevante para as instituições/equipas

58

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

neste nível é a dependência das experiências anteriores. Ainda existe um risco
significativo de exceder as estimativas relativamente aos custos e ao cronograma;
Nível 3 - Definido: neste nível as funções e responsabilidades no processo são
bem definidas. Caraterizado principalmente pela existência de um processo deengenharia de software bem definido e documentado. Os outputs de uma tarefa
fluem naturalmente para os inputs da próxima tarefa. Existe um grupo responsável
pelos processos de desenvolvimento do software de forma a facilitar as tarefas demelhoria de processos. Existe um programa de formação que assegura que todos
tenham o conhecimento e a capacidade requerida para desenvolver as suas tarefas,
utilizando as ferramentas e os métodos disponíveis. Neste nível, os processos
atribuem autonomia e responsabilidades aos elementos da equipa para realizarem
as suas tarefas;
Nível 4 - Gerido: caraterizado pela existência de processos de softwarepassíveis de serem medidos. A produtividade e a qualidade são medidas em todas
as fases do processo de software. A organização começa a aplicar métricas decontrolo de qualidade para aumentar a qualidade e a produtividade do software;
Nível 5 - Otimizado: caraterizado pela existência de processos dedesenvolvimento de software com melhoria contínua. Os processos são avaliados
para prevenir “defeitos” conhecidos devido à recorrência. Apesar de o processo sermaduro, ele é continuamente melhorado. Os elementos analisam o rendimento do
projeto para determinar as fragilidades. Neste nível foi atingido um ambiente deexcelência em engenharia de software.
Se é importante a melhoria de processos de desenvolvimento de software,então quais as desmotivações que levam os elementos de uma equipa a não
implementarem tais melhorias?
- Desmotivações dos profissionais de desenvolvimento de software
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

59

Capítulo II – Enquadramento do Estudo

dado muita atenção ao fator humano na execução destes processos, de forma aperceber o que leva profissionais desta área a ficarem desmotivados quando são
envolvidos

nessesresumidamenteeprocessos.

Tendo

em

de

com

Humphreyacordovista

compreendê-los(1998),

expõe-seos 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) e Humphrey (1998), 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 deconsultar 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 queparticiparam 49 profissionais da área do desenvolvimento de software, os quatro
principais fatores, identificados com maior frequência, designados comodesmotivadores 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
60

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativocomerciais. Para uma pequena e média empresa as restrições temporais e a falta derecursos 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, et al., 2002).
2.6SÍNTESE DO CAPÍTULOO desenvolvimento de software é uma atividade imprevisível sendo necessário
um método adaptável para controlar esta imprevisibilidade (Abbas, et al., 2008).
Relativamente ao desenvolvimento de software educativo, os processos iterativos eincrementais, 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, etal., 2009c; Costa, et al., 2009a). Concorda-se também, com a norma ISO 13407(1999), 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, que será descrita na secção 3.2, este
feedback poderá surgir através da avaliação das soluções de projeto, suportada
normalmente pelo desenvolvimento de protótipos.
As quatro metodologias descritas na secção 2.2, além de terem na sua génese
as fases fundamentais de desenvolvimento de software, norteiam-se pelospressupostos do Design Centrado no Utilizador, entre os quais, a constituição deequipas multidisciplinares, organizadas por profissionais da área da educação
(investigadores de psicologia e pedagogia), profissionais da área da informática,
especificamente da área de engenharia de software e programadores, designers
61

Capítulo II – Enquadramento do Estudo

com conhecimentos de usabilidade. Contemplam ainda o envolvimento ativo dos
utilizadores finais, os professores e os alunos.

62Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

3 CAPÍTULO III – METODOLOGIA(S)Neste capítulo, inicialmente, justificam-se as opções metodológicas adotadas
para este estudo. Posteriormente, apresenta-se a metodologia que a empresa
Ludomedia – Conteúdos Didácticos e Lúdicos adotava anteriormente à
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, sendo esse oponto de partida da empresa. Recorda-se que esta empresa de desenvolvimento derecursos educativos foi parceira da Universidade de Aveiro no desenvolvimento do
Courseware Sere – “O Ser Humano e os Recursos Naturais”, recurso que esteve nabase deste estudo. Posteriormente é efetuada a apresentação do Courseware Sere(constituição e organização) e do processo de desenvolvimento, procedimentos etécnicas, da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador. Naúltima secção deste capítulo é descrita a metodologia de avaliação do Courseware
Sere e do seu processo de desenvolvimento, apresentando-se as técnicas de recolha
e de análise de dados.
63

Capítulo III – Metodologia(s)3.1OPÇÕES METODOLÓGICAS

A metodologia de investigação assentou no desenvolvimento e na análise da
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, na conceção ena avaliação do Courseware Sere, envolvendo uma equipa multidisciplinar: 35
professores dos 1º e 2º Ciclos do ensino básico e 41 alunos do 2º Ciclo do ensino
básico, um investigador em didática das ciências, um investigador em didática dasciências e tecnologia educativa, um perito em didática das ciências, um perito em
tecnologia educativa, dois programadores, dois designers-ilustradores e um gestor
de projeto.
Tendo em conta o acima referido, optou-se por um estudo de investigação &desenvolvimento, de natureza mista, em que se pretendeu descrever eanalisar/avaliar uma metodologia de desenvolvimento de software educativo, i.e.,o processo, bem como o produto final (Bogdan & Biklen, 1994; Carmo & Ferreira,1998).
O estudo é fundamentalmente descritivo e exploratório, tendo a metodologia
de desenvolvimento do software sido proposta (primeira questão de investigação),com base no estudo realizado por Guerra (2007), da revisão integrativa daliteratura da especialidade e com base nos resultados que emergiram da Fase 2 e 3.
Além disso, por um lado, o estudo permitiu avaliar potencial técnico e didático da
1ª versão do software inserido no Courseware Sere (dando resposta à segunda
questão de investigação), e, por outro lado, analisar os pontos fortes e fragilidades
da metodologia de desenvolvimento utilizada (como formulado na terceira questão
de investigação). Desta forma, subdividiu-se a investigação em três fases (verFigura 14), sendo selecionadas, para cada uma delas, diferentes intervenientes etécnicas de recolha e de análise de dados específicas (Bogdan & Biklen, 1994;
Carmo & Ferreira, 1998; Cohen, Manion, & Morrison, 2007), que são apresentadas
na Tabela 9.

64Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 14 – Organização do estudo

Ao pretender-se analisar/avaliar o software e o processo, está-se a falar deavaliação interpretativa (ver subsecção 2.5.2). A análise do processo dedesenvolvimento incidiu na recolha de dados por parte da equipa multidisciplinar
com base nas seguintes dimensões: Comunicação, Coordenação e Colaboração e
Cooperação (modelo 4C apresentado na subsecção 3.3.4).
A avaliação do recurso centrou-se em questões relacionadas com a usabilidade(interface e navegação) e aspetos didáticos (conteúdos e atividades).
Tabela 9 - Síntese das técnicas de recolha e de análise de dados do estudo
Questões de Investigação
Fase 1 – Proposta da MHDCU
Quais os princípios e
procedimentos a integrar numa
metodologia de desenvolvimentode software educativo?

Recolha de Dados
Técnicas
Instrumentos

Ver fase 2 e 3

Ver fase 2 e 3Análise de Dados
TécnicasAnálise integrativa
da literatura daespecialidade

65

Capítulo III – Metodologia(s)Fase 2 – Avaliação do recurso Courseware Sere
Questionário online aAnálise estatística
Qual a perceção dos professores
professores.
descritiva
e dos alunos relativamente aosInquérito
aspetos técnicos e didáticos do
Questionário em papel a Análise estatística
Courseware Sere?
alunos.
descritiva
Fase 3 – Análise do processo de desenvolvimento do Courseware Sere
Quais os pontos fortes e asfragilidades da Metodologia
Plataforma moodle:
Análise estatística
Híbrida de Desenvolvimento
Observação
Registo de interações
descritiva
Centrado no Utilizador aplicada
através de fóruns.
Análise de conteúdo
ao desenvolvimento do
Courseware Sere?

Na Fase 1, definiu-se os princípios e procedimentos a integrar numa
metodologia de desenvolvimento de software educativo. A metodologia proposta,
foi sendo “ajustada” ao longo do processo de desenvolvimento do Courseware
Sere. Surgiu a necessidade de implementar uma ferramenta de suporte àcoordenação e comunicação de forma a promover o trabalho colaborativo e
cooperativo (groupware). Foram propostos procedimentos (workflows) para otrabalho colaborativo e cooperativo presencial e não presencial. Algumas
ferramentas emergiram das Fases 2 e 3 de investigação.
Na Fase 2 recolheu-se as perceções positivas ou negativas dos professores ealunos dos 1º e 2º Ciclos do ensino básico. Para tal, recorreu-se ao registo deobservações no decorrer dos workshops de avaliação e a dois inquéritos por
questionário.

Relativamenteaoregistodeobservações,os

professores

paralelamente à exploração do recurso e através da plataforma moodle, registaram
aspetos que na sua opinião deveriam ser melhorados. Quanto aos inquéritos,
foram aplicados dois questionários de avaliação técnica e didática. Reforça-se queo courseware além de outros elementos é constituído por guiões de apoio à
exploração do software em que a avaliação se centrou apenas no software. A
análise dos dados recolhidos nesta fase foi efetuada através da descrição,recorrendo a estatística descritiva, das respostas dos professores e dos alunos àsquestões fechadas do questionário.
A Fase 3 da investigação teve como objetivo identificar e analisar os pontos
fortes e as fragilidades da Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador que foi explorada no desenvolvimento do Courseware Sere, com a
finalidade de propor melhorias a serem exploradas no desenvolvimento de um
66

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

próximo recurso educativo. Para isso recorreu-se, como técnicas de recolha dedados, à observação das interações, através da plataforma moodle (fóruns), desde
abril de 2008 até fevereiro de 2009. Esta fase de investigação, de naturezaqualitativa, permitiu ao investigador organizar de forma sistemática os dados
recolhidos, tendo como principais objetivos: i) aumentar a sua própria
compreensão sobre o seu conteúdo e ii) facilitar a comunicação aos outros dos
resultados alcançados (Ary, Jacobs, Sorensen, & Razavieh, 2010; Bogdan & Biklen,1994).
Os objetivos, a construção e a implementação dos instrumentos de recolha eanálise de dados serão explicitados seguidamente com mais detalhe.
3.2

METODOLOGIA DE DESENVOLVIMENTO DO COURSEWARE SERE

Nesta secção irá ser descrita a metodologia inicial da empresa (Ludomedia)
que participou neste estudo. Posteriormente, será apresentado o Courseware Sere,
constituição e organização do recurso e no final será apresentada a Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador.
3.2.1 Metodologia Inicial da Empresa Ludomedia
A Ludomedia, empresa que se disponibilizou para fazer parte deste estudo,
tem como missão disponibilizar recursos educativos, tendo por base as novas
tecnologias. Mais do que uma empresa, a mesma pretende afirmar-se como um
elemento dinamizador de sinergias entre profissionais e instituições, explorando
métodos inovadores no desenvolvimento de recursos educativos.
A empresa pretende consolidar a sua posição no mercado nacional, na área dodesenvolvimento de software educativo. Uma ação concertada permitirá criarsoluções eficazes, inovadoras e ajustadas às necessidades dos utilizadores, mastambém especializar a empresa em áreas de excelência, promovendo, desta forma,a sua diferenciação, e preparando as bases para a abordagem, a médio prazo, demercados externos. Assim, são finalidades da empresa:

67

Capítulo III – Metodologia(s)• otimizar os processos internos, de forma a melhorar a capacidade deresposta, minimizando falhas e potenciando a melhoria contínua;• promover a formação, atualização e participação de todos os colaboradores;• promover o trabalho de equipa, motivação, comunicação entre os
colaboradores, bem como a sua autonomia e responsabilização;• fomentar a inovação, através de Investigação e Desenvolvimento, criando
novas soluções para mercados específicos e antecipando as necessidades dos
mesmos;• acompanhar a evolução tecnológica, garantindo a melhoria contínua dos
produtos;• criar parcerias com centros de investigação, fornecedores e clientes;• manter uma participação contínua e ativa em projetos de índole social,utilizando o know-how e a experiência adquiridos na promoção dodesenvolvimento local e regional, através de parcerias com instituições deensino, associações de desenvolvimento local, autarquias locais, entre outros.
À semelhança de outras empresas, o processo de desenvolvimento de recursos
educativos da Ludomedia segue como linha de orientação a articulação dos
seguintes fatores: tempo, recursos e tarefas (Figura 15).

68

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 15 - Fatores da Gestão de Projetos Multimédia, adaptado de Strauss (Ribeiro, 2007)

A partir destes três fatores, a empresa efetuava o planeamento do projeto,tendo por base o Plano de Gantt 7, em que eram estipulados os recursos necessários
para as tarefas que se pretendiam executar num determinado intervalo de tempo.
Nas subsecções seguintes irão ser apresentados o Processo de Gestão de
Projetos e a Instrução de Trabalho Execução de Projetos de Multimédia, ambos
utilizados no desenvolvimento de recursos educativos, nomeadamente software.
•

Processo de Gestão de Projetos

No processo de gestão de projetos (Figura 16) definia-se o planeamento, a
execução e o acompanhamento dos projetos, assim como o modo de tratar as não
conformidades e as reclamações. O modo de avaliação dos prestadores de serviços
e dos colaboradores externos também eram tidos em consideração.
7 O Plano de Gantt - representação gráfica de um projeto que mostra cada fase como uma barra horizontal

cujo comprimento é proporcional ao tempo de duração da atividade.

69

Capítulo III – Metodologia(s)Neste processo eram definidos os inputs (entradas) e os outputs (saídas).
Como inputs, o Gestor de Projeto e a Equipa de Projeto efetuavam o levantamento
das especificações do projeto resultantes de:•requisitos do “cliente ou utilizador”;•

requisitos legais;•

resultados de anteriores projetos.

Como outputs, os recursos implementados e distribuídos, os resultados daavaliação da satisfação dos “clientes ou utilizadores” e as reclamações eram
devidamente tratados.

Figura 16 – Processo de Gestão de Projetos da Ludomedia

70

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

A Tabela 10 apresenta as diferentes fases do processo de gestão de projetos,
bem como os documentos utilizados em cada fase.
Tabela 10 – Descrição das Fases do Processo de Gestão de Projetos
Fases
1
2

3

4

5

6

Descrição das fases (GP – Gestor de Projeto; EP – Equipa deProjeto)Competia ao Gestor de Projeto proceder à elaboração do planeamento do
projeto. Nesta fase eram planeadas todas as tarefas do projeto,nomeadamente as revisões, verificações e validações.
Recolha de dados para possibilitar a conceção do mapa de navegação eelaboração do storyboard.
Consistia na conceção do mapa de navegação. Este mapa era entregue
aos autores e caso estes o aprovassem, a sua aceitação era evidenciada
através da ata de reunião ou através do envio de um e-mail.
O protótipo consistia na elaboração da maqueta inicial, sendo efetuada
uma verificação interna pelo responsável da atividade, que a assinava no
campo de elaborado e na ficha de projeto ou acompanhamento. Paraalém desta verificação, era efetuada uma verificação por elemento
externo à Equipa de Projeto sendo também registada na ficha de projeto.
A maqueta era enviada para os autores e caso fosse aprovada, estes
assinavam a maqueta ou formalizavam a aprovação através do envio deum e-mail.
O procedimento definido para identificar as versões do produto e a sua
evolução ao longo da realização era descrito na Instrução de Trabalho”Versões do produto”.
Os procedimentos definidos para a execução dos projetos encontravamse descritos na Instrução de Trabalho de Projetos Multimédia.
Corretiva
Englobava erros e omissões que do produto e que não tenham sido
identificados na fase de Validação. Todas as situações resultantes damanutenção corretiva eram registadas no registo de ocorrências. O
Gestor de Projeto era responsável por estudar as causas e definir as
respetivas ações de correção. Caso fosse necessário implementar ações
corretivas deveria proceder-se de acordo com a Instrução de Trabalho”Ações corretivas/Preventivas”.
Perfetiva
Englobava a introdução de novas funcionalidades. Nestes casos o Gestorde Projeto procedia à verificação e viabilidade da introdução das
mesmas.
Adaptativa
Englobava a alteração do atual produto para responder a situações
pontuais, ficando ao critério do Gestor de Projeto.
As práticas seguidas para efetuar a avaliação dos projetos e tratamentode reclamações encontravam-se descritas respetivamente nas Instruções
de Trabalho ”Avaliação de projetos” e ”Tratamento das Reclamações”.

•

RegistoDocumentos
Ficha de projeto/Planeamento
Relatório deAnáliseGuião/Storyboard
Ficha de projeto/Acompanhamento

Instrução deTrabalho “Versão
do produto”
Instrução deTrabalho
Registo deOcorrências ”Ações
corretivas/Preventivas”

Alteração de Custos

Instruções deTrabalho ”
Avaliação deprojetos” e” Tratamento das
Reclamações”

Instrução de Trabalho Execução de Projetos de Multimédia

A Figura 17 apresenta a Instrução de Trabalho de Execução de Projetos
Multimédia, sendo este constituído por 10 fases que são descritas na tabela 10.
71

Capítulo III – Metodologia(s)Figura 17 – Instrução de Trabalho Execução de Projetos de Multimédia

A Tabela 11 apresenta as diferentes fases de Instrução de Trabalho Execução de
Projetos de Multimédia, bem como os documentos utilizados em cada fase.
Tabela 11 – Descrição das fases de Instrução de Trabalho Execução de Projetos de Multimédia
Fases

1

2
3
4
5
6

Descrição das fases (GP – Gestor de Projetos; EP – Equipade Projeto)Competia ao Gestor de Projeto, após a aprovação do Protótipo Inicial
por parte do cliente ou utilizador, analisar os orçamentos deprestadores de serviços e verificar a necessidade de solicitar
retificações a orçamentos já solicitados na fase do processo de análise
de viabilidade económica.
A formalização da subcontratação dos serviços era efetuada atravésde uma Requisição aos Fornecedores.
Após a conclusão das respetivas tarefas, competia à Equipa deProjeto, no caso de trabalhos realizados internamente, ou ao Gestorde Projeto, no caso de subcontratação dos serviços, proceder àverificação do conteúdo dos mesmos e registar os resultados na Fichade Projeto (registo de acompanhamento).
Competia à Equipa de Projeto efetuar uma verificação final do
trabalho realizado, sendo efetuada uma outra verificação interna por
um elemento externo à Equipa de Projeto. Os resultados eramregistados na Ficha de Projeto (registo de acompanhamento).

RegistoDocumentos
Protótipo Inicial
Requisição aFornecedoresFicha de Projeto(registo deacompanhamento)
Ficha de Projeto(registo deacompanhamento)

72

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Fases
7

8

9

10

Descrição das fases (GP – Gestor de Projetos; EP – Equipade Projeto)Competia à Equipa de Projeto efetuar uma verificação interna do
projeto testando as aplicações, de modo a definir as especificações
mínimas. Os resultados eram registados na Ficha de Projeto (registode acompanhamento).
Após a receção das cópias, competia ao Gestor de Projeto proceder àvalidação interna, testando as mesmas em vários meios de suporte.
Os resultados eram registados na Ficha de Projeto (registo deacompanhamento).
O controlo a efetuar contemplava os aspetos mencionados no Planode Controlo.
O trabalho era entregue ao cliente ou utilizador para a sua validação.
Os resultados são registados em Ata de Reunião. Caso o cliente ou
utilizador detetasse alguma anomalia, procedia-se, tal como estádefinido na Fase 5 do Processo Gestão de Projetos: “Manutenção
Corretiva”, à sua correção.
Era da responsabilidade do Gestor de Projeto elaborar um Relatório
Final.

RegistoDocumentos
Ficha de Projeto(registo deacompanhamento)
Ficha de Projeto(registo deacompanhamento)
Plano de Controlo

Ata de Reunião

Relatório Final

A metodologia inicial da Ludomedia enquadrava-se no grupo das metodologias
disciplinadas (essencialmente o modelo em cascata), necessitando os elementos daequipa de efetuar muitos registos documentais (burocrático). Os recursos eramavaliados por crianças apenas no final do processo de desenvolvimento. Estas
avaliações decorriam na empresa e por vezes em contexto escolar. A avaliação era
efetuada por elementos da equipa projeto, tendo por base as observações que estes
efetuavam. Na equipa de projeto não era contemplado o envolvimento deinvestigadores ou peritos.
Com a avaliação efetuada apenas na versão final do recurso e sendo
implementada por elementos da equipa de projeto, na sua maioria com pouca
experiência neste tipo de procedimentos, associado ao pouco retorno financeiro, aempresa Ludomedia, deparou-se com a necessidade de aferir e melhorar aqualidade do software educativo que desenvolvia e simultaneamente estudar
processos que fossem viáveis, economicamente. Desta forma, “abraçou” o desafiode desenvolver o Courseware Sere, que se apresenta na secção seguinte, tendo porbase uma nova metodologia, que se designa como Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador, que será descrita na secção 3.2.3.

73

Capítulo III – Metodologia(s)3.2.2 Apresentação do Courseware SereO Courseware Sere integra várias tipologias de software (simulações,inquérito, pesquisa,…) com atividades didáticas especificadas em guiões deexploração, tanto para o professor, como para os alunos. Como se depreende apartir dos seus propósitos (promover a compreensão do impacte que a atividade
humana tem nos recursos naturais e consciencializar de que o futuro da
Humanidade passará pela adoçã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 atividade
humana e a exploração dos recursos naturais, bem como das consequências
ambientais, sociais e económicas desta exploração (Sá, et al., 2010b; Sá, et al.,2010a; Sá, et al., 2009).
O courseware foi pensado para a utilização, em sala de aula, por alunos do 1º e
2º Ciclos do ensino básico (preferencialmente a partir dos 8 anos),particularmente dos 3º ao 6º ano de escolaridade, com a orientação dos respetivos
professores, embora a sua exploração possa ser adaptada a outros níveis deescolaridade, bem como a outros contextos.
•

Constituição do Recurso

Do conjunto de recursos do Courseware Sere fazem parte: um software
educativo (versão em CD-ROM e online, ver em: http://sere.ludomedia.pt), osGuiões de Exploração Didática para o Professor, os Guiões de Registo para o
Aluno/Utilizador e o Manual do Utilizador (Figura 18). No Manual do Utilizador
encontram-se informações relacionadas com a navegação nos ecrãs e os ícones
utilizados no software.
O software está dividido em duas fases principais: Fase 1 – Petróleo e Fase 2 –Florestas, não sendo as mesmas sequenciais, isto é, o professor ou o aluno poderá
optar por qual das fases e atividade pretende iniciar a exploração.
Os guiões foram desenvolvidos para servir de base à exploração do software.
No Guião de Exploração Didática - Professor propõem-se diferentes atividades,
74

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

estruturadas da seguinte forma: 1) Finalidades da Atividade; 2) Contexto de
Exploração; 3) Metodologia de Exploração. Os guiões destinados aos/às alunos(as)são compostos fundamentalmente por folhas de registos.

Figura 18 – Guiões de Exploração Didática

Na versão do software que se encontra online (Figura 19), os professores e osalunos poderão ter acesso a diversas ferramentas de apoio à exploração das
diferentes atividades contidas no software, tais como:• acesso a informação e recursos relacionados com o tema do courseware,disponíveis na mediateca;• a socialização entre os vários utilizadores do recurso didático, bem como otrabalho colaborativo e cooperativo em torno das atividades, a criação dediários de bordo, entre outros, através da exploração de ferramentas Web 2.0(por exemplo, fóruns, chats, wikis, glossários).
Pretende-se, desta forma, promover o desenvolvimento das competências
dos(as) alunos(as)/utilizadores(as) não só ao nível da temática, como também ao
nível da utilização das Tecnologias de Informação e Comunicação, e combater oisolamento dos utilizadores através da partilha de ideias, histórias, problemas,
experiências, entre outros aspetos de interesse mútuo, e construção conjunta desoluções.

75

Capítulo III – Metodologia(s)Figura 19 - Exploração online do Courseware Sere•

Organização do Recurso

O recurso organiza-se, essencialmente, em duas Fases (Figura 20b) que,embora surjam de forma sequenciada, representam momentos de transição entre
sub-problemáticas do uso inconsciente de recursos naturais energéticos
específicos, nomeadamente o petróleo e a floresta (Sá, et al., 2010a).
Na Fase I pretende-se que os alunos pesquisem aspetos relacionados com a
produção e consumo do petróleo e os situem no planisfério, bem como
identifiquem a utilização deste recurso natural e seus derivados em diversas
situações do quotidiano. A finitude do recurso e a impossibilidade de generalizar
os atuais níveis de consumo que alguns praticam levantará o problema seguinte e ouso da floresta, em particular da sua biomassa, surge como uma forma alternativa
de obtenção de energia (Fase II).
Entre cada uma das referidas fases, em que o papel dos utilizadores será o depesquisa, seleção e organização de informação, existem Fóruns de Discussão, que
76

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

permitem não só a partilha da informação reunida intragrupalmente em cadaFase, mas também fazer a transição de forma coerente e contextualizada para a
Fase seguinte.
Para conduzir esta pesquisa e orientar o estabelecimento de relações einterações entre a população e o uso dos recursos foram criadas oito personagens seis exploradores e os dois Presidentes da Organização Mundial para a Proteção doPlaneta - POMPP (Figura 20a) – que podem desempenhar papéis diferentes ao
longo do desenrolar de toda a situação, nomeadamente acompanhar cada um dos
grupos de exploradores ao longo das várias atividades.

a)

b)

c)

d)

77

Capítulo III – Metodologia(s)e)f)

Figura 20 - Exemplos de ecrãs do Courseware SereNo que respeita às atividades e a título de exemplo, nalguns ecrãs o utilizador é
levado a refletir sobre onde existem e como são utilizados os recursos naturais(petróleo e floresta), através de pesquisa e fazendo registos, em tabelas ou gráficos.
O ecrã (Figura 20e) é um exemplo da forma como é efetuado o registo onde existe
petróleo ou quais os níveis de consumo das várias regiões do planeta.
3.2.3 Metodologia
Utilizador

HíbridadeDesenvolvimento

Centradono

A Metodologia Híbrida de Desenvolvimento Centrado no Utilizador foi
utilizada no desenvolvimento do recurso educativo Courseware Sere – “O Ser
Humano e os Recursos Naturais”. Alguns princípios desta metodologia foram
definidos com base no estudo de Guerra (2007), tais como, constituição de uma
equipa multidisciplinar, avaliação formativa por parte de professores e peritos. Na
continuidade, neste estudo, apresenta-se além dos anteriores, outros princípios e
procedimentos em que se baseia esta metodologia de desenvolvimento (Costa, etal., 2009c).
A equipa multidisciplinar foi constituída por elementos com diversas
competências ao nível da Didática das Ciências, da Tecnologia Educativa, daGestão de Projetos, do Design Gráfico, da Programação e da Usabilidade. A equipa
foi formada por elementos da Universidade de Aveiro e da Ludomedia – empresade desenvolvimento de software educativo.

78

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Tendo em vista reduzir o tempo e custo de desenvolvimento, duas dasdesvantagens do Design Centrado no Utilizador (Abras, et al., 2004), a equipa
optou por envolver o utilizador final (professores e alunos) só nas tarefas deavaliação do recurso. O recurso (nomeadamente o storyboard) foi também
submetido a avaliação por parte de peritos externos à equipa multidisciplinar(Costa, et al., 2010a; Costa, et al., 2009a; Guerra, 2007), o que se considera
incontornável, independentemente da metodologia adotada.
A Metodologia Híbrida de Desenvolvimento Centrado no Utilizador também
teve por base princípios dos métodos ágeis, tais como, manutenção dasimplicidade, isto é, foi desenvolvido o essencial de forma a responder aos
requisitos atuais. A equipa (essencialmente os programadores) procurou corrigir emelhorar o código do software continuamente e a entrega foi incremental, dadoque 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.
Seguidamente descreve-se o processo de desenvolvimento do Courseware Sere
através da apresentação das fases que o constituem, bem como os procedimentos etécnicas utilizadas durante o desenvolvimento do recurso educativo.
•

O Processo de Desenvolvimento do Courseware Sere

Tendo em conta os pressupostos acima explicitados, o processo dedesenvolvimento do Courseware Sere foi constituído por quatro fases principais,
sendo transversalmente suportado por desenvolvimento de protótipos avaliados
iterativamente ao longo do processo (Figura 21). Nos parágrafos seguintes,
descreve-se o processo. Na secção 3.3 serão apresentadas em detalhe as técnicas derecolha de dados para avaliação do Courseware Sere.
Sendo um dos objetivos deste estudo, a melhoria da Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador, a fase de avaliação do courseware
incidiu unicamente sobre o grau de satisfação dos utilizadores.

79

Capítulo III – Metodologia(s)Figura 21 - Metodologia Híbrida de Desenvolvimento Centrado no Utilizador• Fase 1, Planeamento (guião didático): compreendeu a realização de um
documento por peritos e investigadores em Didática das Ciências (doiselementos) e da Tecnologia Educativa (dois elementos) com a definição donível de ensino/público-alvo do recurso, da temática e dos propósitos
didáticos, bem como aspetos relacionados com a arquitetura, a navegação e odesenho dos ecrãs do recurso, acima referidos. Esta fase compreendeu aindao registo de marca e da patente, bem como, entre outros, acordos relativos
aos direitos de autoria.
• Fase 2, Design (storyboard): nesta fase harmonizou-se as ideiaspreliminares das atividades didáticas e do conteúdo disciplinar, definidas na
fase anterior, com os aspetos de interação do software, particularmente a
navegação e interface, com a colaboração de um designer e de um

80Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

programador da empresa. Como Bassani, Passerino, Pasqualotti & Ritzel(2006) ou Carvalho (2003), considera-se que o desenho dos cenários
resultantes desta fase foi essencial para se compreender o contexto deutilização do recurso e para representar algumas das situações interativas do
software.
• Fase 3, Implementação: esta fase foi dividida em duas subfases que
decorreram em simultâneo:o a parte educacional - requereu a especificação em detalhe de aspetos,para além dos já especificados no storyboard, como a animação inicial e
os guiões do professor e do aluno.
o a parte técnica - correspondeu ao design e programação do softwaree do respetivo manual do utilizador.
Durante esta tarefa, a equipa multidisciplinar testou e ajustou o conteúdo dosguiões à exploração que se pretendia dos ecrãs do software, o que envolveu acolaboração permanente de todos os elementos, feita quer presencialmentequer online, e o desenvolvimento de vários protótipos.
Protótipos: os protótipos foram desenvolvidos colaborativamente, pelos
elementos da equipa multidisciplinar. Entre outros, a equipa identificou
aspetos na interface que tiveram implicações na arquitetura do software,que, em alguns casos, levou a alterações nos guiões educacionais do recurso.
A prototipagem do software também foi usada, no processo dedesenvolvimento, de forma a explorar algumas soluções de software em
particular.
Durante o desenvolvimento do recurso, a equipa recorreu a três tipos deprotótipos:
o Protótipos em papel (early paper prototypes) – Figura 22a);o Ecrãs chave (key screens) – Figura 22b);81

Capítulo III – Metodologia(s)o Protótipos programados (running prototypes) – Figura 22c).

a)

b)

c)

b)

c)

a)

Figura 22 – a) Cenário da fase 2 e de uma das personagens. b) Ecrã da escolha das personagens e
um ecrã de uma atividade. c) 1º ecrã da fase 1 - petróleo e 2º ecrã da fase 2 – floresta.

• Fase 4, Operação e Manutenção: esta fase inclui a correção de erros,
técnicos e educacionais, que não foram detetados nas fases iniciais do ciclo devida do processo de desenvolvimento do courseware. Desta forma, pode-se
melhorar o software e incrementar novas funcionalidades através de novos
requisitos que são detetados durante este processo (Miguel, 2003;
Sommerville, 2007). Foram tidos em consideração três tipos de manutenção:corretiva, perfetiva e preventiva.
Avaliação: Pretendendo-se avaliar tanto o recurso como o seu processo dedesenvolvimento, esta fase foi transversal a todas as fases acima indicadas. No
final da fase 2 (storyboard) e no final da primeira versão a avaliação foi
efetuada por elementos externos à equipa multidisciplinar, tais como,utilizadores finais, alunos do 2º Ciclo de Ensino Básico e professores dos 1º e 2º
Ciclos do ensino básico, e investigadores em Tecnologia Educativa e Didática
das Ciências. Seguidamente descreve-se resumidamente os procedimentos deavaliação explorados com os utilizadores finais.
o Professores: na avaliação feita por professores, o questionário paraavaliação técnica e didática do Courseware Sere foi respondido em
82

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

workshops (sessões práticas com a duração máxima de 120 minutos, em
que os professores em grupos de dois a três elementos, exploraram duas
atividades de uma das fases do courseware), por parte de um grupo
heterogéneo de potenciais utilizadores do recurso (Costa, et al., 2009a;
Guerra, 2007).
o Alunos: relativamente à avaliação efetuada pelos alunos, oquestionário de avaliação técnica e didática (alunos), foi respondido após
a utilização do recurso em contexto de sala de aula (em blocos de 90
minutos, os alunos em grupos de três a quatro elementos, exploraram as
atividades do courseware, devidamente planificadas pelo professor), peloque se tratou de uma avaliação controlada (Costa, et al., 2010b).
•

ProcedimentoseTécnicasda

Metodologia

HíbridadeDesenvolvimento Centrado no Utilizador
Para agilizar o processo de desenvolvimento e partindo do princípio que otrabalho colaborativo e cooperativo decorre simultaneamente em dois regimes,
presencial e online, a Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador incorporou o Procedimento de Verificação e Validação, representado noworkflow da Figura 23. Este procedimento surge integrado numa das atividadesde Design Centrado no Utilizador, Produção de Soluções de Projeto (protótipos),antecedendo a fase de avaliação destas soluções, com os utilizadores ou peritos,
como referido na secção 2.3. De suporte a estas atividades foi utilizado como
software colaborativo (groupware) a plataforma Learning Management System(LMS) moodle8. 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

8 Moodle é um software livre, de apoio à aprendizagem, que funciona num ambiente virtual.

83

Capítulo III – Metodologia(s)deveu-se à familiaridade e conhecimentos que o Gestor de Projeto detinha sobre amesma.

Figura 23 – Workflow do Procedimento de Verificação e Validação

No Procedimento de Verificação e Validação compete aos elementos da equipa
multidisciplinar efetuar a verificação e validação das versões do software, comodas versões dos documentos (guiões do professor e do aluno, manual de utilizador,
entre outros). Sendo identificadas alterações a efetuar, foi disponibilizada no
moodle uma nova versão, para verificação e validação. Estas iterações apenas
terminam quando não se identificam mais alterações a efetuar.
No Trabalho Colaborativo e Cooperativo Presencial (Figura 24), comummente,é o Gestor de Projeto que efetua um primeiro levantamento dos pontos a serem
discutidos na reunião presencial. Estes pontos são ordenados por importância ouáreas de atuação, sendo enviados previamente para os elementos da equipa
multidisciplinar. Para facilitar esta tarefa foi usada uma mailling list ou o fórum
designado como “Notícias e Anúncios”. O Trabalho Colaborativo e Cooperativo
Presencial foi registado através de gravação áudio.

84

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 24 – Workflow do trabalho colaborativo e cooperativo presencial

No Trabalho Colaborativo e Cooperativo Presencial, ao serem identificadasalterações a efetuar, as mesmas foram disponibilizadas na plataforma moodle.
Neste contexto, as ferramentas (recursos, módulos de atividades e blocos)
utilizadas (ver Figura 25) no Trabalho Colaborativo e Cooperativo Não Presencial,permitiram promover e agilizar uma maior interação entre os elementos da equipa
multidisciplinar.

Figura 25 – Workflow do trabalho colaborativo e cooperativo não presencial

O moodle é um software para gestão da aprendizagem e de trabalho
colaborativo, que permite a criação de grupos de trabalho e comunidades deaprendizagem (Figura 26). O ambiente de trabalho criado era constituído por trêsprincipais secções:85

Capítulo III – Metodologia(s)• Blocos: são disponibilizados verticalmente, do lado esquerdo ou lado direito,
permitindo inserir, por exemplo, o calendário ou a agenda de eventos;• Recursos: permitem a inserção de documentos, imagens, efetuar ligações adocumentos externos através, por exemplo, de diretórios, glossários;• Módulos de atividades (tarefas): disponibilizam ferramentas que permitem
promover o debate e a discussão, como por exemplo, fóruns, chats,referendos.

Figura 26 – Ambiente de trabalho do groupware (moodle)

86

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Além do moodle ter servido de repositório para as versões dos documentos,
também foram utilizados alguns módulos de atividades (tarefas), para promoveruma maior interação entre os elementos da equipa:• Referendos: a decisão sobre qual a versão do logótipo que se deveria optar,
foi tomada com base nos resultados de um referendo (Figura 27a);• Fóruns: todas as versões de software e dos documentos (introdução,contextualização, guiões didáticos do professor, guiões de registo do aluno e
manual de utilizador), foram discutidas e melhoradas através de fóruns
(Figura 27b);• Glossários: definição de termos científicos e técnicos, para que os elementos
da equipa percebessem a linguagem utilizada (figura 27c). Também foi criado
um glossário para inserção de atas de reunião (ver anexo 4 exemplo de ata dereunião);• Chats: discussão síncrona de aspetos, essencialmente técnicos, do projetopermitindo a tomada de decisões de forma célere (figura 27d);• Wikis: ferramenta de trabalho colaborativo, que permitiu a construção dos
textos de apoio ao software (figura 27e);• Inquéritos por questionário: este módulo foi utilizado durante os workshops
de avaliação do recurso feita pelos utilizadores finais a que se aludiu
anteriormente. Os resultados ficavam automaticamente disponibilizados para
todos os elementos da equipa multidisciplinar (figura 27f);• Calendário: marcação de reuniões para que os elementos tivessem acesso adatas, horário, local e que assuntos seriam debatidos nas mesmas;• Diário: esta ferramenta foi utilizada durante os workshops de avaliação paraque os participantes (alunos do 2º Ciclo do ensino básico e professores dos 1º
e 2º Ciclos do ensino básico) pudessem registar as suas observações sobre orecurso durante a sua exploração. No decorrer do processo serviu como Bloco
87

Capítulo III – Metodologia(s)de Notas do Gestor de Projeto, em que registava pontos relativos às reuniões,tais como, os intervenientes, meio de comunicação (msn, chat, skype,
telefone, reunião presencial), hora de início e de fim, data e uma breve síntese
relativamente ao motivo da “interação” e que documentos foram
utilizados/produzidos);• Diretórios: pastas em que foram disponibilizados documentos, como por
exemplo, os guiões, o storyboard, anexos, mapa de navegação. Nestes
diretórios também foram disponibilizadas as diferentes versões dos ecrãs
desenvolvidos (protótipos) em formato vetorial, especificamente para os
Programadores A e B tivessem acesso ao material desenvolvido pelos
Designers-Ilustradores A e B.

a)

b)

c)

d)

e)

f)

88

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 27 – Módulos de atividades (tarefas) utilizados do moodle

A maioria das versões de documentos e protótipos (em imagem e
programados) do software eram disponibilizados na plataforma moodle, de modoa que todos os elementos da equipa pudessem ter acesso.
O

trabalhocolaborativoecooperativo“foi

cultivado”

duranteodesenvolvimento do Courseware Sere, permitindo um maior acerto na realização
das tarefas. Por exemplo, as tarefas, essencialmente técnicas, foram executadas
cooperativamente, uma vez que o gestor de projeto as subdividia em várias
subtarefas interdependentes (evidenciando assim uma hierarquia funcional). O
trabalho colaborativo (presencial e não presencial) serviu essencialmente para
criar novas soluções de projeto com base nos requisitos do utilizador, através dodesenvolvimento de protótipos posteriormente avaliados (Costa, et al., 2010b;
Costa, et al., 2009a). Durante o desenvolvimento das soluções de projeto(protótipos), os designers-ilustradores concebiam um primeiro protótipo de ecrã e,
através das ferramentas disponibilizadas no moodle, o mesmo era discutido,
aprimorado. Apenas posteriormente os programadores incrementavam o protótipo
à estrutura principal do software educativo. Pode-se evidenciar, que o trabalho
colaborativo funcionou como o “motor” do projeto, tendo alavancado o trabalho
cooperativo, através dos compromissos assumidos para a execução das tarefas. O
trabalho colaborativo, bem como o trabalho cooperativo assentaram sobre
processos

iterativoseincrementais,

sendoessencialobter

feedback

atempadamente e uma coordenação atenta às mudanças dos requisitos.
3.3

METODOLOGIA DE AVALIAÇÃO DO COURSEWARE SERE E DO SEUPROCESSO DE DESENVOLVIMENTO

Nesta secção, é apresentada a natureza do estudo e as técnicas de recolha eanálise de dados selecionadas para responder às questões de investigação,formuladas no capítulo 1.

89

Capítulo III – Metodologia(s)3.3.1 Técnicas de recolha de dados para a avaliação do Courseware
Sere
Nesta subsecção apresenta-se, e justifica-se, a escolha da técnica de recolha dedados utilizada neste estudo (inquéritos por questionário), bem como a técnica deanálise dos dados, análise estatística descritiva.
•

Inquéritos por Questionário

Em Ciências Sociais, os inquéritos são usados para recolher dados no terreno,de forma sistematizada. O inquérito por questionário pode ser definido como um
método de recolha de dados, podendo integrar vários tipos de perguntas, taiscomo, perguntas de identificação de forma a caraterizar o inquirido, relativamenteà sua idade, género, situação profissional, habilitações académicas e perguntas deinformação que tem por objetivo recolher as suas opiniões, interesses, expetativas(Carmo & Ferreira, 1998; Cohen, et al., 2007).
A opção pela recolha de informação através do inquérito, por questionário, foi
feita tendo em conta os objetivos definidos para este estudo (ver capítulo 1, secção
1.2) e resultou de uma ponderação entre as potencialidades e os limites/problemasque lhe estão associados.
Este instrumento considera-se vantajoso por poder ser aplicado a uma
amostra de grandes dimensões, não exigindo a presença do investigador. Podemse ainda indicar como vantagem a aplicabilidade de baixo custo (Gray, 2004;
Quivy & Campenhoudt, 1998). O facto de o questionário (dos professores) ter sido
disponibilizado com recurso às Tecnologias de Informação e Comunicação, o queno contexto do presente estudo se afigurava como lógico, pode ainda ser apontado
como uma vantagem devido à rapidez de administração e do tratamento dos
dados.
Para avaliar a 1ª versão do recurso implementaram-se dois inquéritos por
questionário (Anexo 1 e 2), por se considerar que possibilitaria uma maior
sistematização, simplicidade e rapidez na recolha e análise de dados (Bogdan &Biklen, 1994). Estes tiveram como objetivo auxiliar a recolha das perceções

90

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

positivas e negativas de “avaliadores externos” acerca da qualidade da primeiraversão do Courseware Sere, especificamente o software, enquanto recurso para
apoio ao ensino e aprendizagem, bem como ao nível da sessão de avaliação (Carmo& Ferreira, 1998).
- Aplicação do Questionário aos Professores
No final da fase 3, o trabalho da equipa multidisciplinar centrou-se na
avaliação técnica e didática da primeira versão do Courseware Sere (disponível napágina web http://sere.ludomedia.pt) envolvendo para isso, professores dos 1º e
2º Ciclos do ensino básico. Para avaliação da primeira versão do courseware, oquestionário para avaliação técnica e didática (ver Anexo 1), foi respondido atravésda dinamização de workshops (sessões práticas com a duração máxima de 120
minutos, em que os professores em grupos de dois a três elementos, exploraram
duas atividades de uma das fases do courseware) por parte de um grupo
heterogéneo de potenciais utilizadores do recurso (Costa, et al., 2009a).
O envolvimento dos utilizadores é um dos princípios do Design Centrado no
Utilizador, que foi adotado neste estudo, na fase de avaliação da 1ª versão do
Courseware Sere. Como referido, foram envolvidos professores dos 1º e 2º Ciclos
do ensino básico: foram realizados seis workshops (sessões práticas), sendo oprimeiro dinamizado fora do contexto escolar a que os professores normalmenteestavam habituados.
O primeiro workshop foi dinamizado utilizando um protótipo, e ocorreu antes
da produção da primeira versão do courseware. Os restantes cinco workshops,
foram dinamizados já com a exploração da versão final do courseware e ocorreram
nas escolas onde os professores lecionavam ou a que pertenciam (Agrupamentos
Escolares ou Colégios).
Para avaliar o potencial técnico e didático do Courseware Sere, pretendeu-se
verificar quais as perceções positivas e negativas, de interação (interface e
navegação) e didáticos (atividades e conteúdo), por parte de professores. Assim,
com o objetivo de recolher as perspetivas dos participantes no decurso de sessões
91

Capítulo III – Metodologia(s)práticas (workshops de avaliação) na utilização de um protótipo e posteriormente
de uma versão final, optou-se, por desenvolver um questionário (Anexo 1),
composto por quatro partes:i) a primeira parte contém questões que permitem caracterizar o grupo departicipantes no que respeita à idade, sexo, formação académica, atividade
profissional, experiência profissional, a utilização do computador e oenvolvimento em projetos que contemplem a integração das Tecnologias deInformação e Comunicação;ii) a segunda parte tem dois grupos de questões fechadas sobre o potencial
educativo do Courseware Sere: a) o primeiro apresenta uma lista deaspetos relacionados com as características do software; b) o segundo diz
respeito a aspetos relativos às atividades pensadas para a exploração
didática. Para a seleção das questões fechadas da segunda parte doquestionário, teve-se em conta princípios de usabilidade de um software(interface e navegação) descritos na subsecção 2.5.1 e definidos na norma
ISO 9126 (1999): eficácia, eficiência e satisfação de uso;iii) a terceira parte é de resposta aberta e visa a realização de uma síntese daavaliação da relevância e potencial didático do Courseware Sere;iv) na quarta e última parte solicitam-se comentários relativamente à sessão
prática e a este instrumento de avaliação.
Este questionário foi adaptado de Guerra (2007) e tendo em conta
instrumentos similares (Carvalho, 2005; Loureiro, 2002; Loureiro & Depover,2005; Pedatice, 1998; Teem.org, 2008). Para as questões fechadas doquestionário, foi utilizada uma escala de Likert (1 – Discordo plenamente, 2 –Discordo, 3 – Concordo, 4 – Concordo plenamente, NS/NR – Não sei/Não
respondo).

92

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo- Aplicação do Questionário aos Alunos
Relativamente à avaliação efetuada pelos alunos, o questionário de avaliação
técnica e didática (ver Anexo 2), foi respondido após a utilização do recurso em
contexto de sala de aula (em blocos de 90 minutos, os alunos em grupos de três aquatro elementos, exploraram as atividades do courseware, devidamente
planificadas pelo professor), tratando-se de uma avaliação controlada (Costa, etal., 2010b). De igual modo foi desenvolvido um inquérito por questionário para os
alunos (Anexo 2). Com este instrumento de recolha de dados pretendeu-se avaliaro Courseware Sere, relativamente a aspetos relacionados com a usabilidade(programa e desenho das janelas) e aspetos didáticos (atividades), por parte dealunos a frequentar os 1º e 2º Ciclos do ensino básico (a partir do 3º ano). O
instrumento é composto por duas partes:i) a primeira parte é constituída por questões que permitem caracterizar os
alunos (a idade, o género, o ano de escolaridade, a frequência de utilização
do computador e para que fim utilizam o computador);ii) a segunda parte é constituída por dois grupos de questões fechadas sobre opotencial educativo do Courseware Sere: a) o primeiro apresenta uma lista
de aspetos relacionados com a interação do utilizador com o software(navegação e desenho das janelas); b) o segundo diz respeito a aspetos
relacionados com as atividades pensadas para a exploração didática.
Este instrumento foi construído tendo por base o inquérito por questionário
utilizado com os professores e através de instrumentos similares (Associates,
2007; Loureiro, 2002; Paz, 2004; Teem.org, 2008). Para as questões fechadas doquestionário, foi utilizada uma escala simplificada de Likert (1 – Não, 2 – Mais ou
Menos, 3 – Sim) devido à idade dos inquiridos (entre os 8 e os 13 anos).

93

Capítulo III – Metodologia(s)3.3.2 Técnicas de análise de dados para a avaliação do Courseware
Sere
Na Fase 2 deste estudo procede-se à análise estatística descritiva das respostas
às questões fechadas (e apenas) do inquérito por questionário.
A análise estatística descritiva é uma técnica de análise de dados usada,frequentemente, em articulação com a técnica de inquérito por questionário.
Requer, por parte dos investigadores que a utilizam, boas noções ao nível destaárea matemática (Quivy & Campenhoudt, 1998).
Geralmente, os investigadores iniciam o processo com a codificação de cadaquestionário considerado para análise, pela ordem de receção, de forma a facilitaro processamento e o acesso aos dados. É também conveniente associar números às
respostas dadas a cada questão, uma vez que o facto de estarem pré-codificadas
facilita o seu processo de análise por meio de métodos estatísticos (Hill & Hill,2005). No presente estudo, a codificação de cada questionário preenchido não foi
necessária, dado a informatização das respostas.
A análise estatística descritiva estabelece que a apresentação, a análise e ainterpretação de dados numéricos é facilitada através da utilização deinstrumentos adequados, tais como, quadros, gráficos e indicadores numéricos(Reis, 1991). Paralelamente, esta técnica de análise permite a simplificação e
descrição de resultados, possibilitando realçar os aspetos mais relevantes (Pardal& Correia, 1995), ou seja, consiste num tratamento quantitativo que permitecomparar respostas globais (Quivy & Campenhoudt, 1998). Esta técnica apresenta
como vantagens a precisão e o rigor, a possibilidade de utilização de meios
informáticos na análise de grandes quantidades de dados e a clareza dos resultados
que disponibiliza. Porém, nem todos os dados dos fenómenos educativos sãoquantitativamente mensuráveis e o instrumento estatístico não dispõe, em si
mesmo, de um poder explicativo, ou seja, é o investigador que determina o seu
sentido (Quivy & Campenhoudt, 1998).
Para a apresentação das respostas às questões fechadas de ambos osquestionários (Anexo 1 e 2), recorreu-se à organização dos dados em quadros, com
94

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

referência às frequências absolutas das respostas de cada grupo de avaliadores
externos (alunos do 2º ciclo do ensino básico e professores dos 1º e 2º ciclos doensino básico).
3.3.3 Técnicas de recolha de dados para análise do processo dedesenvolvimento do Courseware Sere
A Fase 3 da investigação teve como objetivo compreender os pontos fortes e asfragilidades da metodologia de desenvolvimento adotada para o courseware.
Como descrito anteriormente, a gestão do processo de desenvolvimento foi
suportada pela plataforma LMS moodle, que serviu de groupware. A utilização domoodle permitiu registar as interações (através dos fóruns) entre os elementos daequipa multidisciplinar durante o processo de desenvolvimento do Courseware
Sere. Este registo foi efetuado de abril de 2008 a fevereiro de 2009.
•

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 decidiu criar uma disciplina na plataforma
moodle para funcionar como groupware, com a finalidade de 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 28 apresenta as ferramentas
utilizadas com base no modelo 4C que será descrito na subsecção 3.3.4.

95

Capítulo III – Metodologia(s)Figura 28 – Ferramentas utilizadas no moodle com base no 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 apresenta como vantagens a apreensão dos comportamentos e
acontecimentos no próprio momento em que se produzem; recolher um material
não suscitado pelo investigador, portanto, espontâneo; e um maior grau deautenticidade 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,
et al., 2007; Quivy & Campenhoudt, 1998).

96Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

No que se refere aos tipos de observação podem-se dividi-los em:•

observação participante (direta): envolve a recolha de dados diretamente
pelo próprio investigador, sem a intervenção dos sujeitos observados na
produção da informação procurada (Ary, et al., 2010);•

observação não participante (indireta): o investigador dirige-se aos sujeitos
envolvidos no fenómeno para obter a informação desejada, através dequestionários ou entrevistas. “Ao responder às perguntas, o sujeito intervém
na produção da informação.” (Quivy & Campenhoudt, 1998, pp., p. 164)

A observação realizada neste estudo caracteriza-se por ser participante(direta). Assim sendo, apesar do papel dos sujeitos observados na produção dainformaçã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, obloco de notas, e a máquina de filmar, entre outros, cuja adequação depende dofenómeno que se pretende observar (Ary, et al., 2010; Pardal & Correia, 1995;
Quivy & Campenhoudt, 1998). 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 (taiscomo os registos vídeo ou áudio), dispensa a realização de transcrições, o que
facilita o trabalho do investigador.
3.3.4 Técnicas de análise de dados relativos ao processo dedesenvolvimento do Courseware SereUma parte considerável da qualidade final de um software educativo deve-se
ao seu processo de desenvolvimento Desta forma, nesta secção irá ser analisado oprocesso de desenvolvimento do Courseware Sere tendo por base a análise das
97

Capítulo III – Metodologia(s)interações entre os elementos da equipa multidisciplinar. A análise de conteúdo é
uma técnica de análise de dados utilizada para estudar o comportamento humanode uma forma indireta, através da análise dos textos produzidos. A análise deconteú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 (Carmo & Ferreira, 1998; Cohen, et al., 2007; Gray,
2004).
•

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; Carmo & Ferreira, 1998). 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 (2004), tal como representa a Figura 29.

Figura 29 – Procedimento de análise de conteúdo, adaptado de Coehen, Manion & Morrison (2007)
e Bardin (2004)

98

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativoa) Organização da análise
Uma vez definido o corpus, que se apresentou ser adequado como fonte derecolha de dados, e representativo do objeto em estudo (pertinência), todos oselementos do conjunto foram considerados (exaustividade). Considerou-se que aamostraselecionada

era

representativa

douniversoemestudo(representatividade) (Bardin, 2004).
O corpus/corpora foi obtido através dos instrumentos de recolha de dados,
cuja descrição e processo de aplicação foi explicitado na subsecção 3.3.3.
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 depalavras 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 que seráapresentada na secção 4.2, foram analisados 292 posts tendo por base duasorientações:•a análise estatística descritiva (subsecção 4.2.1) foi definida como unidadede 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);99

Capítulo III – Metodologia(s)•A análise de conteúdo (subsecções 4.2.2, 4.2.3 e 4.2.4) recai sobre factos einterpretações, sendo as unidades de registo definidas a frase ou conjuntode palavras (Bardin, 2004).

-

Identificação

dasdimensões,categorias,

subcategoriaseindicadores
Com a análise do processo de desenvolvimento do Courseware Sere pretendese compreender os pontos fortes e as fragilidades da Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador (Costa, et al., 2010c), 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, 2004; Cohen, et al., 2007) tendo por base o modelo
3C de colaboração (descrição na subsecção 2.4.2) e da sua adaptação para o que sedesigna como modelo 4C.
- Validação do modelo 3C de colaboração para o modelo 4C
O modelo inicial de análise proposto (Anexo 3) foi validado por dois peritos
internos e por quatro peritos externos. Os peritos internos eram elementos que
pertenciam à equipa multidisciplinar do desenvolvimento do Courseware Sere e,os peritos externos, eram da área do desenvolvimento de software educativo e daanálise qualitativa. Seguidamente, apresentamos a estrutura do documento usado
para a validação do modelo de análise de processo de desenvolvimento:
1. As categorias propostas, foram identificadas de forma dedutiva, através dadas componentes que constituem o modelo

3C de colaboração:Comunicação, Coordenação e Cooperação tal como descrito na subsecção
2.4.2; e de forma indutiva, através de uma primeira leitura flutuante dos
dados (posts) que constituiu uma fase inicial da análise de conteúdo;
2. Para facilitar a interpretação do modelo proposto, dividiu-se o mesmo em
duas partes: a) a primeira consiste na contextualização do estudo,
descrevendo sucintamente o modelo 3C e as suas componentes; b) Na
segunda parte, apresenta-se o modelo de categorias proposto bem como a100Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

descrição de cada categoria, subcategoria/indicador. Para a validação,foram apresentados exemplos de posts, que designamos de “verdadeiros” e“falsos”. Apesar de se inserir a totalidade de cada post, os exemplos das
unidades de texto para validação encontram-se a negrito. Salienta-se que,para algumas categorias não se justificou a inserção de exemplos“verdadeiros” e “falsos” (por exemplo, perguntas ativas e perguntas inertes).
No final de cada post foi disponibilizada uma caixa de verificação
que fosse selecionada a caixa, para, em que o exemplo do post seja verdadeiro,

relativamente à categoria e descrição apresentada. Para finalizar, foi
inserida uma coluna para a inserção de comentários e sugestões, através docampo de texto. No final foi disponibilizado um espaço para “outras
sugestões”.
Do resultado da validação, foi proposto o modelo 4C que se apresenta deseguida.
- Modelo 4C de Análise de Processos de Desenvolvimento deSoftware Educativo
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, como referido na
subsecção 2.4.1.
A Figura 30 bem como a descrição de cada componente do modelo 4C é aversão já com as alterações propostas incluídas. A Tabela 12 apresenta as
categorias, subcategorias/indicadores bem como uma breve descrição de cada uma
delas.

101

Capítulo III – Metodologia(s)Figura 30 – Modelo 4C, adaptado do modelo 3C de colaboração de Fuks e colaboradores (2004;
2005; 2008)

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 oprocesso 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 problemasde hierarquia e à difusão de responsabilidade. Compete-lhe preparar a equipa
multidisciplinar para o trabalho colaborativo e cooperativo, através dapreparaçã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

102

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

afeta outras tarefas e todo o processo de desenvolvimento. Uma característica
de interdependência é a reciprocidade, que significa que os elementos daequipa são mutuamente interdependentes (Molleman, Nauta, & Jehn, 2004).
• Colaboração e Cooperação: tarefas que a equipa multidisciplinar
desenvolveem

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 deperguntas) 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 desituaçõ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.
Apesar de se partir de categorias pré-definidas com base no modelo 3C decolaboração foram necessárias propostas novas de categorias de análise. Tal
coaduna-se com uma metodologia qualitativa na qual, através de um processo
indutivo, de natureza empírica, se parte da observação para se construir hipóteses
explicativas do fenómeno em estudo (Bardin, 2004).

103

Capítulo III – Metodologia(s)Tabela 12 – Modelo 4C para análise de processos de desenvolvimento de software educativo
D*

Categoria

Subcategoria

Indicador

Comunicação

Partilha

Informação

Pontos de Vista

Compromissos

Escala temporal

Sem escalatemporalTarefasCoordenação

Pré-Articulação

Insistência

Conflitos

Competição

Descrição
Afirmação ou evidência
relativamente ao processo dedesenvolvido ou a uma solução
de projeto, com intuito de
informar os elementos daequipa multidisciplinar de
determinada situação ou
problema. Esta afirmação ouevidência não funciona comosugestão ou clarificação
associada a uma solução deprojeto. A informação pode
evidenciar conhecimentos
técnicos e científicos.
Perspetiva ou opinião sobre
determinada situação ou
problema que, poderá levar a
tomadas decisão ou à reflexão
dos elementos da equipa
multidisciplinar.
Um ou mais elementos daequipa multidisciplinar
comprometem-se a executar
determinada(s) tarefa(s),definindo um período detempo para a realização das
mesmas.
Um ou mais elementos daequipa multidisciplinar
comprometem-se a executar
determinada(s) tarefa(s), nãodefinindo um período detempo para a realização das
mesmas.
Mensagens enviadas que,preparam ações
essencialmente de cooperação,identificando objetivos e
distribuindo os mesmos em
tarefas (Fuks, Raposo, &Gerosa, 2002). Estas
mensagens também permitem
identificar o que cadaelemento está a executar.
Uma mesma mensagem é
enviada mais do que uma vez afim de se obter alguma
contribuição por parte de um
ou vários elementos da equipa
multidisciplinar.
Um ou mais elemento(s) daequipa multidisciplinar
evidencia(m) atitudes
competitivas através darealização de tarefas.

104

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Desorientação

Hierarquia

Responsabilidade

GeralInterdependência

Direcionada

Perguntas

InerteFeedback

Colaboração e Cooperação

Ativa

Concordância

Um ou mais elemento (s) daequipa multidisciplinar
evidencia(m) desorientação
nas tarefas a executar.
Problemas de hierarquia,
evidenciados pela não
realização de tarefas atribuídas
pela coordenação.
Um ou mais elemento (s) daequipa multidisciplinar não seassumem ou se reconhecem
em alguns papéis ou
responsabilidades.
Mensagens submetidas ao
conhecimento de todos
elementos, em que pelo menos
um elemento necessita defeedback dos restantes (ou damaioria) elementos da equipa
multidisciplinar, de forma apoder executar determinada
tarefa.
Mensagens submetidas ao
conhecimento de todos oselementos mas que, no seu
conteúdo contém
palavras/frases que
direcionam as mesmas para
determinado(s) elemento(s) daequipa multidisciplinar.
A resposta dos elementos daequipa multidisciplinar a uma
pergunta ativa ajuda aesclarecer a situação/problema
ou a melhorar as soluções deprojeto.
Perguntas formuladas que nãocontribuem para melhorar assoluções de projeto,consequentemente podem não
ter obtido qualquer resposta(ignoradas).
Um ou mais elementos
concordam parcialmente ou
totalmente com uma sugestão
ou solução de projeto,permitindo assim o desenrolar
do projeto. Poderão existirmensagens de concordância
com ressalvas.

105

Capítulo III – Metodologia(s)Persistência

Sugestões

Clarificação

Discordância

Identificação de situações em
que os elementos apresentam
divergências nos processos decolaboração e cooperação,podendo atrasar odesenvolvimento do projeto. A
discordância poderáapresentar um argumento ou
uma proposta alternativa.
Face a uma situação ou
problema, são enviadas
mensagens com a finalidade dea clarificar/esclarecer.
Mensagens explicativas, que
na sua maioria estão
associadas às soluções deprojeto, também estão
enquadradas nesta categoria.
Discussão de soluções projetoatravés de sugestões
efetuadas/fornecidas por um
ou vários elementos, podendo
estas gerar novas ações,evidenciadas através de novas
soluções de projeto(documentos e protótipos).
Os elementos da equipa
demonstram persistência na
realização das tarefas, atravésde sugestões e novas soluções
de projeto.

* D - Dimensão

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 (http://www.webqda.com). Com
o webQDA o investigador pode editar, visualizar e interligar documentos. Podecriar categorias, codificar, controlar, filtrar, fazer buscas e questionar os dados com
o objetivo de responder às suas questões de investigação (Souza, Costa, & Moreira,2010, 2011a, 2011b).
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

106

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

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 edecontextoe

distribuídas

pelas

dimensões

ecategorias

estabelecidas

anteriormente (Bardin, 2004; Bogdan & Biklen, 1994; Carmo & Ferreira, 1998;
Fraenkel & Wallen, 2009). 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

mensaldemensagensduranteoperíododedesenvolvimento do recurso, a quantidade de posts com soluções de projeto(protótipos em imagem, documentos e protótipos programados), com a finalidadede sustentar a análise de conteúdo efetuada a posteriori.
Na secção 4.2, de apresentação e discussão dos resultados, descreve-se as
inferências e as interpretações resultantes da análise doprocesso dedesenvolvimento. Na parte final desta secção, apresenta-se um episódio em quesãoreferenciadas

ascategoriasesubcategorias/indicadoresdeanáliseapresentadas na Tabela 12.
3.4 DIFICULDADES METODOLÓGICASAs dificuldades metodológicas sentidas surgiram, em parte, pelo facto doinvestigador ter iniciado a sua experiência em metodologias e técnicas deinvestigação com o estudo empírico realizado. A técnica utilizada que suscitou
maiores dificuldades foi a análise de conteúdo. Associada a esta técnica de análise
existe uma tensão que o investigador se deve esforçar por equilibrar:•

O facto do modelo 4C para análise do processo de desenvolvimento ter sido
proposto de forma indutiva (leitura flutuante dos dados) e dedutiva (combase no modelo 3C de colaboração);107

Capítulo III – Metodologia(s)•As diferenças na linguagem e nas abordagens, evidenciadas na validação domodelo 4C por parte dos peritos internos e externos;•

A análise de conteúdo constitui uma técnica com uma dimensão subjetiva
considerável, devendo o investigador esforçar-se por reduzi-la através dadefinição clara do processo de análise (que se procurou realizar na
subsecção 3.3.4).

108

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

4 CAPÍTULO IV – APRESENTAÇÃO E DISCUSSÃO
DOS RESULTADOS

No capítulo precedente foi apresentada, descrita e justificada a metodologia
seguida no estudo empírico. Pretendendo-se avaliar tanto o recurso como o seu
processo de desenvolvimento, a fase de avaliação foi transversal a todas as fases da
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador (descrita nasecção 3.2). Neste capítulo serão descritos os resultados dessa avaliação. A
primeira secção centra-se na apresentação e discussão das perceções dos
professores e dos alunos, que responderam aos questionários de avaliação,relativamente à 1ª versão do Courseware Sere. Na secção seguinte, apresentam-se
e discutem-se os resultados da análise do processo de desenvolvimento com basenas interações online (trabalho colaborativo e cooperativo não presencial) entre oselementos da equipa multidisciplinar que desenvolveu o Courseware Sere. Comose indicou no capítulo anteriormente, esta análise foi efetuada explorando omodelo 4C (subsecção 3.3.4).

109

Capítulo IV – Apresentação e Discussão de Resultados

4.1

FASE 2 – AVALIAÇÃO DO COURSEWARE SERE

No final da fase 3 do processo de desenvolvimento (ver subsecção 3.2.3) otrabalho da equipa multidisciplinar centrou-se na avaliação técnica e didática daprimeiraversãodo

Courseware

Sere(disponívelnapáginaweb

http://sere.ludomedia.pt) envolvendo para isso, alunos do 2º Ciclo de Ensino
Básico e professores dos 1º e 2º Ciclos do ensino básico. Nas subsecções que seseguem, apresentam-se os resultados dessa avaliação. Relembra-se que tanto os
professores como os alunos que avaliaram o recurso tiveram a oportunidade de o
explorar e responderam a questionários desenvolvidos para o efeito (Anexos 1 e 2).
4.1.1 Avaliação dos professores relativamente aos aspetos técnicos e
didáticos
A avaliação efetuada pelos professores, teve por base o preenchimento de um
inquérito por questionário de avaliação técnica e didática do Courseware Sere. O
questionário foi respondido no decurso de workshops (sessões práticas com aduração máxima de 120 minutos, em que os professores em grupos de dois a trêselementos, exploraram duas atividades de uma das fases do courseware) por um
grupo heterogéneo de potenciais utilizadores do recurso. O questionário é
composto por três partes, já descritas na subsecção 3.3.1.
Nos workshops dinamizados, o questionário foi aplicado a 35 professores(Costa, et al., 2009a). A apresentação dos resultados é feita por recurso a gráficos e
atendendo à estrutura do questionário. Como referido, para as questões fechadas
do questionário, foi utilizada uma escala de Likert (1 – Discordo plenamente, 2 –Discordo, 3 – Concordo, 4 – Concordo plenamente, NS/NR – Não sei/Não
respondo).
Dos professores que participaram neste estudo, 19 lecionavam o 1º Ciclo do
ensino básico e os restantes 16, o 2º Ciclo do ensino básico. A experiência
profissional média dos 35 professores é de 14 anos dos quais 9 professores
possuíam mestrado e 1 professor o doutoramento. O Gráfico 1 apresenta a

110

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

frequência relativa à de utilização semanal das Tecnologias de Informação e
Comunicação por parte dos professores.

Gráfico 1 – Utilização (semana) das Tecnologias de Informação e Comunicação por parte dos
professores

Para um recurso com as caraterísticas do courseware é um fator relevante que
os professores tenham hábitos/rotinas na utilização das Tecnologias deInformação e Comunicação, o que se confirmou com os resultados apresentados
no Gráfico 1 (dos 35 professores, 77% utilizavam diariamente as Tecnologias deInformação e Comunicação). Importa ainda referir que não se registaram
respostas no item “Nunca”.
Relativamente à questão “Esteve ou está envolvido(a) num projeto que
contempla a integração das Tecnologias de Informação e Comunicação na
Educação em Ciência nos primeiros anos de escolaridade?”, 24 professores
responderam que nunca estiverem envolvidos em projetos semelhantes.
- Avaliação dos aspetos técnicos (navegação e interface)
Nos Gráficos 2, 3, 4, 5 e 6 apresentam-se os resultados das questões fechadas(ver Anexo 1) relacionadas com a navegação e a interface.

111

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 2 – Avaliação dos aspetos técnicos (botões de navegação) por parte dos professores.

Na perspetiva dos professores inquiridos, os botões de navegação e os botões
do menu do software que fazem sentido/têm significado (43% concordam e 54%
concordam plenamente), ou seja, mostra que, visualmente, é percetível qual a
finalidade de cada botão. Os inquiridos também concordam que os mesmos botões
são fáceis de selecionar/clicar (40% concordam e 60% concordam plenamente).

Gráfico 3 - Avaliação dos aspetos técnicos (navegação) por parte dos professores.

112

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Da leitura que se efetua ao Gráfico 3, dos 41 inquiridos, 92% concordam ou
concordam plenamente que a forma de navegar entre os ecrãs é facilmente
percetível contrapondo o resultado da questão “É fundamental ter acesso a “ajuda”
para navegar?” em que 31% dos inquiridos concordam e 66% concordam
plenamente da necessidade de ajuda para navegar. 97% concordam ou concordam
plenamente que a estrutura acíclica 9 facilita a navegação no software. Porém, este
tipo de estrutura, em que a possibilidade do utilizador se perder na navegação dosoftware aumenta, poderá justificar os resultados da questão “É fundamental ter
acesso a “ajuda” para navegar?”. A questão “A existência de mais que uma opção
de navegação dentro dos ecrãs ajuda a navegação no software?” 97% dos
inquiridos concordam e concordam plenamente que esta possibilidade é essencialpara o sucesso na navegação do software.

Gráfico 4 - Avaliação dos aspetos técnicos (interface e navegação) por parte dos professores.

Da análise do gráfico acima, infere-se que, na perspetiva do professor, amaioria dos utilizadores (crianças) terão facilidade em utilizar o software,
9 Numa estrutura acíclica o utilizador pode aceder à informação por mais de um percurso. A possibilidade doutilizador se perder aumenta, mas a sua liberdade de navegação é maior.

113

Capítulo IV – Apresentação e Discussão de Resultados

necessitando apenas de uma ajuda pontual. 74% dos inquiridos concordam ou
concordam plenamente com este item do questionário. Este resultado poderá estar
relacionado com o facto dos elementos gráficos utilizados nos ecrãs serem
semelhantes ao de outros programas informatizados, como por exemplo, microsoft
word, microsoft powerpoint, microsoft paint. Esta conclusão é reforçada pela
comparação dos resultados apresentados no Gráfico 1 relativamente à questão “Ainterface é intuitiva apelando a metáforas conhecidas do utilizador?”. Como se
constata, 57% dos inqueridos concordam e 43% concordam plenamente que ainterface é intuitiva apelando a metáforas 10 conhecidas pelo utilizador.
Relativamente à questão “A inexistência de feedback aquando da exploração
das atividades é adequada?”, 51% dos professores acreditam que a ausência de
feedback durante as atividades é adequada. No entanto, 11% dos professores
responderam "Não sei/Não responde" a esta questão.

Gráfico 5 - Avaliação dos aspetos técnicos (interface) por parte dos professores.

O Gráfico 5 apresenta o resultado a 4 questões relacionadas com a interface
gráfica do software que constituía o Courseware Sere. Relativamente à questão “Ainterface é simples e de fácil compreensão?”, 49% concordam e 51% concordam
10 Entende-se por metáfora a representação simbólica de algo. Por exemplo, utilizador sabe intuitivamente queo símbolo “X”, permite fechar determinada janela

114

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

plenamente. As restantes questões reforçam os resultados obtidos na questão
anterior os quais 97% concordam e concordam plenamente que as formas derepresentação da informação são visualmente agradáveis, 97% concordam e
concordam plenamente que a distribuição/equilíbrio 11 dos formatos dos ecrãs é
adequada e 100% concordam e concordam plenamente que a organização dosecrãs apresenta consistência.

Gráfico 6 - Avaliação dos aspetos técnicos (interface/formatos) por parte dos professores.

Para finalizar, apresentam-se os resultados da utilização de diferentes
formatos 12 (Gráfico 6). Os inquiridos concordam (37%) e concordam plenamente(60%) que é relevante a utilização de diferentes formatos de representação dainformação, possibilitando assim que utilizadores com determinadas NecessidadesdeEducativas

Especiais

possamutilizarosoftware(acessibilidade/

funcionalidade). A questão “Nos ecrãs de entrada de cada fase, a possibilidade doutilizador ler e ouvir a explicação do que se pretende na mesma é adequada?”
reforça a importância da utilização de diferentes formatos (11% concordam e 89%
concordam plenamente).

11 Equilíbrio dos diferentes elementos (sem demasiada informação visual nem textual).

12 Por exemplo, opção dada ao utilizador de poder ouvir e ler em simultâneo a mesma informação.

115

Capítulo IV – Apresentação e Discussão de Resultados- Avaliação da estrutura (opções) geral
Os Gráficos 7, 8 e 9 descrevem os resultados das questões fechadas
relacionadas com a estrutura (opções) geral do recurso.

Gráfico 7 - Avaliação da estrutura geral (animação) por parte dos professores.

Na parte inicial da exploração do software que constitui o Courseware Sere,
surge uma animação de contextualização da problemática que o recurso abarca(ver subsecção 3.2.2). Pela leitura do Gráfico 7, 31 % dos inquiridos concordam e
66% concordam plenamente que animação permite, efetivamente, contextualizar
com clareza a problemática e que o facto de se poder visualizar a mesma em
qualquer ecrã é relevante (94% concordam ou concordam plenamente).

116

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Gráfico 8 - Avaliação da estrutura geral (menu) por parte dos professores.

Os resultados apresentados no Gráfico 8 reforçam o que foi apresentado
anteriormente relativamente à avaliação da navegação e da interface do software.
A possibilidade de em qualquer ecrã se poder navegar para outra fase permite um
rápido acesso às mesmas segundo 97% dos inquiridos. De igual modo,
relativamente à navegação dentro de cada fase, 97% dos inquiridos concordam ou
concordam plenamente que o menu de acesso aos outros ecrãs sob forma de
thumbnails 13 permite um rápido acesso.
17% dos inquiridos concordam e 83% concordam plenamente com as
funcionalidades apresentadas no menu. Além disso, o facto de os ícones surgirem
com texto associado à imagem facilita a interpretação por parte dos utilizadores(40% concordaram e 60% concordaram plenamente).

13 Menu constituído por pequenos ecrãs que permitem o acesso respetivo (à semelhança do que acontece em

computadores MAC).

117

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 9 - Avaliação da estrutura geral (opções pré-definidas) por parte dos professores.

Existem algumas opções no software que são obrigatórias para que se possa
prosseguir na exploração do mesmo, sendo um exemplo disso, as três primeirasquestões apresentadas no Gráfico 9. 22% dos inquiridos discordam ou discordam
plenamente com o facto de se ser indispensável escolher uma personagem e 9%
dos inquiridos não sabem/não respondem; 15% discordam ou discordam
plenamente da importância em se atribuir nome a um utilizador ou a um grupo deutilizadores e 3% dos inquiridos não sabem/não respondem; e 9% não acham queseja essencial a associação automática do nome, da idade e da região à personagem
selecionada e 6% dos inquiridos não sabem/não respondem. Por outro lado, 94%
dos inquiridos acha importante que exista uma personagem (neste caso opresidente) a explicar o que se pretende em cada fase.
- Avaliação dos aspetos didáticos (conteúdos e atividades)
Nos Gráficos 10, 11, 12 e 13 descrevem-se os resultados das questões fechadas
relacionadas com os conteúdos e atividades.

118

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Gráfico 10 - Avaliação dos aspetos didáticos (atividades – competências e autonomia) por parte dos
professores.

Dos inquiridos, 29% concordam e 71% concordam plenamente que asatividades proporcionam o desenvolvimento de várias competências gerais pelo
aluno (utilizador) sugeridas no currículo 14. 97 % dos inquiridos considerou que asatividades são adequadas para a faixa etária dos alunos, sendo interessante este
resultado pelo facto dos workshops de avaliação serem constituídos por
professores dos 1º e 2º Ciclos do ensino básico. Os resultados também permitem
aferir que a maioria dos professores acreditam que o recurso permitirá ao alunoadquirir competências 15 de uma forma autónoma. 71% dos professores
responderam "concordo plenamente" a esta questão e os restantes 29%
responderam "concordo".

14 Como por exemplo, mobilizar saberes culturais, científicos e tecnológicos para compreender a realidade epara abordar situações e problemas do quotidiano.
15 Como por exemplo, pesquisar, selecionar e organizar informação para a transformar em conhecimento

mobilizável.

119

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 11 - Avaliação dos aspetos didáticos (atividades - articulação) por parte dos professores.

Pela leitura do Gráfico 11, apenas 6% dos inquiridos discordam e discordam
plenamente que as atividades do recurso facilitam abordagens multi etransdisciplinares, contrapondo com os 94% dos inquiridos que concordam ou
concordam plenamente. Além disso, 97% dos inquiridos (43% concordam e 54%
concordam plenamente) admitem a possibilidade das atividades serem articuladas
curricularmente com outros níveis de ensino.

Gráfico 12 - Avaliação dos aspetos didáticos (atividades – aprendizagem) por parte dos professores.

120

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Os resultados às questões apresentadas no Gráfico 12 reforçam a adequação
das atividades (perspetiva dos professores) à faixa etária (desde dos 8 anos deidade) definida para o recurso. 43% concordam e 51% concordam plenamente que
as atividades respeitam diferentes ritmos de aprendizagem e 100% (49%concordam e 51% concordam plenamente) são de acordo que as atividades
permitem um envolvimento ativo do professor na construção de competências dos
alunos. 89% dos inquiridos concordam ou concordam plenamente que asatividades não refletem preconceitos ou estereótipos 16 sendo um dos critérios deaferição da qualidade de um recurso.

Gráfico 13 - Avaliação dos aspetos didáticos (conteúdos – adequação e pertinência) por parte dos
professores.

Relativamente aos conteúdos (Gráfico 13), apenas 6% dos inquiridos discorda
ou discorda plenamente que os mesmos sejam adequados à faixa etária dos
utilizadores. Por outro lado, 97% dos inquiridos (28% concordam e 69%
concordam plenamente) são da opinião que os conteúdos são pertinentes face ànatureza da temática e aos objetivos curriculares. Relativamente à questão
“Revelam rigor científico (incluindo qualidade e correção científica do conteúdo,
atualidade da informação e clareza no uso de termos e conceitos)?”, 6% discordam
e 14% discordam plenamente.
16 Quanto a aspetos relacionados com a raça, etnia, religião, cultura de origem, entre outros.

121

Capítulo IV – Apresentação e Discussão de Resultados

Pela análise efetuada conclui-se que, segundo a perspetiva, a navegação einterfase bem como as atividades e conteúdos são adequados à faixa etária definida
para o recurso.
4.1.2 Avaliação dos alunos relativamente a aspetos técnicos e
didáticos
Relativamente à avaliação efetuada pelos alunos, o inquérito por questionáriode avaliação técnica e didática, foi respondido após a utilização do recurso em
contexto de sala de aula (blocos de 90 minutos, em que os alunos em grupos detrês a quatro elementos, exploram as atividades do courseware, devidamente
planificadas pelo professor). O instrumento utilizado, um questionário, é composto
por duas partes (descritas na subsecção 3.3.1). Resumidamente, a primeira partevisava caracterizar os alunos (idade, sexo, ano de escolaridade, frequência e paraque fim utilizam o computador) e a segunda parte, constituída por dois grupos dequestões fechadas sobre o Courseware Sere, relacionados com a interação doutilizador com o software (navegação e desenho das janelas) e com as atividades
pensadas para a exploração didática.
Para as questões fechadas do questionário, foi utilizada uma escalasimplificada de Likert (1 – Não, 2 – Mais ou Menos, 3 – Sim). Relativamente aosresultados do questionário, apresentam-se os mesmos relativamente a duas
vertentes: quanto às questões técnicas (navegação e desenho das janelas); e quantoàs questões didáticas (atividades)(Costa, et al., 2010b).
O questionário foi respondido por 41 alunos (duas turmas, lecionadas pelo
mesmo docente) do 2º ciclo do ensino básico, a frequentar o 6º ano deescolaridade, com idades compreendidas entre os 11 e os 13 anos. Posto isto,
quanto à questão “Já algum dos teus professores fez uma catividade parecida com
esta?” 27 alunos (65,8%) afirmaram já terem realizado uma atividade idêntica e os
restantes 14 (34,2%) nunca tinha realizado uma atividade desta natureza.
Os Gráficos 14 e 15 apresentam os resultados das questões “Quantas vezes por
semana utilizas o computador?” e “O que fazes no computador?” respetivamente.

122

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Gráfico 14 – Frequência de utilização (por semana) do computador por partes dos alunos

Pela leitura efetuada ao Gráfico 14, verifica-se que existem alunos que nunca
utilizam o computador (2%) ou que raramente o utilizam (5%). Porém a maioria
dos 41 alunos inquiridos utiliza o computador no mínimo duas a três vezes por
semana (86%).

Gráfico 15 – Finalidade do uso do computador por parte dos alunos

123

Capítulo IV – Apresentação e Discussão de Resultados

A finalidade do uso do computador por parte dos alunos inquiridos servediferentes propósitos tal como representa o Gráfico 15. 63% das preferências dos
alunos recai para o uso da internet e para os jogos informatizados.
- Navegação
Os resultados apresentados nos Gráficos 16, 17 e 18 referem-se à navegação noprograma.
Para analisar os resultados da questão “Consegues navegar sem ajuda?”,relacionou-se os mesmos com os resultados da seguinte questão “Quantas vezes
por semana utilizas o computador?” (Gráfico 16). A amostra foi dividida em duas
partes: a) alunos que utilizam 2 a 3 vezes por semana e todos os dias ocomputador; b) alunos que nunca utilizam o computador, raramente e apenas uma
vez por semana.

Gráfico 16 - Utilização do computador por semana vs. Navegar sem ajuda

Relativamente à utilização do computador, 59 % dos alunos utiliza ocomputador todos os dias e apenas 7% raramente ou nunca utiliza o computador.
Dos 85% dos alunos que utilizam o computador todos os dias ou 2 a 3 vezes por
semana, 63% consegue navegar sem ajuda e 37% nem sempre consegue navegar
sem ajuda. Por outro lado, dos 15% de alunos, que no máximo utilizam o124Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

computador uma vez por semana, apenas 33% consegue navegar sem ajuda e 67%,
por vezes, necessita de ajuda para navegar. É de realçar, contudo, que apesar deexistirem alunos que utilizam o computador com pouca frequência, nenhum aluno
necessitou de ajuda, continuamente, para navegar pelo programa. Desta forma,pode-se concluir que o recurso é de fácil uso (usabilidade), mesmo para alunos queapresentam pouca familiaridade no uso do computador.

Gráfico 17 – Navegação pelo programa (botões)No Gráfico 17, e à semelhança da avaliação efetuada pelos professores (versubsecção 4.1.1), 71% dos alunos perceberam o significado dos botões e 78%
concordaram na facilidade de selecionar os botões usando o rato. A perceção e
facilidade de selecionar os botões permitem que o utilizador tenha maior ou menor
dificuldade para navegar pelo programa.

125

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 18 – Navegação pelo programa (localização e deteção de erros)

Pela leitura do Gráfico 18, 76% dos alunos inquiridos sabiam, aquando da
exploração do software, em que atividade estavam e 59% tinham a perceção dequando cometiam um erro. Estes resultados são importantes para aferir asatisfação de uso e respetiva eficiência e eficácia do software. Neste mesmo
gráfico, também se verifica que 20% dos inquiridos não sabiam e 29% por vezes
não sabiam para onde ir. Este resultado pode ser justificado pelo facto das
atividades não serem sequenciais e não existir feedback após a realização das
mesmas126

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo- Desenho das janelas

Gráfico 19 - Desenhos das janelas (cores e imagens)

Relativamente ao desenho das janelas (interface gráfica), a totalidade dos
alunos (100%) acharam que o desenho das janelas era agradável (Gráfico 19). De
forma a reforçar os resultados da questão “O desenho das janelas era agradável?”,foram analisados os resultados de mais duas questões: a) Gostaste das cores? b)
Gostastes das imagens?. Estas duas questões têm uma relação direta com aquestão “O desenho das janelas era agradável?”, sendo as cores e as imagens
elementos constituintes do desenho das janelas. Assim sendo, dos resultados àquestão “Gostaste das cores?”, depreende-se que as totalidades dos inquiridos
afirmaram terem gostado das mesmas. Por outro lado, 93% dos inquiridos
gostaram também das imagens e apenas 7% acharam as imagens razoavelmente
agradáveis.
- Interesse, adequação e organização das atividades
Os Gráficos 20, 21 e 22 apresentam os resultados relativamente às questões
sobre as atividades contidas no recurso e exploradas pelos alunos das duas turmas
do 6º ano do 2º ciclo do ensino básico.

127

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 20 - Adequação das atividades (interesse)

Dos 41 alunos inquiridos, 83% concordaram em como as atividades eraminteressantes para a sua idade. E destes 83%, 97% afirmaram que foi engraçado
desenvolver estas mesmas atividades. Dos restantes 17% dos inquiridos, que
acharam as atividades razoavelmente interessantes, 71% gostaram de desenvolver
as atividades (Gráfico 20).

128

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Gráfico 21 - Adequação das atividades (envolvimento do professor)

Da leitura efetuado ao Gráfico 21 verifica-se que, 95% dos inquiridos conseguiu
perceber o que era pedido em cada uma das atividades. Podemos relacionar esta
questão com a questão “A ajuda do professor foi importante para desenvolver as
atividades?”, em que 76% concordaram que a mesma foi essencial. Porém, 22%
dos inquiridos acharam ter sido razoável a ajuda do professor e apenas 2% nãoacharam importante a ajuda do professor.

Gráfico 22 - Adequação das atividades (aprendizagem)

129

Capítulo IV – Apresentação e Discussão de Resultados

Da leitura efetuada ao Gráfico 22, certifica-se que 10% dos inquiridos não
acharamasatividades

desafiantese29%

acharam-nas

razoavelmenteinteressantes. Porém, 80% concordaram que aprenderam mais coisas além dotema do programa.
Pela análise dos resultados apresentados anteriormente, pode-se afirmar que osoftware é de fácil navegação, a interface é bastante adequada bem como as
atividades propostas. Além disso pode-se evidenciar que este software além de
Usável é Funcional tendo em consideração a definição apresentada na
subsecção 2.5.1.
4.2

FASE 3 – ANÁLISE DO PROCESSO DE DESENVOLVIMENTO

Com a finalidade de propor melhorias à Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador, 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.
Apesar de terem sido utilizadas diferentes ferramentas de comunicação (e-mails,
chats, entre outras), a nossa análise e interpretação recaiu sobre os 292 posts
inseridos (entre abril de 2008 e fevereiro de 2009) nos fóruns (anexos 05, 06, 07,
08 e 09). Esta opção deveu-se pela riqueza do conteúdo dos posts e volume dedados muito elevado, pelo que se teve que fazer escolhas, recaindo pela análise dos
fóruns. Além disso, os fóruns permitiram que as interações ficassem organizadas edisponíveis para serem revisitadas, podendo ter levado os elementos da equipa ausar 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.
As unidades de registo que serviram de base à análise estatística descritiva que
será apresentada, descrita e discutida nas próximas subsecções, têm por base a
totalidade do post com o intuito de contextualizar o leitor. Algumas frases são
colocadas a negrito de forma a destacá-la no post em que está inserida.

130

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Seguidamente, efetua-se a referida análise estatística descritiva (subsecção
4.2.1) com o intuito de apoiar a análise de conteúdo que será efetuada nas
subsecções 4.2.2, 4.2.3 e 4.2.4. Neste análise (interpretativa) designa-se as
unidades de registo como referências, quantificando o número de referências por
categoria e subcategoria/indicadores, das dimensões definidas: Comunicação,Coordenação e Colaboração e Cooperação.
4.2.1 Descrição geral sobre padrão de interação nos fóruns
A análise estatística descritiva que se apresenta seguidamente, tendo por basea quantificação das unidades de registo, permitiu perceber o fluxo de posts
submetidos pelos diferentes elementos da equipa multidisciplinar.
Para facilitar a apresentação dos resultados desta secção, codificaram-se as
designações atribuídas a cada elemento da equipa multidisciplinar da seguinte
forma:
DI-A: Designer-Ilustrador A
DI-B: Designer-Ilustrador B
GP: Gestor de Projeto
IDC: Investigador em Didática das Ciências
IDC/TE: Investigador em Didática das Ciências e Tecnologia Educativa
PDC: Perito em Didática das Ciências
PTE: Perito em Tecnologia Educativa
PE-A: Programador A
PE-B: Programador B

131

Capítulo IV – Apresentação e Discussão de Resultados

Previamente e antes de se proceder à análise descritiva, bem como à análise deconteúdo, carateriza-se os elementos da equipa no que respeita à sua“disponibilidade” para o projeto, o que ajudará a fundamentar algumas
interpretações:•Designer-Ilustrador A: colaborador externo, com contrato numa instituição,tendo apenas disponibilidade para o projeto em horário pós-laboral e finsde-semana;•

Designer-Ilustrador B: colaborador externo, com contrato numa empresa,
tendo apenas disponibilidade para o projeto em horário pós-laboral e finsde-semana;•

Gestor de Projeto: colaborador interno da Ludomedia, com disponibilidade
total para o desenvolvimento do projeto;•

Investigadora em Didática das Ciências: bolseira de pós-doutoramento, com
disponibilidade parcial para o desenvolvimento do projeto;•

Investigadora em Didática das Ciências e Tecnologia Educativa: bolseira dedoutoramento, com disponibilidade parcial para o desenvolvimento do
projeto;•

Perito em Didática das Ciências: docente e investigador da Universidade de
Aveiro, envolvido em vários projetos, com disponibilidade parcial para odesenvolvimento do projeto;•

Perita em Tecnologia Educativa: docente e investigadora da Universidade
de Aveiro, envolvido em vários projetos, com disponibilidade parcial para odesenvolvimento do projeto;•

Programador A: colaborador externo, freelancer, envolvido em vários
projetos, com disponibilidade parcial para o desenvolvimento do projeto;•

Programador B: colaborador interno, envolvido em vários projetos, com
disponibilidade parcial para o desenvolvimento do projeto.
132

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

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 (quantificação dos posts submetidos) e fundamentá-las,embora com algumas ressalvas decorrentes do referido envolvimento. A
envolvência dos elementos de uma equipa multidisciplinar no desenvolvimento deum software educativo pode ser medida pelo envio de mensagens com conteúdo
significante para o bom desenrolar do projeto. 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, aque 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).
O Gráfico 23 apresenta a autoria dos 292 posts submetidos pelos elementos daequipa multidisciplinar, ao longo do processo de desenvolvimento do Courseware
Sere.

Gráfico 23 – Posts submetidos por elemento da equipa multidisciplinar

133

Capítulo IV – Apresentação e Discussão de Resultados

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 DesignerIlustrador 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 Sere,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 oprojeto, como acima indicado.
Relativamente ao fluxo mensal de posts, é possível observar no Gráfico 24 queo pico de submissão de posts ocorreu em janeiro, mês anterior à data do mês delançamento do recurso, dia 26 de fevereiro de 2008.

Gráfico 24 – Posts submetidos mensalmente

Os 28% de posts (81) submetidos, no acima referido mês, podem dever-se avários fatores que se enumera seguidamente:•

Necessidade de feedback mais célere, nomeadamente de verificação evalidação das soluções de projeto apresentadas. Neste mês, foram
134

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

submetidos 36 posts com soluções de projeto: 1 protótipo corrido, 34
documentos e 1 protótipo em imagem;•

Maior disponibilidade dos elementos da equipa multidisciplinar, pela
aproximação do período de produção do recurso e seu lançamento.

Relativamente à iniciação da interação (42 posts), ou seja, posts que têm como
objetivo desencadear a interação (debate ou discussão) entre os elementos daequipa multidisciplinar relativamente a determinada situação ou problema, 97,6%(41 posts) foram da autoria do Gestor de Projeto (Gráfico 25).

Gráfico 25 – Posts de iniciação por elemento da equipa multidisciplinar

Dos 292 posts submetidos, 129 posts (44,2%) incluem pelo menos um tipo desolução de projeto, o que reforça a utilização dos fóruns para a disponibilização e
discussão das soluções de projeto. As soluções de projeto submetidas nos fóruns
dividem-se em três tipos: protótipos programados, documentos e protótipos em
imagem. O Gráfico 26 apresenta a distribuição dos post por tipo de solução deprojeto.

135

Capítulo IV – Apresentação e Discussão de Resultados

Gráfico 26 – Tipo de Solução de Projeto

2,3% (3 posts), do total de post com soluções de projeto, são posts referentes a
protótipos programados, como ilustra a mensagem abaixo.
“Assunto: SOFTWARE CD-ROM, VERIFICAÇÃO
Enviado: Gestor de Projeto, quarta-feira, 4 de fevereiro de 2009, 20:39
Boa tarde a todos, encontra-se na página Web http://sere.ludomedia.pt aversão do software que será utilizada em CD-ROM. (…)”

54,3% (70 posts) têm associados documentos de texto relativos a diferentesversões dos guiões de exploração didática do professor, guiões de registo do aluno,
manual do utilizador, textos para os áudios de apoio, estrutura e conteúdos dapágina web de apoio ao recurso, como se depreende da mensagem seguinte.
“Assunto: Dossier de conceção do site de apoio ao Courseware Sere
Enviado: Investigadora em Didática das Ciências e Tecnologia Educativa,
quinta-feira, 8 de maio de 2008, 16:39
Dossier_de_concepcao_do_site_de_apoio_ao_Courseware_Sere.doc
Olá. Tal como prometido, aqui segue o primeiro esboço do dossier de conceção
do site de apoio ao Courseware Sere. Saudações.”136

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

43,4% dos posts (56 posts) incluem protótipos em imagem, a sua maioria
associados a elementos gráficos dos ecrãs do software. As mensagens seguintes
constituem exemplos deste tipo de post.
“Assunto: Ecrãs Fase III
Enviado: Gestor de Projeto, terça-feira, 27 de maio de 2008, 18:57
Interfaces_Fase3_vers1_.pdf
Boa tarde, coloco aqui os primeiros protótipos de ecrãs referentes à Fase III.
Um abraço”“Assunto: Re: Ecrãs Fase III
Enviado: Gestor de Projeto, terça-feira, 28 de outubro de 2008, 09:58
Ecra14_Fase3_vers3_.pdf
Bom dia, segue em anexo o último ecrã desta fase já com a Barragem.
Pedia se faz favor que comentassem de forma que o Programador B possa
programar e animar.
Um abraço”

Das soluções de projeto submetidas, 77,5% dos posts (100 posts) foram daautoria do Gestor de Projeto (Gráfico 27a)). 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 (Gráfico 27b)).
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 daequipa multidisciplinar. Do Gráfico 27a) 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 (Gráfico 27b)).
As referências seguintes exemplificam o que foi supracitado:“Assunto: Re: Dossiers de Exploração Didática - FASE 2
Enviado: Perito em Didáticas das Ciências e Perita em Tecnologia Educativa,
terça-feira, 4 de novembro de 2008, 12:13

137

Capítulo IV – Apresentação e Discussão de Resultados

Fase2_Floresta_Dossier_Exploracao_Professor_vers3_1_.doc
Aqui vai a nossa apreciação ao doc. em apreço.
São necessárias também decisões técnicas (Gestor de Projeto e colegas).
Bom trabalho”“Assunto: Re: Pegada Ecológica
Enviado: Investigadora em Didática das Ciências, quarta-feira, 17 de dezembrode 2008, 14:48
Calculo_pegada_ecologica_vers3_.doc
Bom dia a todos,
Estive a ver as alterações propostas pelo Professor Rui ao questionário da
Pegada Ecológica e concordo com todas. Envio, em anexo, apenas mais duas
sugestões.
No entanto, as questões 10 e 12 parecem-me difíceis de responder. Não sei se osutilizadores terão consciência dos km que fazem até à escola ou por fim-desemana. Será uma questão a decidir pela equipa.
A pontuação final deverá ser calculada em função da pontuação máxima que
esta nova versão do questionário permite (se o valor 800 não é possível não
deverá constar). Penso que a única categoria que precisa de ser alterada é aúltima (de limite superior), as outras estarão bem.
Vou ver os textos para a Fase II.
Até breve”

a)

138

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativob)Gráfico 27 – a) Submissão de soluções de projeto por elemento da equipa multidisciplinar b)
Submissão por tipo de solução de projeto efetuada pelo Gestor de Projeto vs. Restantes elementos

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 detempo. 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.
Nas próximas três subsecções (4.2.2, 4.2.3 e 4.2.4) irá proceder-se à análise
interpretativa (de forma individual tendo por base a estrutura apresentada na
Figura 31) das interações dos elementos da equipa multidisciplinar, tendo por baseas dimensões (Comunicação, Coordenação e Colaboração e Cooperação)apresentadas na subsecção 3.3.4.

139

Capítulo IV – Apresentação e Discussão de Resultados

Figura 31 – Estrutura definida para a análise interpretativa

4.2.2 Dimensão “Comunicação”
No modelo de análise proposto, a dimensão “Comunicação” descrita na secção
3.3.4, compreende duas categorias (Figura 32): i) a partilha e ii) os compromissos.
Por sua vez, a categoria partilha está dividida em duas subcategorias: partilha de
informação (36 referências 17) e partilha de pontos de vista (38 referências). Estas
promovem as interações entre os elementos da equipa multidisciplinar
pretendendo “provocar” (re)ações no(s) recetor(es).

Figura 32 – Categorias e Subcategorias/Indicadores da dimensão “Comunicação”

17 Como explicado na subsecção 3.3.4, as referências são as unidades de registo, que podem ser a frase ou

conjunto de palavras que façam sentido e tenham significado.

140

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

A partilha de informação é uma afirmação ou evidência relativamente ao
processo de desenvolvimento ou a uma solução de projeto, com intuito de informar
os elementos da equipa multidisciplinar de sobre uma situação ou problema, como
explicitam as seguintes referências:“Assunto: Fase1 - 2º EcrãEnviado: Gestor de Projeto, sexta-feira, 7 de novembro de 2008, 19:04(…) Normalmente, tudo o que estiver acima ou igual 00,50 é arredondado parao número inteiro seguinte. (…)”
“Assunto: Áudios
Enviado: Gestor de Projeto, sexta-feira, 16 de janeiro de 2009, 19:41(…) segue em anexo dois .mp3s: uma voz feminina e uma voz masculina. (…) Os
locutores/atores têm a capacidade de orientar a voz tendo em conta a finalidadede utilização da mesma. (…) Além das vozes que seguem em anexo, também
envio

este

endereço onde

podem

escutaroutra voz

masculina:

http://www.proimagem.net/ftp/ZTC_B2.wmv”

A partilha de pontos de vista pretende transmitir uma perspetiva ou opinião
relativamente a uma situação ou problema, que poderá levar a tomadas de decisão
ou reflexão dos elementos da equipa multidisciplinar. Os pontos de vista, podem
ainda complementar uma sugestão ou clarificação (categorias que serão descritas
na dimensão “Colaboração e Cooperação”) relativamente a uma solução de projetoe como se depreende das referências que se seguem:“Assunto: Re: Ilustrações para animações da Fase II - Cenário 6
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa, terçafeira, 14 de outubro de 2008, 15:42(…) Tal possibilitará uma exploração didática mais intercultural.”“Assunto: Re: Pegada Ecológica
Enviado: Perito em Didática das Ciências, sexta-feira, 23 de janeiro de 2009,16:28(…) É claro que não é só a pegada que nos pode levantar problemas de rigor;
aproveito para relembrar que tal como está o software ainda não se percebe, na
carta de planificação, qual a unidade usada - legenda (nº de barris)! (…)”

141

Capítulo IV – Apresentação e Discussão de Resultados

Uma outra categoria definida na dimensão comunicação corresponde acompromissos (21 referências) (unicamente nos fóruns, objeto da nossa análise,tendo existido comprometimento para a execução de tarefas através de e-mails,
nas reuniões presenciais, chats ou telefone). Os compromissos, quando
negociados, são um mecanismo que pode promover satisfação (visto potenciar acontribuição dos diferentes elementos da equipa). Contudo, pode não ser
otimizado dado que cada que os elementos podem não conseguir alcançar todos osseus objetivos. Considera-se ter sido importante, para a promoção do trabalho
colaborativo e cooperativo, que os elementos da equipa multidisciplinar
assumissem compromissos de forma autónoma, uma vez que permitiu identificar a
responsabilidade dos elementos nas tarefas a realizar, como evidenciam as
seguintes referências:“Assunto: Re: Planisfério
Enviado: Designer-A, quarta-feira, 7 de maio de 2008, 21:35(…)vamos tratar desse pormenor da colocação dos nomes nos continentes e
oceanos.(…)”“Assunto: Dossier de conceção do site de apoio ao Courseware Sere
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa,
quinta-feira, 8 de maio de 2008, 16:39(…)Tal como prometido, aqui segue o primeiro esboço do dossier de conceção
do site de apoio ao Courseware Sere.(…)”

Algumasreferências

indiciam

compromissos

alongadosnotempo,

compromissos sem escala temporal (16 referências), não sendo exato quandoo(s) elemento(s) da equipa multidisciplinar irá(ão) executar a tarefa. Outros, os
compromissos a uma escala temporal (5 referências), têm uma escalatemporal bem determinada. Apesar do total de referências, a seguir apresentados,
exemplificarem compromissos definidos a uma escala temporal, dois deles (1ª e 2ªreferências) utilizam termos como “vou tentar” ou “espero”, transmitindo assim
alguma incerteza quanto à sua concretização.
“Assunto: Re: Dossiers de Exploração Didática - FASE 1
Enviado: Perito em Didática das Ciências, domingo, 26 de outubro de 2008,
19:48

142

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo(…) Vou tentar durante a próxima semana ler as outras fases.(…)”“Assunto: Re: Textos para Áudios
Enviado: Perito em Didática das Ciências, quinta-feira, 15 de janeiro de 2009,
13:44(…) Espero no fim-de-semana ver a última versão dos Guiões Didáticos.(…)”“Assunto: Re: Glóssário
Enviado: Perito em Didática das Ciências, quarta-feira, 21 de janeiro de 2009,17:15(…) e que amanhã levarei os da fase II.(…)”“Assunto: Re: Glossário
Enviado: Gestor de Projeto, quarta-feira, 21 de janeiro de 2009, 18:08(…) Amanhã procuro uma definição mais apropriada para o Dióxido de Carbono
e acrescento... "trata de um dos componentes / elementos constituintes do ar.
(…)”“Assunto: Re: Pegada Ecológica
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa, sextafeira, 23 de janeiro de 2009, 14:39(…) Na 2ªfeira tentarei recolher alguma bibliografia. A Investigadora em
Didática das Ciências também irá fazer isso. (…)”

Nas referências abaixo (outros exemplos de compromissos sem escalatemporal), os elementos assumem compromissos, mas não definem uma datapara a execução e conclusão dos mesmos. Por exemplo, na 1ª referência, autilização da palavra “logo” poderá indicar que será com alguma brevidade,podendo ser no mesmo dia, após o lançamento do Courseware Sere, passadas
algumas horas ou alguns dias.
“Assumido: Re: Pegada Ecológica
Enviado: Perito em Didática das Ciências, sexta-feira, 23 de janeiro de 2009,
16:28(…) Eu próprio tratarei disto logo depois do lançamento, se possível com todo ovosso apoio e colaboração.(…)”“Assumido: Re: Embalagem

143

Capítulo IV – Apresentação e Discussão de Resultados

Enviado: Investigador em Didática das Ciências, quarta-feira, 17 de dezembrode 2008, 12:19(…) Vou enviar, ainda, as alterações ao guião do aluno (fase I). (…)”

Também é evidenciado nos compromissos que, a realização do mesmo
implica a execução de tarefas por parte de outros elementos (categoriainterdependência, apresentada com mais detalhe na dimensão “Coordenação”).
Por exemplo, na referência seguinte os Designers-Ilustradores (A e B) tinham que
terminar a ilustração de alguns ecrãs de forma que o Perito em Didática dasCiências pudesse efetuar a verificação e validação dos Dossiers de Exploração
Didática da Fase 1 – Florestas.
“Assunto: Re: Dossiers de Exploração Didáctica - FASE 1
Enviado: Perito em Didática das Ciências, domingo, 18 de janeiro de 2009,
22:10(…) Sobre o guião do professor (ficheiro pdf) terei de ver com todos os ecrãs,mesmo os que faltam! (…)”

O assumir compromissos deverá ou poderá estar associado à definição depapéis, numa fase inicial do processo de desenvolvimento. A não definição destes
papéis/responsabilidades pode levar à não identificação, por parte dos elementos,
das suas responsabilidades na execução de tarefas e dificultar o envolvimento. É,
assim, importante estabelecer objetivos e incentivar o envolvimento e aparticipação no projeto. A motivação dos elementos de uma equipa, poderá
certamente trazer enormes benefícios ao projeto que se encontra em
desenvolvimento, constituindo os valores individuais um denominador comum detodos os “problemas das pessoas” (Miguel, 2003; Sommerville, 2007).
Como já se referiu, a falha de compromissos e o pouco envolvimento, conduziu
a que durante o processo de desenvolvimento o Designer-Ilustrador A e
Programador A fossem dispensados/substituídos do projeto. O DesignerIlustradorBdeucontinuidadeao

projeto,acumulandoospapéise

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

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Na próxima secção irá descrever-se e discutir-se a importância da dimensão
“Coordenação”. Esta dimensão efetua a ligação entre a dimensão “Comunicação” ea dimensão “Colaboração e Cooperação”, dado incluir aspetos como, entre outros,
a negociação/atribuição de tarefas ou a gestão de conflitos (ver secção 3.3.4)
4.2.3 Dimensão “Coordenação”
A dimensão “Coordenação” no modelo proposto abrange a execução de tarefas(única categoria desta dimensão) e está muito orientada para o trabalho realizado
pelo Gestor de Projeto ou elementos que assumam este papel (Figura 33). Segundo
Ribeiro (2007), as tarefas numa fase inicial envolvem, normalmente, a definição derequisitos e a caraterização do software, ou seja, definem o âmbito do trabalho adesenvolver em termos de dimensão e da complexidade.

Figura 33 – Categorias e Subcategorias/Indicadores da dimensão “Coordenação”

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 (dimensão analisada
com mais detalhe na secção seguinte). 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, queevolui durante o ciclo de vida do projeto, sendo flexível, e alterando com a
implementação de funcionalidades, respondendo a mudanças.

145

Capítulo IV – Apresentação e Discussão de Resultados

Ao longo do processo de desenvolvimento do courseware, a pré-articulação
permitiu, como sugerem (McChesney & Gallagher, 2004, pp., p. 486), 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

peloselementos

daequipamultidisciplinar, 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ã daescolha 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 owiki 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).(…)”

146

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo“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 oInvestigador em Didática das Ciências: Adaptar a tabela seguinte de forma quese 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 daequipa multidisciplinar. Nestas, era importante o envolvimento da maioria ou detodos elementos da equipa, numa articulação concertada e criativa, promovendo
assim o trabalho colaborativo. As seguintes referências são exemplos deste tipo desituaçõ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 amesma seja mais produtiva possível. (…)”

147

Capítulo IV – Apresentação e Discussão de Resultados

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 deinsistê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 dedesenvolvimento (ver Tabela 13).
Tabela 13 – Equipa Multidisciplinar vs. Mensagens de Pré-articulação, Interdependência e
Insistência
Equipa Multidisciplinar

Pré-articulação

Interdependência

Insistência

Designer-Ilustrador A

1

0

0

Designer-Ilustrador B

0

0

0

Gestor de Projeto

14

36

26

1

2

0

1

2

0

Perito em Didática das Ciências

1

6

2

Perita em Tecnologia Educativa

0

2

0

Programador A

0

0

0

Programador B

0

0

0

Total

18

48

28

Investigadora em Didática dasCiências
Investigadora em Didática dasCiências e Tecnologia Educativa

Uma caraterística da interdependência é a reciprocidade, o que significa que oselementos da equipa são mutuamente interdependentes (Molleman, et al., 2004).
A

subcategoriainterdependência

interdependência

direcionada

foi

dividida

em

dois

e

interdependência

indicadores:
geral.

Na

interdependência direcionada, os posts eram submetidos ao conhecimento de148

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

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 oselementos 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 aosEcrãs da Fase 2.(…)”

As mensagens de insistência (28 referências) podem ser uma repetição deuma 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 aque Designer-Ilustrador B pudesse continuar a ilustração dos cenários (exemplo deinterdependência). O primeiro post, enviado a 2 de junho de 2008, é exatamente
149

Capítulo IV – Apresentação e Discussão de Resultados

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.
1ºecrã

2ºecrã

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 se150

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

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 terminarpaginaçã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, pordiferentes motivos: não se identificam como responsáveis pela realização da tarefa;
falta de disponibilidade por estarem a realizar outras tarefas; ou considerarem queo seu contributo não é necessário.
O excesso de posts com atribuição de tarefas, a alteração de soluções deprojeto, entre outros, pode levar ao surgimento de conflitos. Esta subcategoria
definida dentro da categoria tarefas, está dividida em quatro indicadores:
competição,desorientação,problemasdehierarquiaeadifusão

daresponsabilidade (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 o151

Capítulo IV – Apresentação e Discussão de Resultados

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 nocourseware) 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 ecompetiçã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 econtrolado 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).
4.2.4 Dimensão “Colaboração e Cooperação”
Assente nas definições de “colaboração e cooperação” apresentadas na
subsecção

3.3.4,

que

serviramdeorientação,foi

possível

identificar

simultaneamente tarefas realizadas colaborativamente e cooperativamente no
desenvolvimento do courseware. Nesta dimensão, os elementos da equipa
multidisciplinar discutem as soluções de projeto apresentadas em diferentes
formatos: protótipos programados, documentos e protótipos em imagem. A
análise desta dimensão assenta essencialmente nas categorias apresentadas na
Figura 34.

152

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 34 – Categorias e Subcategorias/Indicadores da dimensão “Colaboração e Cooperação”

Na dimensão “colaboração e cooperação” a interação proporcionada pelo
fluxo de perguntas e respostas, surgiu pelo facto de um elemento não ter
compreendido (elementos de perceção) determinada situação ou problema
relativamente a uma solução de projeto. Quanto à categoria perguntas (76referências) dividiu-se a mesma em duas subcategorias face ao tipo de resposta:
perguntas ativas (60 referências) e perguntas inertes (17 referências).
Na subcategoria perguntas ativas, a resposta dos elementos da equipa
multidisciplinar às perguntas ajudou a esclarecer situações ou problemas
específicos e a melhorar as soluções de projeto apresentadas. A pergunta
apresentada na referência seguinte foi formulada com base na solução de projetopara um dos seis ecrãs da 1ª atividade da Fase II - Florestas (Figura 35).

Figura 35 – Protótipo de um dos ecrãs da Fase II - Florestas.

“Assunto: Re: Ilustrações para animações da Fase II - Cenário 3
Enviado: Perito em Didática das Ciências, quarta-feira, 8 de outubro de 2008,
23:22(…) Não era possível colocar mais uns animais e outros elementos de modo aaumentar a diversidade animal e vegetal? (…)”
153

Capítulo IV – Apresentação e Discussão de Resultados

Não foi identificado nos posts uma resposta textual à pergunta presente na
referência anterior. Porém, como evidenciado seguidamente, o protótipo
apresentado na Figura 36 (protótipo em imagem) “sofreu” melhorias tendo por
base

esta

pergunta.

Relativamenteàdiversidade

vegetal,foram

aumentadas/acrescentadas as plantações de papoilas e malmequeres (número 1 e
2, Figura 36). A diversidade animal não é visualmente detetável, porquecomparando os dois protótipos (Figura 35 e 36) apenas são visíveis o mesmo
número de animais (5 vacas). Contudo, no protótipo programado, o áudio
ambiente (sonoplastia) contempla sons de outros animais, normalmente habituais
nas zonas tropicais, como ilustra o cenário das Figuras 35 e 36 que representa umaregião da América do Sul, que se definiu como sendo do Brasil.

Figura 36 – Protótipo alterado de um dos ecrãs da Fase II – Florestas, tendo por base uma
pergunta ativa.

A referência seguinte, também é um exemplo de pergunta ativa. A resposta à
pergunta foi considerada no protótipo programado (Figura 37), relativamente àsolução de projeto designada como Pegada Ecológica. Numa primeira versão desteecrã não existia a opção “Sem Aquecimento”.
“Assunto: Re: Pegada Ecológica
Enviado: Gestor de Projeto, sexta-feira, 26 de dezembro de 2008, 15:16(…) Se uma casa não tiver aquecimento qual é a opção que devo escolher? (…)”

154

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 37 – Protótipo programado do 3º Ecrã, da Fase I - Petróleo

As referências seguintes evidenciam uma pergunta ativa efetuada pelo
Perito em Didática das Ciências e uma resposta textual formulada pelo Gestor de
Projeto. Como descrito na secção 3.2, o Courseware Sere, além da versão dosoftware em CD-ROM, possui uma versão online. Após a utilização da versão
online, surgiu a seguinte pergunta:“Assunto: Re: SOFTWARE CD-ROM, VERIFICAÇÃO
Enviado: Perito em Didática das Ciências, sábado, 7 de fevereiro de 2009,
19:13(…) Antes de mais, no meu PC portátil (que não é assim tão lento), com ointernet explorer demorei cerca de 6 min a entrar no software. (…) Vai sersempre assim? (…)”

A resposta dada pelo Gestor de Projeto, teve como finalidade esclarecer ou
explicar os possíveis motivos para a situação ou problema técnico. Esta pergunta,
face às duas supracitadas tem um cariz mais técnico, não estando associado
diretamente a uma solução de projeto, porém, convém ressalvar que além da155

Capítulo IV – Apresentação e Discussão de Resultados

explicação apresentada pelo Gestor de Projeto poderão existir outras respostas
para

esta

questão,

como

por

exemplo,problemas

associadas

à

codificação/programação.
“Assunto: Re: SOFTWARE CD-ROM, VERIFICAÇÃO
Enviado: Gestor de Projeto, domingo, 8 de fevereiro de 2009, 13:39(…) A rapidez de visualização do software online deve-se na maioria das vezes àvelocidade da ligação à Internet. (…) Excetuando os utilizadores que têm linhas
dedicadas (linha de acesso à internet unicamente para aquele utilizador, ou seja,
uma autoestrada privada), a maioria dos utilizadores "sofre" com os picosdiários de utilização. (…)”

A ocorrência acima referida, pelo Perito da Didática das Ciências, foi
esclarecida pelo Gestor de Projeto em menos de 24 horas e durante o fim-desemana. O facto de esta ocorrência ter sido submetida através de um post,
acessível portanto a todos os elementos, que tivessem tentado aceder à versão
online do software, poderia ter desencadeado mensagens de concordância ou
discordância, caso a mesma situação tivesse sido identificada. Refira-se, noentanto, que a situação ficou esclarecida com estes dois posts, levando a concluir
tratar-se de um problema pontual. Por outro lado, este tipo de pergunta poderia
ter sido respondida pelo Programador B (visto que o Programador A já não fazia
parte do projeto), partindo do pressuposto que este, possuía conhecimentos
técnicos para o mesmo.
As perguntas inertes caraterizam-se por não contribuírem para melhorarem
as soluções de projeto e, consequentemente, podem não ter obtido qualquer
resposta (ignoradas). A referência seguinte surgiu da discussão criada pelo Gestorde Projeto relativamente ao suporte em que deveria ser disponibilizado software,
online ou em CD-ROM. Nos 292 posts não foi identificada a resposta a esta
pergunta. Contudo, a questão foi discutida em sessões de trabalho presencial
tendo, a versão final do recurso, como descrito na secção 3.2, disponibilizado osoftware online (na plataforma de apoio) e em CD-ROM.
“Assunto: Re: Software on-line e/ou CDRom?
Enviado: Perito em Didática das Ciências, terça-feira, 11 de novembro de2008, 22:53

156

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo(…) Neste momento prefiro uma versão on-line, mesmo considerando que
existem alguns argumentos acima um pouco discutíveis (como a globalização) e
outros não referidos como a desvantagem de alguns pais limitarem os acessos à
net em casa (pelo menos enquanto estão sós). Em um futuro próximo alémdesta ter um CD, pelo menos, com uma versão Demo para as escolas.
E os outros membros da equipa o que pensam? (…)

Uma outra categoria pertencente à dimensão “colaboração e cooperação”é o feedback: concordância (49 referências) ou discordância (5 referências).
Na concordância um ou mais elementos concordam parcialmente ou totalmente
com uma sugestão ou solução de projeto. Nas referências seguintes, é evidente a
concordância relativamente a soluções de projeto apresentadas. Na 1ª referência aafirmação de concordância, relativamente aos desenhos apresentados de um dosecrãs da Fase II – Florestas, inclui uma ressalva. Esta mensagem, essencialmente,
direcionada para o Designer-Ilustrador A e o Designer-Ilustrador B, pode suscitar
diferentes significados e interpretações aquando da leitura da expressão “embora
um pouco simplistas”. Os Designers-Ilustradores (A e B) poderiam assumir ocompromisso de melhorar o protótipo apresentado ou questionar/solicitar
clarificações relativamente ao que se refere o Perito em Didática das Ciências com
esta expressão. Pela verificação dos protótipos, excetuando a inclusão de alguns
elementos gráficos, a solução de projeto apresentada manteve-se igual.
“Assunto: Re: Ilustrações para animações da Fase II - Cenário 3
Enviado: Perito em Didática das Ciências, quarta-feira, 8 de outubro de 2008,
23:22(…) Os desenhos estão excelentes embora um pouco simplistas. (…)”
“Assunto: Re: Biblioteca SERe
Enviado: Investigadora em Didática das Ciências e Tecnologia Educativa,
terça-feira, 9 de dezembro de 2008, 13:37
Penso que está bem para uma primeira versão. (…)”

Na referência seguinte o Perito em Didática das Ciências concorda com o
Gestor do Projeto quanto este afirma que não deveriam existir ecrãs apenas com

157

Capítulo IV – Apresentação e Discussão de Resultados

links, estando disponível um espaço na Mediateca 18 (online) para inserir os
mesmos e, caso os utilizadores usem a versão em CD-ROM (por exemplo, por falta
de acesso à internet), os links não “funcionariam”, podendo transmitir aperceção, que se trata de um erro do software.
“Assunto: Re: Florestas - último ecrãEnviado: Perito em Didática das Ciências, segunda-feira, 12 de janeiro de2009, 15:43(…) Concordo com a proposta. (…) De facto, a maioria dos utilizadores iria
pensar, com o CD-ROM, que se tratava de um erro. (…)”

As

referências

seguintes

evidenciam,noconteúdo,expressões

deconcordância, sendo reforçadas com as palavras “parabéns” e “apoiado”.
“Assunto: Re: Embalagem
Enviado: Investigadora em Didática das Ciências, quarta-feira, 17 de dezembrode 2008, 12:19(…) Gosto muito da capa do courseware. Parabéns!(…)“Assunto: Re: Embalagem
Enviado: Investigadora em Didática das Ciências e Tecnologia Educativa,
quinta-feira, 18 de dezembro de 2008, 11:08(…) Concordo com as sugestões da Perita em Tecnologia Educativa.
Apoiado!(…)

A discordância evidência situações onde os elementos apresentam
divergências podendo atrasar o desenvolvimento do projeto. Como se apresenta na
referência seguinte, o Perito em Didática das Ciências não concordava com aavaliação das personagens, na fase em curso, sugerindo que fosse realizada
aquando da disponibilização de uma versão beta do software.
“Assunto: Re: Personagens
Enviado: Perito em Didática das Ciências, quarta-feira, 23 de abril de 2008,
11:24

18 Disciplina moodle e complementar ao software que permite os utilizadores consultarem informação ouinteragirem entre si, para discutir e encontrar respostas em conjunto para as atividades propostas.

158

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo(…) Não vejo necessidade, para já de validar com crianças do 1º CEB. Penso que
poderemos decidir nós e depois, com uma versão beta testar tudo (e não só os
personagens). (…)”

Discordar sem apresentar um argumento ou uma proposta alternativa não foi
recorrente no desenrolar deste projeto (apenas 2 referências). Na 1ª referência quese segue, o Perito em Didática das Ciências discorda com a estrutura do glossário 19
porém não apresenta soluções alternativas ao mesmo.
“Assunto: Re: Pegada Ecológica
Enviado: Perito em Didática das Ciências - Sexta, 23 Janeiro 2009, 16:28“(…)Também o Glossário, por exemplo, tal como está não pode ficar!(…)”

Na 2ª referência o Designer-Ilustrador A discorda com as alterações que a
efetuar aos ecrãs da Fase II – Florestas. O post, referente à 2ª referência, surgiu
após uma reunião presencial em que equipa decidiu que, no ecrã referente àsenergias alternativas, Fase III 20, nos planisférios fosse retirada a imagem desombreado dos mesmos. Sendo o Designer-Ilustrador A um colaborador externo,
que trabalhava parcialmente no projeto, as alterações solicitadas implicavam um
esforço complementar. O “Abraço à Mudança” como designa Sommerville (2007)
quando se refere a um dos valores dos métodos ágeis, foi uma constante noprocesso de desenvolvimento do Courseware Sere, devido à indefinição evolatilidade dos requisitos (Toth, 2005). Porém nem sempre foi recetivo da partedos elementos da equipa multidisciplinar, como evidencia a referência seguinte:“Assunto: Re: Ecrãs Fase II
Enviado: Designer-Ilustrador A, domingo, 29 de junho de 2008, 19:11(…) Deu-me muito trabalho mesmo a definir as manchas e percebe-se MELHOR
através das manchas do que através de imagens/ícones. (…)”

19 O glossário proposto tinha como objetivo que, os utilizadores tivessem acesso às definições de alguns termos

utilizados no software e nos guiões de exploração didática.
20 A Fase III – Energias Alternativas, foi retirada da primeira versão do Courseware Sere, pelas limitações

temporais e objetivos delineados, ficando definido que a mesma seria desenvolvida posteriormente.

159

Capítulo IV – Apresentação e Discussão de Resultados

No Trabalho Colaborativo e Cooperativo Presencial eram essencialmenteorganizadas reuniões de trabalho, para a discussão e tomadas de decisão, para adefinição de objetivos e divisão de tarefas, como é evidente no exemplo de Ata deReunião apresentado no Anexo 4. Pelas características da equipa, em que amaioria

doselementos

estavamenvolvidos

parcialmenteedispersos

geograficamente (secção 4.2), foi frequente a realização de sessões de trabalho
presenciais sem estarem presentes todos os elementos da equipa multidisciplinar.
Considera-se que se tal tivesse acontecido poderiam ter ocorrido mais situações dealterações ao projeto que envolvesse o trabalho de elementos da equipa que não
estiveram presentes nas sessões de trabalho presenciais.
Um outra categoria que permite analisar o grau de envolvência dos elementos
da equipa multidisciplinar num projeto é a persistência (17 referências). Atravésda persistência os elementos da equipa multidisciplinar têm liberdade para tomar
decisões sobre os objetivos, os métodos de trabalho e os prazos de entrega (Evans& Fischer, 1992). A persistência permite aferir a iniciativa/autonomia de cada um
dos elementos, sem que lhes sejam delegadas tarefas. Na primeira referência, nãosendo uma responsabilidade do Gestor de Projeto, este apresenta um documento
relativo aos textos para áudio.
“Assunto: Re: Textos para Áudios
Enviado: Gestor de Projeto, segunda-feira, 15 de dezembro de 2008, 13:24
Textos_Totais_Audios_SERe_vers4.2_.doc
Boa tarde a todos, deixo ficar uma nova versão dos Textos para Áudio, pelo facto
de achar que alguns ainda estão demasiado longos. (…)”

Outro exemplo, diz respeito à Perita em Tecnologia Educativa que volta a
analisar o guião didático do professor, referente à Fase 2 – Florestas, sem
solicitação prévia.
“Assunto: Re: Guião Professor (Florestas)
Enviado: Perita em Tecnologia Educativa, quarta-feira, 4 de fevereiro de 2009,
18:45
Voltei a analisar o guião do prof.- fase 2 e entreguei as sugestões à Investigadoraem Didática das Ciências e Tecnologia Educativa (que fiz a lápis, uma vez que aversão final está em formato pdf).(…)”

160

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Na dimensão em análise, as mensagens de clarificação (80 referências) estão
associadas na sua maioria a protótipos em imagem ou documentos. Dos 56
protótipos em imagem e dos 70 documentos disponibilizados, 12 e 25
respetivamente são apoiados por mensagens de clarificação. Entende-se, que aclarificação de situações ou problemas associados a soluções de projeto, pode“orientar” ou ajudar a sua interpretação por parte dos elementos da equipa
multidisciplinar, como evidenciam as quatro referências seguintes:“Assunto: Ecrãs Fase II
Enviado: Gestor de Projeto, quarta-feira, 21 de maio de 2008, 11:11(…) O aluno escolhe uma região de 6 (seis), para visualizar uma animação eouvir uma breve descrição referente a essa região. (…) Como imagem de fundo
surge o ecrã 2 desta FASE, que servirá de enquadramento e de cenário. (…)”
“Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, domingo, 25 de maio de 2008, 18:15(…) Após escolhermos no Planisfério, por exemplo, o cenário referente a África,
surge um novo ecrã com uma ilustração referente a este continente. (…) Sobre
esta ilustração surgirá uma janela sobreposta, onde irá passar a animação
descrita no StoryBoard. (…) O utilizador poderá escutar e ler uma descrição
relativa à mesma, pode parar (stop), efetuar pause e recuar na animação. (…) Naopção áudio o utilizador tem a possibilidade de não querer ouvir o mesmo.(…)“Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, segunda-feira, 2 de junho de 2008, 15:35(…) Passo a descrever as imagens abaixo apresentadas.
1º ecrã

2º ecrã

161

Capítulo IV – Apresentação e Discussão de Resultados(…) Quando o utilizador escolhe no Planisfério África, surge o 1º ecrã, que
passará em 3 segundos para o 2º ecrã.(…)”“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(…) A ideia é o explorador poder clicar em elementos do cenário e obter
informação sobre os mesmos. (…) Sempre que clicar em determinado elemento
do cenário surge a possibilidade do explorador poder visualizar esse elemento
através da imagem representada por uns binóculos.(…)”

A última clarificação foi pelo Designer-Ilustrador A, tendo em vista desenhar
as animações do cenário 1:“Assunto: Re: Ecrãs Fase II
Enviado: Designer-Ilustrador A, terça-feira, 3 de junho de 2008, 03:05(…) Aguardo esclarecimentos para poder desenhar as animações. (…)”

Outras clarificações fundamentaram-se numa situação ou problema técnico,de forma a evitar que os elementos da equipa multidisciplinar tecessem
observações sobre o mesmo e se focassem nos protótipos da solução de projetoainda em desenvolvimento:“Assunto: Re: Ilustrações para animações da Fase II - Cenário 5
Enviado: Gestor de Projeto, quinta-feira, 16 de outubro de 2008, 14:44(…) O cenário a converter para pdf ficou com umas partes brancas, contudo dápara transmitir o que se pretende. (…)”
“Assunto: Dossiers de Exploração Didática - FASE 2
Enviado: Gestor de Projeto, quarta-feira, 22 de outubro de 2008, 11:13

162

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo(…) Os itálicos e negritos não surgem, porque obrigava a converter todo odocumento para curvas (termo técnico que se utiliza, para quando se envia
material para impressão e que garante que não existe alteração de textos,
imagens, …) (…)”.
“Assunto: Re: Dossiers de Exploração Didática Aluno - Fase 1
Enviado: Gestor de Projeto, quinta, 29 de janeiro de 2009, 11:38
Bom dia, a versão que segue em anexo ainda não foi totalmente formatada (falta
aumentar tabelas,...).(…)”

Ocorreram ainda clarificações técnicas repetidas, de forma a reforçar ou
relembrar determinado aspeto, como foi o caso da clarificação disponibilizada a 22
de outubro de 2008, que se repetiu posteriormente.
“Assunto: Re: Dossiers de Exploração Didática Aluno - Fase 1
Enviado: Gestor de Projeto, segunda-feira, 2 de fevereiro de 2009, 16:08(…)Os itálicos e negritos não surgem, porque obrigava a converter todo odocumento para curvas (termo técnico que se utiliza, para quando se envia
material para impressão e que garante que não existe alteração de textos,
imagens, …).(…)”

Ainda no que respeita a clarificações técnicas, estas também se verificaram
após validação e verificação, sugestão, discordância ou pergunta.
“Assunto: Re: Ecrãs (interfaces)
Enviado: Programador A, quinta-feira, 5 de junho de 2008, 20:41(…)Em relação à deformação das imagens, estão assim nesta fase porque foi
apenas para teste.(…) Eu não mexi nos tons de verde. Terei de ver se foi na
passagem do vetorial para imagem.(…)”

A discussão do desenvolvimento de protótipos e documentos, para se alcançaro que se pretendia em cada solução de projeto, através das sugestões dos
elementos da equipa multidisciplinar, constitui um fator primordial para se
garantir a qualidade final de um software educativo. Para compreender melhor
esta

categoria

éapresentadoum

episódio(interações

decorrentes

dodesenvolvimento do 1º ecrã da Fase I - Petróleo), em que se evidencia a negrito nos
posts as referências relacionadas com esta categoria. Pretende-se assim, analisar
163

Capítulo IV – Apresentação e Discussão de Resultados

em que medida a interação entre os elementos da equipa multidisciplinar permitiu
melhorar as soluções de projeto. A escolha deste episódio prende-se com a suariqueza e transversalidade, não apenas relativamente à categoria sugestões, masa todas as categorias e subcategorias/indicadores apresentados nas trêsdimensões.
- Episódio: Interações ocorridas no desenvolvimento do 1º Ecrã, daFase I – Petróleo.
O primeiro post submetido tinha como anexo dois ecrãs. Porém, enquadrado
neste episódio, apenas é apresentado o 1º ecrã e respetivo protótipo inicial (Figura37). Neste primeiro post pode compreender-se as dimensões abordadas e quais as
categorias que a mesma abrange.
“Assunto: Re: Ecrãs Fase I
Enviado: Gestor de Projeto, segunda-feira, 23 de junho de 2008, 02:15
Fase1_Ecra6_7_vers1_.pdf [Protótipo em imagem]
Boa noite, envio em anexo dois novos ecrãs para serem validados [Partilha deInformação].
No ecrã que está designado como número 6, é necessário verificar o que se deve
retirar ou inserir [Interdependência].
O ícone referente à Indústria Petroquímica vai ser alterado ou desaparecer, poisé difícil apenas com um ícone associar tudo o que está descrito na legenda.
[Clarificação] (…)”

A mensagem de clarificação, que se pode ler no post, apesar de explicar alguns
aspetos do primeiro protótipo do 1º Ecrã, da Fase I - Petróleo (Figura 38), não secoadunava com o pretendido como solução de projeto. Contudo, permitiu, que oselementos da equipa multidisciplinar discutissem novas soluções de projeto.

164

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 38 – Primeiro protótipo do 1º Ecrã, da Fase I - Petróleo

Não foi recorrente surgirem problemas técnicos, como evidencia a referência
seguinte. Porém, a resposta/resolução célere dos mesmos, permitir que oselementos continuem empenhados dado contributos.
“Assunto: Re: Ecrãs Fase I
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa,
segunda-feira, 23 de junho de 2008, 12:10
olá. Não consigo abrir os pdf. [Partilha de Informação]”O episódio reflete-se algo que foi recorrente em todo o projeto e que já foi
mencionado, ou seja, a pouca ou nenhuma participação por parte dos elementos
com competências técnicas (Designers-Ilustradores e Programadores). Considerase que estes elementos, durante todo o processo de desenvolvimento do
Courseware Sere, desenvolveram mais tarefas de forma cooperativa (demonstrada
através dos protótipos desenvolvidos) do que colaborativa (através da discussão
dos protótipos apresentados).

165

Capítulo IV – Apresentação e Discussão de Resultados

Os protótipos apresentados nas Figuras 39 e 40 demonstram alguma
persistência

por

parte

dos

Designers-Ilustradores,

desenvolvendo

dois

protótipos mesmo sem feedback por parte dos restantes elementos da equipa.
“Assunto: Aplicações do Petróleo
Enviado: Gestor de Projeto, terça-feira, 15 de julho de 2008, 14:59
Boa tarde, coloco em anexo a ilustração da cidade que representará a aplicação
do petróleo [Partilha de Informação].
Apesar desta ser a primeira versão de uma cidade, a mesma já está a sofrer
melhorias [Partilha de Informação].
Um abraço”

Figura 39 – Segundo protótipo do 1º Ecrã, da Fase I – Petróleo

O protótipo representado na Figura 38 é constituído por diferentes elementos
gráficos. Normalmente, nos protótipos iniciais foram criados e desenvolvidos
elementos gráficos que, muitas vezes, parecem não ser adequados ou apropriados,mas posteriormente podiam ser inseridos nas soluções de projeto apresentadas.
Exemplo disso, são os pictogramas que representam os usos do petróleo,desenvolvidos no primeiro protótipo (Figura 38) e que surgem no terceiro
166

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

protótipo (Figura 40), no quarto protótipo (Figura 41) e no quinto protótipo
(Figura 42).

Figura 40 – Terceiro protótipo do 1º Ecrã, da Fase I, Petróleo

Tendo por base o segundo e terceiro protótipos, um dos elementos da equipa
multidisciplinar, disponibiliza uma primeira sugestão. Realça-se que todas assugestões apresentadas no post submetido pelo Perito em Didática das Ciências,
foram desenvolvidas e incrementadas. Além disso, os Designers-Ilustradores
acrescentaram mais elementos gráficos.
“Assunto: Re: Aplicações do Petróleo
Enviado: Perito em Didática das Ciências, sexta-feira, 25-7-08, 16:38
Olá! Como 1º esboço parece-me globalmente bem e coerente com o designusado nos outros cenários [Concordância].
Aconselho mesmo assim que os barris sejam mais cilíndricos (número 1,
figura 41) e o avião passe no lado inferior esquerdo (número 2, figura 41)(menos denso) e desta forma não tape a chaminé! [Sugestão]O ideal seria também incluir uma refinaria (número 5, figura 41)[Sugestão].
É possível? [Pergunta Ativa]
Continuação de bom trabalho”

167

Capítulo IV – Apresentação e Discussão de Resultados

Para melhorar graficamente o cenário, foi acrescentada mais uma fábrica(número 3, Figura 41), não sendo necessário fazer alterações à posição do avião.
Pressupôs-se que a sugestão do Perito em Didática das Ciências passava pela
criança visualizar as emissões de gases poluentes provocadas pelas fábricas.

Figura 41 – Quarto protótipo do 1º Ecrã, da Fase I – Petróleo

Os

protótiposem

imagemquandonão

acompanhados

por

uma

clarificação/descrição, que se considerou muitas vezes substituível pela
apresentação de protótipos programados, pode levar a que alguns elementos nãocompreendam

como

os

elementos

gráficos(texto,áudio,

imagemeanimações/vídeos) em determinado ecrã irão funcionar quando programados. As
referências seguintes ilustram esta situação.
“Assunto: Re: Aplicações do Petróleo
Enviado: Gestor de Projeto, segunda-feira, 8 de setembro de 2008, 11:32
Bom dia a todos, segue em anexo a segunda versão da cidade que representará aaplicação do petróleo. [Partilha de Informação]A equipa que está a desenvolver a programação, está com um ritmo muito
elevado. [Partilha de Informação]Por isso quanto mais depressa existir feedback, melhor. [Ponto de Vista]
Um abraço”

168

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

O post seguinte, submetido pelo Investigador em Didática das Ciências e
Tecnologia Educativa, apesar de não ter sido levado em consideração na sua
totalidade, “alavancou” alterações na solução de projeto (Figura 42). Foi assim,
reconhecido a partir das sugestões apresentadas, que o ecrã necessitava de sermais interativo.
“Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa,
segunda-feira, 8 de setembro de 2008, 11:47
Olá a todos.
Não podendo fazer uma apreciação muito profunda, aproveito para transmitir
que na minha opinião este esboço está bom do ponto de vista de design.
[Concordância]
Contudo, acho que está muito informativo/pictórico. [Ponto de Vista]
Sugestão: Pode-se criar uma sequência de cenários com o explorador(que será o que o utilizador escolher) a percorrer a cidade num
transporte a escolher (carro, bicicleta... – isto poderá possibilitar
ver o consumo de carbono para cada alternativa...), [Sugestão]podendo este clicar nas diferentes ícones representativos dos usos do petróleo?
[Pergunta Ativa]
Penso que dará mais interatividade ao ecrã, certo? [Pergunto Ativa]
Saudações.”Na sequência do post anterior, a maioria das sugestões apresentadas no post
seguinte foram implementadas na solução de projeto apresentada na Figura 42.
“Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática das Ciências, segunda-feira, 15 de setembrode 2008, 09:40
Bom dia a todos,
Estive a comparar as duas propostas e considero a segunda bastante melhor.
[Concordância]
Gostaria de evidenciar que a farmácia, que está representada pela utilização dederivados do petróleo em muitos dos medicamentos - e inclusivamente nas suas
embalagens [Partilha de Informação] - deveria ter, como nos outros casos, um
símbolo associado. [Sugestão]Também seria interessante podermos ver outras utilizações que são
quotidianas e que têm grande impacte no utilizador (ex. roupas,
plásticos, brinquedos, acessórios, cosméticos,...). [Sugestão]169

Capítulo IV – Apresentação e Discussão de Resultados

Sugestão: Seria possível fazer, por exemplo, um corte numa das casas e mostrar,
no interior, os usos acima referidos, e muitos outros que se podem associar aos
nossos gestos diários? [Pergunta Ativa]
Podíamos mostrar a casa por divisões e, a cada uso, associar um
símbolo (como já está nas outras situações) (número 7, Figura 42).
[Sugestão]Fica a sugestão.
Também concordo com a sugestão da Investigador em Didática das Ciências e
Tecnologia Educativa. [Concordância]
Bom trabalho a todos!”

O post seguinte reforça a informação inserida no post anterior, através daconcordância, persistindo com uma sugestão já apresentada pelo mesmo elemento
relativamente à interação entre o utilizador e o ecrã.
“Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática das Ciências e Tecnologia Educativa,
quinta-feira, 2 de outubro de 2008, 15:41
olá. Concordo plenamente com a opinião da Investigador em Didática dasCiências relativamente ao corte da casa. [Concordância]
Podemos colocar, mais uma vez, o explorador a "viajar" pela casa
descodificando os objetos que derivam do petróleo. [Sugestão]Saudações.”A Figura 42 apresenta uma sequência de imagens, de forma a simular como
surgiu a casa no ecrã for programado. Esta sequência de imagens, complementa aclarificação/descrição textual de forma que os elementos da equipa percebessem oque se pretendia.
“Assunto: Re: Aplicações do Petróleo
Enviado: Gestor de Projeto, quinta-feira, 2 de outubro de 2008, 16:04
Boa tarde, coloco em anexo uma versão da cidade (já com o parque infantil) e
com o corte da casa. [Partilha de Informação]Por favor feedback, relativamente aos elementos gráficos. [Interdependência]
Um abraço”

Com base na informação dada pela Investigadora em Didática das Ciências, os
símbolos que representavam as diferentes aplicações do petróleo foram
eliminados, sendo a informação representada quando os mesmos são acedidos
através das lupas (Figura 42).
170

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo“Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática das Ciências, sexta-feira, 3 de outubro de2008, 10:43
Bom dia,
Estive a ver as imagens para a exploração dos vários usos do petróleo. [Partilha
de Informação]Considero que estamos a avançar no bom caminho. [Ponto de Vista]
As imagens estão muito mais explícitas [Concordância] e são mais fáceis deinterpretar pelos utilizadores. [Ponto de Vista]
Temos, no entanto, de ser mais coerentes no uso de símbolos e dos seussignificados (por exemplo, os símbolos usados para assinalar a presença dopetróleo são os mesmos que assinalam o seu uso?) (número 6, Figura 41).
[Pergunta Ativa]
Por outro lado, seria interessante, na exploração da casa, os
utilizadores poderem relacionar o uso do petróleo e seus derivados
às tarefas quotidianas.” [Sugestão]Figura 42 – Quinto protótipo do 1º Ecrã, da Fase I – Petróleo

171

Capítulo IV – Apresentação e Discussão de Resultados

A Figura 43 apresenta o sexto protótipo do 1º ecrã da Fase I - Petróleo. O
cenário sofreu uma transformação resultante da necessidade de o utilizador podernavegar pelo ecrã e com situações do seu quotidiano, que levem à reflexão.

Figura 43 – Sexto protótipo do 1º Ecrã, da Fase I - Petróleo

A diferença entre os protótipos representados na Figura 43 e na Figura 44 estána eliminação da representação das camadas que representam a crosta terrestre.
Após a consulta a um perito da área de Geologia, esta decisão foi tomada, de formaa não induzir os utilizadores em conceitos científicos menos corretos. Esta ação é
um exemplo concreto de que no decorrer do processo de desenvolvimento surgem
tarefas não planeadas (por exemplo, consulta informal a um perito), sendo a sua
execução essencial para a qualidade do projeto (McChesney & Gallagher, 2004).
O acima descrito, reflete a importância deste tipo de recursos ser submetida
avaliação externa de forma a reduzir falhas, muitas vezes, não detetadas pela
“limitação”

dascompetências

dos

elementos que constituem aequipamultidisciplinar.
As figuras 44 e 45 apresentam a versão programada do ecrã. O utilizador ao
clicar nas lupas tem acesso a informação textual ou auditiva, o que permite que osoftware seja acessível a utilizadores com Necessidades Educativas Especiais.

Figura 44 – Versão final do 1º Ecrã, da Fase I - Petróleo

172

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Figura 45 – Versão programada do 1º Ecrã, da Fase I – Petróleo

Do exposto pode inferir-se que as soluções de projeto quando partilhadas e
discutidas, tendo por base protótipos ou documentos, geram novas soluções deprojeto. Sendo a Metodologia Híbrida de Desenvolvimento Centrado no Utilizador,um processo iterativo e incremental, após cada iteração, a nova solução de projeto
foi disponibilizada já com o incremento resultante da última iteração, caso amesma tenha sido validada pelos elementos da equipa. Este procedimento, nem
sempre ocorreu de forma tão evidente e simplificada. Para tal contribuíram vários
fatores, tais como: i) sugestões tecnicamente impossíveis de se desenvolver; ii)
sugestões difíceis de se perceber através de um protótipo de imagem, sendo
necessário apresentar um protótipo programado; iii) mensagens pouco claras doque se propõe ou sugere; iv) dificuldades de perceção sobre o que se pretende com
determinada sugestão.
O modelo 4C permitiu que a análise ao processo definido na Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador fosse realizada, tendo porbase as interações decorrentes nos fóruns disponibilizados na plataforma de apoio

173

Capítulo IV – Apresentação e Discussão de Resultados

ao projeto. A partir das referências ilustrados, pode referir-se que equipas com
diferentes backgrounds que se envolvam ativamente na partilha de informação, depontos de vista, na discussão de soluções de projeto, através de sugestões, na
concordância/discordância, na clarificação de situações ou problemas, na
colocação de perguntas, sendo persistentes e assumindo compromissos,
possibilitam que as soluções de projeto melhorem tecnicamente e didaticamente.
4.3SÍNTESE DO CAPÍTULO

Os resultados da avaliação do Courseware Sere permitiram aferir a qualidade
do recurso, quer tecnicamente quer didaticamente. Os inquéritos por questionário
aplicados a alunos do 2º Ciclo do ensino básico e professores dos 1º e 2º Ciclos doensino básico, assim como a avaliação efetuada por peritos externos, realçaram aimportância da 4ª Fase da Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador, identificada na norma ISO 9126, a Manutenção.
Por outro lado, a análise do processo, explorando o Modelo 4C, e tendo porbase o desenvolvimento do Courseware Sere permitiu identificar pontos fortes efragilidades da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador,sintetizados no capítulo seguinte. Sendo uma metodologia que tem como alicerces
pressupostos do Design Centrado no Utilizador, a pouca experiência dos
elementos da equipa multidisciplinar refletiu-se nos dados analisados.

174

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

5 CAPÍTULO V – CONCLUSÃO DO ESTUDO

Como descrito no capítulo I, o presente estudo foi desenvolvido em três fases.
Neste capítulo faz-se uma síntese conclusiva de cada uma das fases deinvestigação, bem como a apresentação de propostas de melhoria da Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador. Posteriormente, enumeramse limitações do estudo e, para finalizar, enunciam-se sugestões para trabalho
futuro, concretamente linhas de desenvolvimento e investigação de um novo
projeto.

175

Capítulo V - Conclusão do Estudo

5.1SÍNTESE CONCLUSIVA DA FASE 1 DE INVESTIGAÇÃO

A Fase 1 tinha como finalidade responder à questão de investigação “Quais os
princípios e procedimentos a integrar numa metodologia de desenvolvimento desoftware educativo?”. Para tal, na continuidade do estudo realizado por Guerra(2007) e na análise integrativa da literatura da especialidade, surgiu uma proposta
inicial da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador. No
decorrer do processo e com a implementação da Fase 2 e 3 de investigação, a
metodologia proposta foi “sofrendo” adaptações, tais como, a utilização de umgroupware, envolvimento dos alunos no processo de avaliação, alargamento daequipa multidisciplinar, alteração na forma de envolvimento dos professores bem
como o desenvolvimento de novos instrumentos de avaliação. Com a análise doprocesso de desenvolvimento (Fase 3 deste estudo) emergiram propostas demelhoria que são apresentadas na secção 5.4.
5.2

SÍNTESE CONCLUSIVA DA FASE 2 DE INVESTIGAÇÃO

A Fase 2 tinha como questão de investigação “Qual a perceção por parte dos
professores e alunos relativamente aos aspetos técnicos e didáticos?”. Tendo em
vista responder a esta questão, as perceções (positivas e negativas) de potenciais
futuros utilizadores do courseware desenvolvido, professores dos 1º e 2º Ciclos doensino básico e alunos do 2º Ciclo do ensino básico, recolhidas por inquérito porquestionário, foram sujeitas a análise estatística descritiva. Recolheram-se as
perceções relacionadas, principalmente, com aspetos de interação pensados para oCourseware Sere, tendo em conta as premissas do Design Centrado no Utilizador eda usabilidade de recursos didáticos informatizados (Costa, et al., 2010b; Costa, etal., 2009a; Guerra, 2007).
Além da usabilidade, nesta fase do projeto, foi dada importância a outros
critérios definidos na norma ISO 9126 (1999) - Software Quality Characteristics,
tais como, a funcionalidade, a fiabilidade e a eficiência, que permitiramaferir a qualidade do software desenvolvido, bem como a importância do papel daavaliação nos processos de desenvolvimento de software educativo. Os professores

176

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

e os alunos consideraram que a organização e apresentação da informação nosecrãs do software (interface/desenho das janelas) eram simples e de fácil uso. A
título de exemplo, realça-se o facto dos elementos gráficos que compõem osmenus, surgirem no mesmo local e desempenharem sempre as mesmas ações.
Após a disponibilização da 1ª versão do recurso, confirmam-se alguns
resultados já analisados por Guerra (2007) relativamente às perceções positivas e àadequação das atividades didáticas, tais como:•

Articulação curricular com outros níveis de ensino;•

Abordagens multi e transdisciplinares;•

Desenvolvimento de competências gerais dos alunos, contribuindo para oenvolvimento ativo dos mesmos, na execução das atividades didáticas,
respeitando diferentes ritmos de aprendizagem.

Os dados recolhidos na avaliação do recurso desenvolvido permitiram
melhorar o Courseware Sere tendo sido disponibilizada uma 2ª versão, nasequência da Fase 4 – Manutenção e Operação, da Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador. Salienta-se que a Fase II – Florestas,desta 2ª versão, foi validada cientificamente por um perito externo, tendo sido
necessário efetuar algumas alterações no software (versão online e em CD-ROM)
bem como no guião de exploração didática do professor e no guião de registos doaluno.
Verifica-se a concordância/o acordo com Nielsen (2003) quando refere que amaneira mais básica e útil de avaliação de um software é a realizada com
utilizadores finais (participantes representativos). A avaliação com recurso aos
inquéritos por questionário, apresentados na secção 3.3.1, providencia uma
medida clara e objetiva da visão do utilizador acerca da adequabilidade dosoftware às suas tarefas (Veenendaal, 1998), desde que concretizada de modo
contextualizado, em condições reais ou muito próximas do seu ambiente deutilização e com elementos representativos dos utilizadores finais a quem se177

Capítulo V - Conclusão do Estudo

destina. Foi fundamental a exploração didática deste recurso em contexto de salade aula, envolvendo professores e alunos, de forma a aferir a adequação do mesmo
ao contexto de ensino e aprendizagem (Ramos, et al., 2005).
5.3SÍNTESE CONCLUSIVA DA FASE 3 DE INVESTIGAÇÃO

A Fase 3 tinha como objetivo responder à questão de investigação “Quais os
pontos fortes e as fragilidades da Metodologia Híbrida de Desenvolvimento
Centrado no Utilizador aplicada ao desenvolvimento do Courseware Sere?”. Paratal, foi efetuada a análise de conteúdo dos dados recolhidos a partir das interações
online (fóruns). Na Tabela 14 apresenta-se uma síntese de pontos fortes e defragilidades, tendo por base as dimensões do modelo 4C.
Tabela 14 – Pontos Fortes e Fragilidades da Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador
Fragilidades

•

•
•
•
•

•

Autodisciplina não foi constante nem
uma prática de todos os elementos daequipa multidisciplinar;Ausência de comunicação;Reduzida participação por parte dos
Designers-Ilustradores (A e B) e
Programadores (A e B), talvez por lacunas
ao nível das competências sociais, falta deinteresse ou de disponibilidade;
Pouca experiência dos elementos daequipa multidisciplinar relativamente aos
métodos e pressupostos do Design
Centrado no Utilizador.

•
•

•

•

Pontos Fortes
Elementos com diferentes
backgrounds que possibilitaram um
trabalho mais criativo, minimizando
falhas técnicas e didáticas;
Envolvimento dos utilizadores (alunos
e professores do 1º e 2º Ciclos doensino básico) no processo deavaliação que permitiu a deteção deerros e, quando disponibilizada umaversão final do software, a verificação
da qualidade;
Envolvimento de peritos externos quecolmatou as limitações dos elementos
da equipa multidisciplinar;
Processo iterativo e incremental que
permitiu verificar o progresso de cadaversão apresentada (como se
exemplificou a partir do episódio
apresentado na secção 4.2.4);
A prototipagem que tornou visível osvários problemas técnicos e didáticos,
permitindo a sua resolução através doenvolvimento dos elementos daequipa multidisciplinar;
Utilização de inquéritos por
questionário que permitiu recolher
dados de forma célere.

178

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Pretende-se minimizar as fragilidades identificadas com propostas de melhoria
da Metodologia Híbrida de Desenvolvimento Centrado no Utilizador que serão
apresentadas na secção 5.4.
Tal como descrito na subsecção 2.3.1, um dos pressupostos do Design
Centrado no Utilizador prende-se com o desenvolvimento de software a partir daconstituição de equipas multidisciplinares, formada por elementos comcompetências a vários níveis (Facer & Williamson, 2004; Gulliksen, et al., 1999;
Mao, et al., 2001; Mao, Vredenburg, Smith, & Carey, 2005).
Reflete-se neste estudo aquilo que Guerra (2007, pp. 79) já tinha identificado
no seu estudo “o sucesso do trabalho em equipas multidisciplinares depende daforma como cada elemento se organiza, se relaciona e comunica entre si, devendo
haver um (ou mais) elemento(s) que assuma(m) o papel de liderança da equipa.
Nesta linha, considera-se que a diversidade de competências/funções dos vários
elementos da equipa multidisciplinar também pode ter criado fragilidades ao longo
doprocessodedesenvolvimento.

Estas

dificuldades

centraram-se,

fundamentalmente, ao nível da diferença de atitudes dos elementos da equipa,
bem como a falhas de comunicação.”O trabalho em equipas multidisciplinares pode criar diferentes envolvimentos.
Por exemplo, a empresa que desenvolveu o Courseware Sere, a Ludomedia,
pretende que o mesmo tenha custos de desenvolvimento reduzidos. Por outro lado,
um colaborador externo pode querer rentabilizar ao máximo a sua colaboração.
Estes aspetos devem ser ponderados de forma a garantir que as expetativas decada interveniente não sejam frustradas e o resultado final satisfaça o utilizador(Miguel, 2003). No entanto, a satisfação do utilizador final poderá ser colocada em
causa, caso não se consiga um equilíbrio entre a qualidade do produto (neste casoo software educativo), o prazo para o conceber e os custos associados.
Identifica-se na revisão da literatura (subsecção 2.3.1) e no desenvolvimento
do Courseware Sere a importância de se ter em consideração os pressupostos e
métodos do Design Centrado no Utilizador. De acordo com Abras, Maloney-

179

Capítulo V - Conclusão do Estudo

Krichmar & Preece (2004), duas das desvantagens do Design Centrado no
Utilizador são que os projetos necessitam de mais tempo para serem desenvolvidos
e consequentemente tornam-se mais dispendiosos. Por outro lado, Duim,
Andersson, & Sinnema (2007) afirmam que a fase mais dispendiosa do ciclo devida de um software é a de manutenção. Como descrito, o processo dedesenvolvimento do courseware foi moroso. Contudo, estando o recurso na 2ªversão, considera-se que, tal como referido por Shneiderman & Plaisant (2005,
pp., p.118), “User Centered Design methodologies leads to systems that generate
fewer problems during development and have lower maintenance costs over their
lifetime”.
Do survey sobre a integração do Design Centrado no Utilizador nas empresas,
realizado por Venturi & Trust (2004), afirmam estes autores que apenas as
grandes empresas integram o Design Centrado no Utilizador, todavia com
reduzida utilização por parte dos profissionais (apenas 1%). O processo dedesenvolvimento do Courseware Sere, reforça o que os mesmos autores afirmam, asaber, que o desenvolvimento de protótipos são uma das técnicas mais utilizadas(2004) e, quando avaliados pelos utilizadores finais, permitem detetar erros,
reduzindo assim o tempo de execução na fase de manutenção e respetivos custos(Sommerville, 2007).
Fazendo a analogia da Metodologia Híbrida de Desenvolvimento Centrado no
Utilizador (descrita secção 3.2) aos níveis definidos pelo Capability Maturity
Model, associa-se a mesma, ao nível 1 de maturidade, pelo que o sucesso dodesenvolvimento do Courseware Sere dependeu das capacidades e conhecimentos
tácitos de cada elemento da equipa multidisciplinar, não tendo sido definido desdeo início um processo, procedimentos e técnicas. Apesar de reconhecida a qualidade
do recurso desenvolvido, tendo como resultado um software que funciona e éconsiderado adequado para a faixa etária a que se destina e para potenciar as
aprendizagens que visa, foi excedido o orçamento e os prazos definidos para oprojeto. Esta situação, acabou por ser colmatada com o apoio de um sponsor, BP
Portugal, que investiu na produção e distribuição deste recurso.

180

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Como referido na subsecção 2.3.1., referente aos indicadores relativos àeficácia do Design Centrado Utilizador, os três indicadores mais citados são: asatisfação externa (cliente/utilizador), a maior facilidade de uso e o impacto nas
vendas (Jokela, 2004; Marcus, 2005; Vredenburg, et al., 2002). Após avaliação e
distribuição do Courseware Sere, identificamo-nos com os dois primeiros
indicadores. Porém, até ao final deste estudo e após dois anos de disponibilização
do recurso no mercado, o impacto das vendas não tem sido evidente.
Partindo do pressuposto de que todos os processos, nomeadamente dedesenvolvimento de software educativo, necessitam de práticas que levem à sua
melhoria contínua, antevê-se que a Metodologia Híbrida de Desenvolvimento
Centrado no Utilizador constitui uma solução possível para o desenvolvimento desoftware educativo. A metodologia foi utilizada para o desenvolvimento do
Courseware Sere cuja qualidade tem sido reconhecida, nomeadamente num
concurso nacional de produtos multimédia, dado ter sido um dos produtos
finalistas (Costa, et al., 2010c).
Na secção seguinte apresentam-se propostas de melhoria para a Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador, tendo como suporte os
resultados da análise do processo desenvolvimento baseada no modelo 4C (secção
4.2) integrando novos métodos do Design Centrado no Utilizador. Algumas das
propostas de melhoria passam pela integração de ferramentas, essencialmente na
fase inicial dos projetos tendo por base métodos do Design Centrado no Utilizador,tais como, a Identificação dos Stakeholders, a Análise do Contexto de Uso, aAnálise e Mapeamento de Tarefas e a criação de um Focus Groups (Bevan &Macleod, 1994; Kirakowski & Cierlik, 1999; M. Maguire, 2001; M. C. Maguire,
1998; Thomas & Bevan, 1995; Velsen, et al., 2008). Espera-se assim, que otrabalho colaborativo e cooperativo seja mais eficiente, que se consiga diminuir otempo despendido na realização das tarefas e por conseguinte reduzir o custo.

181

Capítulo V - Conclusão do Estudo

5.4

PROPOSTA DE MELHORIA DA METODOLOGIA HÍBRIDA DE
DESENVOLVIMENTO CENTRADO NO UTILIZADOR

Com vista à sua aplicação no desenvolvimento de novos recursos educativos e
com base na análise efetuada na secção 4.2 apresentam-se algumas propostas,
associadas essencialmente ao envolvimento do utilizador e à introdução de novos
métodos de Design Centrado no Utilizador, para a melhoria da Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador.
Dos pressupostos e dos métodos definidos pelo Design Centrado no Utilizador,
verifica-se que uma das propostas de melhoria a ser implementada passa por
envolver o utilizador não apenas no processo de avaliação (enquanto verificador),mas integrá-lo na equipa, como informador ou codesigner (ver subsecções 2.3.2 e
2.3.3). Sendo o Design Iterativo um dos métodos do Design Centrado no
Utilizador mais importantes e a satisfação dos utilizadores a medida mais eficaz(Mao, et al., 2001, 2005) é reforçada, assim, a importância de envolver o utilizador
não apenas na fase de avaliação. Considera-se, contudo, que a sua integração
deverá ser efetuada apenas em algumas fases do processo, tal como defendem os
autores do We!Design (Triantafyllakos, et al., 2008), que se referem seguidamente.
• Envolvimento do Utilizador
Identificou-se na literatura e no desenvolvimento do Courseware Sere que oenvolvimento dos utilizadores no processo de desenvolvimento providencia uma
fonte de conhecimento sobre o contexto de utilização, as tarefas, e a forma como osutilizadores tendem a trabalhar posteriormente com o software. Realça-se,
contudo, que o grau de envolvimento do utilizador poderá variar consoante as
tarefas que estão a ser realizadas. Esta forma de envolvimento normalmente édesignada como Design Participativo. Como referido, nesta metodologia os
utilizadores finais passam de um papel menos interventivo, como o deverificadores (testers), tal como sucedeu no Courseware Sere, para papéis maisinterventivos, como o de informadores ou codesigners (Nesset & Large, 2004),
sendo encarados como membros da equipa multidisciplinar (Preece, et al., 1994).
Os novos métodos do Design Centrado no Utilizador, que se pretende integrar na

182

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, contemplam a
integração do utilizador nas fases iniciais do processo de desenvolvimento.
• Introdução de novos métodos do Design Centrado no Utilizador
Com o indicado anteriormente e tendo por base o estudo apresentado por
Martin Maguire “Methods to support human-centred design” (2001), conclui-seque a Metodologia Híbrida de Desenvolvimento Centrado no Utilizador na fase da
Análise e Planeamento deve incorporar novos métodos do Design Centrado no
Utilizador (Figura 46).

Figura 46 – Métodos do Design Centrado no Utilizador

Na Tabela 15, são descritos os métodos do Design Centrado no Utilizador a
integrar e qual a abordagem ao método.

183

Capítulo V - Conclusão do Estudo

Tabela 15 – Proposta de novos métodos do Design Centrado no Utilizador (adaptado de Maguire(2001))
MétodoIdentificação eanálise de
stakeholders

Análise docontexto de uso(Bevan &Macleod, 1994;
Kirakowski &Cierlik, 1999; M.
C. Maguire, 1998;
Thomas & Bevan,
1995)

Focus groups

Descrição
Identificar todos os grupos de utilizadores (utilizadores finais, peritos,
responsáveis pela instalação e manutenção) e outras partes interessadas(aqueles que podem ter influência ou são afetados pelo software) incluindo
equipas de apoio, equipas comerciais e de marketing e diferentes clientes que
poderão adquirir o recurso. Este levantamento pode ser complementado com
uma análise do mercado. Nesta fase são atribuídos papéis e responsabilidades.
Abordagem ao método: reunião realizada com o gestor de projeto e
representantes dos utilizadores para discussão de papéis com maior detalhe.
Caraterização do grupo de utilizadores (competências e experiência,
conhecimento da tarefa, formação, qualificações, competências linguísticas,
capacidades físicas e cognitivas e atitudes e motivações), das tarefas (lista detarefas, objetivos, output, passos, frequência, importância, duração edependências) e do ambiente técnico, físico e organizacional (hardware,
software, rede de internet, caraterísticas das salas, objetivos organizacionais,
políticas de utilização das TIC, apoio técnico).
Abordagem ao método: reunião com representantes de cada grupo deutilizadores e representantes da equipa de projeto.
Grupo de discussão de potenciais utilizadores sobre o que pretendem que sejaconcebido no software.
Abordagem ao método: presencialmente ou através da plataforma decomunicação a distância, os utilizadores discutem os requisitos.

A seleção dos métodos para a “Identificação e análise de stakeholders” e a“Análise do contexto de uso”, propostos na Tabela 17, tem por base a análise doprocesso de desenvolvimento do Courseware Sere e a identificação de quais os
principais fatores de desmotivação dos profissionais de desenvolvimento desoftware. Desta forma, sendo as restrições associadas ao tempo e ao orçamento,
estipulado para os projetos, fatores de desmotivação (Baddoo & Hall, 2003) e
sabendo que, dos métodos mais relevantes, os “Estudos de campo” e as
“Entrevistas a utilizadores” necessitam de muito tempo para a sua aplicação ecomummente um maior investimento (Vredenburg, et al., 2002), optou-se por
escolher métodos que equilibrassem estes dois fatores.
Partindo do princípio que a melhoria da Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador será contínua, a necessidade deintrodução de outros métodos do Design Centrado no Utilizador, além dos
apresentados na Tabela 17, poderá ser uma realidade. Porém, este facto será um
desafio para as equipas multidisciplinares que utilizem a Metodologia Híbrida de184

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Desenvolvimento Centrado no Utilizador, dependendo das competências de cadaelemento.
Num próximo projeto, um fator importante seria o de garantir que, a um dos
elementos da equipa, fosse atribuída a responsabilidade/papel de “facilitador do
Design Centrado no Utilizador” no processo de desenvolvimento. O facilitador do
Design Centrado no Utilizador mediaria a relação entre os utilizadores e oselementos

daequipamultidisciplinar,

devendoterumbackgroundmultidisciplinar (por exemplo, perceber como os utilizadores interagem com osoftware educativo e perceber o contexto de uso) (Gulliksen, et al., 1999).
5.5

LIMITAÇÕES DE CARÁCTER INVESTIGATIVO

Este estudo esteve sujeito a limitações de caráter investigativo, de naturezainterna, e que tiveram influência no desenvolvimento do mesmo. Estas limitações,centraram-se, essencialmente, ao nível da metodologia de investigação adotada em
cada uma das fases de investigação.
- Fase 2: Avaliação do Recurso
Na fase 2 da investigação, uma das limitações foi o número reduzido derespostas dos “avaliadores externos”, professores dos 1º e 2º ciclos do ensino
básico, ao questionário de avaliação técnica e didática do Courseware Sere. Poroutro lado, relativamente à avaliação efetuada pelos alunos, o questionário apenas
foi aplicado a alunos do 2º ciclo do ensino básico. Por se tratar de uma amostra por
conveniência não nos é possível generalizar ao universo, permitindo, portanto,
apenas inferir de modo circunscrito mas não desprezável. (Hill & Hill, 2005).
Desta forma, apenas é aferida a adequação do software para alunos do 1º ciclo do
ensino básico através da avaliação efetuada pelos professores.
- Fase 3: Análise do Processo de Desenvolvimento
No que confere à fase 3 deste estudo, uma das limitações foi a aplicação da
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador, ter sido aplicada

185

Capítulo V - Conclusão do Estudo

apenas a um caso – o courseware que se desenvolveu no âmbito deste estudo –não permitindo assim uma análise aprofundada da adequação dos métodos,
técnicas e procedimentos que constituem o processo de desenvolvimento.
Para otimizar as vantagens de metodologias que tenham por base pressupostos
de Design Centrado no Utilizador seria necessário que a equipa multidisciplinar
tivesse experiência e conhecimento relativamente a estes pressupostos. A
Metodologia Híbrida de Desenvolvimento Centrado no Utilizador dependeu,
essencialmente, das competências dos elementos da equipa multidisciplinar. O
desenvolvimento do Courseware Sere, foi subordinado à capacidade de improviso
dos elementos da equipa, não sendo possível implementar alguns procedimentos
mais formais e rígidos, pelo que não beneficiaria do desempenho dos mesmos.
Inicialmente, encarámos como limitação o facto dos elementos da equipa
multidisciplinar

estarem

apenasdisponíveis

parcialmenteedispersos

geograficamente. Estes dois fatores, levaram à implementação de uma ferramenta
que promovesse o trabalho colaborativo (software colaborativo - groupware) paraequipas dispersas geograficamente e que executam as tarefas remotamente. Um
aspeto bastante importante para o sucesso de aplicações groupware é o benefício
que estas podem trazer aos diversos membros da equipa.
5.6

SUGESTÕES PARA TRABALHO FUTURO

Prevê-se, no futuro, explorar a Metodologia Híbrida de Desenvolvimento
Centrado no Utilizador noutros projetos de software educativo, implementando as
melhorias acima reportadas. Está previsto a sua aplicação ao desenvolvimento deuma 3ª Fase do Courseware Sere, sobre Energias Alternativas.
Propõe-se também a melhoria do próprio modelo 4C de análise de processos
de desenvolvimento de software educativo (apresentado na secção 3.3.4). Peloestudo realizado, conclui-se que as metodologias que tenham por base os
pressupostos do Design Centrado no Utilizador, especificados na norma
International Organization for Standardization – ISO 13407 (1999), bem como as
práticas e os valores dos métodos ágeis de desenvolvimento (Abbas, 2006; Dybå &186

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Dingsøyr, 2008; Manifesto, 2001; Sommerville, 2007), requerem elementos com
determinado perfil. Desta forma, seria pertinente como melhoria, além daredefinição e possível inserção de novas categorias ao modelo apresentado,
acrescentar uma nova dimensão ao modelo 4C, competências, passando este adesignar-se como modelo 5C (Figura 47).

Figura 47 – 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 – Avaliação da
Qualidade de Produtos de Software (1999), que no decorrer do desenvolvimento
deste recurso serviram de base ao desenvolvimento de instrumentos (inquéritos
por questionário) de avaliação técnica e didática, seria relevante analisar ascompetências dos elementos da equipa multidisciplinar de forma assegurar aqualidade do processo de desenvolvimento e do software educativo (Beaver &Schiavone, 2006; Gulliksen, et al., 1999).

187

Capítulo V - Conclusão do Estudo

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, dacapacidades técnicas e 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 (2005)
designada por “reportory grid analysis” é uma possibilidade a explorar, dado
identificar boas caraterísticas de personalidade dos elementos de equipas dedesenvolvimento que utilizam o método ágil Extreme Programming.

188

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

REFERÊNCIAS BIBLIOGRÁFICAS
Abbas, N. (2006). Choosing the Appropriate Strategy for a Particular Software
Development

Project.

MScin

SoftwareEngineering,

UniversityofSouthampton.
Abbas, N., Gravell, A. M., & Wills, G. B. (2008). Historical Roots of Agile Methods:
Where did “Agile Thinking” Come from?, pp. 1-10. Consultado em Agile
processes and eXtreme programming in Software Engineering, 10-14 junho,
Limerick, Ireland.
Abras, C., Maloney-Krichmar, D., & Preece, J. (2004). User-Centered Design. In S.
Publications (Ed.), Encyclopedia of Human-Computer Interaction: Thousand
Oaks: Sage Publications.
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, Vol. 51, pp. 627-639.
Africano, D., Berg, S., Lindbergh, K., Lundholm, P., Nilbrink, F., & Persson, A.
(2004). Designing tangible interfaces for children's collaboration. CHI '04
extended abstracts on Human factors in computing systems, pp. 853-868.
Vienna, Austria.
Ary, D., Jacobs, L. C., Sorensen, C., & Razavieh, A. (2010). Introdution to Researchin Education (8ª ed.). Belmont, CA, USA.: Wadsworth.
Associates, A. L. (2007). How We Rate Interactive Media: About the Ratings, andCTR's Software Evaluation Instrument. Consultado em 2 de junho de 2009,
em http://www.childrenssoftware.com/rating.html#inst
Baddoo, N., & Hall, T. (2002). Software Process Improvement Motivators: An
Analysis using Multidimensional Scaling. Empirical Software Engineering,Vol. 7, pp. 93–114.
Baddoo, N., & Hall, T. (2003). De-motivators for software process improvement:
an analysis of practitioners views. The Journal of Systems and Software, Vol.
66, pp. 23–33.

189

Referências Bibliográficas

Bardin, L. (2004). Análise de Conteúdo. Lisboa: Edições 70.
Bassani, P. S., Passerino, L. M., Pasqualotti, P. R., & Ritzel, M. I. (2006). Em buscade uma proposta metodológica para o desenvolvimento de software
educativo colaborativo. Novas Tecnologias na Educação, Vol. 4(1), pp. 1-10.
Beaver, J. M., & Schiavone, G. A. (2006). The Effects of Development Team Skillon Software Product Quality. ACM SIGSOFT Software Engineering Notes,
Vol. 31(3).
Beck, K. (2000). Extreme Programming Explained: Embrace Change: AddisonWesley.
Benbunan-Fich, R., & Hiltz, S. R. (1999). Impacts of Asynchronous Learning
Networks on Individual and Group Problem Solving: A Field Experiment.
Group Decision and Negotiation, Vol. 8, pp. 409-426.
Benitti, F. B. V., Seara, E. F. R., & Schlindwein, L. M. (2005). Processo de
Desenvolvimento de Software Educacional: proposta e experimentação.
CINTED-UFRGS, Novas Tecnologias na Educação, Vol. 3(1), pp. 1-10.
Bergin, J., Caristi, J., Dubinsky, Y., Hazzan, O., & Williams, L. (2004). Teaching
Software Development Methods:The Case of Extreme Programming. SIGCSE'04, Norfolk, Virginia.
Bevan, N., & Macleod, M. (1994). Usability measurement in context. Vol. 13, pp.
132-145.
Bicudo, S. F., Nogueira, T., Oliveira, G. S., Machuca, V. F., Romero, J. P. F.,
Montenegro, E., et al. (2007). Projecto e Desenvolvimento de Jogos
Educativos em 3 Dimensões: a experiência da Univap Virtual.
Blois, A. P. T. B., & Becker, K. (2002). A Component-Based Architecture to
Support Collaborative Application Design. 8th International Workshop on
Groupware: Design, Implementation and Use, pp. 134-146. La Serena, Chile.
Boehm, B., & Turner, R. (2003). Observations on Balancing Discipline andAgility: Addison Wesley.

190

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Bogdan, R., & Biklen, S. (1994). Investigação Qualitativa em Educação - Uma
introdução à teoria e aos métodos. Porto: Porto Editora.
Borghoff, U. M., & Schlichter, J. H. (2000). Computer-Supported Cooperative
Work - Introduction to Distributed Applications: Springer.
Carmo, H., & Ferreira, M. M. (1998). Metodologia de Investigação - Guia de Autoaprendizagem, pp. 216-219. Lisboa: Universidade Aberta.
Carroll, J. M., Koenemann, J., Rosson, M. B., & Singley, M. K. (1993). Criticalincidents and critical threads in empirical usability evaluation. Carroll,Singley & Rosson: Critical threads.
Carvalho, A. A. A. (2005). Como olhar criticamente o Software Educativo
Multimédia. In M. d. Educação (Ed.), Cadernos SACAUSEF – Sistema de
Avaliação, Certificação e Apoio à Utilização de Software para a Educação e aFormação - Utilização e Avaliação de Software Educativo, Número 1., pp. 6982, 85-86.
Carvalho, C. V. (2003). Conceitos básicos para o desenvolvimento de cursos
multimédia - Manual do Formador (1.ª Edição). Porto: Sociedade Portuguesa
de Inovação.
Castro, G. C. M. d., & Aguiar, T. C. d. (1999). Engenharia de Software no
Desenvolvimento de Software Educacional Hipermídia. XXV Conferência
Latinoamericana de Informática, pp. 1-12. Asunción-Paraguay.
Cohen, L., Manion, L., & Morrison, K. (2007). Research Methods in Education (6ªed.). London and New York: Taylor & Francis Group.
Costa, A. P., Loureiro, M. J., & Reis, L. P. (2009c). Development Methodologies for
Educational Software: the practical case of Courseware Sere. International
Conference on Education and New Learning Technologies (EDULEARN09),
pp. 5816-5825. Barcelona, Espanha.
Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010a). Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador: o caso prático do Courseware Sere.

191

Referências Bibliográficas

5ª Conferência Ibérica de Sistemas e Tecnologias de Informação (CISTI2010),
pp. 192-197. Santiago de Compostela, Espanha.
Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010b). Courseware Sere: Avaliação
Técnica e Didáctica efectuada por Alunos. 5ª Conferência Ibérica de Sistemase Tecnologias de Informação (CISTI2010), pp. 198-203. Santiago deCompostela, Espanha.
Costa, A. P., Loureiro, M. J., & Reis, L. P. (2010c). Metodologia Híbrida de
Desenvolvimento Centrado no Utilizador aplicada ao Software Educativo.
Revista Ibérica de Sistemas e Tecnologias de Informação – RISTI, Vol. 6, pp. 115.
Costa, A. P., Loureiro, M. J., Reis, L. P., Guerra, C., Sá, P., & Vieira, R. (2009a).
Courseware Sere: Technical and Didactic Evaluation. V Conferência
Internacional de Multimédia e TIC na Educação (m-ICTE2009), pp. 502-506.
Lisboa, Portugal.
Costa, A. P., Loureiro, M. J., Reis, L. P., Sá, P., Guerra, C., Vieira, R., et al. (2009d,
24 a 26 de Setembro). Exploradores no Courseware Sere - "O Ser Humano e
os Recursos Naturais". XIII Encontro Nacional de Educação em Ciências Educação e Formação: Ciência, Cultura e Cidadania (ENEC2009). Castelo
Branco, Portugal.
Costa, A. P., Sá, P., Guerra, C., Loureiro, M. J., Vieira, R., Martins, I. P., et al.
(2009b). Courseware Sere - O Ser Humano e os Recursos Naturais: da ideia
à primeira versão. Conferência Internacional de TIC na Educação
(CHALLANGES2009), pp. 281-286. Universidade do Minho, Braga, Portugal.
Coutinho, C., & Chaves, J. (2001). Desafios à Investigação em TIC na Educação: As
metodologias

dedesenvolvimento.

Consultadoem

http://repositorium.sdum.uminho.pt/
Dejong, M., & Schellens, P. J. (1997). Reader-focused text evaluation. An overview
of goals and methods. Journal of Business and Technical Communication,
Vol. 11, nº 4, pp. 402-432

192

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Denise, L. (1999). Collaboration vs. C-Three (Cooperation, Coordination, andCommunication).

Innovating,

Vol.

7(3).

Consultadoem

http://www.practitionerresources.org/ cache/documents/646/64621.pdf
Dillenbourg, P., Baker, M., Blaye, A., & O'Malley, C. (1995). The Evolution of
Research on Collaborative Learning. Learning in humans and machines.
Towards an interdisciplinary learning science, pp. 189-211. London:
Pergamon.
Druin, A. (1999). The Design of Children's technology. Morgan Kaufmann
Publishers, Inc.
Druin, A. (2002). The Role of Children in the Design of New Technology
Behaviour and Information Technology (BIT) Vol. 21(1), pp. 1-25.
Duim, L. v. d., Andersson, J., & Sinnema, M. (2007). Good Practices for
Educational Software Engineering Projects. Proceedings of the 29th
International Conference on Software Engineering, pp. 698-707. Minneapolis,USA.
Dybå, T., & Dingsøyr, T. (2008). Empirical studies of agile software development:
A systematic review. Information and Software Technology, Vol. 50(9-10), pp.
833-859.
Ellis, C., Gibbs, S., & Rein, G. (1991). Groupware: Some Issues and Experiences.
Communications of the ACM, Vol. 34(1), pp. 38-58.
Evans, B. K., & Fischer, D. G. (1992). A hierarchical model of participatory
decision-making, job autonomy, and perceived control. Human Relation, Vol.
45, pp. 1169–1189.
Facer, K., & Williamson, B. (2004). Designing educational technologies with users- A handbook from Futurelab.

Consultado em

maio de 2008, em

http://www.futurelab.org.uk/resources/documents/handbooks/designing_wi
th_users.pdf
Fantina, R. (2005). Practical Software Process Improvement. Norwood: Artech
House.

193

Referências Bibliográficas

Fowler, M. (2005). The New Methodology Consultado em maio de 2009, em
http://www.martinfowler.com/articles/newMethodology.html
Fraenkel, J. R., & Wallen, N. E. (2009). How to Design and Evaluate Research in
Education: McGraw-Hill
Fuks, H., Gerosa, M. A., & Lucena, C. J. P. d. (2002). The development andapplication of distance learning on the Internet. The Journal of Open andDistance Learning, Vol. 17, pp. 23-38.
Fuks, H., Gerosa, M. A., Raposo, A. B., & Lucena, C. J. P. d. (2004,
Janeiro/Junho). O Modelo de Colaboração 3C no Ambiente AulaNet.
Informática na Educação: teoria & prática, Vol. 7, pp. 25-48.
Fuks, H., Raposo, A. B., & Gerosa, M. A. (2002). Engenharia de Groupware:
Desenvolvimento de Aplicações Colaborativas. XXI Jornada de Atualização
em Informática, Anais do XXII Congresso da Sociedade Brasileira deComputação, pp. 89-128.
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 (IJCIS), Vol. 14(2-3), pp. 299-328.
Fuks, H., Raposo, A. B., Gerosa, M. A., Pimentel, M., Filippo, D., & Lucena, C. J. P.
(2008). Inter and Intra-relationships between Communication Coordination
and Cooperation in the Scope of the 3C Collaboration. 12th International
Conference on Computer Supported Cooperative Work in Design, pp. 148-153.
Beijing, China.
Gomes, M. C. A. (2000). Avaliação e Ciclo de Vidas das Aplicações Educativas:
uma proposta com base na análise no desempenho do aluno.

Tese deDoutoramento em Ciências de Engenharia na Área de Engenharia Informática,
Universidade de Coimbra, Coimbra, Portugal.
Gray, D. E. (2004). Doing Research in the Real World. Londres: Sage
Publications.

194

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Guerra,C.

(2007).

Avaliação

do

StoryboardedaMetodologia

deDesenvolvimento do Courseware Sere. Tese de Mestrado em Comunicação e
Educação em Ciência, Universidade de Aveiro, Aveiro.
Gulliksen, J., Lantz, A., & Boivie, I. (1999). User Centered Design in Practice Problems and Possibilities (Centre for User Oriented IT Design (CID) ed.).
Stockholm: Royal Institute of Technology.
Hanna, L., Risden, K., Czerwinski, M., & Alexander, D. (1999). The role of usability
research in designing children’s computer products. The design of children’s
technology, pp. 4-26. San Francisco, USA.
Hauser, A. (2007). UCD Collaboration with Product Management andDevelopment. Interactions, pp. 34-35.
Hill, M. M., & Hill, A. (2005). Investigação por Questionário (2ª ed.). Lisboa:
Edições Sílabo.
Humphrey, W. S. (1987). Characterizing the Software Process A Maturity
Framework. In T. S. P. F. Project (Ed.). Pittsburgh, Pennsylvania: Software
Engineering Institute, Carnegie Mellon University.
Humphrey, W. S. (1998). Why Don't They Practice What We Preach? Annals of
SoftwareEngineering,pp.

201-222.

Consultadoem

http://www.sei.cmu.edu/library/assets/whitepapers/17072009whydontthey.p
df
ISO13407. (1999). Human-centred design processes for interactive systems.
Geneva: International Standards Organisation.
ISO14598. (1998). Information technology — Evaluation of Software Products Part
1: General guide.
ISO15504. (2004). Information technology - Process assessment Part 1 - concepts
and vocabulary.
ISO/IEC9126. (1999). Avaliação de Qualidade de Produtos de Software Geneva:
International Standards Organisation.

195

Referências Bibliográficas

ISO/TR18529. (2000). Ergonomics of Human-System Interaction. Geneva:
International Standards Organisation.
Jacobson, I., Christerson, M., Jonsson, P., & Övergaard, G. (1992). ObjectOriented Software Engineering: A Use Case Driven Approach: Addison
Wesley Publishing.
Jiang, L., & Eberlein, A. (2008). Towards A Framework for Understanding theRelationships

betweenClassical

SoftwareEngineering

and

Agile

Methodologies.
Jokela, T. (2004). When good things happen to bad products: where are thebenefits of usability in the consumer appliance market? Interactions, Vol.
11(6), pp. 28-35.
Keith, E. R. (2002). Agile Software Development Processes - A Different Aprroachto Software Design.
Kelly, S. R., Emanuela, M., Matthew, H., & Janet, C. R. (2006). Bluebells: a design
method for child-centred product development. 4th Nordic Conference on
Human-computer interaction: changing roles, pp. 361-368. Oslo, Norway.
Kirakowski, J., & Cierlik, B. (1999). Context of Use: Introductory Notes
Consultado

em

março

de

2010,

em

http://hfrg.ucc.ie/baseline/filearchive.html#cou
Krasteva, I., & Ilieva, S. (2008). Adopting an Agile Methodology — Why It Did
Not Work. APSO’08, pp. 33-36. Leipzig, Alemanha.
Larman, C., & Basili, V. R. (2003). Iterative and Incremental Development: A
Brief History. Computer, Vol. 36(6), pp. 47-56.
Loureiro, M. J. (2002). Un environnement d’apprentissage informatise développe
base sur des conceptions alternatives des élèves: Une application à
l’enseignement de l'électricité. . Université de Mons-Hainaut.
Loureiro, M. J., & Depover, C. (2005). Avaliação do programa Wlabel. IV
Conferência Internacional de Tecnologias de Informação e Comunicação na
Educação (CHALLENGES2005). Universidade do Minho, Braga, Portugal.

196

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Loureiro, M. J., & Pombo, L. (2006). Avaliação de Software Educativo - recursosde à apoio disciplina. Departamento de Didáctica e Tecnologia Educativa,
Mestrado em Multimédia em Educação. Aveiro: Universidade de Aveiro,
Portugal.
Maguire, M. (2001). Methods to support human-centred design. Internacional
Journal of Human-Computer Studies, Vol. 55.4, pp. 587-634.
Maguire, M. C. (1998). Respect User-Centred Requirements Handbook Telematics
Applications Project TE 2010: Requirements Engineering and Specificationin Telematics
Malone, T. W., & Crowston, K. (1990). What is coordination theory and how can it
help design cooperative work systems? III Conferência de Trabalho
Cooperativo Suportado por Computador (CSCW), pp. 357-370, Los Angeles,
Califórnia, USA.
Malone, T. W., & Crowston, K. (1994). The Interdisciplinary Study of
Coordination. Computing Surveys, Vol. 26(1), pp. 87-119.
Manifesto. (2001). Manifesto for Agile Software Development. Consultado em
abril de 2008, em http://agilemanifesto.org/
Mao, J.-Y., Vredenburg, K., Smith, P. W., & Carey, T. (2001). User-centered design
methods in practice: a survey of the state of the art. Conference of the Centre
for Advanced Studies on Collaborative research, Toronto, Ontario, Canada.
Mao, J.-Y., Vredenburg, K., Smith, P. W., & Carey, T. (2005). The state of usercentered design practice. Communications ACM, Vol. 48(3), pp. 105-109.
Marcus, A. (2005). User-centered design in the enterprise. Interactions, Vol. 12(1),pp. 18-23.
Marsic, I., & Dorohonceanu, B. (2003). Flexible User Interfaces for Group
Collaboration. International Journal of Human-Computer Interaction, Vol.
15(3), pp. 337-360.

197

Referências Bibliográficas

McChesney, I. R., & Gallagher, S. (2004). Communication and co-ordination
practices in software engineering projects. Information and Software
Technology Vol. 46, pp. 473-489.
Miguel, A. (2003). Gestão de Projectos de Software: FCA - Editora de Informática.
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, Vol. 52, pp. 480–491.
Molleman, E., Nauta, A., & Jehn, K. A. (2004). Person-job ﬁt applied to
teamwork: a multi-level approach. Small Group Research, Vol. 35, pp. 515–
539.
Monk, A., Wright, P., Haber, J., & Davenport, L. (1993). Improving Your HumanComputer Interface: A Practical Technique.
Neale, D. C., Carroll, J. M., & Rosson, M. B. (2004). Evaluating computersupported cooperative work: models and frameworks. ACM Conference on
Computer Supported Cooperative Work, pp. 112-121. New York, USA.
Nesset, V., & Large, A. (2004). Children in the information technology design
process: A review of theories and their applications. Library & Information
Science Research, Vol. 26(2), pp. 140-161.
Nielsen, J. (1992). Finding usability problems through heuristic evaluation.
Conference on Human Factors in Computing Systems Monterey, pp. 373-380.
California, USA.
Nielsen, J. (1993). Usability Engineering. London: Academic Press.
Nielsen, J. (2003). Usability 101: Introduction to Usability. Consultado em
janeiro de 2009, em http://www.useit.com/alertbox/20030825.html
Paelke, V., & Nebe, K. (2008). Integrating Agile Methods for Mixed Reality
Design Space Exploration. Proceedings of the 7th ACM Conference on
Designing Interactive Systems, pp. 240-249. Cape Town, South Africa.
Pardal, L., & Correia, E. (1995). Métodos e técnicas de investigação social. Porto:
Areal Editores.

198

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Pardo, S., Vetere, F., & Howard, S. (2005). Broadening stakeholder involvement
in UCD: designers' perspectives on child-centred design. 19th Conference of
the Computer-Human Interaction Special Interest Group (CHISIG) of
Australia on Computer-Human Interaction: citizens online: considerations fortoday and the future. Canberra, Australia.
Pardo, S., Vetere, F., & Howard, S. (2006). Teachers' involvement in usability
testing with children. Conference on Interaction Design and Children, pp. 8992. Tampere, Finland.
Paz, A. (2004). Software Educativo Multimédia no Jardim de Infância. Tese de
Mestrado em Educação na área de Especialização em Tecnologia Educativa,
Universidade do Minho, Braga, Portugal.
Pedatice. (1998). Educational Multimedia In Compulsory School: From
Pedagogical Assessment To Product Assessment. Consultado em maio de2008, em http://www.fpce.ul.pt/projectos/pedactice/
Pimentel, M., Fuks, H., & Lucena, C. J. P. (2008). Um Processo de
Desenvolvimento de Sistemas Colaborativos baseado no Modelo 3C: RUP-3CGroupware. Anais IV Simpósio Brasileiro de Sistemas de Informação – SBSI,
Rio de Janeiro.
Preece, J., Rogers, Y., & Sharp, H. (2002). Interaction Design: beyond human computer interaction: John Wiley & Sons.
Quivy, R., & Campenhoudt, L. (1998). Manual de Investigação em Ciências
Sociais. Lisboa: Gradiva.
Ramos, J. L., Teodoro, V., Maio, V. M., Carvalho, J. M., & Ferreira, F. M. (2005).
Sistema de Avaliação, Certificação e Apoio à Utilização de Software para a
Educação e Formação. Cadernos SACAUSEF – Sistema de Avaliação,Certificação e Apoio à Utilização de Software para a Educação e a Formação
- Utilização e Avaliação de Software Educativo (Vol. 1). Lisboa: Ministério de
Educação.

199

Referências Bibliográficas

Raposo, A. B., Magalhães, L. P., Ricarte, I. L. M., & Fuks, H. (2001). Coordinationof collaborative activities: A framework for the definition of tasksinterdependencies. 7th International Workshop on Groupware (CRIWG 2001),
pp. 170-179. Darmstadt, Alemanha.
Reis, E. (1991). Estatística Descritiva. Lisboa: Edições Sílabo.
Ribeiro, N. (2007). Multimédia e Tecnologias Interactivas. Lisboa: FCA - Editora
de Informática.
Robinson, H., & Sharp, H. (2004). The characteristics of XP teams, in Extreme
Programming and Agile Processes in Software Engineering. Lecture Notes in
Computer Science, Vol. 3092, pp. 139-147.
Ruland, C. M., Starren, J., & Vatne, T. M. (2008). Participatory design withchildren in the development of a support system for patient-centered care inpediatric oncology. Journal of Biomedical Informatics, Vol. 41(4), pp. 624635.
Sá, P., Guerra, C., Martins, I. P., Loureiro, M. J., Vieira, R., Costa, A. P., et al.
(2010b). Development of digital educational resources for education forsustainable development: the Courseware Sere. In Lazar, B.; Reinhardt, R.
(Ed.). XIV IOSTE - International Organization for Science and Technology
Education Proceedings. Bled: Eslovénia.
Sá, P., Guerra, C., Martins, I. P., Loureiro, M. J., Vieira, R., Costa, A. P., et al.
(2010a, Fevereiro). Desenvolvimento de Recursos Didácticos Informatizadosno Âmbito da Educação para o Desenvolvimento Sustentável. O Exemplo do
Courseware Sere. Revista Eureka sobre Enseñanza y Divulgación de lasCiencias, Vol. 7, pp. 330-345.
Sá, P., Martins, I. P., Guerra, C., Loureiro, M. J., Vieira, R., Costa, A. P., et al.
(2009). Courseware Sere: Metodologia e finalidades de exploração. XIII
Encontro Nacional de Educação em Ciências - Educação e Formação: Ciência,
Cultura e Cidadania (ENEC2009), pp. 899-908. Castelo Branco, Portugal.
Saeki, M. (1995). Communication, Collaboration and Cooperation in Software
Development - How Should We Support Group Work in Software

200

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Development?. Asia Pacific Software Engineering Conference (APSEC '95), pp.
12-20. Brisbane, Austrália.
Scaife, M., Rogers, Y., Aldrich, F., & Davies, M. (1997). Designing for or designing
with? Informant design for interactive learning environments. SIGCHI
conference on Human factors in computing systems, pp. 343-350. Atlanta,
Georgia, USA.
Schrage, M. (1990). Shared Minds. NY: Random House.
Seffah, A., Mohamed, T., Habieb-Mammar, H., & Abran, A. (2008). Reconcilingusability and interactive system architecture using patterns. Journal of
Systems and Software, Vol. 81(11), pp. 1845-1852.
Serçe, F. C., Swigger, K., Alpaslan, F. N., Brazile, R., Dafoulas, G., & Lopez, V.
(2010). Online collaboration: Collaborative behavior patterns and factors
affecting globally distributed team performance. Computers in Human
Behavior, pp. 1-14.
Shneiderman, B., & Plaisant, C. (2005). Designing the User Interface- Strategies
for Effective Human-Computer Interaction (Fourth ed.): Pearson Education.
Soloway, E., Guzdial, M., & Hay, K. E. (1994). Learner-centered design: thechallenge for HCI in the 21st century. Interactions, Vol. 1(2), pp. 36-48.
Sommerville. (2007). Software Engineering (Eighth Edition ed.): Addison Wesley.
Souza, F. N., Costa, A. P., & Moreira, A. (2010). WebQDA: Software de Apoio àAnálise Qualitativa. 5ª Conferência Ibérica de Sistemas e Tecnologias deInformação (CISTI2010), pp. 293-298. Santiago de Compostela, Espanha.
Souza, F. N., Costa, A. P., & Moreira, A. (2011a, 12 e 13 de maio). Análise de Dados
Qualitativos

Suportadapelo

Software

webQDA.

VII

Conferência

Internacional de TIC na Educação (Challanges 2011), pp. 49-56. Universidade
do Minho, Braga, Portugal.
Souza, F. N., Costa, A. P., & Moreira, A. (2011b, Julho). Questionamento no
Processo de Análise de Dados Qualitativos com apoio do software WebQDA.
EduSer - Revista de educação, Vol. 3(1), pp. 19-30.
201

Referências Bibliográficas

Squires, D., & Mcdougall, A. (1997). Como Elegir y Utilizar Software Educativo.
Madrid: Ediciones Morata.
Svanaes, D., & Gulliksen, J. (2008). Understanding the Context of Design Towards Tactical User Centered Design. Nordic Conference on HumanComputer Interaction (NordiCHI2008), pp. 353-362. Lund, Suécia.
Teem.org. (2008). TEEM — Advice and guidance that teachers trust. First in thefield of educational software evaluation. Consultado em junho de 2008, em
http://teem.org.uk/
Theng, Y. L., Mohd-Nasir, N., Thimbleby, H., Buchanan, G., & Jones, M. (2000).
Designing a children's digital library with and for children. Fifth ACM
Conference on Digital Libraries, pp. 266-267. San Antonio, Texas, USA.
Thomas, C., & Bevan, N. (1995). Usability Context Analysis: A Practical Guide(4.04 ed.). Teddington,

Middlesex,

TW11 0LW,

UK: National PhysicalLaboratory.
Toth, K. (2005). Which is the Right Software Process for Your Problem?.
Triantafyllakos, G. N., Palaigeorgiou, G. E., & Tsoukalas, I. A. (2008). We!Design:
A student-centred participatory methodology for the design of educational
applications. British Journal of Educational Technology, Vol. 39(1), pp. 125139.
Turoff, M., & Hiltz, S. R. (1982). Computer Support for Group Versus Individual
Decisions IEEE Transactions on Communications, Vol. COM-30(1), pp. 82-91.
Veenendaal, E. P. W. M. V. (1998). Questionnaire based usability testing.
European Software Quality Week. Bruxelas, Bélgica.
Velsen, L. V., Geest, T. V. D., Klaassen, R., & Steehouder, M. (2008). User-centeredevaluation of adaptive and adaptable systems: a literature review. The
Knowledge Engineering Review, Vol. 23(3), pp. 261-281.
Venturi, G., & Troost, J. (2004). Survey on the UCD integration in the industry.
Proceedings of the third Nordic conference on Human-computer interaction,
pp. 449-452. Tampere, Finlândia.

202

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Vieira, R. M. (1996). O Desenvolvimento de Courseware Promotor de Capacidade
de Pensamento Crítico. Dissertação de Mestrado não publicada, Universidade
de Lisboa, Lisboa, Portugal.
Vredenburg, K., Mao, J.-Y., Smith, P. W., & Carey, T. (2002). A survey of usercentered design practice. Conference on Human Factors in Computing
Systems: Changing our world, changing ourselves, Vol. 4(1), pp. 471-478.
Minneapolis, Minnesota, USA.
Wallace, J. R., Scott, S. D., Stutz, T., Enns, T., & Inkpen, K. (2009). Investigating
teamwork and taskwork in single- and multi-display groupware systems.
Personal Ubiquitous Computing, Vol. 13(8), pp. 569-581.
Weick, K. E., & Roberts, K. H. (1993). Collective mind in organisations: heedfulinterrelating on ﬂight decks. Administrative Science Quarterly, Vol. 38,
pp. 357–381.
Young, S. M., Edwards, H. M., McDonald, S., & Thompson, J. B. (2005).
Personality characteristics in an XP team: a repertory grid study. Workshop
on Human and Social Factors of Software Engineering, pp. 1-7. St. Louis,
Missouri, USA.

203

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

ANEXOS

205

Anexos

Anexo 01 - Inquérito por Questionário para Avaliação Técnica e
Didática (Professores)
1ª PARTE – Caraterização dos Participantes
1. Idade? _________
2. Sexo?
Feminino
Masculino
3. Formação Académica?
Licenciatura
Mestrado
Doutoramento
Pós-Doutoramento
Outro
4. Que atividade exerce?
_______________________________________________________
5. Em que instituição exerce a Sua
atividade?______________________________
6. Há quantos meses/anos exerce esta
atividade?___________________________
7. Quantas vezes por semana, utiliza o computador?
Nunca
1 vez
2 a 3 vezes por semana
4 a 5 vezes por semana
Todos os dias
8. Esteve ou está envolvido(a) num projeto que contempla a integração das TIC na
Educação em Ciência nos primeiros anos de escolaridade?
Se sim, quais as modalidades de integração das TIC e os princípios de Educação emCiência explorados? Dar um ou dois exemplos.

206

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

2ª PARTE – ASPETOS TÉCNICOS E DIDÁTICOS
Assinale com um X as afirmações que são apresentadas. No final de cada grupo deafirmações, poderá comentar outros aspetos que considere relevantes, focadas na
avaliação.
a) QUANTO AOS ASPETOS DO SOFTWARE:
1- Discordo plenamente, 2- Discordo, 3 - Concordo, 4Concordo plenamente, NS/NR - Não sei/Não respondo
Aspectos Técnicos
É funcional o software ser disponibilizado unicamente
online.
É importante existir uma versão do software em CDROM, além da versão online.
É aconselhável que o software funcione em diferentes
browsers 21.
É relevante que o utilizador saiba os requisitos mínimos
necessários.
Navegação
A estrutura em acíclica 22 facilita a navegação nosoftware.
A existência de mais que uma opção de navegação dentro
dos ecrãs ajuda a navegação no software.

1

2

3

4

NS/NR

É fundamental ter acesso a "ajuda" para navegar.
Os botões para navegação e os botões do menu fazem
sentido/têm significado.
Os botões são fáceis de selecionar/clicar.
A forma como se pode navegar entre ecrãs é facilmente
percetível.
O utilizador (criança) pode usar o software sozinho ou
com um par, apenas com uma ajuda reduzida.
A existência de uma mensagem para confirmar a ação“sair do software” é pertinente.

21 Internet Explorer, Netscape Navigator, Firefox.
22 “Na estrutura acíclica o utilizador pode aceder à informação por mais de um percurso. A possibilidade doutilizador se perder aumenta, mas a sua liberdade de navegação é maior.” (Carvalho, 2005, p. 14).

207

Anexos

Insira neste espaço comentários relativos aos aspetos técnicos e à navegação que
considere relevantes:

Interface gráfica (TENHA EM CONTA OS OBJETIVOS E O NÍVEL ETÁRIO A QUE SE
DESTINA O RECURSO)
A interface é simples e de fácil compreensão.
A interface é intuitiva apelando a metáforas 23 conhecidas
do utilizador.
A capacidade de utilizar em simultâneo diferentes
formatos 24 de representação da informação é pertinente.
Do ponto de vista estético, as formas de representação dainformação são visualmente agradáveis.
A distribuição/equilíbrio 25 dos formatos dos ecrãs é
adequada.
A organização dos ecrãs apresenta consistência.
A navegação e/ou orientação do utilizador na exploração
é suficiente.
As personagens são adequadas ao público-alvo.
A inexistência de feedback aquando da exploração das
atividades é adequada.
A possibilidade de trocar de personagem durante a
exploração do software é pertinente.
Nos ecrãs em que surgem animações, a possibilidade doutilizador poder controlá-las 26 é importante.
Nos ecrãs de entrada de cada fase, a possibilidade doutilizador poder ler e ouvir a explicação do que sepretende na mesma é adequada.

23 Entende-se por metáfora a representação simbólica de algo (por exemplo, o utilizador interpretar que osímbolo “X”, permite fechar determinada janela).

24 Por exemplo, opção dada ao utilizador de poder ouvir e ler em simultâneo a mesma informação.
25 Equilíbrio dos diferentes elementos (sem demasiada informação visual nem textual).
26 Entende-se por ter controlo, o facto do utilizador poder escolher as seguintes opções: avançar/recuar,stop, play/pause, com ou sem áudio.

208

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Insira neste espaço comentários relativos à interface gráfica que considere relevantes:

Estrutura (opções) geral
A animação permite contextualizar com clareza a
problemática do courseware.
A opção de se poder visualizar a animação em qualquerecrã é relevante.
A estrutura do recurso, por fases não sequenciais, épertinente.
No segundo ecrã, a possibilidade do utilizador poder
escolher uma de 6 personagens é indispensável.
No segundo ecrã, a necessidade do utilizador inserir o seu
nome ou o do grupo é importante.
A associação automática do nome, da idade e da região à
personagem escolhida é essencial.
No terceiro ecrã, a possibilidade das fases 1 e 2 serem
apresentadas por uma imagem é relevante.
É importante que no início de cada fase surja opresidente a explicar o que se pretende na mesma.
É vantajoso que todos os ecrãs tenham um menu com as
seguintes funcionalidades: visualizar a animação, escutaráudio de apoio, imprimir e capturar imagens.
O facto de, em cada fase, existir um menu de acesso às
outras fases, permite um rápido acesso às mesmas.
O facto de, nos ecrãs de cada fase, existir um menu deacesso aos outros ecrãs, sob a forma de thumbnails 27,
permite um rápido acesso aos mesmos.
A apresentação em texto e imagem dos ícones do menu
que se apresenta na parte inferior/centro de cada ecrã é
vantajosa, em termos de interpretação.

27 Menu constituído por pequenos ecrãs que permitem o acesso respetivo (à semelhança do que

acontece em computadores Mac).

209

Anexos

Insira neste espaço comentários relativos à estrutura do software que considere
relevantes:a) QUANTO AOS ASPETOS DIDÁTICOS:
1- Discordo plenamente, 2- Discordo, 3 - Concordo, 4Concordo plenamente, NS/NR - Não sei/Não respondo
As atividades

1

2

3

4

NS/NR

São adequadas à faixa etária.
Possibilitam a articulação curricular com outros níveis deensino.
Facilitam abordagens multi e transdisciplinares.
Proporcionam o desenvolvimento de várias competências
gerais pelo aluno/utilizador, sugeridas no currículo 28.
Respeitam diferentes ritmos de aprendizagem.
Facilitam o desenvolvimento da autonomia dos
utilizadores/alunos na construção de competências 29.
Permitem um envolvimento ativo do professor na
construção de competências dos utilizadores/alunos.
Não refletem preconceitos ou estereótipos 30.
Insira neste espaço comentários relativos às atividades que considere relevantes:

Os conteúdosSão adequados à faixa etária dos utilizadores.
Revelam rigor científico (incluindo qualidade e correção
científica do conteúdo, atualidade da informação eclareza no uso de termos e conceitos).

28 Como por exemplo, mobilizar saberes culturais, científicos e tecnológicos para compreender arealidade e para abordar situações e problemas do quotidiano.
29 Como por exemplo, pesquisar, selecionar e organizar informação para a transformar em
conhecimento mobilizável.
30 Quanto a aspetos relacionados com a raça, etnia, religião, cultura de origem, entre outros.

210

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

São pertinentes face à natureza da temática e aos
objetivos curriculares 31.
Insira neste espaço comentários relativos aos conteúdos que considere relevantes:

Em cada fase (I e II)
As tarefas são apresentadas de forma simples e clara pelo
explorador.
As atividades não serem exploradas sequencialmente épertinente.
Insira neste espaço comentários relacionados com outros aspetos que considere
relevantes:

3ª PARTE
Preencha o campo de acordo com a sua perceção acerca dos aspetos que lhe parecem
relevantes e que podem contribuir para uma melhor compreensão acerca das maisvalias educativas do Courseware Sere enquanto recurso pedagógico a usar no currículo
e/ou aprendizagem.

4ª PARTE
Deixe aqui os seus comentários sobre o decorrer da oficina e a forma como foi
perspetivada a avaliação do Courseware Sere (incluindo este instrumento de avaliação).

Obrigado pela colaboração!

31 Como por exemplo, analisar criticamente algumas manifestações da intervenção humana nanatureza e adotar um comportamento de defesa, conservação e recuperação do equilíbrio
ecológico da mesma.

211

Anexos

Anexo 02 - Inquérito por Questionário para Avaliação Técnica e
Didática (Alunos)

Temos algumas questões
para te colocar.

Em 5 minutos,
vais conseguir
responder.

ALGUMAS COISAS SOBRE TIQueremos saber
algumas coisas
sobre ti.

Mas não tepreocupes, que
guardamos
segredo.

1. Que idade tens? _________
2. Tu és?
Rapaz

212

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Rapariga
3. Em que ano da escola andas?
3º ano4º ano5º ano6º anoOutro
4. Quantas vezes por semana utilizas o computador?
Não utilizo computador
Todos os dias
2 a 3 vezes por semana
1 vez por semana
Raramente.
5. O que fazes no computador? (podes escolher mais do que uma opção)Trabalhos para a escola
Utilizo para ir à internet
Jogo
Outro:__________________________________________
6. Já algum dos teus professores fez uma atividade parecida com esta?
Sim
Não

213

Anexos

O QUE ACHAS DO PROGRAMA

Muito bem Explorador. Ajuda-nos
mais um pouquinho respondendo a

Assinala com

algumas questões.

um X as tuas
respostas.

Utilização do ProgramaNão

Mais oumenos

Sim

7. Conseguiste navegar sem ajuda?
8. Por vezes não sabias para onde ir?
9. Percebeste o significado dos botões?
10. Foi fácil selecionar os botões/ícones 32 com o rato?
11. Deste conta de quando cometias um erro?
12. Sabias sempre em que atividade estavas?
13. O que gostaste mais relativamente à navegação (utilização do programa?) Porquê?

14. O que gostaste menos relativamente à navegação (utilização do programa)?

Porquê?

32 Ícone

Botão
214

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Está quase,

Queremos saber

só mais um

se gostaste das

bocadinho.

janelas.

Desenho das Janelas
Não

Mais oumenos

Sim

15. O desenho das janelas era agradável?
16. Gostaste dos exploradores?
17. Gostaste das cores?
18. Gostaste das imagens?
19. Percebeste o áudio?
20. Percebeste os textos?
21. Gostaste da animação inicial?
22. O que gostaste mais no desenho das janelas? Porquê?

23. O que gostaste menos no desenho das janelas? Porquê?

215

Anexos

E agora, para

Vamos ver seterminar, só

gostaste das

mais uma coisa.

atividades!

AtividadesNão

Mais oumenos

Sim

24. Percebeste o que te foi pedido nas atividades?
25. Foi engraçado desenvolver as atividades em grupo?
26. Gostavas de desenvolver estas atividades em casa?
27. As atividades são interessantes para a tua idade?
28. Conseguiste aprender mais coisas além do tema do
programa?
29. Tiveste tempo suficiente para desenvolver as atividades?
30. A ajuda do professor foi importante para desenvolver as
atividades?
31. As atividades eram desafiantes?
32. O que gostaste mais das atividades? Porquê?

33. O que gostaste menos das atividades? Porquê?

Obrigado pela ajuda Explorador J !

216

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Anexo 03 – Modelo de Análise do Processo de Desenvolvimento
1. Contextualização

Com análise do processo de desenvolvimento do Courseware Sere,pretende-se compreender os pontos fortes e fragilidades da Metodologia
Híbrida de Desenvolvimento Centrado no Utilizador (Costa, Loureiro, & Reis,
2010c), através das interações ocorridas em ambiente não presencial (fóruns),
por parte dos elementos da equipa multidisciplinar, tendo por base o modelo
3C. O modelo 3C surgiu na década de 90 (Ellis, Gibbs, & Rein, 1991) e tem sido
explorado/estendido por Fuks e colaboradores (2002, 2005, 2008).

Figura 48 – Modelo 3C, adaptado de Fuks et al. (2005)
O modelo 3C está assente em três pilares, que passamos a descreversucintamente:• Comunicação: partilha informação, através do conhecimento e dos
pontos de vista. Nesta dimensão a comunicação funciona como ocontributo espontâneo dado pelos elementos da equipa multidisciplinar,
sendo

essencialmente

refletidanas

dimensões

coordenação

ecolaboração/cooperação.
• Coordenação: organização da equipa, negociando/atribuindo tarefas
217

Anexospara serem realizadas por determinada ordem, dentro de um determinado
tempo e cumprindo os objetivos propostos. A coordenação deve gerir
conflitos, deve garantir os compromissos e a realização do trabalho
cooperativo através das diferentes tarefas individuais, gerindo as
interdependências, fazendo a pré-articulação das tarefas a ser realizadas.
• Colaboração/Cooperação: tarefas que a equipa multidisciplinar
desenvolve ou em conjunto ou individualmente, com um objetivo comum,
através de um espaço partilhado. Na colaboração/cooperação é normal quese contribua ou solicite-se feedback sobre as soluções de projeto(documentos e protótipos), apresentadas, através de sugestões, deconcordância/discordância. A clarificação é um fator essencial dacolaboração/cooperação, no qual a troca de mensagens permite esclareceruma situação ou problema associado às soluções de projeto apresentadas.
A persistência é demonstrada na realização das tarefas, através das
sugestões e das novas soluções de projeto.
2. Categorias

A proposta de modelo de categorias para análise do processo dedesenvolvimento do Courseware Sere, é apresentada na Tabela 1.
Para a validação, apresentamos exemplos de posts, que designamos de“verdadeiros” e “falsos”. Apesar de inserirmos a totalidade de cada post, os
exemplos das unidades de texto para validação encontram-se a negrito.
Salientamos que, para algumas categorias não se justificou a inserção deexemplos “verdadeiros” e “falsos”. No final de cada post, foi disponibilizada uma
caixa de verificação

. Deverá selecionar (clicar) na caixa, em que o exemplo

seja verdadeiro, relativamente à categoria e descrição apresentada. Para
finalizar, foi inserida uma coluna para a inserção de comentários e sugestões.
Através do campo de texto

poderá escrever os comentários e sugestões. No

final disponibilizamos um espaço para “outras sugestões”.

218

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Comunicação
Categoria
Partilha deInformação

Subcategoria
Conhecimento

Descrição

Conhecimento
tácito ou explícito
demonstrado que
ajuda a resolução
de problemas.

Exemplo 1

Contexto: Post submetido relativamente ao
desenho do planisfério.
Assunto: Re: Planisfério
Enviado: Investigador em Didática dasCiências e Tecnologia Educativa, quartafeira, 7-5-08, 16:40“Olá.
Para ajudar a fazer a representação doplanisfério, sugiro a adaptação do seguinte
mapa
http://www.mapsofindia.com/worldmap/w
orld-map.gif que já possui uma escala. É
possível colocar o nome aos continentes e
aos oceanos?
Neste momento, penso que a forma como ointerior da terra está desenhado poderá criar“concepções erradas” nos alunos. Por
exemplo, a crosta oceânica é mais fina doque a crosta terrestre (o que não está
explicito da imagem). Sugiro que vejam a
imagem http://formacao.esloule.edu.pt/biogeo/geo12/temaI/imagens/l
ito_astenosfera.jpg
Não encontrei nenhum cortelongitudinal com o ângulo que
pretendemos do interior da terra
versus planisfério.
Este desenho terá que ser feito por
estimativa… No entanto, tem que servalidado por alguém da geologia.
É possível fazer uma pequena simulação daformação dos continentes? Penso que estava
no storyboard... Ver exemplo em
http://www.enchantedlearning.com/cgifs/C
ontinentaldrift.gif. Penso que tal poderá ser
uma das estratégias para os alunos
compreenderem a noção do “tempo
geológico”. Saudações.”Exemplo 2

Sugestões e Comentários

Contexto: Mensagem enviada
relativamente aos protótipos apresentadospara os ecrãs da Fase II.
Assunto: Ecrãs Fase II
Enviado: Investigador em Didática dasCiências e Tecnologia Educativa, terça-feira,
3-6-2008, 13:17“Bom dia Celso.
Esta situação reflete, de alguma
forma, algo que já tinha identificado
no meu estudo de mestrado: asdiferenças de linguagem dos vários
elementos da equipa.
Contudo, penso que esta dificuldade poderá
ser ultrapassada numa reunião presencial(para explicar a filosofia dos vários
cenários). Penso que dará mais trabalho
estar a reformular, de novo, a descrição dos
cenários da fase II. Eu posso reunir todos osdias a partir das 17h00 (excepto aos fins-desemana). Espero que a Patricia também
possa estar presente, mas se isso não forpossível estou cá eu… Com apenas 1 mêspara o seminário CTS, não podemos
permitir que a concepção da fase II seja
adiada …
O storyboard já foi validado pela equipa deconcepção, certo? A descrição dos cenários
da fase II foi feita desta forma para
dar liberdade ao designer e/ou
programador para interpretar o que sepretende (usou-se a mesma estratégia nomovieclip...).
Quanto ao som dos vários cenários da fase
II só poderei elaborá-los para a semana.
Saudações.”219

Anexos
Pontos de Vista

Pontos de vista,
relacionados
essencialmente,com situações
processuais(métodos etécnicas).

Contexto: Post referente aos guiões
exploração didática que acompanham osoftware.
Assunto: Re: Dossiers de Exploração
Didáctica Aluno - Fase 1
Enviado: Gestor de Projeto, segunda-feira,5-1-09, 18:45“Hello, vou opinar unicamente sobre o ponto
que devo. O guião de aluno ou caderno deregistos, seja qual for a designação, deve ser
impresso pelos seguintes motivos:
A versão do software em CDRom não
permitirá aceder às mesmas funcionalidades
da versão do software on-line. O software em
CDRom será uma versão do software on-line
sem a possibilidade instalar no computador,
sem a capacidade de preencher tabelas, entre
outros. A partir do momento que começou aser pensado para funcionar on-line, algumas
especificações/requisitos sofreram
alterações.
Os guiões do aluno deverão ser impressos
por motivos comerciais e nesta versão o seu
formato "comercial" não deverá ser alterado.
As restantes questões penso que
deverão ser respondidas pelos outros
elementos, contudo continuo a pensar
que nos deveriamos concentrar em
terminar esta versão do SERe, apesarde achar as observações da Maria JoãoLoureiro muito pertinentes.
É necessário que este guião seja verificado oquanto antes.
Um abraço”

Contexto: Post submetido relativamente
aos ecrãs das fase 2 – florestas.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, terça-feira, 176-08, 10:39
Boa tarde, concordo com a ideia da Cecília.
Penso que seria interessante ficar
como o Planisfério das Energias
Alternativas, isto é, uma legenda que
o utilizador pudesse verificar em queparte do Planisfério existe
determinada mancha Florestal.
Celso neste caso teria que entrar um novo
ecrã, porém, aguarda pelo feedback deoutras elementos da equipa.
Alguém consegue enviar as legendas e as
respetivas manchas florestais?
Obrigado pela atenção.”Colaboração/Cooperação

220

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Concordância

Um ou maiselementos
concordam
parcialmente ou
totalmente com
uma sugestão ou
solução deprojeto,permitindo assimo desenrolar do
projeto.

Contexto: Post associado a uma proposta
de melhoria relativamente ao 1º Ecrã, daFase 1 – Petróleo.
Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática dasCiências e Tecnologia Educativa, quintafeira, 2-10-08, 15:41“olá.
Concordo plenamente com a opinião
da Patrícia relativamente ao corte dacasa. Podemos colocar, mais uma vez, o
explorador a "viajar" pela casa
descodificando os objetos que derivam dopetróleo. Saudações.”Contexto: Post de resposta a várias
situações.
Assunto: Re: Ecrãs (interfaces)
Enviado: Investigadora em Didática dasCiências e Tecnologia Educativa, quartafeira, 21-5-08, 12:34“ Olá
Relativamente ao menu, sugiro que também
dê acesso ao movieclip.
Não acho relevante descrever a
personalidade da personagem. A ideia
é que os nomes sugeridos no storyboard
estimule os alunos a saber mais sobre cadapersonagem (Ver storyboard...), alargandoo espectro de exploração didáctica dorecurso.
Saudações. “Discordância

Identificação desituações onde oselementos
apresentam
pontos de vista
divergentes,
podendo atrasar odesenvolvimento
do projeto.

Contexto: Reposta a solicitação dealteração de ecrãs da fase 2 – Florestas.
Assunto: Re: Pegada Ecológica
Enviado: Perito em Didática das Ciências,
sexta-feira, 23-1-09, 16:28“ Cecília (e Patrícia)Obrigado também pelo vosso esforço.
Eu também tenho dúvidas, do ponto de vista
do conteúdo disciplinar (Biologia, Química,...) sobre algumas das questões e opções,quer do questionário da pegada, quer deoutras componentes do courseware. É
fundamental escrever, pelo menos no guião
do Professor (e na bibliografia), de onde se
adaptou o questionário! Também oGlossário, por exemplo, tal como estánão pode ficar! Neste caso preferia
remeter para os conceitos que estão na
Wikipédia. …”

Contexto: Post relacionado com os ecrãs
da fase 2 – florestas.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, terça-feira, 176-08, 10:39
Boa tarde, concordo com a ideia da
Cecília. Penso que seria interessante ficar
como o Planisfério das Energias
Alternativas, isto é, uma legenda que outilizador pudesse verificar em que parte doPlanisfério existe determinada mancha
Florestal.
Celso neste caso teria que entrar um novo
ecrã, porém, aguarda pelo feedback deoutras elementos da equipa.
Alguém consegue enviar as legendas e as
respectivas manchas florestais?
Obrigado pela atenção.”221

Anexos
Clarificação

Face a uma situação
ou problema (i.e.
relacionada com
uma solução deprojeto ou sugestão),segue-se uma troca
de mensagens, a fim
de seclarificar/esclarecera situação ou oproblema.
Mensagensexplicativas ou deesclarecimento, que
na sua maioria estão
associadas a anexos,
também estão
enquadradas neste
perfil.

Contexto: Post em resposta a uma solução
de projeto, referente ao 1º Ecrã da fase 1,
Petróleo.
Assunto: Re: Aplicações do Petróleo
Enviado: Investigador em Didática dasCiências, sexta-feira, 3-10-08, 10:43“Bom dia,
Estive a ver as imagens para a exploração
dos vários usos do petróleo. Considero que
estamos a avançar no bom caminho. As
imagens estão muito mais explícitas e sãomais fáceis de interpretar pelos utilizadores.
Temos, no entanto, de ser mais coerentes nouso de símbolos e dos seus significados (porexemplo, os símbolos usados para assinalar apresença do petróleo são os mesmos que
assinalam o seu uso?). Por outro lado,
seria interessante, na exploração dacasa, os utilizadores poderem
relacionar o uso do petróleo e seus
derivados às tarefas quotidianas.”

Contexto: Post com anexos e a mensagem
esclarece o conteúdo dos anexos. Alémdisso, alerta para terem em atenção
algumas situações.
Assunto: Re: Dossiers de Exploração
Didáctica - FASE 2
Enviado: Gestor de Projeto, domingo, 181-09, 13:20
Guioes_Exploracao_Florestas_Professor.zip“Boa tarde em anexo segue um
ficheiro zipado com uma versão doGuião de Exploração Didáctica
Professor paginado/ilustrado,
faltando numerar as páginas, ajustar
formatações e inserir os ecrãs finaisde cada actividade. Além disso
também segue em anexo a última
versão do Guião de Exploração
Didáctica Professor em word, deforma a poderem fazer alterações.
Nesta Guião ainda falta ser paginadoo Anexo_1.doc, que está anexo ao
tópico anterior.
NOTA: pedia que tivessem em
consideração para facto
das actividades poderem ser
exploradas com base na versão dosoftware em CDRom e/ou online, isto
é, nos casos em que o Professor não
tiver acesso à Internet não deverá ser
impeditivo de realizar as mesmas.”222

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Sugestões

Discussão desoluções projetoatravés desugestões
efetuadas/forneci
das por um ou
vários elementos,
podendo estas
gerar novas ações,demonstradas
através de novas
soluções deprojeto(documentos e
protótipos).

Contexto: Resposta ao primeiro protótipo
do 1º Ecrã, da Fase 1 – Petróleo.
Assunto: Re: Aplicações do Petróleo
Enviado: Perito em Didática das Ciências,
sexta-feira, 25-7-08, 16:38“Olá! Como 1º esboço parece-me
globalmente bem e coerente com o designusado nos outros cenários. Aconselho
mesmo assim que os barris sejam
mais cilíndricos e o avião passe nolado inferior esquerdo (menos denso)
e desta forma não tape a chaminé! O
ideal seria também incluir uma
refinaria. É possível?
Continuação de bom trabalho”

Contexto: Post enviado com protótipos
referentes aos ecrãs da fase 2 – florestas,
contendo na mensagem informações
explicativas dos mesmos.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, domingo, 255-08, 18:15.
Interfaces_Fase2_vers2.pdf“Boa tarde, é necessário que deixem ficar as
Vossas opiniões relativamente aos Ecrãs daFase 2. Após escolhermos no
Planisfério, por exemplo, o cenário
referente a África, surge um novoecrã com uma ilustração referente a
este continente. Sobre esta ilustração
surgirá uma janela sobreposta, onde
irá passar a animação descrita no
StoryBoard. O utilizar poderá escutare ler uma descrição relativa à mesma,
pode parar (stop), efectuar pause e
recuar na animação. Na opção áudio
o utilizador tem a possibilidade denão querer ouvir o mesmo. Um abraço”

223

Anexos
Persistência

Os elementos daequipademonstram
persistência na
realização das
tarefas, através desugestões e novas
soluções deprojeto (Pinelle,
Gutwin, &Greenberg, 2003).

Contexto: Post com nova verificação deguião do professor, fase 2- florestas.
Assunto: Re: Guião Professor (Florestas)
Enviado: Perito em Tecnologia Educativa,
quarta-feira, 4-02-09, 18:45“Viva!
Voltei a analisar o guião do prof.- fase2 e entreguei as sugestões à Cecília(que fiz a lápis, uma vez que a versão
final está em formato pdf). Umas
poderão ser introduzidas já. Outras ficam
para a revisão. No entanto, há dois aspectos
com os quais não me sinto confortável,porque podem induzir ideias incorrectas: um
diz respeito aos produtos florestais que
podem ser usados como fonte de energia.
Faz-se alusão só à madeira (o termo lenha é
do senso comum e convinha evitar).
Acontece que o óleo, entre outros, também é.
O outro prende-se com o quadro final quetem várias coisas com as quais não concordo
ou pelo menos tenho interrogações. Assim
sendo, a minha proposta é que se tire e seindique a página da FAO onde o professor
poderá encontrar informações (se não tiverInternet na escola, tem em casa ou em casa
de um colega). Voilà! Inté.”

Contexto: Post relacionado com o 2ª ecrãda fase 2 - florestas.
Assunto: Re: Manchas Florestais
Enviado: Gestor de Projeto, quinta-feira,13-7-08, 18:27“Boa tarde a todos, na segunda
actividade desta fase é necessário
identifcar as principais manchas
florestais. Por agora o utilizador passa orato e surge uma imagem referente à tipode floresta daquela região.
Outro ponto, Cecília as imagens foram
tiradas de locais em que a utilização é
livre, sendo necessário apenas referir afonte? Pergunto isto por causa dos Direitos
de Autor.
Contudo, esta actividade deverá ser maisrica. Eu, a Patrícia e a Cecília pensamos que
o utilizador poderia pintar as manchas
florestais, de forma as identificar. A partir
desta imagem não sei como o podemos
fazer?
Sugestões precisam-se!
Muchas gracias.”

Coordenação

224

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Compromissos

Um ou maiselementos daequipamultidisciplinar
comprometem-se
a executar
determinadas
tarefas.

Contexto: Post relativo às manchas
florestais, da 2ª atividade da Fase 2 –Florestas.
Assunto: Re: Manchas Florestais
Enviado: Perito em Didática das Ciências,
domingo, 21-9-08, 3:04
“Olá a todas!
Apesar de estar fora do país, não quero
deixar de responder para poder avançar com
o processo de desenvolvimento.
Sobre o assunto acima só posso responder
com toda a segurança para o final dasemana. Mesmo assim adianto já que não
devem aparecer aerogeradores em África (é oque me parece!!) e na América do sul devem
surgir árvores diferentes em formatos e
alturas (para tentar representar melhor aideia da diversidade).
O que pensam as outras colegas?
Vou tentar ver as aprendizagens
esperadas, mas apesar da resposta da
Cecília (que agradeço), não consigo
encontrar os documentos em
referência.
Bom trabalho.”

Contexto: Documento enviado com aprimeira proposta para conceção da página
web de apoio à exploração do software.
Assunto: Dossier de conceção do site deapoio ao Courseware Sere.
Enviado: Investigador em Didática dasCiências e Tecnologia Educativa, quintafeira, 8-5-08, 16:39
Dossier_de_concepcao_do_site_de_ap
oio_ao_Courseware_Sere.doc“Olá. Tal como prometido, aqui segueo primeiro esboço do dossier deconceção do site de apoio ao
Courseware Sere.
Saudações.”225

Anexos
Tarefas

Pré-Articulação

Documentos ou
mensagensenviadas através
dos fóruns que,preparam ações
de cooperação,identificando
objetivos e
distribuindo os
mesmos em
tarefas(Fuks, Gerosa, &Lucena, 2002).

Contexto: Mensagem enviada para todos oselementos informando/solicitando tarefas acada elemento.
Assunto: Re: Ecrãs
Enviado: Gestor de Projeto, segunda-feira,9-6-08, 11:47“Bom dia a todos,
Daniel, Celso e Paulo, coloquei na
pasta de Material em Formato
Vectorial, a versão 6.2. Não existe
alterações da estrutura (pois o Danieltinha um "ataque" de fúria J), masdeve ser a partir desta versão que se
devem fazer as alterações propostas:- Paulo está a fazer o MovieClip. Nesta
caso convém criares um novo ficheiro
designado como MovieClip;- Celso está a fazer as ilustrações paraas animações da FASE 2. Nesta caso
também deverás criar um novo
ficheiro designado como
Anima_Fase_2; Celso as
melhorias/alterações que ainda faltam
nos ecrãs devem ser enviadas oquanto antes, para o Daniel efectuar
as alterações. Por exemplo, o ecrã daúltima fase, os ícones para escolher
ouvir e/ou ler os textos de explicação
de cada fase...
- Daniel, é necessário começar
animar, por exemplo o ecrã da escolhadas personagens, o ecrã da escolhas
das fases, o ecrã da entrada...
- Patrícia, era importante que os
textos desta legenda ficassem maispequenos. É viável reduzir os
mesmos?

- Cecília e Patrícia não se esqueçam
dos textos.
Esta equipa é que é movida a energia
positiva (tenho que mandar isto para os
queridos da GALP). Um abraço”

Contexto: Mensagem enviada pelo Perito
em Tecnologia Educativa sobre a verificação
de documento.
Assunto: Re: Guião Professor (Florestas)
Enviado: Perito em Tecnologia Educativa,
quarta-feira, 4-2-09, 18:45“Viva!
Voltei a analisar o guião do prof.- fase2 e entreguei as sugestões à Cecília(que fiz a lápis, uma vez que a versão
final está em formato pdf). Umas
poderão ser introduzidas já. Outras
ficam para a revisão. No entanto, hádois aspectos com os quais não me sinto
confortável, porque podem induzir ideias
incorrectas: um diz respeito aos produtos
florestais que podem ser usados como fontede energia. Faz-se alusão só à madeira (otermo lenha é do senso comum e convinha
evitar). Acontece que o óleo, entre outros,
também é. O outro prende-se com o quadro
final que tem várias coisas com as quais nãoconcordo ou pelo menos tenhointerrogações. Assim sendo, a minha
proposta é que se tire e se indique a página
da FAO onde o professor poderá encontrar
informações (se não tiver Internet na
escola, tem em casa ou em casa de um
colega).”226

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Insistência

Uma mesma
mensagem ou
solução deprojeto, é enviado
mais do que uma
vez a fim de seobter feedback
por parte de um
ou vários
elementos daequipamultidisciplinar.

Contexto: Post enviado com uma versão dedocumento relativamente aos textos deáudios referentes a todo o software.
Assunto: Re: Textos para Áudios
Enviado: Gestor de Projeto, segunda-feira,15-12-08, 13:24
Textos_Totais_Audios_SERe_vers4.2_.doc“Boa tarde a todos, deixo ficar uma
nova versão dos Textos para Áudio,
pelo facto de achar que alguns aindaestão demasiado longos. Sugestão: Serápossível existir uma versão mais curta do
texto para se gravar o áudio e a versão
completa ficar impressa no guião do aluno
em formato de Banda Desenhada?
A outra questão que coloco, passa por
verificar se o texto se enquadra no conceitode "Apoio", isto é, se o mesmo ajuda outilizador a desenvolver as actividades e/ou
simplesmente enquadrar-se. Pelo que li,
temos os 3 casos (apoio, enquadramento eapoio/enquadramento). Um abraço”

Contexto: Post com solução de projetoreferente ao guião da Fase 1 – Petróleo.
Assunto: Re: Dossiers de Exploração
Didáctica Aluno - Fase 1
Enviado: Gestor de Projeto, quinta-feira,29-1-09, 11:38
Guioes_Registos_Petroleo_Aluno_vers2_.
pdf“Bom dia, a versão que segue em anexo
ainda não foi totalmente formatada (falta
aumentar tabelas,...). Mais uma vez
verifiquem os textos e atividades.
Um abraço”

227

Anexos
Conflitos

Conflitos que
prejudiquem aequipa, comocompetição,desorientação,problemas dehierarquia,
difusão deresponsabilidade(Acuna, Gómez, &Juristo, 2009).

Contexto: Post submetido a solicitar
esclarecimentos sobre determinada situação
relacionada com a ilustração de cenários das
Fase 2, Florestas.
Assunto: Re: Ecrãs Fase II
Enviado: Ilustrador/Designer-A, terçafeira, 3-06-08, 03:05“preciso de coisas concretas da parte dacecília ou de alguém que me saiba responder.
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...
O que temos é isto:
Exemplo do cenário 1 – sequência deimagens que mostram a evolução da
exploração de uma porção de floresta
primária do Canadá (floresta boreal).
…
Exemplo do cenário 2 – sequência deimagens que mostram a evolução da
exploração de uma porção de floresta
primária do Brasil (Amazónia) (floresta
tropical húmida). O abate de áreas florestaispara fins agrícolas, expansão da pecuária,construção de estradas implica afragmentação e perda de biodiversidade, eda diversidade cultural, nomeadamente amanutenção das formas tradicionais desustento dos grupos indígenas. …
Mas não sei mais concretamente o que
hei-de desenhar para compor uma
animação para cada um dos
cenários... Tem de haver um
encadeamento nos elementos
da animação. O que temos são frases
soltas sem nenhum encadeamento
entre elas...
Aguardo esclarecimentos para poderdesenhar as animações. Obrigado”

Contexto: Post submetido a solicitar que
todos contribuam sobre as sugestões
apresentadas.
Assunto: Re: Textos para Áudios
Enviado: Perito Didática das Ciências,
sexta-feira, 2-1-09, 17:30“Após nova leitura nada tenho aacrescentar.
O ideal é que todos digam o que
pensam sobre algumas das minhassugestões.
Um bom ano de 2009.”

228

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Interdependênci
a

Situação em que oresultado de uma
tarefa afeta oprocesso e oresultado deoutras tarefas.
Umacaracterística deinterdependência
é a reciprocidade,o que significa que
os elementos daequipa são
mutuamenteinterdependentes(Molleman, Nauta& Jehn, 2004).

Contexto: Mensagem relacionada comouma solução de projeto apresentada, da Fase2 - Florestas.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, terça-feira, 1706-08, 10:39“Boa tarde, concordo com a ideia da Cecília.
Penso que seria interessante ficar como oPlanisfério das Energias Alternativas, isto é,
uma legenda que o utilizador pudesse
verificar em que parte do Planisfério existe
determinada mancha Florestal.
Celso neste caso teria que entrar um
novo ecrã, porém, aguarda pelo
feedback de outras elementos daequipa.
Alguém consegue enviar as legendas e as
respectivas manchas florestais?
Obrigado pela atenção.”Contexto: Solicitação de opinião
relativamente a protótipos apresentados.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, domingo, 25-508, 18:15
Interfaces_Fase2_vers2.pdf“ Boa tarde, é necessário que deixem
ficar as Vossas opiniões
relativamente aos Ecrãs da Fase 2.
Após escolhermos no Planisfério, por
exemplo, o cenário referente a África, surge
um novo ecrã com uma ilustração referentea este continente. Sobre esta ilustração
surgirá uma janela sobreposta, onde irá
passar a animação descrita no StoryBoard.
O utilizar poderá escutar e ler uma
descrição relativa à mesma, pode parar(stop), efectuar pause e recuar na animação.
Na opção áudio o utilizador tem apossibilidade de não querer ouvir o mesmo.
Um abraço”

Tabela 1 – Componentes 3C

Outras sugestões (novas categorias, sobre este processo de validação, entre outras).

Obrigado pela colaboração.

229

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

Anexo 04 – Exemplo de Ata de Reunião
ATA DE REUNIÃO

Instituição
:Referª:Data:

Assunto:Instituição

UAveiroUAveiro12-01-08

Hora Início:Courseware SERe
10:00

Hora Fim:

0

13:3

Apresentação e discussão de protótipos

Nome
Investigadora em
Didática dasCiências e
Tecnologia
Educativa
Investigadora em
Didática dasCiências
Perita em
Tecnologia
Educativa

UAveiroProjeto:

Universidade de Aveiro

Assinatura

Instituição

Nome

Assinatura

Ludomedia

DesignerIlustrador B

Ludomedia

Programador A

Ludomedia

Gestor de Projeto

Ludomedia

DesignerIlustrador A

Conclusões da Reunião:Esta reunião ocorreu com o objectivo de definir tarefas relacionadas com o Courseware
SERe. Conclui-se o seguinte:
1) Após

análise

da

fase

1,

primeirocenário,conclui-sequeé

necessário

encontrar/desenvolver um Algoritmo que permita relacionar diferentes factores. Para
isso é necessário definir:a. Quantos factores irão ser utilizados;b. Qual o peso de cada factor;
c. Se um factor tem influência sobre outro.
Para resolver esta questão ficou estabelecido que a Investigadora em Didática das Ciências
e/ou Investigadora em Didática das Ciências e Tecnologia Educativa e/ou Perita em
Tecnologia

Educativa

Peritaem

Tecnologia

Educativa

iriam

contactarum

investigador/professor do departamento de ambiente. Em última análise e caso ninguém

231

Anexos

deste

departamento

solucioneaquestão

doalgoritmo,

será

contactado

investigador/professor do departamento de Matemática para o mesmo efeito.
2) Caso o Courseware SERe seja desenvolvido na totalidade com metodologia centrada noutilizador será necessário que nas reuniões de projecto estejam presentes professores ealunos do 1º e 2º ciclos do ensino básico.
3) As personagens que estão a ser desenvolvidas para o Courseware SERe deverão seravaliadas por crianças que frequentem o 1º e 2º ciclos do ensino básico.
4) O Programador A referiu que, não sendo um jogo, consideramos que a interactividade
num produto multimédia é indispensável. A possibilidade do utilizador podermanipular inúmeras variáveis e observar qual o resultado que atinge é muito
interessante. Ainda que não seja um jogo, o facto de levar o utilizador a interagir com osistema e ele dar 'feedback' prende o utilizador à aplicação. Isto acontece na primeiraparte. Teria que se trabalhar bem a questão do feedback, com desenhos, animações
simples, mas com alguma variação e que, sobretudo, contemplassem as várias
realidades que se poderiam atingir com a manipulação das diferentes variáveis. A 2ª e
3ª fases falha neste capítulo em que não existe mais do que um conjunto de botões que
acedem a vários slideshows. Não que não seja interessante, mas falta algo mais. Poderá
ser utilizado como referência a 1ª parte e adaptar 2ª e 3ª fases. Há ainda alguns
elementos que não desempenham qualquer papel em toda a aplicação. As personagens
que se escolhe no início não têm qualquer intervenção em toda a aplicação. Isto porquenão há grande interacção. A escolha de personagens está muito ligado a jogos, em queela própria surge no ecrã, participa nos jogos, ou serve apenas para aparecer na tabela
de pontuação. Neste caso, depois da escolha da personagem, ela cai no esquecimento. A
personagem do Presidente POMPP parecia que iria ser usada como cicerone ao longo
de toda a aplicação, mas pelo que verificamos, também cai no esquecimento.
5) Perita em Tecnologia Educativa abordou questões relacionadas com o uso das
tecnologias nas escolas, tendo em conta o que se passa nas mesmas em termos deintegração das TIC; Se em termos de empresa tem interesse desenvolver para Sala deAula? Países mais ricos, têm mais material mas o panorama é igual, pois existe material
em sala de aula mas não é utilizado. Deveria/poderia convergir-se para trabalhar em
contextos de estudo acompanhado e áreas de projecto. Não se pode ignorar o facto deestarmos presos a 5% dos professores que utilizam estas tecnologias e que se deveria ler
os estudos como as crianças utilizam estes recursos. Em sala de aula é pouco utilizado,

232

Metodologia Híbrida de Desenvolvimento Centrado no Utilizador
Aplicada ao Software Educativo

podendo aproveitar o facto de 70% dos recursos deste tipo são utilizado em contexto
não formal, casa, juntas de freguesia, centro de recursos, entre outros.
6) Foram colocados diferentes cenários para o desenvolvimento do Courseware:a. 1º Cenário: partindo do pressuposto que o Courseware é desenvolvido em 3 (três)fases, verificando a possibilidade de ser comercializado faseadamente.
b. 2º Cenário: efectuar o esforço de fazer simultaneamente todas as fases utilizando
3 (três) diferentes metodologias desenvolvimento;c. 3º Cenário: verificar a colocação no mercado, os 3 (três) em simultâneo, mesmo
que este seja desenvolvido por fases.
Se o projecto for comercializado por fases obriga a redefinir/repensar o guião deexploração que está concebido. Com isto, sugiram os seguintes problemas relativamente àdisponibilidade da Investigadora em Didática das Ciências e da Investigadora em Didática
das Ciências e Tecnologia Educativa. A Investigadora em Didática das Ciências não está
disponível até Março, devido à defesa da tese de Doutoramento. Defende que não se deve
fasear a comercialização, mas lançar o produto como um todo, mesmo seja concebido porfases. Relativamente à Investigadora em Didática das Ciências e Tecnologia Educativa,
estará disponível até Junho e depois só a partir de Janeiro. Defende que o produto deverá
ser desenvolvido todo em simultâneo e ser lançado até Junho.
Caso se opte pela concepção faseada, poderá existir a possibilidade de envolver outras
pessoas de forma a colmatar as possíveis faltas da Investigadora em Didática das Ciências
e da Investigadora em Didática das Ciências e Tecnologia Educativa.
A Ludomedia pela voz do seu responsável, afirmou que independentemente do produto, opúblico-alvo da Ludomedia são os professores que compram os produtos Ludomedia para
utilização com os alunos. A estratégia da Ludomedia, actualmente, não passa por
desenvolver produtos direccionados unicamente para a aquisição/utilização por parte dascrianças, pois os principais clientes da Ludomedia (80%) comercializam unicamente os
nossos produtos aos professores.
Assuntos pendentes: Como será concebido o Courseware SERe: em simultâneo eserá lançado em Julho de 2008, ou por fases e lançado em Julho de 2009.
Próxima Reunião:Hora:233