Autarquia Educacional do Vale do São Francisco - AEVSF
Faculdade de Ciências Aplicadas e Sociais de Petrolina – FACAPE
Computação, educação e música:
Um estudo interdisciplinar para o levantamento de requisitos de um
software educativo musical.
Ricardo de Lima Gonçalves
Petrolina – PE
2010
Ricardo de Lima Gonçalves
Computação, educação e música:
Um estudo interdisciplinar para o levantamento de requisitos de um
software educativo musical.
Monografia apresentada ao Curso de Ciência da Computação
da Faculdade de Ciências Aplicadas e Sociais de Petrolina –
PE, como requisito parcial para a obtenção do título de
Bacharel em Ciência da Computação.
Orientador: Professor Esp. Carlos Alberto Teixeira Batista
Petrolina – PE
2010
Ricardo de Lima Gonçalves
Computação, educação e música:
Um estudo interdisciplinar para o levantamento de requisitos de um
software educativo musical.
Monografia apresentada ao Curso de Ciência da Computação da Faculdade de
Ciências Aplicadas e Sociais de Petrolina – PE.
Petrolina – PE, 2010.
________________________________________________
Professor Esp. Carlos Alberto Teixeira Batista – FACAPE
Orientador
________________________________________________
Presidente da Banca
________________________________________________
Membro da Banca
DEDICATÓRIA
Aos meus amados pais Cecília e Antonio, por tudo o que tem feito, pela
confiança e pelo amor.
AGRADECIMENTOS
Agradeço a Deus, por mais essa oportunidade em minha vida.
Ao meu orientador, professor Carlos Alberto, pelas sábias palavras nos
momentos de dúvidas.
A minha “Estrelinha” (Geisa), pelas palavras de apoio, incentivo, compreensão e
principalmente pelo amor.
Aos “irmãos da música”, que me aguçaram na escolha do tema.
E aos participantes da pesquisa, peças fundamentais neste trabalho.
EPÍGRAFE
“Sem a música, a vida seria um erro.”
Friedrich Nietzsche
RESUMO
Assim como o quadro-negro, o giz e os livros, os softwares educacionais têm se
mostrado excelentes ferramentas de apoio às práticas pedagógicas. No ensino da música
não é diferente: existem a disposição do professor infinitas ferramentas, que vão desde
simples editores de partitura a complexos ambientes simulados de aprendizagem. No
entanto, é preciso observar quais pressupostos pedagógicos, musicais e computacionais
estão inseridos na ferramenta, uma vez que a interseção dessas três áreas nem sempre
representa garantia de sucesso no processo de ensino-aprendizagem. Será realizado
neste trabalho um estudo interdisciplinar, envolvendo a computação, a educação e
música, levando em consideração uma das etapas mais críticas no desenvolvimento de
softwares: o estudo de requisitos. Para tanto, iniciar-se-á com revisões bibliográficas
acerca das três áreas e culminará com a criação de um protótipo de um software
educacional, denominado “Baticum”.
Palavras-chave: softwares educacionais, ensino-aprendizagem, estudo de requisito.
ABSTRACT
Like the blackboard, chalk and books, educational software have proven
excellent tools to support pedagogical practices. In the teaching of music is no different:
there are the endless willingness of the teacher tools, ranging from simple score editors
to complex simulated environments for learning. However, one must look at which
pedagogical assumptions, and computer music are inserted into the tool, since the
intersection of these three areas is not always a guarantee of success in the teachinglearning process. Will be proposed in this paper an interdisciplinary study, involving
computing, education and music, taking into consideration one of the most critical steps
in software development: the study of requirements. For this, it will start with literature
reviews on the three areas and will culminate with the creation of a prototype of an
educational software called “Baticum”.
Keywords: educational software, teaching-learning, study requirement.
LISTA DE GRÁFICOS
GRÁFICO 1 – DISTRIBUIÇÃO DAS IDADES............................................................................................55
GRÁFICO 2 – ALUNOS QUE POSSUEM COMPUTADOR EM CASA..........................................................56
GRÁFICO 3 – ALUNOS QUE JÁ REALIZARAM ALGUM CURSO DE INFORMÁTICA....................................56
GRÁFICO 4 – ATIVIDADES DOS ALUNOS USANDO O COMPUTADOR....................................................57
GRÁFICO 5 – AULAS PREFERIDAS.......................................................................................................57
LISTA DE FIGURAS
FIGURA 1 – TELHARMONIUM DE THADDEUS CAHILL..........................................................................17
FIGURA 2 – MAX MATHEWS E O MUSIC I............................................................................................20
FIGURA 3 – DEFINIÇÕES DAS ATIVIDADES DO MODELO (T)EC(L)A DE SWANWICK................................25
FIGURA 4 – CICLO DE VIDA DE PCU.....................................................................................................38
FIGURA 5 – CICLO DE VIDA DO PCU MODIFICADO..............................................................................41
FIGURA 6 – TÉCNICAS USADAS PARA O LEVANTAMENTO DE REQUISITOS. .........................................42
FIGURA 7 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA DE IDENTIFICAÇÃO DO USUÁRIO.......................62
FIGURA 8 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA PARTITURAS.....................................................62
FIGURA 9 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA NOVA PARTITURA.............................................63
FIGURA 10 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA TOCADOR DE ÁUDIO.......................................64
FIGURA 11 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA TOCADOR DE VÍDEO........................................64
FIGURA 12 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA MANUTENÇÃO DOS USUÁRIOS.......................65
FIGURA 13 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA CADASTRO DE USUÁRIOS................................65
FIGURA 14 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA ATIVIDADES.....................................................66
FIGURA 15 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA NOVA ATIVIDADE............................................66
FIGURA 16 – PROTÓTIPO DE BAIXA FIDELIDADE: TELA METRÔNOMO.................................................67
FIGURA 17 – PROTÓTIPO DE ALTA FIDELIDADE: TELA DE IDENTIFICAÇÃO DO USUÁRIO.......................68
FIGURA 18 – PROTÓTIPO DE ALTA FIDELIDADE: TELA PRINCIPAL.........................................................68
FIGURA 19 – PROTÓTIPO DE ALTA FIDELIDADE: TELA PARTITURAS.....................................................69
FIGURA 20 – PROTÓTIPO DE ALTA FIDELIDADE: TELA CRIAÇÃO DE PARTITURAS..................................69
FIGURA 21 – PROTÓTIPO DE ALTA FIDELIDADE: TELA VISUALIZAR PARTITURAS..................................70
FIGURA 22 – PROTÓTIPO DE ALTA FIDELIDADE: TELA TOCADOR DE ÁUDIO.........................................70
FIGURA 23 – PROTÓTIPO DE ALTA FIDELIDADE: TELA TOCADOR DE VÍDEO..........................................71
FIGURA 24 – PROTÓTIPO DE ALTA FIDELIDADE: TELA BATERISTA VIRTUAL..........................................71
FIGURA 25 – PROTÓTIPO DE ALTA FIDELIDADE: TELA ATIVIDADES......................................................72
FIGURA 26 – PROTÓTIPO DE ALTA FIDELIDADE: TELA NOVA ATIVIDADE..............................................72
FIGURA 27 – PROTÓTIPO DE ALTA FIDELIDADE: TELA AULA................................................................73
FIGURA 28 – PROTÓTIPO DE ALTA FIDELIDADE: TELA CADASTRO DE USUÁRIO....................................74
FIGURA 29 – PROTÓTIPO DE ALTA FIDELIDADE: TELA EDITAR USUÁRIO..............................................74
FIGURA 30 – PROTÓTIPO DE ALTA FIDELIDADE: TELA PESQUISAR USUÁRIO........................................74
FIGURA 31 – PROTÓTIPO DE ALTA FIDELIDADE: TELA METRÔNOMO...................................................75
FIGURA 32 – NOVO PROTÓTIPO: TELA DO METRÔNOMO...................................................................80
FIGURA 33 – NOVO PROTÓTIPO: TELA NOVA PARTITURA...................................................................81
FIGURA 34 – NOVO PROTÓTIPO: TELA LEGENDA................................................................................81
FIGURA 35 – NOVO PROTÓTIPO: FUNÇÃO ZOOM...............................................................................82
FIGURA 36 – NOVO PROTÓTIPO: TELA BATERISTA VIRTUAL................................................................83
SUMÁRIO
1.1. JUSTIFICATIVA.......................................................................................................................................14
1.2. OBJETIVO GERAL ..................................................................................................................................15
1.3. OBJETIVOS ESPECÍFICOS ...........................................................................................................................15
1.4. ESTRUTURA DO TRABALHO ........................................................................................................................16
2. COMPUTAÇÃO MUSICAL ..............................................................................................................16
3. EDUCAÇÃO MUSICAL E O USO DE SOFTWARES EDUCATIVOS.........................................................22
3.1. CONCEPÇÕES EDUCATIVO-MUSICAIS...............................................................................................................23
3.2. CLASSIFICAÇÃO.....................................................................................................................................26
3.2.1. FAMÍLIA DE SOFTWARES DE ATUAÇÃO DIRETA ................................................................................................26
3.2.2. FAMÍLIA DE SOFTWARES DE ATUAÇÃO INDIRETA...............................................................................................27
4. ENGENHARIA DE SOFTWARE ........................................................................................................29
4.1. ENGENHARIA DE REQUISITOS.......................................................................................................................30
4.1.1. Requisitos funcionais................................................................................................................32
4.1.2. Requisitos não funcionais........................................................................................................32
4.2. USABILIDADE E SOFTWARE EDUCACIONAL.........................................................................................................33
5. ASPECTOS METODOLÓGICOS .......................................................................................................36
4.1. CONTEXTO E POPULAÇÃO..........................................................................................................................36
5.2. DESENVOLVIMENTO E AVALIAÇÃO DE SOFTWARES EDUCACIONAIS...............................................................................37
5.3. PCA - PROJETO CENTRADO NO APRENDIZ.....................................................................................................39
5.4. IDENTIFICANDO USUÁRIOS/ALUNOS E ESTABELECENDO SUAS NECESSIDADES ...................................................................42
4.3.1. Entrevistas................................................................................................................................43
4.3.2. Questionários .........................................................................................................................43
4.3.3. Observação .............................................................................................................................44
4.3.4. Cenários...................................................................................................................................44
5.5. PROTOTIPAÇÃO.....................................................................................................................................45
5.6. AVALIAÇÃO MULTIDISCIPLINAR ...................................................................................................................47
5.6.1. Avaliação Heurística ................................................................................................................49
5.6.2. Ensaios de interação................................................................................................................51
6. LEVANTAMENTO DE REQUISITOS..................................................................................................52
6.1. ENTREVISTAS ....................................................................................................................................52
6.2. QUESTIONÁRIOS...................................................................................................................................55
6.3. OBSERVAÇÃO ......................................................................................................................................58
6.4. CENÁRIO............................................................................................................................................59
7. PROTOTIPAÇÃO............................................................................................................................61
7.1. PROTÓTIPO DE BAIXA FIDELIDADE.................................................................................................................61
7.2. PROTÓTIPO DE ALTA FIDELIDADE..................................................................................................................67
8. AVALIAÇÃO MULTIDISCIPLINAR ....................................................................................................76
8.1. AVALIAÇÃO HEURÍSTICA............................................................................................................................76
8.2. ENSAIOS DE INTERAÇÃO............................................................................................................................78
8.3. NOVO PROTÓTIPO..................................................................................................................................80
9. CONCLUSÃO E TRABALHOS FUTUROS............................................................................................83
REFERÊNCIAS ..................................................................................................................................84
APÊNDICE A – CARTA DE CONSENTIMENTO......................................................................................91
APÊNDICE B – ROTEIRO ENTREVISTA SEMI-ESTRUTURADA ...............................................................92
APÊNDICE C – QUESTIONÁRIO AOS ALUNOS.....................................................................................93
ANEXO B – SOFTWARES DE ATUAÇÃO INDIRETA...............................................................................96
13
1. INTRODUÇÃO
A computação, impulsionada com o fervor dos avanços tecnológicos tem se
mostrado um campo extremamente dinâmico, não a toa tem conquistado as mais
diversas áreas e atividades (MILETTO ET AL, 2006). Entre essas, a Computação
Musical merece destaque pela imensa contribuição que tem propiciado aos mais
diversos profissionais da rádio e televisão, estudantes na área do som, engenharia
eletrotécnica, engenharia da computação, músicos (profissionais e amadores), audiófilos
e tantos outros (FLORES, Luciano, 2002).
Computação musical é um campo da computação encarregado de estudar as
aplicações computacionais relacionadas aos problemas musicais (MILETTO ET AL,
2006). Assim, numa visão resumida, a Computação Musical, lida com a interação da
arte com os sons: a música, o que a torna uma disciplina ainda mais instigante, não só
para os músicos como também para os profissionais em geral da computação. Mas essa
relação não se restringe apenas a informática e aos sons, segundo Sabattini
(SABATTINI, 1997), a COMPUTAÇÃO MUSICAL aponta para um universo
complexo e interdisciplinar:
Vista como um domínio do conhecimento, a música computacional é uma das
atividades mais interdisciplinares que existem, englobando muitos aspectos
de música (composição, performance, musicologia), ciência da computação
(programação, inteligência artificial), engenharia elétrica (circuitos
analógicos e digitais, arquiteturas de máquinas, processamento digital de
sinal), psicologia (percepção, cognição) e física (acústica).
Em termos práticos, a COMPUTAÇÃO MUSICAL se ocupa com questões do
tipo: digitalização dos sons, composição algorítmica, reconhecimento de expressões
musicais, softwares e hardwares para áudio, música e áudio na internet, softwares
voltados para educação musical, etc.
Na literatura brasileira o estudo e o desenvolvimento de pesquisas abrangendo a
informática, a música e a educação ainda é pouco difundido (PATRÍCIO ET AL, 2005).
Gradativamente, no entanto, tem despertado a atenção tanto dos educadores quanto dos
alunos, diante das infinitas aplicabilidades que as ferramentas podem proporcionar.
O problema é que, de acordo com Miletto (MILETTO ET AL, 2006), grande
parte dos educadores ainda evitam o uso destas tecnologias nas salas de aula. Isso
14
ocorre, segundo o autor, por falta de conhecimento sobre a maneira de aproveitá-las
como meio facilitador do processo de ensino-aprendizagem (MILETTO ET AL, 2004).
Kruger (KRUGER, 1996), alerta ainda para um outro problema: a maior parte
dos softwares brasileiros não são construídos seguindo pesquisas recentes sobre o
desenvolvimento cognitivo e musical. Acerca disso, Miletto (MILETTO ET AL, 2004)
pondera que independente do tipo de software voltado para a educação, é indispensável
o uso e a observação dos pressupostos pedagógicos de forma coesa com os objetivos de
tais softwares, buscando com isso propiciar o desenvolvimento dos estudantes, de forma
mais abrangente possível.
Será realizado neste trabalho, o estudo de requisitos para a elaboração de um
software voltado para o estudo de bateria. As especificações de tais requisitos seguirão a
fundamentação teórica educacional, musical e computacional, a fim de se obter o
melhor resultado.
1.1. Justificativa
No ensino tradicional, os livros têm sido as principais ferramentas de apoio para
a construção do conhecimento (PATRÍCIO ET AL, 2005). A adoção de um determinado
livro requer uma detalhada avaliação por parte do professor, afim de que seja escolhido
aquele que melhor se adéque à sua realidade, proporcionando conseqüentemente, a
melhor relação ensino/aprendizagem (COSTALONGA, 2004).
Apesar disso, tem-se percebido que os livros ainda representam um relativo
impasse para o ensino de algumas matérias, a exemplo da música, pois a maioria dos
alunos é resistente a absorção através desses (PATRÍCIO ET AL, 2005).
É nesse contexto que entra o uso de softwares como instrumento de apoio ao
ensino, de maneira a auxiliar o professor e serem utilizados em paralelo com os métodos
tradicionais, como os livros. O uso do computador nessa tarefa é uma realidade e vem
ganhando seu espaço notavelmente. Entretanto, os educadores ainda são resistentes
quanto ao uso das tecnologias, quer seja pela falta de conhecimento, quer seja pela falta
de qualidade nos softwares (KRUGER, 1996) (MILETTO ET AL, 2006).
15
Quanto as indiferenças por parte dos professores, Kruger (Kruger, 1996) salienta
que a solução para esse problema é investir em campanhas de divulgação dos recursos
tecnológicos a essa classe.
Em
relação
a
qualidade
dos
softwares
educativos
musicais,
ante
o
desenvolvimento, é fundamental um estudo mais aprofundado das principais áreas
envolvidas: computação, música e educação (PATRÍCIO ET AL, 2005). Tal estudo deve
ocorrer de maneira interdisciplinar e multidisciplinar, a fim de estabelecer e propiciar
conhecimentos suficientes para a elaboração de uma ferramenta que de fato seja útil e
utilizada.
O emprego em sala de aula de ambientes simulados de aprendizagem via software,
resultará em uma série de benefícios, tanto para professor quanto para o aluno. O
professor terá a praticidade, organização, agilidade e uma série de outras vantagens,
enquanto que o aluno poderá ser mais estimulado pelo alto poder interativo do
computador. No entanto, é importante observar que dentre tantas vantagens o principal
objetivo de um software educativo é a melhoria da relação ensino-aprendizagem
(COSTALONGA, 2004).
1.2. Objetivo geral
O objetivo geral desse trabalho é desenvolver um estudo de requisitos para um
software educativo voltado para o ensino de bateria, através do estudo investigativo e
interdisciplinar, envolvendo a computação, educação e a música. Dada a extensão do
tema, não se pretende aqui o desenvolvimento de uma ferramenta educativo-musical,
ficando essas atividades para uma outra abordagem.
1.3. Objetivos específicos
Os objetivos específicos são:
1. Delinear os principais fatos da Computação Musical;
2. Realizar estudo sobre as concepções educativo-musicais;
3. Elucidar o estudo com o levantamento de requisitos para um software
educativo-musical;
16
4. Implementar os principais requisitos em um protótipo;e
5. Realizar avaliação e refinamento do protótipo.
1.4. Estrutura do trabalho
Na seção 2 serão levantados os pontos relevantes acerca da computação musical,
indo da “origem” até o estado da arte. Em seguida, na seção 3, serão expostos os
fundamentos teóricos, métodos e novas correntes sobre a educação musical, finalizando
a seção com um apanhado sobre a classificação dos softwares educativos. Na sequência
(seção 4) buscou-se uma revisão acerca da Engenharia de Software e da Engenharia de
Requisitos. Os aspectos metodológico abordados neste trabalho serão explanados na
seção 5. O levantamento de requisitos será detalhado na seção 6, correspondendo aos
resultados proveniente das técnicas empregadas. Definidos os principais requisitos da
aplicação, desenvolveu-se o protótipo, mostrado na seção 7. Na seção 8 acontecerá as
etapas de avaliação e correção do protótipo. Por fim, a conclusão e trabalhos futuros
aparecem na seção 9.
2. COMPUTAÇÃO MUSICAL
17
Considerada como marco inicial do desenvolvimento da musica eletrônica, a
criação do telefone (MILETO ET AL, 2006), em 1876, veio a demonstrar que o som
poderia ser digitalizado, ou seja, com o invento foi possível evidenciar a possibilidade
de conversão das ondas sonoras em sinais elétricos (GOHN, 2007).
Apesar dos primeiros sons terem sidos gravados no ano de 1877, usando o
fonógrafo de Thomas Edison, o aprimoramento da técnica aconteceu apenas 10 anos
depois. Foi em 1887, quando alemão Emil Berliner criou o chamado gramofone, que a
gravação e reprodução dos sons se tornaram possíveis (MILETO ET AL, 2006). O
inventor foi o primeiro a produzir cópias de discos, feitos de vulcanite de borracha a
partir de uma matriz de zinco (FLORES, Rodrigo, 2004).
O primeiro ancestral dos atuais instrumentos eletrônicos surgiu somente em
1906, quando Thaddeus Cahill apresentou o seu dínamofone, chamado de
Telharmonium (Telarmónio) (MILETO ET AL, 2006). Tal equipamento consistia em
um conjunto de dínamos ligados a indutores eletromagnéticos que produziam sons em
várias freqüências. A escolha e alteração dos sons eram feitas por um painel de controle
e o som gerado, difundido por meio de amplificadores acústicos, interconectados por
cabos telefônicos. Tal equipamento é mostrado na figura 1.
Figura 1 – Telharmonium de Thaddeus Cahill
Fonte: http://miniurl.com.br/sMk
Para um época onde não existiam muitos componentes eletrônicos, o
Telharmonium representou um instrumento revolucionário pois empregava artifícios
18
habilidosos, uma vez que as “tecnologias” ainda não existiam. A terceira, das três
versões construídas, pesava mais de 200 toneladas e ocupava várias salas (MED, 1996).
A válvula triodo criada por Lee De Forest, possibilitou a geração de freqüência a
partir de sinais elétricos e com isso, a elaboração de instrumentos eletrônicos mais
intuitivos. O oscilador a válvula marcou uma nova fase da música eletrônica (MOORE,
2007).
Um dos primeiro instrumentos a usar dessa “nova tecnologia” foi o Theremin,
desenvolvido pelo russo Lev Termen, entre os anos de 1919 e 1920 (MILETO ET AL,
2006).O instrumento tinha um aspecto totalmente diferenciado dos outros equipamentos
da época, e a base do seu funcionamento era simples: possuía dois osciladores
controlados pelo movimento das mãos em torno de duas antenas, uma horizontal e
outra vertical, mas não havia a necessidade de tocá-las. A antena vertical media 45cm e
era responsável pela variação dos tons1 (pitch) , ou seja, ao aproximar a mão, a nota
subia, podendo alcançar até três oitavas2 a partir do tom (Dó) central. Já a antena
horizontal era responsável pelo volume, assim, ao encostar a mão a intensidade do som
diminuía até cessar (SOUZA, 2007).
Muitos outros instrumentos foram criados após o Theremin, como “Ondas
Martenot”, pelo francês Maurice dMartenot e o “Trautonium” pelo alemão Friedrich
Trautwein, por volta do ano de 1928. Outro grande inventor da época foi o alemão Jörg
Mager, responsável pelo desenvolvimento de várias peças na década de trinta
(FLORES, Rodrigo, 2004).
Ainda em 1928, o americano Lores Hammond produziu o primeiro órgão
elétrico. O órgão Hammond era um instrumento eletro-mecânico, pois utilizava de
engrenagens mecânicas em conjunto com circuitos elétricos, responsáveis pela
amplificação do sinal. O conjunto de rodas fônicas (tone wheels), formado por discos
dentados, giram a grande velocidade, estabelecendo uma variação do campo magnético,
captada através de captadores eletros-magnéticos. Posteriormente, esses sinais elétricos
são transformados em sinais acústicos (MED, 1996).
1
Refere-se ao intervalo entre duas notas.
Corresponde ao intervalo entre uma nota musical e outra com a metade (abaixo) ou o dobro (acima) de
sua freqüência.
2
19
Diante desse “explosivo” surgimento dos equipamentos de áudio e instrumentos
eletromecânicos, alguns compositores começaram a desenvolver técnicas de
composição que tratava o som de maneira diferente da utilizadas pelos compositores
convencionais. Usando sons pré-existentes, realizavam algumas edições, relativamente
simples como colagens, alteração da velocidade, inversão, etc (MIRANDA, 2006). Era
o nascimento da chamada música concreta.
Tratando-se de música concreta, alguns compositores se destacaram, como o
francês Pierre Schaeffer. Schaeffer com auxílio de Pierre Henry, compôs varias peças de
música concreta, na Radiodiffusion et Télévision Française (RTF), em Paris. Umas das
primeiras obras eletrônicas apresentada ao público foi Symphonie pour un Homme Seul
(1949-1950), um trabalho conjunto dos dois compositores (GOHN, 2007)
Segundo Zagonel (ZAGONEL, 2000), paralelo ao desenvolvimento da música
concreta, começa a surgir em 1952, na Alemanha, uma nova concepção musical: a
música eletrônica, onde as obras eram compostas utilizando-se das técnicas e conceitos
eletromecânicos para criação dos sons. Assim, em oposição aos princípios da música
concreta, a música eletrônica buscava compor sem o uso de sons naturais, mas sim a
partir de sons sintetizados.
A mescla dos princípios da música concreta e da música eletrônica dá o
embasamento para um novo modelo de concepção da música: a música eletroacústica.
(MILETO ET AL, 2006)
Nesse contexto logo inicia-se a produção de softwares. Conforme afirma Jacome
(JÁCOME, 2007), a primeira aplicação computacional voltado para a música foi criado
em 1957, por Max Mathews em Nova Jersey. O programa chamava-se Music I e possuía
apenas um timbre, uma forma de onda triangular e apenas podia ser alterada a afinação,
intensidade e duração dos sons.
Outras versões do programa foram criadas por Max ( Music II, Music III e o
Music IV), assim como diferentes aplicações surgiram através do uso de linguagens de
alto nível e a disseminação do “computador pessoal” (MILETO ET AL, 2006). Por esse
feito, muitos estudiosos consideram Max Mathews o pai da Computação Musical. A
figura 2 mostra Max Mathews e o seu invento, o Music I.
20
Figura 2 – Max Mathews e o Music I
Fonte: http://miniurl.com.br/133
Em 1964, Robert Moog inspirado pelos trabalhos de Max Mathews (JÁCOME,
2007), desenvolve um sintetizador controlado por teclados ou outros aparelhos e que
oferecia uma variedade de sons prontos para serem editados. Tal invento atraiu ainda
mais a atenção dos entusiastas, uma vez que estes estavam despertando para o uso de
equipamentos eletrônicos nas suas performances ao vivo (GOHN, 2007).
A partir de então, gradualmente, os teclados e órgãos tidos como analógicos
(botões, partes mecânicas), deram espaço para equipamentos revolucionários, que
tratavam do som de maneira digital. Surgiam os primeiros sintetizadores propriamente
ditos (MILETO ET AL, 2006).
Por volta da década de 1970, os sintetizadores eram monofônicos e
interconectados através de cabos simples. Com a chegada dos equipamentos
polifônicos, vários sons podiam ser executados através de um único teclado, no entanto
as interligações tornaram-se complexas, pois eram necessárias
muitas conexões
(COSENTINO, 2009). O padrão MIDI (Musical Instrument Digital Interface), foi
criado com o objetivo de simplificar e uniformizar as conexões entre os mais diversos
equipamentos (SILVA, Botelho, 2007), inclusive com o computador.
A criação da MIDI e a difusão dos computadores pessoais, representam um
marco na história da Computação Musical (MILETO ET AL, 2006). Nesse período, a
música que já era beneficiava por os softwares, passou também a usufruir dos
hardwares dos computadores (COSENTINO, 2009), já que esses também adotaram a
21
padronização MIDI, possibilitando a interligação física entre os mais diversos
componentes.
Segundo Flores (FLORES, Rodrigo, 2007) a difusão da gravação digital e do
padrão MIDI ocorreu graças a popularização dos computadores multimídias.
Atualmente, com a sensível redução dos custos e acessibilidade aos meios
computacionais e equipamentos musicais, a Computação Musical continua a expandir,
adentrando em novas áreas como a educação musical (MILETO ET AL, 2006), que será
vista na próxima seção.
22
3. EDUCAÇÃO
MUSICAL
E
O
USO
DE
SOFTWARES
EDUCATIVOS
Os primeiros estudos envolvendo a educação musical e a COMPUTAÇÃO
MUSICAL, datam de 1990 (DENARDI, 2008). No entanto, de acordo com Patrício
(PATRÍCIO ET AL, 2008) o Brasil ainda hoje não possui uma linha de pesquisa sólida,
principalmente quando comparada a produção de outros países. MacGregor, citado por
Kruger (KRUGER, 1996), comenta que a utilização de sintetizadores e afins, em salas
de aula, são comumente encontrados em países como Austrália, Inglaterra e Estados
Unidos. Nesse sentido, Kruger (KRUGER, GERLING & HENTSCHKE 1999) reforça
a necessidade da intensificação e apoio as pesquisas quanto ao uso de softwares no
ensino instrumental:
Os softwares desenvolvidos no Brasil podem ser considerados mais
adequados a realidade social e musical do país e, portanto as pesquisas
dessa natureza precisam ser incentivadas. Além da continuidade desta,
também considera-se necessário proporcionar aos professores instrumentos
de avaliação apropriados a complexidade do processo educacional.
Conforme Moreira (MOREIRA, 1987) e Galvis (GALVIS, 88), não é intenção
dos softwares educativos (SE) substituir problemas já solucionados de maneira mais
simples. Galvis (GALVIS, 88) comenta ainda, que o computador deve ser explorado no
processo de ensino como um meio para executar “situações difíceis ou impossíveis de
se obter.”.
De fato o uso dos inúmeros recursos tecnológicos de forma inteligente e criativa
pode proporcionar, tanto aos professores quanto aos alunos, novas experiências,
tornando as aulas mais eficientes (RAMOS, 91).
No entanto, ainda existem muitos profissionais da educação, em destaque os
professores, que não acolhem as novas ferramentas tecnológicas como um instrumento
de apoio a sua prática pedagógica. A grande parte dessas rejeições acontece por falta de
conhecimento sobre a maneira de como aproveitá-las como meio facilitador do processo
de ensino-aprendizagem (MILETTO ET AL, 2004).
Para Denardi (DENARDI, 2008), essa resistência tem como causa base a crença
de que o trabalho do professor de música seja substituído pelo uso de ferramentas
computacionais. A autora completa afirmando que “Essa atitude pode ser modificada a
23
partir de uma maior divulgação dos fundamentos e ferramentas tecnológicas disponíveis
aos educadores musicais (...)”. Somente através do contato com informações e/ou com
experiências práticas, os benefícios do uso complementar de sistemas informatizados
poderão ser constados. Por conseguinte, professores e alunos, estando convencidos
quanto ao uso das ferramentas, poderão partilhar as suas experiências sobre as
aplicações relacionadas a música (MILETTO ET AL, 2004).
Relativo a qualidade dos sistemas educativos, conforme afirmado por Carraher,
citado por Ramos (RAMOS, 1991), “são dois basicamente os contextos nos quais
podem ser inseridos os aspectos observáveis na qualificação de um software
educacional: o educacional ou pedagógico e o técnico computacional. ”.
3.1. Concepções educativo-musicais
Na elaboração de softwares, em especial aqueles voltados para educação, é
importante atentar para os pressupostos pedagógicos, relativos a área de ensino, em
coerência com a intenção da ferramenta (MILETTO ET AL, 2004). Assim, um ambiente
educacional deve ser concebido para alcançar os objetivos pedagógicos desejados,
subordinando para tanto a sua qualidade técnica às necessidades de ensino
(STAHL,1990). Hentschke (1993) citado por Lima, Oliveira & Ramos (LIMA,
OLIVEIRA & RAMOS, 2002), avalia que “Toda prática educacional está direta ou
indiretamente ligada a uma teoria de aprendizagem. Um software com que se deseja
propiciar experiências no campo da música tem que conter alguma concepção
musical.”.
Infelizmente, no Brasil, de acordo com Kruger (KRUGER, 1996), poucos SE
são criados segundo os estudos que norteiam o desenvolvimento cognitivo e musical. O
mais preocupante é que, conforme a autora, por estarem fundamentados em métodos
tradicionais de apresentação, aplicação dos conceitos e avaliação dos resultados, esses
programas acabam tendo a sua estrutura técnica, a forma de avaliação e o conteúdo,
comprometidos (KRUGER, GERLING & HENTSCHKE 1999). Nesse sentido Ramos
(RAMOS, 1991) lembra que “é preciso estar alerta contra os atraentes circos
tecnológicos, propagandeados pela indústria da área, pois os mesmos, frequentemente
retratam visões pedagógicas retrógadas.”.
24
Em relação a educação musical, dentre os diversos pontos de vista de ensino,
destacam-se o tradicional e o progressista. Na abordagem tradicional, o professor é o
centro do ensino e promove basicamente valores relativos ao ensino de música erudita
ocidental, execução instrumental, dados históricos. Nessa concepção, o método é
prioritário em detrimento as necessidades do aluno, assim o fundamento dessa
metodologia consiste em estudar e executar (mecanicamente) uma obra. No conceito
progressista, o foco do ensino é o aluno, o professor passa a ter o papel de facilitador,
mas sem perder a importância no processo. Não existe um método definido, por isso as
experimentações são a base para a composição, improvisação e apreciação (LIMA,
OLIVEIRA & RAMOS, 2002).
Neste trabalho será adotada a linha progressista, por ser considerada atualmente
a mais importante na elaboração de ambientes computacionais educativos, uma vez que
aproveita as características do computador relativas a apresentação do conteúdo,
interação e simulação, e que colaboram com a construção do conhecimento por parte
dos alunos (FICHMAN ET AL, 2003).
As experiências práticas devem ser usadas como base na compreensão da teoria
musical, sendo assim as atividades musicais devem propiciar o envolvimento direto
com a música (FICHEMAN ET AL, 2003). Segundo Hentschke (HENTSCHKE, 1996)
citado por Miletto (MILETTO ET AL, 2004), “ O referencial teórico para muitas
pesquisas curriculares na Educação Musical brasileira segue as diretivas do Modelo
(T)EC(L)A, de
Keith Swanwick (SWANWICK, 1979) ”. O estudo de requisitos
proposto neste trabalho também adotará tal modelo.
O Modelo (T)EC(L)A (SWANWICK, 1979) define um grupo de cinco
atividades musicais ou parâmetros de experiências musicais (MILETTO ET AL, 2005),
sendo que dentro dessas, são priorizadas três como primárias por proporcionarem
maior envolvimento com a prática da música. Estas atividades referem-se a execução
[E], a composição [C], e a apreciação musical [A] (FICHEMAN ET AL, 2003). As
outras atividades são chamadas de complementares e dizem respeito ao aprendizado
técnico [(T)] e literário [(L)] sobre música. Viana Júnior e Castro Filho (VIANA
JÚNIOR & CASTRO FILHO, 2005) reforçam afirmando que “essas duas últimas
atividades não são centrais ao desenvolvimento musical, sendo dependentes e
25
trabalhadas nas experiências musicais obtidas a partir da composição, performance e
audição.”
Na figura 3 são mostradas as definições para os cinco parâmetros de experiência
musical do Modelo (T)EC(L)A de Swanwick (KRUGER, GERLING & HENTSCHKE,
1999).
Figura 3 – Definições das atividades do Modelo (T)EC(L)A de Swanwick.
Fonte: KRUGER, GERLING & HENTSCHKE, 1999.
26
Adotando o estudo de Swanwick como referencial teórico, fica evidente
quais atividades um SE deve contemplar. Outros pontos a serem observados são a
identificação do público alvo, a definição do conteúdo e sua forma de apresentação
(MILETTO ET AL, 2004).
3.2. Classificação
Em um sentido amplo, todo software pode ser considerado uma ferramenta
educativa, desde que esteja inserido num contexto orientado por uma metodologia e que
potencialize o processo de ensino-aprendizagem (GIRAFFA & VICCARI, 1999). No
entanto, nesta seção, para efeito quantitativo, serão abortados apenas os softwares com
uma ligação mais íntima com a música.
Conforme proposto por Kruger (KRUGER, GERLING & HENTSHKE, 1999),
levando em consideração “seus objetivos principais e a forma de utilização no período
das aulas ou estudo”, foram designadas duas famílias de softwares educativos: os de
atuação direta e de atuação indireta.
3.2.1.
Família de softwares de atuação direta
Corresponde aos programas cuja a inserção no ensino se dá de forma mais
“compromissada”, ou seja, além de auxiliar o professor nas atividades pedagógicas,
realizam outras tarefas como, por exemplo, o monitoramento de desempenho técnico
do aluno.
Miletto et al (MILETTO ET AL, 2004) afirmam que essa categoria é
desenvolvida exclusivamente para os usuários que pretendem usar o computador para
adquirir conhecimentos sobre determinada área da música. É importante ressaltar que os
usuários compreendem tanto os alunos como os professores.
Devido a essas peculiaridades, possuem apenas dois subgrupos, que tem por
características principais:
i.
Exercícios e prática: normalmente de programação simples, objetiva a
fixação das atividades através da (repetitiva) prática. É evidente o uso de
práticas pedagógicas baseadas
na relação estímulo-resposta e se
aproxima da metodologia tradicional do ensino da música.
27
ii.
Ambiente simulado de aprendizagem: como o título propõe, objetivam
simular um ambiente e/ou equipamentos ( uma bateria ou uma guitarra,
por exemplo) através dos quais o aprendiz possa interagir, experimentar e
adquirir novos conhecimentos. Iazzeta (IAZZETTA, 1994) comenta que
“o uso de computadores associados a placas de som rompeu a
necessidade de se possuir um instrumento físico para performance e
composição musical.”. As facilidades trazidas pelas tecnologias
permitem que um leigo, mesmo que teoricamente, investigue, acesse,
crie, manipule e execute trechos sonoros complexos. Ao contrário do
grupo anterior, é fundamentado segundo a linha construtivista e faz uso
das características do computador relativas a apresentação do conteúdo,
interação
e simulação, e que colaboram com a construção do
conhecimento (FICHMAN ET AL, 2003). Esse grupo vem de encontro
com a proposta deste trabalho.
No Anexo A, podem ser vistos alguns exemplos de softwares de atuação direta, bem
como as suas principais características.
3.2.2.
Família de softwares de atuação indireta
Segundo Kruger (KRUGER, GERLING & HENTSHKE, 1999), enquadram-se
nesse grupo todos aqueles ambientes de teoria musical, inicialmente concebidos para
serem usados em aulas teóricas, e que complementam essas. Dentro dos sub-grupos
destacam-se:
i.
Jogos: possuem alto poder de motivação, devido a pedagogia lúdica
implícita na sua concepção. Normalmente exploram as atividades do tipo
“desafios”, o que impõem os conceitos da ótica construtivista. Em termos
computacionais, podem ser simples ou fazer uso de recursos avançados
de áudio e vídeo, marcantes nos jogos atuais (SILVA, 2003).
Pode
também ser incluído nesse grupo o Karaokê3, usado na exploração e
desenvolvimento do canto.
3
Karaokê é um termo japonês que designa pequenos arquivos de música, ou informação musical,
(normalmente .mid ou . kar) e, embora signifique “sem orquestra”, esse arquivos correspondem a
músicas sem vocais.
28
ii.
Editores de partituras: como o nome sugere, nesse grupo estão as
aplicações que realizam a criação e edição de partituras4. Alguns
possuem um editor avançado que dispensa o uso do mouse,
“transformando” os comandos midi de um instrumento (o teclado
normalmente) em notação musical. Do mesmo modo é possível importar
e exportar as partituras, assim como convertê-las em arquivos .midi e
vice-versa. Uma grande utilidade desses ambientes é na elaboração das
chamadas pré-produções musicais, pois o músico poderá escrever a obra
e realizar a audição da informação escrita como uma amostra, antes que
seja submetida a outras etapas da produção. Outra recurso presente em
boa parte desses softwares é o OCR (Optical Character Recognition), ou
seja, reconhecimento ótico de caracteres, o que possibilita através da
digitalização (“scanear”) de partituras em papel a recuperação e reedição dos símbolos musicais (FRITSCH ET AL, 2003).
iii.
Gravadores de áudio: permitem a digitalização do som, através de
periféricos (hardwares) específicos, para posterior edição (correção de
equalização, ruídos, aplicação de efeitos e tempo, entre outros). Aqui
estão inseridas as chamadas DAW – Digital Áudio Workstation, ou
estação para edição de áudio digital. As DAW’s possuem recursos
avançados
como
a
gravação
de
múltiplos
canais
(pistas)
simultaneamente, o que economiza tempo pois cada instrumento é
registrado em um canal diferente, permitindo assim a sua manipulação
individual. Outra característica muito útil é o overdub, que consiste
adicionar novos instrumentos aos já gravados anteriormente. Desse modo
é possível, por exemplo, um único músico, pista a pista, gravar uma
música completa. Por esse fato é muito usado por estudantes para
registrar as composições/estudos, além de enriquecer as técnicas de
processamento de som. Vale ressaltar que esses ambientes exigem alta
performance (processamento e memória RAM), muito espaço em disco
rígido, além de periféricos externos, como placa de áudio, mixers,
microfones, etc.
4
Partitura é uma representação padronizada mundialmente da informação musical, para tanto dispõe de
notação própria que indicam as características do som.
29
iv.
Apoio a aprendizagem: geralmente na forma de tutorias sobre um tema
especifico dentro do domínio da música, empregam normalmente a
multimídia para criar um ambiente mais agradável. Segundo Yavelow,
citado por Fritsch (FRITSCH, 2003), esse subgrupo constituem
ferramentas úteis para o complemento das aulas musicais e pode ainda
ser ainda fracionados de acordo com a abordagem:
•
História e apreciação musical: biografia de compositores,
regionalismo musical, apreciação de obras, etc.;
•
Treinamento
auditivo:
ditados
rítmicos,
melódico
e/ou
harmônicos, afinação, “ouvido absoluto”, etc.;
•
Teoria instrumental: teoria de bateria/ piano/violão, ensino de
improvisações, analise de execuções, etc.; e
•
Teoria e análise: ensino de teoria musical, análise harmônicorítmica ou melódica, etc.;
v.
Acompanhamento: são ferramentas muito usadas no estudo de um
determinado instrumento, pois possibilita o acompanhamento automático
como se o músico estivesse tocando com demais instrumentistas
(FRITSCH, 2003). Assim, por exemplo, um baterista pode acompanhar
um playback5 previamente criado, inclusive com as vozes e outros
instrumentos, exceto a bateria, para fins de estudo. Essa técnica, em
termos musicais, caracteriza o chamado play along, ou seja, “toque
junto”. Aqui também podem ser enquadrados os tocadores de karaokê
com funções avançadas onde é possível escolher quais instrumentos
deverão ser executados.
Alguns exemplos de softwares de atuação direta, e suas principais características.
Podem ser vistas no Anexo B.
4. ENGENHARIA DE SOFTWARE
5
Playback representa uma música ou ainda uma pré-produção, onde houve a gravação prévia de alguns
instrumentos para uso posterior em apresentação ou show. Popularmente é conhecido como uma música
“sem voz”.
30
Entende-se por engenharia de software o conjunto de subsídios fundamentais
para o controle do desenvolvimento, a fim de se alcançar a alta qualidade de softwares
(PRESSMAN, 2006). Para o autor são três os subsídios fundamentais, a saber:
•
Métodos: fornecem as informações de “como fazer”. Abordam passos
que compreendem o planejamento e estimativa, análise de requisitos,
projeto da estrutura de dados, arquitetura de programa e algoritmo de
processamento, codificação, teste e manutenção.
•
Ferramentas: fornecem o apoio automatizado ou semi-automatizado aos
métodos. As inúmeras ferramentas existentes atualmente apóiam a
execução dos métodos propostos pela engenharia.
•
Procedimentos: representam a ligação entre os métodos e as ferramentas,
promovendo o desenvolvimento racional do software.
Ainda sobre a engenharia de software, Sommerville (SOMMERVILLE, 2003)
define: “é uma disciplina que se ocupa de todos os aspectos da produção de software,
desde os estágios inicias até a manutenção, quando o sistema já entrou em operação.”.
Nesse contexto, nota-se que é função do engenheiro de software a adoção dos conceitos
de forma sistematizada, primando para a elaboração de produtos que venham de
encontro com as necessidades do usuário/cliente.
Em se tratando de SE, a engenharia deve abraçar além dos cuidados básicos de
desenvolvimento, cuidados com os pressupostos pedagógicos e didáticos que
constituem a base dos meios de ensino/aprendizagem (SANTOS, 1998). O autor
justifica que softwares educativos diferem dos sistemas computacionais tradicionais,
como aplicações bancárias ou automação de empresa, onde imperam tarefas préestabelecidas e previsíveis.
Assim, nesse trabalho foram levados em consideração os principais momentos
da análise de requisitos convencional em paralelo com as particularidades que
permeiam o ensino da música.
4.1. Engenharia de requisitos
31
O objetivo fundamental ao se desenvolver um software qualquer é que esse
venha a suprir as necessidades previstas pelos usuários. Para tanto, é preciso que haja
uma correta especificação de tais necessidades, que culminará posteriormente nos
chamados requisitos de software. A engenharia de requisitos, como um subdomínio da
engenharia de software, vem propor um conjunto de técnicas para a aquisição,
refinamento e verificação das necessidades dos clientes/usuários (VASCONCELOS ET
AL, 2006). Assim, a engenharia de requisitos representa uma etapa crucial no ciclo de
desenvolvimento, onde além do conhecimento teórico, aborda questões gerenciais,
organizacionais, sociais e econômicas embutidas no processo (PRESSMAN, 2006).
Preece, Rogers & Sharp (PREECE, ROGERS & SHARP, 2005) definem
requisito como “uma declaração sobre um produto pretendido que especifica o que ele
deveria fazer ou como deveria operar.”. As autoras enfocam ainda sobre a importância
de se obter requisitos “mais específicos, não ambíguos e o mais claro possível.”.
Para Sommerville (SOMMERVILLE, 2003) um requisito pode representar uma
propriedade geral do sistema, sua restrição específica ou ainda uma restrição no seu
desenvolvimento, indo de encontro com o que afirmam Fiorini, Staa & Baptista
(FIORINI, STAA & BAPTISTA, 1998), uma vez que segundo os autores, os requisitos
não se referem apenas às funcionalidades (requisitos funcionais), mas também às
questões não funcionais, como desempenho, portabilidade, etc.
Embora alguns autores considerem necessária a classificação mais abrangente
dos requisitos, de modo geral, os requisitos são classificados em dois tipos: funcionais e
não funcionais (ZAPAROLI, 2003), e serão vistos com maiores detalhes nas subseções
4.1.1 e 4.1.2.
Para Alencar (ALENCAR, 1999), além dos requisitos funcionais e não
funcionais, devem ser consideradas também as características “relacionadas com metas,
políticas e estratégias da empresa”, o que o autor chama de requisitos organizacionais.
Sommerville (SOMMERVILLE, 2003) comenta sobre os requisitos de domínio, que são
aqueles relativos ao contexto da aplicação. Fiorini, Staa e Baptista (FIORINI, STAA &
BAPTISTA, 1998) acrescentam três categorias: requisitos inversos – definem o que o
software não deve fazer; requisitos de design e implementação – condições que limitam
32
como o software poderá ser implementado; e requisitos não técnicos – acordos,
condições ou termos contratuais.
4.1.1. Requisitos funcionais
São relativos às funções que o software ou um componente do sistema deve ser
capaz de executar (FIORINI, STAA & BAPTISTA, 1998). Ou seja, determinam o quê
ou qual o resultado será produzido (saída), de acordo com uma ação (entrada)
(ZAPAROLI, 2003).
Preecer, Rogers e Sharp (PREECER, ROGERS & SHARP, 2005) definem que
os “requisitos funcionais captam o que o produto deveria fazer” e argumentam que a
compreensão desses requisitos para o desenvolvimento de sistemas interativos é muito
importante.
4.1.2. Requisitos não funcionais
Para Alencar (ALENCAR, 1999) os requisitos não funcionais retratam as
“restrições, aspectos de desempenho, interfaces com o usuário, confiabilidade,
segurança, manutenabilidade, portabilidade, padrões etc., bem como aspectos sociais e
políticos.”.
Zaparoli (ZAPAROLI, 2003) faz uma associação entre o conceito de requisitos
não funcionais com a idéia de restrição sobre como os requisitos funcionais são
implementados. Conclui-se com isso, que os requisitos funcionais descrevem o que o
sistema deve fazer, enquanto os não funcionais descrevem como os requisitos
funcionais são implementados.
Fiorini, Staa e Baptista (FIORINI, STAA & BAPTISTA, 1998) relaciona os
requisitos não funcionais com padrões de qualidade, entre os quais:
•
Acurácia: precisão dos dados e resultados, relativo a realidade que
representam;
•
Precisão: número de algarismo de cálculo dentro das margens de
tolerância aceitáveis;
33
•
Confiabilidade: conforme solicitações o software produz resultados
corretos, precisos e acurados;
•
Segurança: os riscos pessoais, materiais, ecológicos ou financeiros
gerados pelo software são compatíveis com a natureza do serviço;
•
Desempenho: requer recursos computacionais, humanos, financeiros e
outros, em volume compatível com a natureza do serviço;
•
Rentabilidade: o retorno esperado resultante do uso do sistema,
deduzidos os custos de desenvolvimento, de manutenção, de uso e de
recuperação de erros;
•
Manutenibilidade: o artefato está apto para ser fácil, rápido e
corretamente mantido;
•
Disponibilidade: o artefato está pronto para ser utilizado sempre que
necessitado;
•
Recuperabilidade: o artefato permite a recuperação no caso de erros e
acidentes;
•
Proteção: o artefato é capaz de perceber a ocorrência a interceptar erros,
acidentes e agressões externas; e
•
Utilizabilidade: o artefato está apto a ser utilizado pelos usuários finais a
que se destina. Requer níveis aceitáveis de treinamento, suporte e
habilitação, necessários a classes especificas de usuários de modo que o
sistema ou artefato possa se utilizado eficazmente.
4.2. Usabilidade e software educacional
A usabilidade representa um conjunto de metas que objetiva a criação de
produtos onde vigorem a facilidade de uso, a eficiência e que sejam agradáveis de se
usar (PREECE, ROGERS & SHARP, 2005).
34
A NBR 9241-11 (ABNT, 2002) define: “Usabilidade: Medida na qual um
produto pode ser usado por usuários específicos para alcançar objetivos específicos com
eficácia, eficiência e satisfação em um contexto específico de uso.”.
Referente as metas nas quais a usabilidade é dividida, encontram-se:
•
Eficácia: indica o quanto o sistema é bom em realizar o que se espera
dele (PREECE, ROGERS & SHARP, 2005);
•
Eficiente: indica a quantidade de recursos utilizados para se alcançar um
determinado objetivo do usuário (ABNT, 2002);
•
Segurança: assegura baixa taxa de erros e quando ocorrem devem
permitir a solução e o retorno para o estado anterior. O usuário deve está
seguro de situações perigosa ou indesejáveis (PREECE, ROGERS &
SHARP, 2005);
•
Utilidade: refere-se ao comportamento adequado que o sistema realiza
para atingir as necessidades do usuário (ABNT, 2002).
•
Facilidade de aprender (learnability): refere-se a facilidade com que o
usuário aprende a usar as funções básicas do sistema (PREECE,
ROGERS & SHARP, 2005); e
•
Facilidade de memorização (memorability): refere-se a facilidade com
que o usuário lembra das funções, atalhos, comandos já aprendidos
anteriormente sem a necessidade de re-aprender (PREECE, ROGERS &
SHARP, 2005).
Para Fritsch (FRITSCH ET AL, 2003) quanto mais
as etapas de
desenvolvimento de um sistema computacional abraçam as metas proposta pela
usabilidade, maior as chances de se produzir algo realmente usável, com qualidade de
fato. Frisch ressalta que “Programas educativo-musicais envolvem conceitos da
educação musical e de disciplina correlatas, que também devem ser observadas como
critérios de qualidade.”.
35
Flores (FLORES, Luciano, 2002) afirma que os softwares educativos musicais
demandam, além das preocupações clássicas com a usabilidade, cuidados quanto a
representação das complexas informações relativas ao domino musical envolvido. O
autor destaca essas informações como sendo: a) geração de sons (notas musicas,
características fundamentais como altura, intensidade, timbre, etc.); b) edição e
manipulação dos símbolos musicais (pauta, pausa, claves, etc.); e c) controle da emissão
dos sons (velocidade, ritmo, elementos visuais sincronizados, etc.).
36
5. ASPECTOS METODOLÓGICOS
Conforme visto, na seção 2 foi apresentada uma pesquisa bibliográfica com a
intenção de revisar os estudos relativos ao uso do computador em beneficio da música.
Assim, foram levantados os principais marcos do desenvolvimento da computação
musical e de suas vertentes.
Na seção 3, uma segunda revisão bibliográfica fez-se necessário para o
refinamento das bases pedagógicas da educação musical, cujo embasamento foi
alcançado através de estudos sobre o Modelo (T)EC(L)A, de Keith Swanwick
(SWANWICK, 1979), muito adotado em grande parte das pesquisas e estudos
realizados sobre a educação musical (COSTALONGA ET AL, 2004). Além disso podese realizar a identificação das principais classes de softwares educativo-musicais.
Por fim, na seção 4, buscou-se uma revisão dos conceitos de Engenharia de
software, que servirão de fundamentação para as etapas de levantamento e análise de
requisitos.
4.1. Contexto e população
Fez-se necessário a escolha de uma população (escola de música) representativa,
a fim de elucidar as questões práticas envolvidas nessa pesquisa, bem como obter um
resultado mais próximo da realidade. Os critérios para a escolha da escola foram: a)
estar situada na cidade de Jaguarari – Ba; e b) oferecer aulas de bateria.
A escola selecionada possui sede própria com uma área de aproximadamente
300m², subdividida em 3 salas: uma para as aulas de teclado, outra para aulas de
violão/guitarra e a terceira é utilizada para as aulas de bateria. Nesta última estão
dispostas duas baterias da marca Staff Drums, um amplificador Cíclotron e um
metrônomo analógico da marca Boss, constituindo os equipamentos utilizados na
maioria das aulas práticas. A escola possui ainda um material de apoio composto por
um notebook e um projetor de vídeo, que é compartilhado em todas as outras aulas.
Atualmente conta com dois professores (referenciados neste trabalho por P1 e
P2), ambos capacitados para lecionar todos os cursos oferecidos. As aulas de bateria
acontecem no período das 14hs às 16hs, nos dias de segunda, quarta e sexta-feira.
37
Atualmente existe apenas uma turma composta por 5 alunos (referenciados neste
trabalho por A1, A2, A3, A4 e A5) matriculados nas aulas de bateria.
Outras informações relevantes sobre o perfil dos professores e alunos serão
expostas na seção 6.
É válido ressaltar que todos os participantes (professores e alunos) foram
conscientizados sobre a finalidade deste trabalho. A confirmação de participação foi
obtida através de uma Carta de Consentimento, cuja cópia encontra-se no Apêndice A.
5.2. Desenvolvimento e avaliação de softwares educacionais
Um ambiente educacional quer seja um software ou um web site, deve ser
concebido para alcançar os objetivos pedagógicos desejados, subordinando para tanto a
sua qualidade técnica às necessidades de ensino (STAHL,1990). No mesmo contexto
Kruger (KRUGER, 2006) afirma que “Um software Educativo Musical pode ser
considerado de qualidade quando apresenta as seguintes características: Parâmetros
pedagógicos; Interações sociais; e Informática & Educação Musical.”.
No entanto, como alcançar um ponto de equilíbrio entre os principais objetivos
que norteiam a concepção dos softwares, a educação e a música?
Em se tratando de educação no domínio musical, alguns desafios são evidentes e
vão além das preocupações clássicas, como os critérios da usabilidade. Assim, faz-se
necessário cuidados redobrados quanto apresentação e manipulação das informações do
domínio a serem desenvolvidas. Flores (FLORES, Luciano, 2002), comenta que “é
necessário seguirmos um método para o seu desenvolvimento e que este inclua etapas
de avaliação.”.
Nesse sentido, optou-se por seguir o modelo proposto por Winckler, Nemetz e
Lima (WINCKLER, NEMETZ & LIMA, 2000), denominado Projeto Centrado no
Aprendiz (PCA). O PCA é na verdade uma extensão do Projeto Centrado no Usuário
(PCU).
Segundo Lewis e Gould citado por Winckler, Nemetz e Lima (WINCKLER,
NEMETZ & LIMA, 2000) três aspectos caracterizam PCU: “processo cíclico de
desenvolvimento, ênfase nos usuários e suas tarefas e avaliação empírica da interface.”.
38
Assim, esses aspectos correspondem a uma seqüência de eventos, onde sucessivos
protótipos são analisados e evoluem para o produto final. A figura 4 mostra como tal
ciclo ocorre.
Figura 4 – Ciclo de Vida de PCU
Fonte: WINCKLER, NEMETZ & LIMA, 2000
No decorrer dessa sucessão de eventos, a participação dos usuários objetiva a
identificação e refinamento dos requisitos ao passo que os problemas com a interface
serão apontados.
Analisando cada etapa do ciclo, têm-se:
i.
Conhecer usuários e suas tarefas: Têm-se aqui dois objetivos: (a)
conhecer as pessoas (usuários) e (b) suas tarefas (o que eles farão
com sistema). É preciso definir quem usará o sistema, traçar o
perfil desses, incluindo informações sobre a idade, a escolaridade,
conhecimento sobre o tema e o uso do computador (FLORES,
Luciano, 2002). Observar o usuário no seu ambiente de trabalho,
realizando as tarefas normais do dia-a-dia poderá revelar
requisitos ainda não descobertos nas entrevistas. É importante
porém, que sejam atentadas os pontos que de fato promovem a
assimilação do conhecimento. Coletadas as informações sobre os
alunos e suas tarefas, avalia-se com a equipe de desenvolvimento
o status do projeto, considerando quais requisitos serão
implementados. Conhecidos os usuários e suas tarefas, inicia-se a
etapa de prototipação.
ii.
Prototipação: As informações levantadas na etapa anterior serão
implantadas em um protótipo, que nada mais é do que uma visão
simplificada do projeto, normalmente feitas a papel e caneta.
39
Posteriormente irá evoluir para simulação funcional, próxima do
produto final. Os protótipos constituem uma forma de baixo custo
para a representação aproximada do produto final.
iii.
Avaliação de usabilidade: É objetivo primordial nessa etapa a
detecção de possíveis erros que possam comprometer a interação
do usuário com a ferramenta. Representa por isso uma das etapas
mais importantes do ciclo. Os problemas encontrados nesse
momento serão corrigidos e implementados em um novo
protótipo, que por sua vez será re-avaliado. Faz uso de métodos,
escolhido entre vários disponíveis, classificados em métodos de
inspeção de usabilidade e testes empíricos com usuários.
Por definição o PCU tem como foco principal assegurar que as atividades do
usuário sejam realizadas da melhor maneira possível, usando-se para tanto o
computador. No entanto, segundo Winckler, Nemetz e Lima (WINCKLER, NEMETZ
& LIMA, 2000), esta é uma representação limitada, em se tratado de software
educacional, uma vez que não há garantia de aprendizado, mesmo sua interface sendo
de fácil interação. Os autores observam que levando em consideração a evolução do
aprendizado, junto com as evidentes diferenças entre os diversos perfis, faz-se
extremamente necessário que a ferramenta de ensino possa se “adaptar” a cada um
desses usuários, acompanhando a evolução das pessoas ao longo do processo de ensinoaprendizagem.
5.3. PCA - Projeto Centrado no Aprendiz
O Projeto Centrado no Aprendiz (PCA), foi proposto por Winckler, Nemetz e
Lima (WINCKLER, NEMETZ & LIMA, 2000) com a intenção de suprir as
necessidades do usuário/aprendiz em relação ao PCU. A proposta é que a aprendizagem
seja colocada em primeiro plano em relação as tarefas tidas como de apoio. São
enfatizados três parâmetros tidos como fundamentais: motivação, crescimento e
diversidade.
A motivação deve estar presente nas atividades a serem desempenhadas dentro
do ambiente de ensino, promovendo assim uma boa relação do aluno com a tecnologia.
Kruger (KRUGER, 2006) comenta que o uso do computador pode ser motivador para
40
alguns, mas poderá inibir aqueles menos afeiçoados, sendo que também é papel do
educador promover a motivação dos alunos antes e durante as aulas.
O crescimento é um processo que se espera dentro das atividades de ensino. Um
aluno ao longo do tempo irá adquirir novas experiências e conhecimentos, de forma que
o
ambiente
deverá
acompanhá-lo,
promovendo
novas
oportunidades
de
desenvolvimento, desafios e tarefas. Segundo Flores (FLORES, Luciano, 2002), um
software com o qual se almeja promover o ensino deve atentar para com a
parametrização das tarefas, de modo a moldá-las às necessidades do aprendiz e do
professor.
Por fim, a diversidade proposta no PCA diz respeito ao perfil do usuário. A
heterogeneidade está presente em qualquer grupo de alunos: diferentes culturas,
experiências, interesses, etc.. É preciso um bom preparo do conteúdo didático a fim de
se conseguir englobar a maior parte dos tipos de alunos. Até porque, comentam
Campos, Campos & Rocha (CAMPOS, CAMPOS & ROCHA, 1996) “o homem
percebe o mundo através do sistema sensório, o planejamento de uma interface deve
considerar os sentidos visual, táctil e auditivo. É importante notar os níveis de
habilidades pessoais e as diferenças individuais entre os usuários.”.
Observa-se que a metodologia de desenvolvimento proposta por PCA, sugere
que o software educativo contenha estruturas de apoio ao aluno de maneira a possibilitar
o aprendizado de forma inovadora. Assim, são estratégias do PCA a criação de
ambientes de modelagem e simulação, onde o aluno possa interagir com base em
situações reais, podendo representar uma infinidade de eventos do campo de domínio
em estudo (WINCKLER, NEMETZ & LIMA, 2000).
Diante dessas necessidades o ciclo de vida do PCU (vide figura 4) foi estendido
para atender os requisitos propostos pelo PCA. A extensão proposta sugere alterações na
primeira e na terceira etapa do ciclo (vide figura 5):
41
Figura 5 – Ciclo de vida do PCU modificado.
Fonte: WINCKLER, NEMETZ & LIMA, 2000
•
Conhecer usuário, alunos e suas tarefas: verificou-se que cuidados
especiais deveriam ser dados em relação aos alunos, considerando-os
como usuários que necessitam de tratamento diferenciado. Além disso,
em um ambiente de aprendizado podem haver diversos tipos de usuários,
alguns possuem conhecimento sobre a área de domínio e outros não,
como por exemplos os professores que certamente conseguirão maior
desenvoltura ao usar o sistema. Por isso, deverão ser atentadas as
concepções pedagógicas envolvidas no ambiente e a adequação destas,
de acordo com os perfis traçados (WINCKLER, NEMETZ & LIMA,
2000). Uma escala simples e muito adotada é classificação dos alunos
em subgrupos (iniciante, intermediário ou avançado) onde o conteúdo,
diálogos e atividades são diferenciados considerando-se esse nível
(FLORES, Luciano, 2002).
•
Avaliação multidisciplinar: no caso de um software educativo, cuidados
com a usabilidade devem ser redobrados,
requerendo para tanto o
trabalho de avaliação feito por vários profissionais, em sintonia com as
áreas do projeto. Uma equipe composta por vários especialistas
(programadores, professores, designers, etc) poderá discutir soluções e
alternativas, extraindo resultados de diferentes perspectivas. Os autores,
em outro trabalho, Estudo de Caso da Aplicação do Método de Avaliação
Heurística em um Projeto Multidisciplinar (WINCKLER, NEMETZ &
LIMA, 1996), constataram que agentes especializados e treinados (no
caso professores de música) conseguiram identificar problemas relativos
42
ao domínio musical nos protótipos analisados, enquanto que os
desenvolvedores não conseguiram pois não tinham conhecimento
suficiente para tanto.
Apresentada a fundamentação sobre o modelo de desenvolvimento, pode-se
agora iniciar o detalhamento das questões práticas que serão utilizadas nesse trabalho.
As subseções a seguir farão uma abordagem descritiva das técnicas usadas a fim de
contemplar os objetivos propostos, bem como as fases do PCA.
5.4. Identificando usuários/alunos e estabelecendo suas necessidades
Conforme proposto pelo Projeto Centrado no Aprendiz, em um primeiro instante
será preciso conhecer os usuários/alunos que farão uso do sistema, para somente depois
estabelecer as suas necessidades. Preece, Rogers e Sharp (PRECE, ROGERS &
SHARP, 2005) comentam:
Para projetar algo que realmente dê suporte às atividades das pessoas,
devemos conhecer quem são nossos usuários-alvo e que tipo de suporte um
produto interativo poderia oferecer de maneira útil. Essas necessidades
constituem as bases dos requisitos do produto e sustentam o design e o
desenvolvimento subsequentes. Essa atividade é fundamental para uma
abordagem centrada no usuário e muito importante no design de interação;
As técnicas aqui apresentadas foram escolhidas dentre as várias propostas pela
engenharia de requisitos, levando em consideração o objeto de estudo. A figura 6 mostra
tais técnicas.
Figura 6 – Técnicas usadas para o levantamento de requisitos.
Fonte: O autor
43
4.3.1. Entrevistas
Entrevistas constituem uma forma simples de se obter informações através de
perguntas diretas. São classificadas de acordo com a maneira com que o entrevistador se
prende ao roteiro (conjunto de perguntas pré-formuladas) (PRECE, ROGERS &
SHARP, 2005).
Uma entrevista bem realizada pode ser considerada uma etapa muito importante
no processo de identificação dos usuários. O entrevistador poderá capturar as opiniões
pessoais, que revelarão as expectativas do usuário sobre a solução para um dado
problema (BRAGA, 2008).
Será realizada num primeiro instante entrevista semiestruturada, individual com
os professores da instituição. O roteiro é composto por doze itens, onde busca-se obter
informações generalizadas dos participantes, como as atividades desempenhadas,
concepções educativo-musicais, perfil tecnológico, entre outras. O roteiro completo é
mostrado no Apêndice B.
Foi escolhida a entrevista do tipo “semiestruturada”, pois segundo Lakatos
citado por Pinto (PINTO, 2007), esse tipo de entrevista possibilita maior flexibilidade,
permitindo o entrevistador reformular, repetir ou esclarecer perguntas que não foram
ainda compreendidas.
4.3.2.
Questionários
Em um segundo momento serão aplicados questionários individuais aos alunos
do curso de bateria. Optou-se pelo uso do questionário, como segunda técnica para o
levantamento de dados, pois este permite atingir um maior número de participantes de
uma única vez. Além disso, pelo fato de ser impessoal é também menos propenso a
apresentar distorções da realidade em estudo (PREECE, ROGERS & SHARP, 2005),
favorecendo a obtenção de dados fidedignos junto ao objeto de estudo.
Quanto a elaboração, Braga (BRAGA, 2008) argumenta que as perguntas devem
ser “claras e sem ambiguidade, ter fluxo definido, prever antecipadamente dúvidas que
possam surgir e não pode ser muito extensa, pois pode ocasionar desinteresse das
pessoas”.
44
Espera-se com essa etapa levantar algumas informações sobre o perfil dos
alunos, como a faixa etária, perfil tecnológico, preferência musical, entre outras. O
questionário composto por nove perguntas é mostrado no Apêndice C.
4.3.3. Observação
Segundo Lakatos e Marconi citados por Pinto (PINTO, 2007), a técnica de
observação consiste em averiguar uma realidade, objetivando o entendimento dos
processos inseridos, sem a necessidade de utilizar técnicas especiais ou de
questionamento direto. Os autores comentam ainda que nessa técnica o quadro de
observação se torna um tanto impreciso, razão pela qual o observador deve atentar para
a sistematização das informações.
Apesar de demandar mais tempo e exigir mais empenho da equipe
desenvolvedora, a observação é útil para compreender a natureza das tarefas e o
contexto em que são realizadas. Preece, Rogers e Sharps (PREECE, ROGERS &
SHARP, 2005) justificam:
A observação natural pode não apenas ajudar a preencher detalhes e
nuanças que simplesmente não aparecem em outras investigações, mas
também oferecer um contexto para as tarefas. Contextualizar o trabalho ou o
comportamento que uma máquina deve apresentar fornece dados que outras
técnicas não fornecem – dados dos quais podemos extrair requisitos.
No contexto do software musical, essa técnica demonstra uma excelente
oportunidade para a observação da interação professor-aluno e aluno-professor,
revelando os elementos “chave” do processo de ensino aprendizagem. Além disso, o
observador estando inserido nas aulas poderá conhecer as técnicas desenvolvidas e
também os materiais de apoio (MENDES, 1999).
Assim, objetiva-se nesta etapa, analisar as atividades e estratégias didáticas
desenvolvidas pelos professores nas aulas de bateria.
Será observada uma aula,
composta por um dos professores e os cinco alunos.
4.3.4. Cenários
Os cenários constituem uma forma de ilustrar, para os envolvidos no projeto, a
realização de uma ou um conjunto de tarefas descritas através narrativas (PREECE,
ROGERS & SHARP, 2005). Por isso, são representações muito úteis para se obter e
45
analisar requisitos funcionais, pois mantêm o foco nos objetivos do usuário ao realizar
determinadas atividades (BELGAMO & MARTINS, 2000).
De um modo geral, os cenários incluem: a) os atores ou agentes – pessoas que
realizam alguma ação dentro da narrativa; b) ambiente – descreve a situação em que se
encontra o contexto a ser descrito; e c) roteiro – a narrativa propriamente dita. Descreve
uma seqüência de passos claros até atingir ou não o objetivo dos atores.
Em conjunto com os professores será criado um cenário atual, ou seja, sem o
uso do software, contendo a descrição dos passos para elaboração de uma atividade.
5.5. Prototipação
Durante o processo de levantamento de requisitos é comum não ficarem
explícitas todas as necessidades dos usuários. No entanto, como afirmam Preece,
Rogers e Sharp (PREECE, ROGERS & SHARP, 2005), os usuários “quando vêem algo
e começam a utilizá-lo, logo sabem o que não querem.”. Nesse sentido, segundo as
autoras, após a etapa inicial de coleta de requisitos, faz-se necessário testar as idéias
obtidas, através do uso de protótipos em parceria com os usuários que serão melhorados
ao longo do ciclo de desenvolvimento.
Um protótipo é uma simulação do sistema final ou parte dele, utilizado para
validar os requisitos definidos ou mesmo para definir requisitos ainda vagos. Para a
equipe de desenvolvimento representa mais uma forma de comunicação, uma vez que a
visualização de objetos “reais” facilita o processo de compreensão (SOMMERVILLE,
2003).
Pressman (PRESSMAN, 2006) define prototipação como “um processo que
capacita o desenvolvedor a criar um modelo do software que será implementado.”.
Assim, além de verificar questões como a eficiência de um determinado algoritmo, a
adaptabilidade de um sistema operacional, entre tantas outras utilidades, um protótipo
poderá ser útil em revelar novos requisitos e prevenir falhas, possivelmente não
verificados durante a elicitação de requisitos. O autor (PRESSMAN, 2006) comenta que
protótipos podem assumir uma das três formas:
i.
Um protótipo em papel ou modelo baseado em computador;
46
ii.
Um protótipo de trabalho que implementa algum subconjunto da função
exigida do software desejado; e
iii.
Um programa existente que executa parte ou toda a função desejada,
mas que tem outras características que serão melhoradas em um novo
esforço de desenvolvimento.
Preece, Rogers e Sharp (PREECE, ROGERS & SHARP, 2005) destacam dois
tipos de protótipos, a saber:
i.
Prototipação de baixa-fidelidade: Como sugere o nome, representam
versões muito simplificadas em relação a versão final, sendo por essa
razão utilizadas nas etapas iniciais. São representações rápidas e de baixo
custo, podendo ser modificadas facilmente. Algumas técnicas usadas
para a elaboração de protótipos de baixa-fidelidade são: (a) storyboard –
um conjunto de desenhos mostrando como o usuário interage com o
sistema a ser desenvolvido; (b) esboços; (c) protótipos em fichas – cada
ficha representa uma tela ou elemento da tarefa; e (d) Mágico de Oz – um
operador humano simula o funcionamento do computador.
ii.
Prototipação de alta-fidelidade: Usam de artifícios mais próximos aos
usados na versão final do software. Assim, contemplam toda ou boa parte
das funcionalidades, permitindo elevado grau de interação com os
usuários, o que representa a vantagem em se usar esse tipo de
prototipação. Por outro lado, requerem maior tempo para a sua criação e
consequentemente elevam os custos do projeto, além disso, podem elevar
demais as expectativas dos clientes/usuários.
Neste trabalho optou-se pela criação dos protótipos de baixa e de alta fidelidade,
expostos na seção 7. A criação de tais protótipos, em conjunto com os usuários (alunos e
professores) tem três objetivos: 1) validar os requisitos levantados anteriormente; 2)
contemplar a adequação quanto a representação musical; e 3) verificar a interação dos
usuários.
Para a elaboração dos protótipos de baixa-fidelidade será utilizado papel sulfite,
régua, lápis e caneta.
47
A criação dos protótipos de alta-fidelidade será feita através do ambiente de
desenvolvimento
Embarcadero
Delphi
2010,
que
é
uma
ferramenta
de
“Desenvolvimento Rápido de Aplicação” (Rapid Application Development - RAD)
baseada em object pascal. O ambiente permite o desenvolvimento de inúmeros tipos de
aplicações como cliente/servidor quanto aplicações de uso genérico, como planilhas,
editores de textos, etc.
5.6. Avaliação Multidisciplinar
Segundo Preece, Rogers e Sharp (PREECE, ROGERS & SHARP, 2005), a
avaliação faz-se necessária para garantir que os usuários venham realmente a utilizar o
sistema final, estando de fato satisfeitos. As autoras comentam:
Os usuários preferem sistemas que sejam fáceis de aprender e utilizar assim
como eficazes, eficientes, seguros e satisfatórios. É também essencial que
alguns produtos sejam agradáveis, atraentes, desafiadores, etc. Saber o que
avaliar, a importância de avaliar e quando avaliar são, portanto, tarefas
fundamentais (...)
Assim, conforme visto na seção 5.3, a premissa básica do Projeto Centrado no
Aprendiz – PCA, é a priorização do processo de aprendizagem durante todas as etapas
de desenvolvimento do software educativo. Para alcançar esse objetivo, o PCA enfoca
no ciclo de avaliações, onde sucessivos testes/avaliações são realizados e novos
protótipos gerados (WINCKLER, NEMETZ & LIMA, 2000). No entanto, é importante
que as preocupações de domínio da aplicação venham de encontro com as metas
clássicas da usabilidade.
Kruger (KRUGER, 1996) sugere um roteiro de avaliação onde são observados
três aspectos, tidos para autora, como fatores de qualidade:
1. Parâmetros pedagógicos – “Um software com que se deseja propiciar
experiências no campo da música tem que conter alguma concepção
musical.” (HENTSCHKE apud LIMA, OLIVEIRA & RAMOS, 2002).
Subitens a serem avaliados:

Teorias da aprendizagem e concepções da educação musical;

Parâmetros da experiência musical;

Objetivos pedagógicos;
48

Avaliação do aprendizado;

Adequação sociocultural e Musical;
2. Interações sociais - Avalia o quanto o software é capaz de modificar as
interações aluno/professor e professor/aluno; e
3. Informática & Educação Musical – Avalia a relação dos três eixos:
computação, educação e música. Subintes a serem avaliados:

Interatividade – Avalia a relação dos usuários (alunos e
professores) com a ferramenta;

Interface – Avalia se o software corresponde com as entradas do
usuário dando-lhes feedback adequado e imediato. Verifica
também se as informações são legíveis e se a interação do usuário
é fácil; e

Usabilidade – Prevê a avaliação da ferramenta quanto a
adequação com as metas clássicas da usabilidade.
O roteiro proposto por Kruger (KRUGER, 1996) reforça a necessidade de se
avaliar a qualidade do software educacional considerando, além das questões
pedagógico-musicais, as metas de usabilidade (FRITSCH ET AL 2003), o que vai de
encontro com a proposta do PCA, especificamente com a terceira etapa do ciclo:
Avaliação Multidisciplinar.
Neste trabalho será observada apenas parte do roteiro proposto por Kruger
(KRUGER, 1996). Assim, o segundo aspecto proposto pela autora – Interações Sociais,
não será avaliado, uma vez que, segundo Viana Júnior e Castro Filho (VIANA JÚNIOR
& CASTRO FILHO, 2005), essa característica será melhor analisada pósimplementação do software educativo, o que não será contemplado neste trabalho.
Relativo aos métodos de avaliação, Wincler, Nemetz e Lima (WINCKLER,
NEMETZ & LIMA, 2000) classificam, diante da variedade existente, em dois grupos:
1. Métodos de inspeção de usabilidade – São caracterizados por empregar
especialistas na procura de possíveis problemas de usabilidade. Alguns
49
exemplos desses métodos são: Avaliação Heurística, Revisão Cognitiva e
Inspeção formal de usabilidade; e
2. Testes empíricos com usuários – São caracterizados por empregar
usuários para a identificação de possíveis problemas. Alguns exemplos
desses métodos são: Ensaios de interação, questionários, análise de
arquivos de log, focus group e classificação de cartões.
Para que seja alcançado o roteiro proposto por Kruger (KRUGER, 1996),
observando-se os aspectos 1 e 3, Parâmetros Pedagógicos e Informática & Educação
Musical, respectivamente, optou-se por utilizar duas técnicas descritas anteriormente:
“Avaliação Heurística” e “Ensaios de interação”, detalhadas a seguir.
5.6.1. Avaliação Heurística
Avaliação heurística é um método de inspeção de usabilidade, onde o avaliador
interage com o sistema e analisa a adequação deste, comparando com heurísticas prédeterminadas. Nielsen citado por Wincler, Nemetz e Lima (WINCKLER, NEMETZ &
LIMA, 2000) e por Preece, Rogers e Sharp (PREECE, ROGERS & SHARP, 2005)
sugere dez regras heurísticas a serem observadas:
1. Diálogos simples e naturais: a interface deve ser o mais simples possível,
combinando as tarefas do usuário com conceitos computacionais de
maneira objetiva;
2. Compatibilidade do sistema com o mundo natural: a linguagem deve ser
orientada ao usuário e não ao sistema. Deve utilizar palavras, frases e
conceitos familiares ao invés de termos técnicos;
3. Minimizar a sobrecarga de memória do usuário: a ferramenta deve exibir
elementos de diálogo para o usuário e permitir que o mesmo faça suas
escolhas, sem precisar lembrar de comando específicos;
4. Consistência: uma mesma operação deverá ser disposta na mesma
posição em todas as telas e deverá ser formatada da mesma maneira para
facilitar a memorização;
50
5. Feedback: o sistema deverá manter o usuário informado sobre o que está
acontecendo, oferecendo mensagem adequada em tempo ágil;
6. Saídas claramente marcadas: deve permitir que o usuário saia de lugares
inesperados fazendo uso de comandos genéricos como botões
“Cancelar”, “Desfazer”, etc;
7. Atalhos: o sistema deverá dispor de artifícios do tipo teclas de atalho,
clique duplo do mouse, ou botões especiais para funções usadas com
maior frequência.
8. Boas mensagens de erro: devem ser em linguagem clara e sem códigos,
sugerir uma maneira de resolver o problema;
9. Prevenir erros: onde possível, impede a ocorrência de erros; e
10. Ajuda e documentação: fornece informações de fácil acesso para a
resolução de problemas ou informações sobre o software.
Wincler, Nemetz e Lima (WINCKLER, NEMETZ & LIMA, 1998), sugerem a
criação de outras heurísticas, argumentando que “o método mostra-se de fácil
adaptação, permitindo que os avaliadores possam criar heurísticas especificas de
domínio;”. Assim, duas heurísticas servirão para classificar possíveis problemas
específicos do domínio:

Adequação da notação musical – Deve contemplar a representatividade
dos parâmetros do domínio musical: duração, intensidade, valor das
notas, entre outros, utilizando para isso os símbolos padrões para a
notação musical. É importante investigar esta heurística pois, segundo
Viana Júnior & Castro Filho (VIANA JÚNIOR & CASTRO FILHO,
2005) muito softwares musicais acabam criando outros modelos de
representatividade,
o
que
acaba
interferindo
no
processo
de
aprendizagem dos alunos.

Adequação ao modelo (T)EC(L)A – Conforme visto na seção 3.1, este
modelo define um grupo de cinco atividades musicais, onde a execução
[E], a composição [C], e a apreciação musical [A] são priorizadas por
51
proporcionarem maior envolvimento com a prática da música. As outras
atividades são chamadas de complementares e dizem respeito ao
aprendizado técnico [(T)] e literário [(L)] sobre música.
Neste trabalho, participarão dos testes os dois professores da escola, previamente
orientados para a avaliação utilizando-se das doze heurísticas descritas anteriormente.
Cada um dos professores realizará a inspeção individualmente, de modo a garantir
avaliações independentes e sem influências. Terminada as sessões os participantes
descreverão
os
problemas
encontrados,
a(s)
heurística(s)
violada(s)
e
comentários/sugestões.
5.6.2. Ensaios de interação
Essa técnica fornece maiores detalhes sobre as dificuldades encontradas pelos
usuários ao utilizar o software e os problemas de interação, considerados problemas
reais de usabilidade (WINCKLER, NEMETZ & LIMA, 1998).
Consiste em estabelecer um conjunto de tarefas a serem realizadas pelos
usuários, enquanto são observados por avaliadores. Durante a execução os usuários
devem ser questionados sobre o que estão fazendo e o que estão pensando, assim o
avaliador deverá estimular o diálogo através de perguntas do tipo “O que você acha
dessa tela?” ou “Tem alguma coisa na interface que você não gostou?” , essa forma
de conversação é conhecida como “Pensamento em voz alta” (Thinking Aloud Protocol)
(VIANA JÚNIOR & CASTRO FILHO, 2005).
Para a realização desta técnica participarão os cinco alunos (usuários). Os
ensaios de interação acontecerão individualmente, de modo a garantir avaliações
independentes e sem influências. As tarefas solicitadas serão apresentadas na seção 8.2.
Ao término de cada uma das atividades o usuário poderá comentar sua impressão sobre
a interface.
52
6. LEVANTAMENTO DE REQUISITOS
A seguir encontram-se os resultados obtidos após a aplicação das técnicas
descritas na seção 5.4. O objetivo aqui é, através dos resultados adquiridos, levantar os
requisitos que servirão de base para a criação do protótipo da aplicação proposta.
6.1. Entrevistas
Conforme explanado na seção 5.4.1., as entrevistas aconteceram de maneira
individual, obedecendo a um roteiro semiestruturado, cuja cópia é apresentada no
Apêndice B. A seguir é apresentado um breve resumo das informações.
o Professor 1
P1 é formado em teologia, atua como professor de música há cinco anos na
escola, onde ministra aulas de teclado, violão e bateria. Embora não possua nenhum
curso na área da informática, pela experiência prática, utiliza alguns programas do
domínio musical como gravadores, editores e sequenciadores, de modo a criar suas
produções musicais em casa.
Questionado sobre a educação musical no Brasil, o entrevistado comenta que
“merecia mais apoio, os governantes deveriam incentivar a criação de novos centros de
ensino.”, e concluiu “ (...) o fato da música em 2011 voltar a fazer parte do currículo
escolar é um grande passo, mas representa muito pouco para a nossa realidade.”. Em
relação à qualidade do ensino prestado na instituição, P1 considera bom, argumentando
que a instituição possui bons equipamentos de apoio para as aulas práticas e que os
professores estão sempre buscando soluções criativas para a exposição dos conteúdos
teóricos.
Sobre o uso do computador como ferramenta de apoio, P1 relata algumas
experiências fracassadas. Em uma delas tentou usar um determinado software nas aulas
de teclado, especificamente para o treinamento de escalas, mas logo foi desestimulado
pela dificuldade em aprender a usar as funções da ferramenta. O professor comenta
ainda “a ferramenta parecia uma adaptação para o português, por isso achei muito longe
da nossa realidade, os exemplos usados eram trechos de músicas estrangeiras, além
53
disso, não havia a possibilidade de inserir novos exemplos, o que a tornou ainda mais
limitada.”.
Sobre a sua opinião quanto ao uso do computador como ferramenta de apoio, P1
revela-se interessado em usar “algo inovador” para com seus alunos, algo que possa de
fato contribuir para a melhoria do processo de ensino-aprendizagem. No entanto, teria
que ser algo “fácil de usar”, totalmente adaptável a nossa realidade musical e as
necessidades dos alunos.
o Professor 2
P2 é formado em pedagogia e possui nível técnico em informática (Manutenção
de Computadores), atua como professor de música nesta escola há aproximadamente
quatro anos, onde ministra aulas de teclado, guitarra e bateria.
Quando atua como músico em apresentações ao vivo, faz uso de recursos
computacionais para “disparar loops”, playbacks e efeitos de guitarra. Também costuma
registrar suas composições através de programas gravadores/editores de áudio.
Em relação a educação musical no Brasil, P2 acredita que “as coisas irão tomar
um novo rumo no próximo ano, quando as aulas de educação musical retomarão o seu
espaço(...)”, completa afirmando que as faculdades ainda são muito “burocráticas” no
processo seletivo dos cursos de música, “pra conseguir uma vaga o aluno já tem que
entrar sabendo muita coisa.”, conclui P2.
P2 relata que há três meses tentou usar um software para a edição e criação de
notação musical (partituras), de forma a agilizar e facilitar o processo manual de escrita.
Entretanto acabou desistindo após algumas dificuldades: os alunos reclamavam que “era
um programa em inglês”, não exportava/importava partituras de outros programas e não
era intuitivo.
A partir das entrevistas, foram percebidos alguns requisitos listados a seguir.
Para os requisitos de entrevista, será utilizado o identificador RE (Requisitos de
entrevista).
54

RE01 – Inserir novos exemplos: O sistema deverá
permitir que o professor insira novos exemplos (áudio, vídeo, partituras e
imagens) nas atividades a serem trabalhadas com os alunos.
Editor de partituras – O sistema deverá conter um editor de partituras
com os seguintes requisitos funcionais:
• RE02 – Criar partituras: Conjunto de ferramentas e
símbolos musicais que possibilitem a elaboração de
partituras;
• RE03 – Salvar partituras: Partituras criadas ou
alteradas poderão ser salvas;
•
RE04 – Alterar partituras: Permitir a alteração de
partituras já cadastradas ou previamente importadas.
•
RE05 – Excluir partituras: O sistema deverá
possibilitar a remoção de partituras da base de dados.
•
RE06 – Exportar partituras: As partituras criadas ou
pertencentes a base de dados, poderão ser exportadas no
formato
“.ENC”
(programa
Encore6),
“.MUS”
(programa Finale7) e “.SIB”(do programa Sibelius8), que
representam os editores de partituras mais populares.
•
RE07 – Importar partituras: Deverá ser permitido
importar partituras criadas com as extensões “.ENC”
(programa Encore), “.MUS” (programa Finale) e “.SIB”
(do programa Sibelius), que representam os editores de
partituras mais populares.
6
Softwares editores de partituras:
Encore - http://www.gvox.com/
7
Finale - http://www.finalemusic.com/
8
Sibelius - http://www.sibelius.com/home/index_flash.html
55
•
RE08 – Pesquisar partituras: Deverá permitir que os
usuários realizem pesquisas de acordo com o título ou
autor da partitura; e
•
RE09 – Visualizar partituras: As partituras poderão
ser lidas através de um visualizador.
6.2. Questionários
Conforme dito na seção 5.4.2, os questionários foram aplicados aos cinco alunos
matriculados nas aulas de bateria. Todos com idade superior a 10 anos, sendo que a
maior parte - 60%, estão entre 14 e 17 anos. O gráfico 1 ilustra a distribuição das idades
dos alunos.
Gráfico 1 – Distribuição das idades
Fonte: Dados da pesquisa
Constatou-se que 80% dos alunos têm computador em casa, embora apenas 40%
dos questionados já realizaram algum curso de informática.
O gráfico 2 mostra o percentual de alunos que possuem computador em casa,
enquanto o gráfico 3 mostra os alunos que já realizaram algum curso de informática.
56
Gráfico 2 – Alunos que possuem computador em casa
Fonte: Dados da pesquisa.
Gráfico 3 – Alunos que já realizaram algum curso de informática
Fonte: Dados da pesquisa
Em relação às atividades musicais desempenhadas usando o computador, 31%
dos alunos afirmaram apreciar músicas, enquanto que as atividades “Praticar exercícios”
e “Gravação/edição de áudio” ficaram ambas com 23%. O gráfico 4 mostra os detalhes
desta distribuição.
57
Gráfico 4 – Atividades dos alunos usando o computador
Fonte: Dados da pesquisa
Os alunos mostraram-se mais interessados por aulas com atividades práticas
(40% dos votos), enquanto que as aulas teóricas e de composição musical receberam
cada uma 20% dos votos. O gráfico 5 ilustra a escolha dos alunos.
Gráfico 5 – Aulas preferidas
Fonte: Dados da pesquisa
Após análise dos resultados obtidos com a essa etapa, alguns requisitos foram
evidenciados e serão mostrados logo abaixo. Serão identificados aqui como RQ requisitos de questionários.
58

RQ01 – Executar sons: Será possível a execução arquivos de áudio,
tanto para as atividades de “Apreciação Musical”, como exemplos nas
atividades; e

RQ02 – Executar vídeo: Será possível a execução arquivos de vídeo,
tanto para as atividades de “Apreciação Musical”, como exemplos
usados nas atividades.
6.3. Observação
A aula teve duração de 120 minutos, durante os quais puderam ser percebidos
alguns pontos relatados abaixo:
•
Na maior parte das atividades é utilizado um metrônomo9 para o controle
do andamento (velocidade). O professor gasta muito tempo tendo que
ajustá-lo para cada exercício diferente;
•
Em algumas atividades práticas, o professor demonstra o exercício em
uma bateria e em outra um dos alunos repete. Isso requer mais tempo,
pois como a escola dispõe apenas de duas baterias, os alunos têm que
revezar até que todos executem a mesma atividade;
•
Todo o material produzido durante as aulas é identificado com o nome do
aluno, data, nome do professor e título da música, se for o caso. O
material é arquivado em fichários, onde estão todas as atividades
realizadas.
Sobre os pontos observados, foram extraídos alguns requisitos, aqui
denominados de RO – Requisitos de observação, listados a seguir:
Possuir metrônomo: A aplicação deve implementar um metrônomo que
contemple os seguintes requisitos:
•
RO01 - Ajuste de velocidade: Será possível controlar a velocidade do
click, permitindo que o usuário ajuste de acordo com a atividade a ser
realizada; e
9
Relógio que mede o tempo (andamento) musical. Emite pulsos (click) de duração regular, e é utilizado
para fins de estudo ou interpretação musical.
59
•
RO02 – Ajuste de timbre: Dentro das atividades o usuário poderá
escolher entre três timbres disponíveis para o som do click.

RO03 – Baterista virtual: Um baterista virtual, programável para executar os
exemplos selecionados pelo professor. Desse modo o aluno poderá observar e
repetir na bateria “real”, liberando o professor para avaliar a execução do
aprendiz; e

RO04 – Identificar usuários: O sistema deve permitir a identificação dos
usuários (alunos e professores).
6.4. Cenário
O cenário a seguir descreve a preparação para uma aula de pratica rítmica.
Ator: Professor
Roteiro: O professor verifica no seu cronograma qual o tipo de aula para hoje.
Descobre que é dia de prática rítmica, onde os alunos devem ler na partitura uma música
e logo após tocar na bateria. O professor procura nos seus CDs por uma música que será
utilizada na atividade. Encontra uma, mas fica na dúvida se já utilizou em outras
atividades. Na dúvida, faz uma busca em um fichário onde estão todas as partituras já
escritas e utilizadas, onde acaba percebendo que já havia empregado aquela música em
uma atividade de apreciação. O professor volta a procura de outra música. Escolhida, o
professor procura em outro fichário onde estão algumas partituras prontas e sem uso,
mas não encontra a música escolhida. O professor pega uma folha de papel pauta em
branco, preenche um pequeno cabeçalho, onde constam quatro campos: o nome da
música, nome do professor, a data e o nome do aluno. O professor começa a ouvir
pequenos trechos da música e escrever no papel, assim faz até a conclusão. O professor
confere os valores anotados com as notas ouvidas. Percebe que houve um erro
aproximadamente no meio da música. O professor tenta corrigir, mas acaba rasurando o
papel. O professor pega uma nova folha e repassa as informações a partir da folha
rasurada. O professor tira Xerox da atividade a ser distribuída para os alunos. A aula foi
preparada.
A partir deste cenário deduz-se alguns requisitos, aqui denominados de RC
(Requisito de cenário), mostrados abaixo:
60
Tarefas do professor – Algumas atividades poderão ser realizadas pelos
professores:
•
RC01 – Criar atividade: O professor poderá criar novas
atividades a serem utilizados nas aulas pelos alunos.
•
RC02 – Editar atividade: O professor poderá modificar
as atividades existentes, acrescentando novos arquivos (áudio ou vídeo);
•
RC03 – Pesquisar atividade: Será possível realizar
pesquisas sobre as atividades já criadas;
•
RC04 – Ver aula: As atividades previamente formatadas
poderão ser visualizadas pelos usuários;
•
RC05 – Excluir atividades: O professor poderá remover
as atividades que julgar conveniente;
Manutenção dos usuários: Caberá ao professor realizar
operações relativas aos usuários (alunos e professores) do
sistema:
 RC06 – Cadastrar usuário: O sistema deverá
permitir a inserção de novos usuários no sistema;
 RC07 – Excluir usuário: Deverá ser possível
remover usuários cadastrados no sistema;
 RC08 – Editar usuário: O sistema deverá
permitir que as informações dos usuários sejam
alteradas; e
 RC09 – Pesquisar usuários: O professor poderá
realizar pesquisas entre os usuários cadastrados.
É importante ressaltar que alguns requisitos dedutíveis a partir deste cenário,
foram omitidos pois coincidem com RE02, RE03, RE04, RE05, RE06, RE07, R08 e
RE09, encontrados através da técnica “Entrevistas” (seção 6.1.).
61
7. PROTOTIPAÇÃO
Conforme exposto na seção 5.5, a construção dos protótipos visam atender a três
aspectos: validação dos requisitos, representação musical e interação do usuário.
7.1. Protótipo de baixa fidelidade
62
Em conjunto com os usuários foram esboçadas algumas telas, mostradas a
seguir. Na figura 7 é apresentado o esboço da tela de identificação.
Figura 7 – Protótipo de baixa fidelidade: tela de identificação do usuário.
Fonte: O autor.
A figura 8 mostra a tela “partituras”. Foram organizadas nesta tela todas as
operações relativas às partituras.
Figura 8 – Protótipo de baixa fidelidade: tela partituras.
63
Fonte: O autor.
Na sequência foi esboçada a tela “nova partitura”, onde a participação dos
professores fez-se necessário, devido às representações da notação musical envolvidas.
A figura 9 mostra a tela nova partitura.
Figura 9 – Protótipo de baixa fidelidade: tela nova partitura.
Fonte: O autor.
64
As figuras 10 e 11 ilustram as telas de execução de áudio e vídeo,
respectivamente. Os controles básicos para a manipulação dos arquivos de mídia foram
identificados e já aparecem nos esboços.
Figura 10 – Protótipo de baixa fidelidade: tela tocador de áudio.
Fonte: O autor.
Figura 11 – Protótipo de baixa fidelidade: tela tocador de vídeo.
Fonte: O autor.
65
A manutenção dos usuários poderá ser realizada a partir da tela “usuários”, onde
estarão as funções como cadastrar, editar, excluir e pesquisar. O rascunho da tela
“usuários” é mostrado na figura 12.
Figura 12 – Protótipo de baixa fidelidade: tela manutenção dos usuários.
Fonte: O autor.
Ainda relativo à manutenção dos usuários, foi esboçada a tela de cadastro,
mostrada na figura 13.
Figura 13 – Protótipo de baixa fidelidade: tela cadastro de usuários.
Fonte: O autor.
66
A figura 14 mostra a tela “atividades”. Nesta tela estão reunidas as possíveis
tarefas relacionadas com as atividades, como criar nova, editar, excluir e ver atividade.
Figura 14 – Protótipo de baixa fidelidade: tela atividades.
Fonte: O autor.
A tela “nova atividade” é mostrada na figura 15.
Figura 15 – Protótipo de baixa fidelidade: tela nova atividade.
Fonte: O autor.
67
Por fim, foi esboçada a tela “metrônomo” de acordo com explicitações
dos professores. Tal tela é exibida na figura 16.
Figura 16 – Protótipo de baixa fidelidade: tela metrônomo.
Fonte: O autor.
7.2. Protótipo de alta fidelidade
Após a criação do protótipo de baixa fidelidade elaborou-se o protótipo alta
fidelidade, conforme proposto em 5.5. Com os resultados obtidos aqui, os usuários
poderão realizar os testes previstos para a etapa de avaliação, que será exposta na seção
8.
Os usuários serão identificados através de um nome e de uma senha, solicitados
ao iniciar o sistema. A tela de identificação do usuário é mostrada na figura 17. Tal tela
atende ao requisito RO04 (identificar usuários).
68
Figura 17 – Protótipo de alta fidelidade: tela de identificação do usuário.
Fonte: O autor.
A tela principal é apresentada logo após a validação do usuário. A figura 18
mostra tal tela.
Figura 18 – Protótipo de alta fidelidade: tela principal.
Fonte: O autor.
Na tela “partituras”, mostrada na figura 19, os usuários poderão listar as
partituras de acordo com o gênero musical ou pesquisá-las pelo título ou autor,
atendendo o requisito RE08 (pesquisar partituras). Os requisitos RE01 (inserir novos
69
exemplos), RE04 (alterar partituras), RE05 (excluir partituras), RE06 (exportar
partituras) e RE07 (importar partituras) são contemplados respectivamente através das
funções nova, editar, excluir, exportar e importar, acessados através desta tela.
Figura 19 – Protótipo de alta fidelidade: tela partituras.
Fonte: O autor.
A tela para criação de novas partituras é mostrada na figura 20. As funções
propostas contemplam os requisitos RE02 (criar partituras) e RE03 (salvar partituras).
Figura 20 – Protótipo de alta fidelidade: tela criação de partituras.
Fonte: O autor.
70
O requisito RE09 (visualizar partituras) será contemplado através da tela
visualizar partituras, mostrada na figura 21.
Figura 21 – Protótipo de alta fidelidade: tela visualizar partituras.
Fonte: O autor.
As telas tocador de áudio (requisito RQ01) e tocador vídeos (requisito RQ02)
são mostradas nas figuras 22 e 23, respectivamente. É importante ressaltar que ambos
contemplam o requisito RE01 (inserir novos exemplos).
Figura 22 – Protótipo de alta fidelidade: tela tocador de áudio.
Fonte: O autor.
71
Figura 23 – Protótipo de alta fidelidade: tela tocador de vídeo.
Fonte: O autor.
A tela “baterista virtual” poderá ser acessada via menu principal, através de um
botão de atalho. Esta tela, mostrada na figura 24, atende aos requisitos RO03 (baterista
virtual) e RE01 (inserir novos exemplos).
Figura 24 – Protótipo de alta fidelidade: tela baterista virtual.
Fonte: O autor.
72
Os usuários terão acesso às atividades propostas através da tela “atividades”,
mostrada na figura 25 e que correspondente ao requisito RC03 (pesquisar atividade).
Outros requisitos aqui contemplados são: RC02 (editar atividade) e RC05 (excluir
atividades), relativos aos botões editar e excluir atividades.
Figura 25 – Protótipo de alta fidelidade: tela atividades.
Fonte: O autor.
Para a elaboração de novas atividades o sistema conta com um editor de textos,
onde o professor poderá incluir também exemplos de áudio, vídeo, partituras e imagens.
Na figura 26 é mostrada a tela “nova atividade”, correspondente aos requisitos RC01
(criar atividade) e RE01 (inserir novos exemplos).
Figura 26 – Protótipo de alta fidelidade: tela nova atividade.
Fonte: O autor.
73
A visualização das atividades (RC04) será feita através da tela “aula”, onde o
professor poderá organizar as atividades criadas. Esta tela é mostrada na figura 27.
Figura 27 – Protótipo de alta fidelidade: tela aula.
Fonte: O autor.
Os requisitos RC06 – cadastrar usuários (figura 28), RC07 – excluir usuários,
RC08 – editar usuários (figura 29) e RC09 – pesquisar usuários (figura 30)
correspondem as atividades relativas a manutenção dos usuários. Estas telas serão
acessadas através do menu “Professor”, disponível na tela principal.
74
Figura 28 – Protótipo de alta fidelidade: tela cadastro de usuário.
Fonte: O autor.
Figura 29 – Protótipo de alta fidelidade: tela editar usuário.
Fonte: O autor.
Figura 30 – Protótipo de alta fidelidade: tela pesquisar usuário.
Fonte: O autor.
75
Na figura 31 é mostrada a tela “metrônomo”, onde é possível o controle da
velocidade e ajuste de timbre do click, o que atende aos requisitos RO01 e RO02,
respectivamente.
Figura 31 – Protótipo de alta fidelidade: tela metrônomo.
Fonte: O autor.
76
8. AVALIAÇÃO MULTIDISCIPLINAR
As avaliações aconteceram conforme previsto na metodologia deste trabalho,
sendo realizadas em duas etapas: 1) Avaliação heurística – somente com os professores;
e 2) Ensaios de interação – alunos. Na seção 8.3 são mostradas as correções dos
problemas encontrados, implementadas em um novo protótipo.
8.1. Avaliação heurística
Aconteceram em duas sessões, com duração de aproximadamente 45 minutos
cada uma. Inicialmente foi explicado o funcionamento do teste e qual o objetivo geral.
Foi entregue aos avaliadores uma cópia da lista contendo as 12 heurísticas e a seguir,
feita a leitura dos itens, explicou-se detalhadamente cada um. Para enfatizar foram
dados exemplos de como o avaliador poderia utilizar-se das heurísticas para encontrar
problemas no Baticum. Também foi entregue uma cópia (Tabela 1) da escala de
severidade (WINCKLER, NEMETZ & LIMA, 1998), para a classificação dos
problemas de usabilidade encontrados.
Grau de severidade
Descrição
0
Pouca importância para a execução da tarefa.
1
Afeta lentamente a execução da tarefa.
2
Causa confusão e atrapalha sensivelmente a execução da tarefa.
3
O usuário fica muito confuso ou completa a tarefa com muita dificuldade.
4
O usuário não consegue completar ou desiste da tarefa.
Tabela 1 – Escala de severidade de problemas de usabilidade.
Fonte: WINCKLER, NEMETZ & LIMA, 1998
Na tabela 2 são expostos os problemas (identificados como problemas de
heurística - PH), a heurística violada e o comentário/sugestão do avaliador.
PH
Tela
Problema
Grau de
Heurística
Comentário/sugestão
77
identificado
severidade
“A acentuação é um
Ausência da
01
Metrônomo
opção
violada
2
“acento”.
Adequação da
recurso importante
notação musical.
para o estudo de
cadeias rítmicas.”
“Disparar através de
botões do teclado
Ausência de
02
Metrônomo
teclas de
ajudaria no seu uso, ao
1
Atalhos.
atalho.
invés de ter que
apenas usar o mouse.”
Existem músicas onde
03
Nova
partitura
Apenas uma
página por
4
música.
Adequação da
notação musical.
são necessárias mais
de uma folha para se
escrever a partitura
completa.
“O aluno que não tem
04
05
Nova
partitura
As notas e as
conhecimento
pausas
suficiente poderá
aparecem
confundir as notas
juntas numa
3
barra lateral,
Adequação da
com as pausas. Seria
notação musical.
melhor que fossem
sem
separas em grupos e
identificação.
identificadas.”
Nova
A tela possui o
partitura
2
Ajuda e
“Uma legenda com as
menu “Ajuda”
documentação. /
principais notas e
mas não possui
Minimizar a
posições das peças da
78
informações
bateria seria útil e
sobrecarga de
que pudessem
memória do
auxiliar a
usuário.
escrita.
dispensaria ter que
consultar um manual
externo.”
Nas duas
primeiras telas
a função
Nova Aula,
ZOOM aparece
Nova
no menu
Partitura e
“Exibir”
Visualizador
enquanto na
de partituras.
última no
06
1
Consistência.
-
menu
“Ferramentas”
.
Tabela 2 – Problemas de usabilidade encontrados pelos especialistas de domínio.
Fonte: O autor.
8.2. Ensaios de interação
Participaram desta etapa os cinco alunos da escola. As cinco sessões individuais
tiveram duração aproximadamente de 30 minutos cada uma. Inicialmente foi explicado
qual o objetivo da técnica e o seu funcionamento. Os alunos deveriam executar o
conjunto de 6 tarefas, exibidas na tabela 3.
Tarefa Nº
01
02
Descrição
Abrir a tela “Nova partitura”, verificar as ferramentas e funções.
Abrir o metrônomo, alterar a velocidade para 50 bpm e o timbre para
“bumbo”.
03
Abrir a tela “Baterista virtual” e verificar o funcionamento.
04
Executar uma música no tocador de áudio.
79
05
06
Abrir o “Visualizador de atividades”, localizar a barra de exemplos e
executar um exemplo disponível.
Abrir a tela “Partituras” e visualizar um exemplo.
Tabela 3 – Tarefas executadas pelos usuários.
Fonte: O autor.
Na tabela 4 são listados os problemas identificados (PE – Problemas de ensaio)
após a aplicação da técnica.
PE
Tarefa
Problema
identificado
Comentário/sugestão
Notou-se que
alguns alunos
tiveram
01
01
dificuldades em
Surgiram
compreender o
questionamentos do
funcionamento
tipo: “Isso é uma nota
básico do editor,
ou uma pausa?” e
além de terem
“Que nota é essa?”.
dificuldades em
identificar as notas
e as pausas.
Os alunos não
conseguiram
02
01
relacionar o nome
-
(zoom) com a
função em si.
03
03
Três dos cinco
Um dos alunos
alunos acharam
sugeriu agregar a tela
difícil compreender
“Visualizador de
o que estava sendo
partituras”. E
executado.
comentou: “Se fosse
80
possível ler a partitura
que está sendo tocada
seria melhor. Poder
ver é bom, e ler o que
está sendo tocado
seria ainda melhor.”
Tabela 4 – Problemas encontrados com os ensaios de interação.
Fonte: O autor.
8.3. Novo protótipo
Concluída a etapa de avaliações, os problemas encontrados foram corrigidos
gerando um novo protótipo. A seguir são listadas os PH ( Problemas de heurística) e PE
(Problemas de ensaio), juntamente com as soluções adotadas.
Na tela “Metrônomo”, foi implementada a função “Acento” conforme solicitado
em PH01. Para atender PH02 adicionou-se teclas de atalho: 1) barra de espaço: inicia
ou pára; 2) seta para cima: aumenta a velocidade;e 3)seta para baixo: diminui a
velocidade. Na figura 32 é mostrada a tela alterada.
Figura 32 – Novo protótipo: tela do metrônomo.
Fonte: O autor.
Para solucionar PH03 foi inserida a opção “Nova folha”, o que vem a permitir
que o usuário crie partituras independente do número de folhas. A barra lateral foi
redesenhada com o objetivo de corrigir os problemas apontados em PH04 e as
dificuldades dos alunos descritas em PE01. Na figura 33 é mostrado o novo layout da
tela.
81
Figura 33 – Novo protótipo: tela Nova partitura.
Fonte: O autor.
O problema apontado em PH5 foi resolvido adicionando-se à tela “Nova
Partitura” uma pequena legenda com as informações básicas para a escrita de novas
partituras. A tela “Legenda” é mostrada na figura 34.
Figura 34 – Novo protótipo: tela Legenda.
Fonte: O autor.
82
As funções “Zoom (+)” e “Zoom (-)” foram renomeadas, respectivamente para
“Aumentar (+)” e “Diminuir (-)”, solucionando o problema destacado em PE02. Além
disso, corrigiu-se PH06 movendo a referida função para o menu “Exibir”. Podem ser
observadas na figura 35 as alterações.
Figura 35 – Novo protótipo: função zoom.
Fonte: O autor.
Por fim, visando melhorar a interação dos usuários na tela “Baterista virtual”, foi
adicionada a possibilidade de visualizar a partitura juntamente com o exemplo tocado. A
nova tela é mostrada na figura 36.
83
Figura 36 – Novo protótipo: Tela Baterista virtual.
Fonte: O autor.
9. CONCLUSÃO E TRABALHOS FUTUROS
84
Este trabalho possibilitou o estudo das principais interseções entre a
computação, a educação e a música, de maneira multi e interdisciplinar, com o objetivo
de construir o embasamento mínimo para o desenvolvimento de software educativomusical. Assim, procurou-se revelar, mesmo que de forma sucinta, cada uma das áreas
envolvidas, extraindo os conceitos que serviram de referencial teórico na concepção das
atividades de elicitação de requisitos, prototipação e avaliação.
O estudo da Computação Musical foi crucial para o conhecimento das
tecnologias computacionais existentes a favor da música, como por exemplo, a
tecnologia MIDI, largamente adotada nos softwares de apoio ao ensino de teclado.
Em outro momento, as concepções educativas estudadas serviram para fortalecer
as preocupações quanto à coerência com os pressupostos pedagógicos, fundamentais
para a elaboração de ferramentas que prezem pela qualidade de ensino. O que
infelizmente não é atentado pela maioria dos produtores de softwares educativos, em
especial aqui no Brasil.
Por fim, a relação interdisciplinar entre essas três fascinantes áreas –
computação, educação e a música, revelou-se um vasto campo para estudos e,
curiosamente, ainda pouco explorado.
Como sugestões para trabalhos futuros estão:
a) Explorar novos requisitos, utilizando-se de outras técnicas como a
análise de competidores;
b) Refinar o protótipo criado, através de sucessivos testes de usabilidade
e/ou heurísticas com o envolvimento de outros profissionais (equipe
multidisciplinar);
c) Realizar estudo sobre o interfaceamento MIDI e a possibilidade de
agregar instrumentos virtuais; e
d) Integrar a ferramenta a um ambiente de estudo coletivo via Web.
REFERÊNCIAS
85
(ABNT, 2002) ABNT, Associação Brasileira de Normas Técnicas. NBR 9241-11:
requisitos ergonômicos para trabalho de escritórios com computadores: orientações
sobre
usabilidade.
Rio
de
Janeiro,
2002.
Disponível
em:
<
http://www.usp.br/fau/cursos /graduacao/arq_urbanismo/disciplinas/aut0260/Iso9241__11f2.pdf>. Acesso em: 17 mai. 2010.
(ALENCAR, 1999) ALENCAR, F. M. R. Mapeando a Modelagem Organizacional em
Especificações Precisas 1999. Tese de doutorado. Centro de Informática. UFPE, Recife.
(BELGAMO & MARTINS, 2000) BELGAMO, Anderson; MARTINS, Luiz. E. G; Um
Estudo Comparativo sobre as Técnicas de Elicitação de Requisitos do Software, XIX
CTIC (Concurso de Trabalhos de Iniciação Científica) no XX Congresso Brasileiro da
Sociedade
Brasileira
de
Computação,
Curitiba,
2000.
Disponível
em:
<http://comp.unicruz.edu.br/~cotto/pdf/artigoExtReq.pdf >. Acesso em: 10 mai. 2010.
(BRAGA, 2008) BRAGA, F.P. Técnicas de Levantamento de Requisitos. Brasília, 2008.
Disponível
em:
<
http://www.followscience.com/library_uploads/18acc7bf4b074939504a665beab111d2/1
75/tecnicas_de_levantamento_de_requisitos.doc >. Acesso em: 22/05/2010.
(CAMPOS, CAMPOS & ROCHA, 1996) CAMPOS, F. C. A; CAMPOS, G. H. B. de;
ROCHA, A. R. C. da. Dez etapas para o desenvolvimento de software educacional do
tipo hipermídia. Rio de Janeiro: COPPE/UFRJ, 1995. Disponível em:<>. Acesso em: .
(COSTALONGA, 2004) COSTALONGA, L.Simulação Rítmica de Violão Baseada em
Perfil do Usuário. In Anais do Ambientes de Aprendizagem Baseados em Agentes.
Simpósio Brasileiro de Informática na Educação, Manaus. 2004. Disponível em: <
http://www.evandromanara.net/academicpt.html > Acesso em:02/03/2010.
(DENARDI, 2008) DINARDI, C. A educação musical e o uso do software educativomusical.
Paraná:
2008.
Disponível
em:
<
http://www.editoraopet.com.br/services/DocumentManagement/FileDownload.EZTSvc.
asp?DocumentID=%7BD106B04C-B26C-49E9-B211-viceInstUID=%7BF82908F90C99-4669-A7D2-91881B007714%7D >. Acesso em: .
(FICHMAN ET AL, 2003) Ficheman, I.K; Lipas, R.A.; Kruger, R.A.; Lopes, R.D.;
Editor Musical: uma Aplicação para Aprendizagem de Música apoiada por Meios
86
Eletrônicos Interativos, Anais do XIV Simpósio Brasileiro de Informática na Educação
(SBIE), 12-14 nov. 2003, UFRJ, Rio de Janeiro, p.193-212. Disponível em: <
http://www.br-ie.org/pub/index.php/sbie/article/view/248/234 > Acesso em: 22/05/2010.
(FIORINI, STAA & BAPTISTA, 1998) FIORINI, Soeli T. STAA, Arndt Von.
BAPTISTA, Renan Martins. Engenharia de software com CMM. Rio de Janeiro:
Brasport, 1998.
(FLORES, Luciano, 2002) FLORES, L. V. Conceitos e Tecnologias para Educação
Musical Baseada na Web . Dissertação (Mestrado em Ciência da Computação). Porto
Alegre:
PPGC
/
UFRGS,
2002.
Disponível
<http//biblioteca.universia.net/htmll_bura/ficha/params/id/38063357>.
em:
Acesso
em:03/03/2010 .
(FLORES, Rodrigo, 2004) FLORES, R. Computação Musical – Uma visão geral.
UFSM,
2007.
Disponível
em:
<
http://www-
usr.inf.ufsm.br/~dflores/elc1020/t1/artigo.pdf >. Acesso em: 21/05/2010.
(FRITSCH ET AL, 2003) FRITSCH, E. F.; FLORES, L. V.; MILETTO, E. M.;
VICARI, R. M.; PIMENTA, M. S. Software Musical e Sugestões de Aplicação em
Aulas de Música (book chapter). In: HENTSCHKE, L.; DEL BEN, L. (Org.) Ensino de
Música: Propostas para Pensar e Agir em Sala de Aula. São Paulo: Moderna, 2003.
p.141-157. ISBN 8516039056. (In Portuguese.)
(GALVIS, 88) GALVIS, Álvaro H Panqueva. Engenharia de Software Educativo.
Ediciones Uniandes. Colombia. 1988.
(GIRAFFA & VICCARI, 1999) GIRAFFA, Lucia Maria Martins. Fundamentos de
Teorias de Ensino-aprendizagem e sua Aplicação em Sistemas Tutores Inteligentes.
Porto Alegre, 1995. Trabalho Individual I ( Mestrado em Ciência da Computação) .
UFRGS.
(GOHN, 2007) GOHN, D. M. Auto-aprendizagem musical: alternativas tecnológicas.
São
Paulo,
Annablume:
Fapesp,
2003.
Disponível
em:<
87
http://www.diaadiaeducacao.pr.gov.br/diaadia/diadia/arquivos/File/Mestrado.pdf>
Acesso em: 22/05/2010.
(HENTSCHKE, 1996) HENTSCHKE, Liane. Um estudo Longitudinal Aplicado a
Teoria Espiral de Desenvolvimento Musical de Swanwick com crianças Brasileiras da
Faixa Etária de 6 a 10 anos de Idade: Pólo Porto Alegre – 1994. In: Música: Pesquisa e
Conhecimento 2. Porto Alegre: CPG em Música – Mestre e Doutorado / UFRGS –NEA,
1996. p9-34.
(IAZZETTA, 1994) IAZZETTA, F. Um novo músico chamado usuário. Em anais do “I
Simpósio Internacional de Computação e Música”, Caxambu, Minas Gerais, Agosto de
1994, PP. 231 -235.
(JÁCOME, 2007) JÁCOME, J. O. J. Sistemas Interativos de Tempo Real para
Processamento Audiovisual Integrado. Recife: UFPE, 2007.Disponivel em: <
http://jarbasjacome.files.wordpress.com/2009/04/dissertacao_vimus_jarbasjacome2007.
pdf >. Acesso em: 25/05/2010.
(KRUGER, 1996) KRUGER, S. E. Dos receios à exploração das possibilidades: formas
de uso de software educativo-musical, capítulo 10 de Ensino de Música – propostas
para pensar e agir em sala de aula, org. Hentschke, L e Del Ben, L., Ed. Moderna, 2003.
(KRUGER, GERLING & HENTSCHKE 1999) KRUEGER, S. E.; GERLING, C. C.;
HENTSCHKE, L. Utilização de softwares no processo de ensino e aprendizagem de
instrumentos de teclado. OPUS: Revista da Associação Nacional de Pesquisa e PósGraduação
em
Música,
n.
6,
out.
1999.
Disponível
em:
<http://www.anppom.com.br/opus/opus6/kruger.htm>. Acesso em: 13/04/2010.
(LIMA, OLIVEIRA & RAMOS, 2002) LIMA, J. M. A. X.; OLIVEIRA, M.; RAMOS,
G.
WEBFLAUTA
Doce.
–
Fortaleza:
Uma
aplicação
CFETC,2002.
EAD
para
o
Disponível
Ensino
de
Flauta
em:
<
http://mpcomp.pgcomp.uece.br/admin/arquivos/ JoseLima2002. PDF >. Acesso em: .
(MED, 1996) MED, Bohumil. Teoria da Música. Brasília: MusiMED, 1996.
(MILETTO & PIMENTA,1993) MILETTO, E. M.; PIMENTA, M. S. Rumo a um
Ambiente para Composição Musical Coletiva Baseado na Web. In: IX SIMPÓSIO
88
BRASILEIRO EM COMPUTAÇÃO MUSICAL (IX SBCM), 1993, Campinas. Anais
do XXIII Congresso da Sociedade Brasileira de Computação. 2003. Disponível em:<
http://comp.unicruz.edu.br/~cotto/pdf/artigoExtReq.pdf >. Acesso em: 10 mai. 2010.
(MILETTO ET AL, 2004) MILETTO, E. M.; COSTALONGA, L. L.; FLORES, L. V.;
FRITSCH, E. F.; PIMENTA, M. S.; VICARI, R. M. Educação Musical Auxiliada por
Computador: Algumas Considerações e Experiências. RENOTE - Revista Novas
Tecnologias na Educação, Porto Alegre, RS, v. 2, 08 mar. 2004.
(MILETTO ET AL, 2005) MILETTO, Evandro M. et al. Educação musical auxiliada
por computador: algumas considerações e experiências. Porto Alegre, 2004. Disponível
em:<http://www.cinted.ufrgs.br/renote/mar2004/artigos/09-educacao_musical.pdf>.
Acesso em: 23/05/2010.
(MILETTO ET AL, 2006) Congresso Brasileiro de Ciência da Computação,
Edição
Especial 39, 2004. Disponível em: < http://www.unesc.net/portal/capa/index/ 213/0/1
/componente/ post/listar/65/10/4/1/0 > Acesso em: 10/03/2010.
(MIRANDA,
2006)
MIRANDA,
E.
R.
Neuromusic.Disponível
em:<http://neuromusic.soc.plymouth.ac.uk.> Acesso em:12/03/2010.
(MOORE, 2007) MOORE, F. R. Pcmusic Information. 1995. Disponível em: <
http://www.crca.ucsd.edu/cmusic/cmusicpc.html> Acesso em:23/05/2010.
(MOREIRA, 1987) MOREIRA, M. A questão da produção e avaliação do software
educacional. In: Seminário o Computador e a Realidade Educacional Brasileira, 2. Belo
Horizonte, UFMG/Centro Piloto de Informática na Educação, mai 1987.
(PATRÍCIO ET AL, 2008) PATRÍCIO, N. S.; FICHEMAN, I.K.; LOPES, R. D. Jogo do
Piano: Software Livre na educação Musical. São Paulo, SP: LSI-USP, 2008. Disponivel
em:
http://download.laptop.org/content/conf/20080417-
fisl09/jogo_do_piano/JogoDoPiano.pdf Acesso em: 18/05/2010
(PREECE, ROGERS & SHARP, 2005) PREECE, Jennifer. ROGERS, Yvonne. SHARP,
Helen. Design de Interação: além da interação homem-computador. Porto Alegre:
89
Bookman, 2005.
(PRESSMAN, 2006) PRESSMAN, Roger S. Engenharia de Software. São Paulo:
McGraw-Hill, 2006.
(RAMOS, 91) RAMOS, Edla. O fundamental na avaliação da qualidade do software
educacional.
Santa
Catarina,
RS:
UFSC,
1991.
Disponível
em:<
http://www.inf.ufsc.br/~edla/publicacoes/Qualid.pdf> Acesso em: 25/05/2010.
(SANTOS, 1998) SANTOS, Gilberto. Proposta de uma estratégia holística para a
engenharia
de
softwares
educativos.
Brasília
–
DF,
1998.
Disponível
em
<http://lsm.dei.uc.pt/ribie/docfiles/txt20034242744208.PDF> Acesso em 25/05/2010.
(SILVA, 2003) SILVA, J. Software educacional para auxilio ao aprendizado de Flauta
doce
a
crianças.
Itajaí,
SC:
UNIVALI,
2003.
Disponível
em:<
http://www.inf.ufsc.br/~julia/pub/10.pdf > Acesso em 25/05/2010.
(SOMMERVILLE, 2003) SOMMERVILLE, Ian. Engenharia de Software. São Paulo:
Pearson Addison Wesley, Campus, 2003.
(SOUZA, 2007) SOUZA, Reinaldo. O que é um Theremin? 2007. Disponível em: <
http://www.theremin.com.br/docs/theremin.pdf >. Acesso em: 14/03/2009.
(STAHL,1990) STAHL, M. Software educacional: características dos tipos básico. IN:
Anais do Simpósio Brasileiro de Informática na Educação 1:34-36, Rio de Janeiro, Nov
1990.
(STARUML,
2010)
STARUML.
http://staruml.sourceforge.net/en/ Acesso
em:
15/06/2010.
(VASCONCELOS ET AL, 2006) VASCONCELOS, A. M. L. Introdução à Engenharia
de Software e à qualidade de software. Lavras, MG: 2006. Disponível em :
<http://www.facape.br/jocelio/es/apostilas/Mod.01.MPS_Engenharia&QualidadeSoftwa
re_V.28.09.06.pdf> Acesso em: 13/03/2010.
(VIANA JÚNIOR & CASTRO FILHO, 2005) VIANA JÚNIOR, G. S.; CASTRO
FILHO, J. A. Avaliação de Software para o Ensino de Música: Reconhecendo a
Singularidade do Discurso Musical. São Leopoldo, RS: 2005. Disponível em: <
90
http://www.br-ie.org/pub/index.php/wie/article/view/833/819>. Acesso em: 13/03/2010.
(WINCKLER, NEMETZ & LIMA, 2000) WINCKLER, M. A. A.; NEMETZ, F.;
LIMA, J. V. Interação entre Aprendiz e Computador: Métodos para Desenvolvimento e
Avaliação de Interfaces. In: Tarouco, L. M. R. (Ed.) Tecnologia Digital na Educação .
Porto Alegre: Pós-Graduação em Informática na Educação, UFRGS. p.7-33. 2000.
Disponível
em:
<http://ihcs.irit.fr/winckler/2000-winckler-nemetz-valdeni-
InteracaoAlunoComputador.pdf >. Acesso em: 04/03/2010.
(ZAPAROLI, 2003) ZAPAROLI, Wagner. Engenharia de Requisitos: um fundamento na
construção de sistemas de informação. Exacta, Vol. I, 2003. Disponível em:<
http://www4.uninove.br/ojs/index.php/exacta/article/viewFile/522/500>.
03.03.2010.
Acesso
em
91
APÊNDICE A – CARTA DE CONSENTIMENTO
CARTA DE CONSENTIMENTO
[Adaptado de Cogdill (1999), citado em Preece, Rogers e Sharp (PREECE, ROGERS & SHARP, 2002)]
Afirmo que desejo participar do programa de pesquisa que esta sendo conduzido
pelo Sr. Ricardo de Lima Gonçalves, graduando em Ciência da Computação pela
Faculdade de Ciências Sociais e Aplicadas de Petrolina.
A intenção dessa pesquisa é o estudo de requisitos para a construção de um
software de educação musical, voltado especificamente para o aprendizado de bateria.
Todas as informações coletadas são sigilosas e minha identidade será preservada.
Estou ciente de que posso fazer perguntas ou desistir da colaboração em qualquer
momento, sem qualquer tipo de penalidade.
Data: ___ / ___ / ___
__________________________
Assinatura do participante
92
APÊNDICE
B
–
ROTEIRO
ENTREVISTA
SEMI-
ESTRUTURADA
1. Qual a sua formação acadêmica?
2. Quais atividades você desempenha nesta instituição?
3. Há quanto tempo exerce esta profissão?
4. Possui alguma formação na área tecnológica (informática)?
( ) Sim. Quais? ( )Não.
5. Já fez uso do computador como ferramenta auxiliar durante as aulas? Caso
afirmativo, relatar experiências.
6. Qual sua opinião sobre a educação musical no Brasil?
7. Como você avalia o ensino musical oferecido nesta instituição?
8. Possui algum conhecimento sobre Computação Musical?
9. Fora da sala de aula, usa o computador para alguma atividade que envolva a
música?
10. Adota algum modelo/teoria de referência para o ensino da música?
11. O que você pensa sobre o uso do computador como mais uma ferramenta de
ensino?
12. Quais funções/características desejáveis em um software educativo-musical para
apoio às aulas de bateria?
93
APÊNDICE C – QUESTIONÁRIO AOS ALUNOS
1. Qual a sua idade?
( ) 6 a 9 anos. ( ) 10 a 13 anos. ( ) 14 a 17 anos. ( ) mais de 18 anos.
2. Toca algum instrumento além da bateria?
( ) Sim. Qual? ____________________
( ) Não.
3. Seus pais tocam algum instrumento?
( ) Sim. Qual?____________________
( ) Não.
4. Tem computador em casa?
( ) Sim.
( ) Não.
5. Já fez algum curso de informática?
( ) Sim.
( ) Não.
6. Gostaria que o professor utilizasse o computador com mais freqüência nas
aulas?
( ) Sim. ( ) Não.
7. Quais atividades já realizou usando o computador? (se for o caso, mais de uma
opção poderá ser marcada)
( ) Gravação / edição de áudio
( ) Praticar exercícios
( ) Estudar teoria musical
( ) Criar/editar partituras
( ) Apreciação
8. Qual é o estilo de música que você mais gosta?
( ) Forró
( ) MPB
( ) Sertanejo
( ) Pop/Rock - Nacional
( ) Axé/Pagode
( ) Outro:_______________
9. De que tipo de aula você mais gosta?
( ) Teóricas
( ) Práticas
( ) Composição
( )Todas
94
ANEXO A – SOFTWARES DE ATUAÇÃO DIRETA
Software
Fabricante
The Pianist / PG Music
The Jazz
Inc.
Pianist
Plataforma
IBM/
PC,
Mac
Miracle
Piano
Music-ware
Piano
(Course I
and II)
Music-ware
IBM/
PC
The Music
Yamaha
Suite / Music
In Education
IBM/
PC
Mac
Principais Características
Referências
Pesquisador
Demonstra mais de 200 peças de
Glanzmann,
compositores do repertório erudito / 1995
jazzístico. As obras podem ser
escolhidas segundo alguns critérios,
como compositor, nome, período
histórico, modo e grau de
dificuldade.
As lições iniciam no Dó Ce
expandem até o aprendiza
peças a duas mãos.
Oferece 50 horas de lições sobre
habilidades pianísticas para alunos
de nível inicial e intermediário.
"Inclui atividades de altura, ritmo,
escalas, intervalos, acordes, leitura
à primeira vista, treino auditivo,
símbolos e vocabulário", e a versão
"estúdio"possibilita a
individualização do currículo (p.89)
Rudolph,
1996;
The
Wood-wind
& The
Brasswind,
1995.
Controlam laboratórios de teclados Rudolph,
eletrônicos e sintetizadores. Podem 1996
ser utilizados em escolas de música
ou de ensino fundamental,
apresentando um currículo
completo de formação musical, com
ensino teórico e prático, inclusive
de edição sonora (ibid.
p.163;178-9).
95
Piano Tutor
Cappel &
PC
Dannen-berg
Para ensino básico de piano.
"Estação de trabalho multimídia
que emprega acompanhamento de
partitura em tempo real, sistema
especialista e vídeo-disco"(p.80).
Cada lição é tratada
individualmente, associada com
pré-requisitos, objetivos, uma
apresentação e uma avaliação.
"É possível o uso de um modelo
formal baseado nestas lições e
habilidades para representar o
currículo, e adaptá-lo
automaticamente à individualidade
de cada aluno"(ibid. p.81).
Glanzmann,
1995
Expert Piano Glanz-mann
PC
Software para auxílio no estudo de
piano, com vários módulos para
atividades diferentes.
Glanzmann,
1995
Vistamusic
não
especificado
Software para execução,
composição e arranjo de peças
utilizado em pesquisa de
expressividade em performance em
instrumentos de teclado
Dalgarno,
1997
Dalgarno
96
ANEXO B – SOFTWARES DE ATUAÇÃO INDIRETA
Software
Encore 4.2
Finale
Fabricante Plataforma
Passport
Coda
IBM/P
C Mac
Editoração de partituras
IBM/PC
Software de editoração de
partituras a nível profissional
Mac
Master Trax
Pro 4.9
Passport
Cakewalk
Twelve
IBM/PC
Tone
System Inc.
Alfred’s
Alfred Co.
Basic Piano
Theory
Software
Principais Características
IBM/PCMac Software seqüenciador
IBM/PC
Referências
Pesquisador
Braga,
1995,
Krüger et
al.,
1999
Braga, 1995
Braga, 1995
Software seqüenciador
Glanzmann,
1995
Coleção de software de teoria
musical, complementares ao
método de piano homônimo
The
Woodwind
& The
Brass-wind,
1995
MacGregor,
1994
(Software
para
Composiçã
o Infantil)
LADAM
MacGregor Não
Software criado a partir de
mencionada pesquisas na área de psicologia
da música, com recursos
específicos para composição
Braga
IBM/PCMac Apoio à aprendizagem
Braga, 1995
musical: editoração e
seqüenciação de partituras,
ensino de harmonia, história
The Musical Opcode
IBM/PC
Ensino de Teoria Musical, por Krüger, 1996
World of
Interactive
meio de atividades variadas como
Mac
Prof. Piccolo
análise musical e jogos
Beethove
n Lives
Upstairs
BMG
Musi
c
IBM/PC
Juilliard
Music
Adventur
e
Introdução
à Teoria
Musical
Theatrix
IBM/P
Interactive C Mac
& Juilliard
School
MSD
IBM/PC
Softwar
e
SETMUS
UFRGS
ULBRA
IBM/PC
Jogos musicais com diferentes
conteúdos (instrumentos
musicais, notação tradicional e
outros)
Jogos visando realização de
composições musicais, e ensino
de conteúdos teóricos voltados a
recursos composicionais
Ensino de teoria musical, por
meio de apresentação de
conceitos e exercícios de fixação
Software para aprendizado
e exercícios de escalas
Maiores e menores
Krüger, 1996
Krüger,
1996, 1997
Krüger, 1996