Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp

CENTRO UNIVERSITÁRIO DO ESTADO DO PARÁ
ÁREA DE CIÊNCIAS EXATAS E TECNOLOGIA
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
Felipe Guimarães Cunha
Rodrigo Carneiro Andrade
APLICATIVO DE APOIO AO ENSINO DE TEORIA MUSICAL PARA A
PLATAFORMA ANDROID – MOZAPP
Belém
2015

CENTRO UNIVERSITÁRIO DO ESTADO DO PARÁ
ÁREA DE CIÊNCIAS EXATAS E TECNOLOGIA
BACHARELADO EM CIÊNCIA DA COMPUTAÇÃO
APLICATIVO DE APOIO AO ENSINO DE TEORIA MUSICAL PARA A
Trabalho de Curso na modalidade Produto,
apresentado como requisito parcial para
obtenção do grau em Bacharelado em
Ciência da Computação do Centro
Universitário do Estado do Pará – CESUPA,
sob orientação da Profª. Msc. Alessandra
Natasha Alcântara Barreiros e Coorientação
do Prof. Msc. Carlos dos Santos Portela.
Belém
2015

Dados Internacionais de Catalogação-na-publicação (CIP)
Biblioteca do Cesupa, Belém - PA
Cunha, Felipe Guimarães.
Aplicativo de apoio ao ensino de teoria musical para a plataforma android -
Mozapp / Felipe Guimarães Cunha, Rodrigo Carneiro Andrade; orientação de
Alessandra Natasha Alcântara Barreiros; coorientação de Carlos dos Santos
Portela, 2015.
Trabalho de Conclusão de Curso (Bacharelado em Ciência da Computação) –
Centro Universitário do Pará, Belém, 2015.
1. Aplicativo de software. 2. Android (Sistema operacional). 3. Música –
Estudo e ensino. I. Andrade, Rodrigo Carneiro. II. Barreiros, Alessandra
Natasha Alcântara (orient.). III. Portela, Carlos dos Santos. IV. Título.
CDD. 23º ed. 005.1

APLICATIVO DE APOIO AO ENSINO DE TEORIA MUSICAL PARA
Trabalho de Curso apresentado na modalidade Produto, apresentado como requisito
parcial para obtenção do grau em Bacharelado em Ciência da Computação do Centro
Universitário do Estado do Pará – CESUPA.
Data da Defesa: 11/12/2015
Banca Examinadora:
________________________________
Prof. Msc. Alessandra Natasha Alcântara Barreiros - CESUPA
________________________________
Prof. Msc. Carlos dos Santos Portela - CESUPA
________________________________
Prof. Dr. Msc. Marcos Paulo Alves de Sousa - CESUPA
Belém
2015

AGRADECIMENTOS
Agradeço aos meus pais Romildo Figueiredo Cunha e Maria do Socorro Guimarães
Cunha, pelos ensinamentos que me passaram desde o início da minha vida, que contribuíram
para a minha formação como ser humano. Agradeço também à minha irmã Júlia Guimarães
Cunha, por estar sempre presente e por me apoiar quando precisei.
A minha orientadora Alessandra Natasha por sua compreensão, paciência e pelo
incentivo que me deu, que foi de extrema importância para a conclusão deste trabalho.
O meu co-orientador Carlos Portela, por sua sabedoria acerca dos processos de
desenvolvimento e Engenharia de Software, e por seu apoio constante no decorrer deste
trabalho, que também foi extremamente importante.
Aos professores que contribuíram para a minha formação dentro do ambiente
acadêmico, em especial à professora Polyana Nascimento, professora Eliane Alves, professor
Andracir Alves, professor Otávio Noura e professora Lêda Monteiro.
Ao meu amigo e parceiro de trabalho Rodrigo Andrade, pela amizade construída
durante a graduação e por ter realizado junto comigo a conclusão deste trabalho.
Aos meus amigos e companheiros de curso Daniel Leal, Ariadne Ferreira e Filipe
das Neves e Armando Toda, pela ótima companhia durante a nossa graduação e por me
ajudarem sempre que puderam.
E a todas as pessoas que eu tenho o prazer de considerar como meus amigos, pessoas
importantíssimas para mim, que estão sempre dispostas a me ajudar quando preciso.

Primeiramente, gostaria de agradecer à Deus, pela oportunidade de ter me concedido
essa maravilhosa graduação, a qual me esforcei muito para chegar ao fim. Agradeço também a
Ele por todas as lições dadas ao longo desses anos de vida acadêmica, pelas amizades que
construí e pelas amizades antigas que se reforçaram.
Gostaria de agradecer aos meus pais, José Aloizio Santana Andrade e Marlete
Carneiro Andrade, por serem pessoas incríveis e por fazerem parte da minha formação como
ser humano me aconselhando e impulsionando. Sempre na minha vida foi me passado através
dos meus pais, princípios e valores que moldaram o meu caráter como pessoa e que vou levar
para o resto da minha vida. Também, por terem me proporcionado e me incentivado essa
experiência desde seu início, sem os quais literalmente não teria acontecido. A eles, serei
eternamente grato.
Agradeço eternamente a minha namorada, Juliane de Matos Frazão, por ter me
acompanhado nas madrugadas, por ter me apoiado nos momentos que mais precisei, por não
ter me deixado sozinho nesse período importante da minha vida e te agradeço muito mais ainda
por me amar. Gostaria ainda de registrar aqui meu apreço, carinho, amor e admiração por ser
uma mulher tão inteligente, que se sempre me encanta de todas as formas.
A toda minha família tanto por parte de pai, quanto por parte de mãe, por estenderem o
sentimento acolhedor e por partilhar tantos momentos de felicidade, união e fraternidade.
Gostaria de agradecer ao meu companheiro de jornada Felipe Guimarães Cunha, que
foi crucial no desenvolvimento deste trabalho e por partilhar a mesma paixão que é a música.
Agradeço a Prof. Msc. Alessandra Natasha Alcântara Barreiros por ter aceitado orientar
esse trabalho e por sempre se mostrar uma professora extremamente competente e capacitada,
sempre ensinando aos seus alunos a melhor forma de ser um profissional competente e
exemplar. Agradeço ao Prof. Msc. Carlos dos Santos Portela por ter sido um ilustre
professor, profissional e peça fundamental para conclusão desse trabalho, sempre disposto a
ajudar no que fosse necessário para engrandecer o trabalho, corrigindo ou esclarecendo as
dúvidas. Agradeço ao Prof. Msc. Andracir Alves Oliveira por ser um dos melhores
professores que já tive o prazer de conhecer e ser aluno, por ter me mostrado o significado das
palavras “dedicação” e “esforço”. Agradeço ao Prof. Msc. Andréa Marques Araújo por ser
uma professora esplêndida e por ter prestado toda ajuda e atenção que pôde a este trabalho.
Agradeço ao Prof. Msc. Polyana Santos Fonseca por ser um exemplo de pessoa e por
expressar em sala de aula a melhor didática que já presenciei. Agradeço ao Prof. Dr. Msc.

Otavio Noura Teixeira, que nos inspirou a nunca desistirmos por maiores que sejam os
obstáculos. Agradeço aos Prof. Dr. Msc. Marcos Paulo Sousa, Prof. Dr. Msc. Orlando
Shigueo Ohashi Junior, Prof. Msc. Ricardo Melo Casseb do Carmo e Prof. Msc. Rodrigo
Lisboa Pereira por terem me passado os ensinamentos e conhecimentos para poder me tornar
um bom desenvolvedor de software, e por serem os profissionais mais exemplares que já
conheci.
Agradeço aos meus amigos Daniel Borges Leal, Marcos Pereira Lourinho, Milton
Neto Cordeiro de Alcântara, Rafael Mendonça Ribeiro por terem sido os melhores amigos
que pude desejar durante esses anos de luta e de muito esforço na graduação. Agradeço também
a todos aqueles que, de alguma forma, possibilitaram o acontecimento deste trabalho.

“A música não exprime nunca o fenômeno, mas
unicamente a essência intima de todo
fenômeno, numa palavra a própria vontade.
Portanto não exprime uma alegria especial ou
definida, certas tristezas, certa dor, o medo, os
transportes, o prazer, a serenidade do espírito;
exprime-lhes a essência abstrata e a geral, fora
de qualquer motivo ou circunstância. E todavia
nessa quinta essência abstrata, sabemos
compreendê-la perfeitamente. ”
Arthur Schopenhauer

RESUMO
Este trabalho apresenta o aplicativo Mozapp, cuja finalidade é servir como ferramenta de
incentivo ao aprendizado de teoria musical por meio de metodologias dinâmicas fazendo uso
de gamificação e visando o melhor aproveitamento do aluno. As aulas e exercícios são
interativos de modo que o usuário irá acompanhar o seu progresso de aprendizagem. O
aplicativo foi concebido para a plataforma mobile (Android), e utiliza um banco de dados com
as informações sobre cada conta de usuário, incluindo seu progresso de aprendizado e suas
conquistas. O Mozapp tem por base a confiabilidade de informações sobre teoria musical
procedente de profissionais da área, bem como o formalismo de uma programação
desenvolvida nos moldes da engenharia de software, sendo adotado o Scrum como metodologia
para a gestão do projeto e o XP (Extreme Programming) como metodologia de
desenvolvimento. Como parte do trabalho foi feita uma parceria com a Fundação Amazônica
de Música, a qual foram realizados testes de usabilidade do aplicativo com alunos e professores
de música, a fim de obter a validação do Produto Mínimo Viável e criar diretrizes para o
refinamento do sistema.
Palavras-chave: Teoria Musical. Mozapp. Gamificação. Android.

ABSTRACT
This paper presents the Mozapp application whose purpose is to serve as a tool to encourage
the learning of music theory through dynamic methodologies that uses gamification methods
to achieve better results in learning, such as lessons and interactive exercises where the users
can track their learning progresses. The application is designed for the mobile platform
Android, and uses a database that contain information about each user account, including its
learning progress and user achievements. Mozapp is based on the confiability of music theory
information that comes from professionals from that area, as well as the formalism of software
engineering templates for its developing processes, adopting Scrum as a methodology for
project management and XP (Extreme Programming) as a software developing methodology.
As part of the work, we did a partnership with the Foundation Amazônica de Música, and we
tested the usability of the application with students and music teachers in order to obtain
validation of the Minimum Viable Product and create guidelines for system refinement.
Keywords: Music Theory. Mozapp. Gamification. Android.

LISTA DE FIGURAS
Figura 1 - Porcentagem de alunos inscritos por graus nas escolas investigadas ................... 15
Figura 2 - Fração de Mercado por Sistemas Operacionais Móveis ...................................... 19
Figura 3 - Fluxo do Scrum ................................................................................................. 34
Figura 4 - Ciclo de vida do Scrum...................................................................................... 35
Figura 5 - Fases do processo de desenvolvimento do Mozapp ............................................ 47
Figura 6 - Fase de Pré-Game do Mozapp............................................................................ 48
Figura 7 - Fases de Game do Mozapp................................................................................. 49
Figura 8 - Fases de Pós-Game do Mozapp.......................................................................... 50
Figura 9 - Diagrama de caso de uso do aplicativo Mozapp ................................................. 51
Figura 10 - O wireframe da tela inicial ............................................................................... 52
Figura 11 - Diagrama de Entidade-Relacionamento do Mozapp ......................................... 53
Figura 12 - A pilha do Android e sua divisão de camadas................................................... 54
Figura 13 - Adobe Photoshop............................................................................................. 56
Figura 14 - Android Studio................................................................................................. 57
Figura 15 - Astah Community............................................................................................ 57
Figura 16 - Balsamiq Mockups........................................................................................... 58
Figura 17 - FL Studio......................................................................................................... 58
Figura 18 - Genymotion ..................................................................................................... 59
Figura 19 - GIMP............................................................................................................... 59
Figura 20 - Paint ................................................................................................................ 60
Figura 21 - Spider-PM ....................................................................................................... 60
Figura 22 - MySQL Workbench......................................................................................... 61
Figura 23 - Trello............................................................................................................... 61
Figura 24 - Tela de abertura do Mozapp............................................................................. 63
Figura 25 - Tela Principal do Mozapp ................................................................................ 64
Figura 26 - Tela de Login do Mozapp................................................................................. 64
Figura 27 - Tela de Cadastro Mozapp................................................................................. 65
Figura 28 - Dashboard....................................................................................................... 66
Figura 29 - Menu de Seleção.............................................................................................. 67
Figura 30 - Aula de Notas do Mozapp................................................................................ 67
Figura 31 - Exercício de Notas do Mozapp......................................................................... 68
Figura 32 - Tela de Gamificação do Aplicativo .................................................................. 69
Figura 33 - Tela de Gamificação do Aplicativo (Parte 2).................................................... 69
Figura 34 - Perfil do Usuário no Mozapp ........................................................................... 70
Figura 35- Reunião na Fundação Amazônica...................................................................... 71
Figura 36 - Usabilidade do aplicativo Mozapp ................................................................... 72
Figura 37 - Pesquisa de Campo (Parte 1)............................................................................ 73

LISTA DE SIGLAS
SO - Sistema Operacional
XP - Extreme Programming
OpenGL - Open Graphics Library
SSL - Secure Socket Layer
APK - Android Package
XML - Extensible Markup Language
UML - Unified Modeling Language
DER - Diagrama Entidade-Relacionamento
SQL - Structured Query Language

SUMÁRIO
1 INTRODUÇÃO.............................................................................................................. 15
1.1 OBJETIVO GERAL.................................................................................................. 17
1.2 OBJETIVO ESPECÍFICO ......................................................................................... 17
1.3 JUSTIFICATIVA ...................................................................................................... 18
1.4 METODOLOGIA...................................................................................................... 20
1.5 ESTRUTURA DO TRABALHO ............................................................................... 20
2. FUNDAMENTAÇÃO TEORICA ................................................................................ 22
2.1 TEORIA MUSICAL.................................................................................................. 22
2.2 GAMIFICAÇÃO....................................................................................................... 22
2.3 TECNOLOGIA NA EDUCAÇÃO MUSICAL .......................................................... 25
2.4 MÉTODO SUZUKI................................................................................................... 27
2.5 APLICATIVOS EXISTENTES NO MERCADO ...................................................... 29
3. PROCESSO DE DESENVOLVIMENTO.................................................................... 30
3.1 METODOLOGIAS ÁGEIS ....................................................................................... 30
3.2 SCRUM..................................................................................................................... 32
3.2.1 Fluxo do Scrum ................................................................................................. 34
3.2.2 Ciclo de vida ...................................................................................................... 35
3.2.2.1 Pré-Game...................................................................................................... 36
3.2.2.2 Game ............................................................................................................ 36
3.2.2.3 Pós-Game ..................................................................................................... 36
3.2.3 Papéis................................................................................................................. 37
3.2.4 Práticas .............................................................................................................. 38
3.2.4.1 Sprint planning meeting................................................................................ 38
3.2.4.2 Sprint............................................................................................................ 38
3.2.4.5 Daily meeting................................................................................................ 39
3.2.4.3 Sprint review meeting.................................................................................... 39
3.2.4.4 Sprint retrospective....................................................................................... 39
3.2.5 Artefatos ............................................................................................................ 40
3.2.5.1 Vision ........................................................................................................... 40
3.2.5.2 Product backlog............................................................................................ 40
3.2.5.3 Sprint backlog............................................................................................... 40
3.2.5.4 Sprint burndown ........................................................................................... 40

3.3 XP – EXTREME PROGRAMMING......................................................................... 41
3.3.1 Valores ............................................................................................................... 41
3.3.1.1 Comunicação ................................................................................................ 41
3.3.1.2 Coragem ....................................................................................................... 42
3.3.1.3 Feedback ...................................................................................................... 42
3.3.1.4 Respeito........................................................................................................ 43
3.3.1.5 Simplicidade................................................................................................. 43
3.3.2 Práticas .............................................................................................................. 44
3.3.2.1 Cliente presente ............................................................................................ 44
3.3.2.2 Jogo do planejamento.................................................................................... 44
3.3.2.3 Stand up meeting........................................................................................... 45
3.3.2.4 Programação em Par ..................................................................................... 45
3.3.2.5 Código coletivo............................................................................................. 45
3.3.2.6 Design simples.............................................................................................. 46
3.3.2.7 Refatoração................................................................................................... 46
3.3.2.8 Ciclo semanal ............................................................................................... 46
3.4 FASES DO PROCESSO............................................................................................ 47
3.4.1 Pré-game............................................................................................................ 48
3.4.2 Game.................................................................................................................. 49
3.4.3 Pós-game............................................................................................................ 50
3.5 MODELAGEM DO MOZAPP .................................................................................. 51
3.5.1 Caso de Uso........................................................................................................ 51
3.5.2 Wireframe do Aplicativo Mozapp ..................................................................... 52
3.5.3 Diagrama de Entidade-Relacionamento do Aplicativo Mozapp...................... 53
3.6 ARQUITETURA....................................................................................................... 53
3.6.1 Núcleo Linux...................................................................................................... 54
3.6.2 Bibliotecas nativas............................................................................................. 55
3.6.3 Framework de Aplicação ................................................................................... 55
3.6.4 Aplicações .......................................................................................................... 55
3.7 FERRAMENTAS E TECNOLOGIAS....................................................................... 56
3.7.1 Ferramentas....................................................................................................... 56
3.7.2 Tecnologias Utilizadas....................................................................................... 62
4 O APLICATIVO MOZAPP .......................................................................................... 63

4.1 TELA PRINCIPAL ................................................................................................... 63
4.2 DASHBOARD .......................................................................................................... 66
4.3 AULAS ..................................................................................................................... 66
4.4 EXERCÍCIOS............................................................................................................ 68
4.5 GAMIFICAÇÃO NO APLICATIVO ........................................................................ 68
4.6 PERFIL ..................................................................................................................... 70
4.7 PESQUISA DE CAMPO ........................................................................................... 70
5 CONSIDERAÇÕES FINAIS ......................................................................................... 75
5.1 DIFICULDADES ENCONTRADAS......................................................................... 75
5.2 TRABALHOS FUTUROS......................................................................................... 76
REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................. 77
APÊNDICES ..................................................................................................................... 81
ANEXOS ............................................................................................................................... 88

15
1 INTRODUÇÃO
A exigência de conhecimentos de teoria da música e de leitura e escrita musical nos
exames de admissão para instituições do ensino de música, faz com que estudantes vindos de
experiências musicais diferentes da música erudita dificilmente tenham condições de ingressar
e frequentar uma escola de música. Além disso, a formação dos professores dificulta a
permanência de tais estudantes nas escolas, já que a maioria dos docentes desconhece o saber
musical e as práticas de aprendizagem de músicos populares. (LIMA, 2010).
Segundo Sousa (2004),
Não obstante o aumento do número de escolas de música e do número de jovens a aprender
música, atestamos a existência de elevadas taxas de insucesso e de abandono. É muito
escasso o número de alunos a completarem o curso de instrumento, sendo frequente na
generalidade das Academias e Escolas de Música a existência de um número muito reduzido
de alunos a frequentarem os últimos anos. Verificamos a presença de uma discrepância entre
as disponibilidades dos alunos para o estudo da música e a exigência dos professores e da
própria escola, havendo uma enorme dificuldade de conciliação entre a aprendizagem
musical e o ensino genérico. As Academias têm currículos, planos de estudo e programas
oficiais, mas a generalidade dos alunos não os completa.
De acordo com pesquisa feita por Sousa (2004), apenas 15% dos alunos frequentava os
últimos graus nas escolas vocacionais de música. A investigação foi realizada em três escolas
privadas, e foi efetuado um estudo para constatar a situação de abandono descrita
anteriormente.
Uma das métricas utilizadas na pesquisa foi a distribuição por graus dos alunos inscritos
na disciplina de instrumento, onde se nota que o número de alunos decresce constantemente a
medida que o grau aumenta, como se pode observar na Figura 1.
Figura 1 - Porcentagem de alunos inscritos por graus nas escolas investigadas
Fonte: Adaptado de Sousa (2004).
32,1
24,1
13,4 13,1
7,8 5,3 3,2 1,1
0
5
10
15
20
25
30
35
1º 2º 3º 4º 5º 6º 7º 8º

16
Neste sentido se apresenta um dos grandes problemas encontrados por estudantes e
aspirantes de música: a dificuldade no aprendizado de teoria musical, na forma tradicional de
como são aplicados seus conhecimentos, além do longo período de tempo que é dedicado ao
aprendizado da mesma. Apesar de existirem diversos métodos convencionais de ensino, é
notável que os mesmos carecem de flexibilidade e de elementos ou mecânicas estimulantes, o
que por vezes torna o aprendizado dificultoso e monótono, havendo pouco ou nenhum
dinamismo. O referido modelo de ensino acaba retardando o processo de aprendizagem de
estudantes ou até desestimulando aspirantes, fazendo com que deixem de entrar no mundo da
música.
Um aspecto comum no meio musical é encontrar pessoas que tocam instrumentos,
entretanto desconhecem a leitura de partituras ou formalismo de notações clássicas referentes
a seus instrumentos. Estas situações ocorrem, sobretudo, pelo grau de dificuldade percebido
para esta aprendizagem, muitas vezes maior e mais desestimulante do que dominar o próprio
instrumento (SOUSA, 2004).
Acerca destas situações, foi observada a necessidade de uma abordagem mais dinâmica
do ensino de música, sendo esta a motivação para a proposta do Mozapp: uma metodologia
interativa do ensino formal de música, que integra o aprendizado do usuário com desafios e
conquistas gamificadas em um aplicativo mobile como tecnologia de acesso.
Neste contexto de abordagens de ensino mais dinâmicas, observa-se que recursos
tecnológicos estão presentes na vida de todos e em diversos momentos do cotidiano. A
tecnologia avança constantemente e uma das grandes vantagens que proporciona é o aumento
da praticidade no que diz respeito a obtenção de informação, e também ao aumento da
mobilidade, através dos dispositivos móveis. Ações que antes demoravam uma quantidade
significativa de tempo hoje são realizadas em segundos, e essa evolução se aplica também na
pesquisa, onde conteúdos que antes só eram obtidos através de livros físicos podem ser
acessados de maneira muito mais prática através da internet.
Com a popularização dos computadores e da internet, surgem novas tecnologias
capazes de auxiliar diversos processos, como é o caso do processo de ensino-aprendizagem.
Uma das grandes tendências nesta área tem vindo da adoção de técnicas de Gamificação
(ANDRIOTIS, 2014). Segundo este autor, as tecnologias que envolvem técnicas de
gamificação oferecem recursos de grande importância e são peças-chave para a adoção em
diversas áreas.

17
Na área da música, alguns aplicativos encontram-se fortemente inseridos nos segmentos
de composição, arranjo, ferramentas (como metrônomos, calculadoras e afinadores) e
principalmente de instrumentos virtuais. Entretanto, de forma específica na área do ensino da
Teoria Musical, foi identificada, de acordo com pesquisa feita por estes autores, uma escassez
de aplicativos, sendo os existentes limitados ao idioma inglês e não atrelados a uma proposta
de gamificação associada à música. Este foi o motivo que serviu de inspiração para o
desenvolvimento de um aplicativo que estimula e facilita e aprendizagem da Teoria Musical
de forma gamificada, bem como a principal contribuição do Mozapp.
Tem-se ainda como proposta do aplicativo, uma maneira de popularizar o ensino de
música, ou seja, fazer com que aprender música se torne mais acessível, além de mais intuitivo,
simples e divertido. Em linhas gerais, portanto, trata-se de um aplicativo diferenciado do que
se tem hoje no mercado, pois o mesmo traz a aprendizagem de Teoria Musical de forma lúdica,
associada a gamificação e a mobilidade da plataforma com a qual foi desenvolvido, de forma
a contribuir de maneira positiva para o seu público-alvo.
1.1 OBJETIVO GERAL
A proposta desse trabalho é desenvolver um aplicativo para dispositivos móveis com o
Sistema Operacional (SO) Android, que terá como objetivo inspirar e facilitar o aprendizado
de alunos de música, tornando-o mais intuitivo e diferenciado dos métodos tradicionais de
ensino. Para este fim, o aplicativo utilizará a gamificação como método próprio de ensino, ao
tratar aulas e exercícios como desafios e acertos como bonificações, além de trazer recursos
interativos que abordam o assunto de forma mais clara e dinâmica.
1.2 OBJETIVOS ESPECÍFICOS
Para que o objetivo geral fosse alcançado, as seguintes metas foram definidas:
 Apresentar um aplicativo que mostre de maneira lúdica a Teoria Musical;
 Apresentar o conteúdo de Teoria Musical através de módulos interativos,
facilitando assim a compreensão dos mesmos;

18
 Adaptar exercícios de Teoria Musical dispostos por meio de ferramentas de
gamificação;
 Criar uma interface intuitiva e simples, com o propósito de tornar a
ferramenta acessível a qualquer público;
 Premiar as atividades bem-sucedidas e estimular novas tentativas em caso
de falhas;
 Armazenar as informações sobre os usuários do aplicativo em um banco de
dados.
1.3 JUSTIFICATIVA
O interesse e vivência musical dos integrantes deste Trabalho de Curso, aliados a
formação acadêmica em Ciência da Computação trouxeram uma experiência real do mercado
de aplicativos voltados à educação musical. Desta forma, como citado na introdução deste
Trabalho, percebeu-se a escassez de um aplicativo que propusesse aliar o ensino de música a
técnicas de gamificação, justificando a escolha do presente trabalho como forma de estimular
o aprendizado deste denso conteúdo.
A plataforma do aplicativo foi escolhida a fim de maximizar o seu acesso, pois segundo
pesquisa feita até a metade de 2015 pela corporação de pesquisas de mercado IDC (2015), o
Android, como é mostrado na Figura 2, ocupa 82,8% do mercado de smartphones, e em relação
aos anos anteriores, apresenta um crescimento nesta fração. Outros sistemas móveis como o
iOS, Windows Phone e Blackberry ocupam respectivamente 13,9%, 2,6% e 0,3%. Tais dados
provam que o sistema Android detém a maior fração do mercado de sistemas e aplicativos
móveis. Pretende-se com isso, que uma maior quantidade de pessoas tenha acesso ao conteúdo
do aplicativo e por fim, pretende-se atender a um de seus objetivos: a popularização do ensino
de música.

19
Figura 2 - Fração de Mercado por Sistemas Operacionais Móveis
Fonte: IDC (2015, online).
Buscou-se, ainda, acrescentar na proposta uma metodologia de ensino que esteja
baseada, em sua essência, a uma aprendizagem que estimule a redução do conteúdo teórico
formal na fase inicial da introdução à música, com intenção de não enfadar o aprendiz com
excesso de informação desnecessária em um primeiro momento, desencorajando-o a prosseguir
com seus estudos.
Tal metodologia de ensino é consoante ao que propõe métodos de educação musical
como o do violinista Shinichi Suzuki, o qual segundo o instituto Australiano Suzuki Music
(2015), propõe um aprendizado musical que consiste em brincadeiras para que as crianças se
divirtam enquanto aprendem. A metodologia abordada pelo aplicativo também vai ao encontro
do que hoje é praticado por alguns institutos, como é o caso da Fundação Amazônia de Música,
que por meio do projeto Vale Música, ensina o ofício da música a crianças da rede pública de
Belém e forma profissionais para orquestras e bandas há mais de 15 anos (VALE MÚSICA,
2015).

20
1.4 METODOLOGIA
O trabalho foi concebido em etapas, iniciando pela pesquisa bibliográfica do conteúdo
musical e passando pela pesquisa de mercado referente aos aplicativos neste segmento. Em
seguida, foram verificadas as tecnologias que pudessem ser utilizadas no desenvolvimento do
produto. Foram adotadas as plataformas de acordo com sua abrangência de acesso e
usabilidade, como já mencionado na subseção 1.3 deste capítulo.
Em seguida, para a concepção do aplicativo, buscou-se consonância com um modelo
qualitativo de pesquisa, empregando o método Suzuki de ensino de música, que segundo o site
Suzuki Music (2005), busca tornar o conteúdo mais divertido e fácil de se aprender.
Já o desenvolvimento do sistema foi guiado pela metodologia ágil de gestão e
planejamento de projetos, denominada de Scrum. O projeto também seguiu uma metodologia
ágil de desenvolvimento de software, o XP (Extreme Programming).
O aplicativo Mozapp também faz uso da abordagem de gamificação, isto é, a aplicação
de elementos e mecânicas de jogos em outros contextos (NICHOLSON, 2012). Tal aspecto
tem finalidade de conseguir maior participação e envolvimento dos usuários, o que é essencial
para um bom rendimento no ambiente do aplicativo e na proposta de tecnologia de ensino-
aprendizagem.
1.5 ESTRUTURA DO TRABALHO
O acesso facilitado à teoria musical tem sido a inspiração para o desenvolvimento deste
Trabalho de Curso. O cenário que apresenta esta dificuldade e correlaciona à escassez de
tecnologias, metodologias e aplicativos que busquem tal objetivo, são a base do Capítulo 1,
introdutório.
No Capítulo 2 é explorada a fundamentação teórica para o desenvolvimento do Mozapp,
que conta com fundamentos de Teoria Musical e uma pesquisa aprofundada em técnicas e
metodologias de gamificação.

21
Em seguida, foram verificadas as tecnologias que pudessem ser utilizadas no
desenvolvimento do produto. Foram adotadas as plataformas de acordo com sua abrangência
de acesso e usabilidade, como já mencionado no item 1.3 deste capítulo.
O Capítulo 3 contém as práticas utilizadas para a concepção do aplicativo. Para seu
desenvolvimento, baseou-se consonância com o framework de gestão e planejamento de
projetos Scrum, e com a metodologia de desenvolvimento de software XP. Foram selecionadas
as características de cada uma das metodologias que se adaptaram melhor ao desenvolvimento
do produto Mozapp.
Neste capítulo, abordam-se as metodologias Scrum e XP de forma genérica, e também
da forma que foram utilizadas dentro do ambiente do processo de desenvolvimento do
aplicativo. São mostrados neste capítulo o fluxo do Scrum, ciclo de vida, papéis, práticas e
artefatos. O capítulo também explica sobre os valores e práticas presentes na metodologia XP.
Ainda neste capítulo, são abordadas as metodologias da maneira que foram utilizadas
no processo do aplicativo. São explicadas neste capítulo as fases do framework Scrum, a
modelagem do aplicativo, incluindo seu caso de uso, wireframe, diagrama de entidade, além
de sua arquitetura, findando pelas ferramentas e tecnologias que foram utilizadas ao longo do
desenvolvimento do projeto.
O Capítulo 4 mostra as telas do aplicativo e suas respectivas funcionalidades, da
maneira em que são organizadas. Este capítulo exibe a maneira que as funcionalidades
explanadas ao longo do trabalho são abordadas no aplicativo, junto com seu design e interface
de usuário.
Também no Capítulo 4, apresentam-se dados da pesquisa de campo feita com alunos e
professores do Instituto Amazônia de Música, em parceria com o projeto Vale Música, com o
objetivo de validar o aplicativo e avaliar sua usabilidade.
Por fim, o Capítulo 5 contém a conclusão do trabalho, e aborda as considerações finais
do desenvolvimento do Mozapp, assim como os impactos esperados com a disponibilização do
aplicativo, as dificuldades encontradas ao longo de seu processo de desenvolvimento e os
planos de trabalhos futuros para aprimorar o aplicativo.

22
2. FUNDAMENTAÇÃO TEÓRICA
2.1 TEORIA MUSICAL
De acordo com a escola Música Sacra e Adoração (2012, online)
Música é a arte de expressar nossos sentimentos através dos sons e a Teoria é o
conjunto de conhecimentos que propõe explicar, elucidar e interpretar o que ocorre
nesta atividade prática e é uma importante ferramenta na formação de conceito,
metodologia de estudo, maneira de pensar e entender. É a parte científica do estudo
da música.
Com base no conceito da escola Música Sacra e Adoração, compreende-se a extrema
importância da Teoria Musical para o registro da música, pois é uma maneira padronizada de
representar graficamente uma peça musical, o que permite que músicos consigam facilmente
interpretá-las da maneira como são mostradas no arranjo.
Além de uma notação escrita para a música, a Teoria Musical abrange diversas áreas de
conhecimento que permitem compreender melhor os fundamentos e conceitos da música, assim
como suas mecânicas, expressões e significados. Ou seja, a Teoria Musical dá as ferramentas
para a compreensão e utilização da linguagem musical.
Dentre as áreas existentes na Teoria musical, o aplicativo apresentado neste trabalho irá
focar em temas que envolvem leitura e interpretação de partituras, como: interpretar notas e
claves na pauta; interpretar valores de notas; compasso e tempo; tons, semitons e intervalos e
ditados rítmicos. Cada tema terá níveis dispostos de maneira linear que contêm os subtópicos
de cada módulo. O módulo de compasso e tempo, por exemplo, irá conter subtópicos
envolvendo compassos simples e compostos.
Como mencionado anteriormente no capítulo introdutório, uma das propostas do
aplicativo é a de tornar o ensino do conteúdo de Teoria Musical mais dinâmico e imersivo,
envolvendo uma metodologia com aspectos de gamificação, como será visto na subseção
seguinte.
2.2 GAMIFICAÇÃO
Quanto ao disposto até aqui, o Mozapp teve sua concepção baseada em um método
lúdico de abordar o conteúdo de Teoria Musical. Neste sentido foram utilizadas técnicas que
envolvem conceitos de gamificação.

23
Gamificação é a prática de introduzir elementos e design de jogos em ambientes e
contextos que não são considerados jogos, para obter metas específicas ou para modificar
comportamentos. Portanto o foco da gamificação é inserir elementos lúdicos para que o usuário
tenha experiências positivas e distintas, que contribuam de forma significativa para diferentes
contextos e que proporcionem artifícios que beneficiem o usuário, de acordo com suas
necessidades e metas (SOFRONIJEVIC et al, 2014; NICHOLSON, 2012).
De acordo com Kenski (2012), gamificação é muito utilizada no mundo corporativo,
sendo uma estratégia de interação entre pessoas e empresas cuja finalidade é oferecer
incentivos que estimulem o engajamento e a vontade do público.
Segundo Andriotis (2014), com relação ao ambiente da educação e do trabalho, existe
uma demanda muito alta pela gamificação e acredita-se que a mesma tem potencial para mudar
a forma como as pessoas aprendem e maximizar o envolvimento de alunos. Partindo deste
princípio, o site de aprendizado online TalentLMS realizou uma pesquisa com seus usuários
sobre o impacto da gamificação. De acordo com um dos tópicos da pesquisa feita pelo site,
79% dos usuários responderam que seriam mais produtivos se as suas
universidades/instituições de ensino ou trabalho fossem de alguma forma gamificadas.
Portanto, dentro da área da música, assim como outras áreas do ensino, estratégias de
gamificação se mostram bastante eficientes como método de incentivo ao aprendizado.
O objetivo da gamificação é impactar na produtividade de empregados. Segundo uma
pesquisa feita pela companhia de gamificação Badgeville com mais de 500 empregados de
diversos níveis em companhias, comprovou o sucesso da gamificação entre as organizações
norte-americanas. De acordo com a pesquisa, 78% dos trabalhadores estão utilizando
motivação baseada em jogos no trabalho e 91% deles afirmam que tais sistemas melhoram suas
experiências de trabalho pois aumentam o engajamento, consciência e produtividade dentro da
empresa (BADGEVILLE, 2015).
A pesquisa revela que motivação baseada em jogos, incluindo competições,
estabelecimento de metas, recompensas de performance e estatísticas de sucesso aumentam a
experiência de trabalho de 95% dos trabalhadores que a utilizam. Os dados ainda informam
que a gamificação aumenta os níveis de produtividade dos trabalhadores em 90% e aumenta a
consciência dos colegas de trabalho com relação as suas metas e tarefas em 86%. Os principais
benefícios da gamificação são um maior desejo de estar no trabalho (30%), inspiração para ser

24
mais produtivo no trabalho (27%) e o foco em continuar realizando a tarefa e evitar distrações
(20%).
O impacto da gamificação na produtividade depende diretamente de 8 princípios
básicos (ARK, 2014):
 Desafios conceituais, que ao incorporar uma pedagogia rigorosa e desafios e tarefas
instigantes, promovem uma maior aprendizagem e interação do usuário;
 O fracasso produtivo, pois bons jogos sabem dar incentivo e suporte ao erro, e dão
feedbacks com instruções úteis aos usuários, que consequentemente irão aprender com
seus erros;
 A calibragem cuidadosa da zona de desenvolvimento, ou seja, da distância entre o que
o aluno sabe e o que ele irá alcançar. Bons jogos não são tão fáceis a ponto de entediar
os usuários, e nem tão difíceis a ponto de frustrá-los;
 O estímulo à persistência, ou seja, da possibilidade de falhar e continuar tentando, o
que aumenta a persistência e a preparação dos usuários para lidar com problemas do
mundo real;
 A construção da confiança, conforme os usuários aprendem como ter uma experiência
de aprendizagem vencedora. Bons jogos também desenvolvem a noção de eficiência;
 Aumento da motivação do usuário, graças ao feedback contínuo e as recompensas ao
cumprir tarefas;
 Acessibilidade, ou seja, o mesmo acesso aos recursos e informações do jogo embora o
progresso possa variar, ou seja, uma mesma oportunidade de aprender habilidades para
o domínio do jogo ou de alguma tarefa específica dele;
 E o aprendizado profundo, pois jogos bem estruturados e aplicados tem a capacidade
de aumentar os níveis de motivação e persistência dos usuários e consequentemente
aprofundar seu aprendizado.
A gamificação é um dos aspectos presentes que agem como diferencial do aplicativo
Mozapp em relação aos demais existentes no mercado. No ambiente do aplicativo, tal aspecto
tem a principal função de contribuir positivamente na interação e envolvimento dos usuários
com a interface do aplicativo e com conteúdo que é ensinado, fazendo com que o aprendizado
não se torne fastidioso.

25
Algumas técnicas de gamificação são utilizadas no aplicativo como forma de estimular
a interatividade entre os participantes. Tais técnicas consistem em progress bars, que
apresentam o progresso do usuário em relação as aulas e exercícios do aplicativo; e a conquista
de medalhas ao finalizar desafios propostos pelo aplicativo, como será melhor apresentado no
capítulo de desenvolvimento deste trabalho.
Por se tratar de um aplicativo de ensino voltado para um público geral. A gamificação
é um aspecto muito importante para a metodologia de ensino utilizada pelo Mozapp, e faz com
que aprender Teoria Musical se torne uma experiência mais agradável e divertida para os
usuários do aplicativo.
A gamificação contém em suas características intrínsecas a capacidade de fazer com
que o aprendizado de Teoria Musical por meio do aplicativo Mozapp seja bem mais eficiente
e proveitoso. Além disso, é uma maneira de harmonizar o uso de tecnologias com a
metodologia de ensino de música no qual o aplicativo se inspira.
2.3 TECNOLOGIA NA EDUCAÇÃO MUSICAL
Inúmeras pesquisas, como é o caso de Mulatti (2015), Loureiro (2001) e Sugahara
(2014), mostram a influência positiva da educação musical no desenvolvimento de crianças, e
ao associar tal influência com os recursos e ferramentas tecnológicas que podem ser usados
para aprimorar tal processo, se observa um grande potencial positivo no que tange aos
benefícios que são proporcionados pela educação musical e por aulas de musicalização.
Segundo Mulatti (2015), professora de Piano certificada em pedagogia com ênfase no
método Suzuki, as aulas de musicalização têm o objetivo de despertar nas crianças o interesse
pela música, fazendo-a sentir a beleza da música e a desenvolver percepções de ritmo e audição.
Tais aulas visam desenvolver alguns objetivos específicos da área que ajudam nas demais
áreas, tais como:
 Estimular ao máximo a participação ativa, física e mental da criança;
 Estimular a atividade criadora da criança, ao animá-la a inventar ritmos e melodias;
 Associar imagens e sensações através de processos espontâneos, os quais permitem
apurar a audição e o senso ritmo da criança;

26
 Desenvolver e estimular a disciplina nos estudos, assim como a atenção e concentração;
 Desenvolver e estimular a disciplina de forma que o despertar do ouvido rítmico,
melódico e harmônico, passa a auxiliar no processo de atenção, compreensão e fixação
de ideias;
 Estimular a coordenação motora visando às habilidades para tocar um instrumento,
entre outros benefícios.
A música possui uma expressão cultural e social de sentimento inquestionável e se faz
presente em todos os ritos e cerimônias da sociedade, desde o nascimento até a morte. Desde
2008 a iniciação ao aprendizado de música tornou-se obrigatória na disciplina de Artes nas
escolas do Brasil. A música desenvolve um nível de escuta mais crítico pois através de uma
forma de linguagem mais acessível a todos (SUGAHARA, 2014).
Segundo Loureiro (2001, p. 108)
A importância da Arte na “Era Tecnológica” se deve ao fato de ser um elemento
essencial de integração do homem na sociedade, surgindo como um instrumento de
desenvolvimento da personalidade, de libertação, de estímulo à criatividade, meio
indispensável de educação.
A empresa Sonotec Music & Sound (2012) afirma que aprender música aguça a
percepção e desenvolve o raciocínio, além de ensinar autodisciplina, paciência e sensibilidade.
E quando trabalhada desde a infância, a música faz com que a criança adquira uma maior
facilidade para o entendimento de outras áreas do conhecimento, recebendo normalmente notas
mais altas na escola. Além disso, a criança adquire uma estrutura emocional e psicológica que
lhe fornecerá bases para uma vida mais saudável.
Com base nos autores citados anteriormente, foi observado que a influência positiva da
educação musical no desenvolvimento de crianças, com o auxílio da tecnologia como
ferramenta de ensino, é capaz de obter níveis maiores de engajamento e foco de seus usuários,
assim como um maior índice de aprendizado aliado a uma experiência mais agradável e
divertida. Neste sentido e objetivando uma maior apresentação da metodologia de ensino de
música utilizada neste trabalho, o item 2.4, a seguir, apresenta alguns ensinamentos propostos
por Suzuki (2005).

27
2.4 MÉTODO SUZUKI
Como referenciado desde a introdução deste Trabalho de Curso, o método Suzuki foi
utilizado como base para a metodologia de ensino do aplicativo Mozapp.
Trata-se de um método de aprendizado de música desenvolvido pelo violinista Shinichi
Suzuki, no Japão. Segundo a associação Suzuki Talent Education of Australia (2005), é um
método direcionado para crianças e consiste em criar um ambiente semelhante ao que as
crianças têm para aprender sua língua materna. O método consiste em brincadeiras para que a
criança aprenda se divertindo.
Suzuki estudava violino na Alemanha com o renomado violinista Karl Klinger, e foi na
Alemanha que ele observou a facilidade que as crianças têm de aprender Alemão, um idioma
que ele próprio se esforçava bastante para aprender. Shinichi percebeu que as crianças
aprendem suas línguas maternas sem maiores esforços, por meio da audição, imitação e
repetição. Ele concluiu que crianças também poderiam aprender música desta forma.
Seus ensinamentos utilizavam o conceito de “caráter primeiro, habilidades em
segundo”. O seu objetivo era abranger toda a criança, alimentando o amor pela música e o
desenvolvimento de um bom caráter em vez de apenas o domínio de um instrumento musical.
Suzuki chamou este conceito de Talent Education e logo estabeleceu uma escola em
Matsumoto.
Foi realizada uma pesquisa no Centro Suzuki de Santa Maria sobre o método Suzuki,
onde foram examinadas as contribuições do ensino do instrumento pelo método na vida de ex-
alunos do centro, descrevendo as influências do método na vida pessoal desses instrumentistas
e analisando as críticas feitas ao método. Segundo a pesquisa, foram investigados 14 ex-alunos
do método Suzuki que começaram os seus estudos em Santa Maria. Todos eles estavam na
faixa etária de 26 a 36 anos de idade, com exceção de um que possuía 52 anos. Todos os
investigados iniciaram os estudos violinísticos pelo método Suzuki entre os anos de 1974 a
1981, quando tinham entre 3 e 4 anos de idade, com exceção de um, que começou aos 26 anos
(LUZ, 2004).

28
Os investigados foram solicitados a responder um questionário com perguntas sobre o
método. As respostas apresentam as opiniões, influências e benefícios do método para a suas
vidas, e os pontos fortes e fracos do método. Muitos dos investigados consideram o método
Suzuki como o melhor método para o ensino da música e do instrumento, principalmente ao
que se refere ao ensino de crianças, os depoimentos a seguir justificam essa opinião (LUZ,
2004, p. 22):
O método produz efeitos de forma bastante rápida, onde a criança aprende brincando,
tornando o “tocar” extremamente natural, oferecendo também a oportunidade de
aprender músicas (melodias) em curto prazo.
Por ser um método em que as crianças aprendem mais facilmente com idades
menores, desde os 3 ou 4 anos de idade, é mais fácil de introduzir a música para elas
através do método Suzuki do que pelos métodos tradicionais.
Acho maravilhoso esse método, pois a criança ou aluno aprende brincando, seja qual
for a idade, aprende brincando.
Na minha opinião, é um método para iniciar crianças. Aulas em grupo são importante
atividade para a concentração e dinâmica de grupo.
De acordo com Schramm (2009) o ensino de música, quando associado a tecnologias,
oferece recursos e descortina possibilidades sendo capaz de gerar motivação, surpreender e
superar barreiras. E por mostrar-se como uma eficiente maneira de ensino de música e de
violino que tem forte ligação com a gamificação, o método Suzuki, ao ensinar a música por
meio de brincadeiras, faz com que as crianças possam aprender mais facilmente a música com
idades menores. O método faz também com que desenvolvam habilidades musicais desde cedo,
como tocar de ouvido, o treinamento da memória e o desenvolvimento da concentração, da
percepção e da sociabilidade.
Para um estudo aprofundado sobre o método Suzuki de música, recomenda-se a
associação Suzuki Talent Education of Australia (2005) ou Luz (2004). Outros aspectos
relevantes para uma melhor compreensão do desenvolvimento do aplicativo Mozapp serão
vistos a seguir, na seção referente as pesquisas de mercado.

29
2.5 APLICATIVOS EXISTENTES NO MERCADO
Foi feita uma pesquisa sobre os aplicativos móveis já existentes no mercado na área
específica da teoria musical. A partir da pesquisa foi observado que, considerando-se como
métrica a quantidade de downloads, os principais aplicativos disponíveis baixados têm o
propósito principal de praticar o conteúdo por meio de exercícios, onde tal conteúdo não é
previamente explicado e já devem ser de conhecimento do usuário. Nesse sentido, o público-
alvo do aplicativo torna-se bem mais limitado, uma vez que apenas usuários que já detém
conhecimento prévio sobre os temas dos exercícios podem fazer uso do mesmo.
Este é o caso do aplicativo Tenuto, desenvolvido pela empresa musictheory.net (2015).
O Tenuto contém diversos exercícios para que estudantes de música e professores possam
praticar os seus conhecimentos, porém é de uma proposta distinta da que envolve o aplicativo
referido neste trabalho, que é a de popularizar e facilitar o aprendizado de Teoria Musical.
Também se ressalta os fatos de que a grande maioria dos aplicativos de Teoria Musical
estão disponíveis apenas no idioma inglês. E em específico para o Tenuto, só está disponível
em versão paga, e apenas para o sistema iOS.
Ainda na pesquisa realizada, encontrou-se no site musictheory.net inspiração para a
construção do Mozapp, uma vez que dispõe de exercícios em inglês para seus usuários,
entretanto sem a adoção da gamificação e sem aulas de embasamento dispostas de forma
interativa. No capítulo a seguir, serão abordadas as metodologias utilizadas no processo do
desenvolvimento do aplicativo.

30
3. PROCESSO DE DESENVOLVIMENTO
Neste capítulo, será abordado o processo de desenvolvimento do Mozapp. Para o
desenvolvimento do aplicativo, utilizou-se o framework de gestão e planejamento de projetos
Scrum, e para a metodologia de desenvolvimento de software utilizou-se o XP.
3.1 METODOLOGIAS ÁGEIS
Segundo Dias (2005, p. 57),
Como uma resposta as crescentes pressões por inovação em prazos cada vez mais
reduzidos, às necessidades de constantes mudanças de requisitos e ao mau
desempenho de grande parte dos projetos de desenvolvimento de software, houve um
movimento na comunidade de desenvolvimento de software, que deu origem aos
Métodos Ágeis.
Depois de reunir-se nos Estados Unidos para discutir formas de melhorar o desempenho
de seus projetos, um grupo de profissionais veteranos na área de software percebeu que embora
cada envolvido tivesse suas próprias práticas e teorias sobre como fazer um projeto de software
ter sucesso, cada um continha formas de pensamento diferente, mas todos concordavam que,
em suas experiências prévias, um pequeno conjunto de princípios sempre parecia ter sido
respeitado quando os projetos davam certo. Com base nisso eles criaram o Manifesto para o
Desenvolvimento Ágil de Software, frequentemente chamado apenas de Manifesto Ágil
(TELES, 2008).
As metodologias ágeis reconhecem que utilizar processos, ferramentas, documentação,
contatos e planos é de grande importância para que o software obtenha sucesso, mas também
é de maior importância os valores ágeis: os indivíduos e interações entre eles tem mais
importância que os processos e ferramentas, o software (produto) em funcionamento é mais
importante do que uma documentação abrangente, colaboração com o cliente que é mais
importante que negociações de contrato e responder a mudanças que é mais importante que
seguir um plano que não se pode mudar (SABBAGH, 2013).
Com a criação do Manifesto, foram estabelecidos princípios que estabelecem a maioria
das práticas dos chamados Métodos Ágeis de Desenvolvimento de Software (AGILE
ALLIANCE, 2005).
Para o desenvolvimento do Mozapp foram escolhidos os princípios se seguir de acordo
com o manifesto para desenvolvimento ágil de software que mais se adequam ao projeto,
apresenta-se os mesmos na Tabela 1.

31
Tabela 1 - Princípios do manifesto para desenvolvimento ágil de software
Principio Significado
Nossa maior prioridade é satisfazer o cliente por meio da
entrega cedo e frequente de software com valor.
O foco no desenvolvimento do produto está na satisfação dos
clientes. Gera-se, desde cedo e frequentemente, retorno ao
investimento dos clientes no projeto a partir da entrega de partes
do produto que atenda mais as suas necessidades. Esse princípio
se opõe à prática de se seguir um plano detalhado, sugerindo que
a prioridade está em se adaptar e buscar, em cada momento, o que
de fato trará valor aos clientes, para entregar-lhes o mais cedo e
frequentemente possível.
Mudanças de requisitos são bem-vindas, mesmo em fases
tardias do desenvolvimento. Os processos Ágeis utilizam a
mudança em favor da vantagem competitiva para o cliente.
Aceitar a mudança como natural no processo de desenvolvimento
do produto, para melhor atender às necessidades dos clientes. Ao
se trabalhar em ciclos curtos de feedback, permite-se aos clientes
evoluírem o produto à medida que melhor entendem suas
necessidades e adaptarem às mudanças de mercado, tornando-se
mais competitivos. Esse princípio se opõe a se tratar o processo
de desenvolvimento do produto como previsível, cenário irreal no
qual a necessidade de mudança poderia e deveria ser prevenida,
já que ela seria considerada indesejada e custosa.
Entregar software em funcionamento com frequência, desde
a cada duas semanas até a cada dois meses, com uma
preferência por prazos mais curtos.
Entregar a seus clientes e usuários, com frequência, partes do
produto prontas gera, a cada entrega, retorno ao investimento dos
clientes e permite obter-se feedback sobre o que foi produzido.
Assim, pode-se adaptar o produto às necessidades dos clientes de
maneira incremental, reduzindo os riscos do projeto. Esse
princípio se opõe a realizar poucas ou, no limite, uma entrega de
valor única, apenas ao final do projeto.
As pessoas do negócio e os desenvolvedores devem
trabalhar em conjunto diariamente ao longo do projeto.
Pessoas de negócio e desenvolvedores do produto possuem o
objetivo comum de garantir a geração de valor para os clientes e,
para atingir esse objetivo, cooperam continuamente durante todo
o projeto, interagindo com frequência. Esse princípio se opõe ao
cenário de antagonismo comum em projetos de desenvolvimento
de software, nos quais pessoas de negócios — que frequentemente
incluem os próprios clientes do projeto — e desenvolvedores
raramente se comunicam e, muitas vezes, estão em lados opostos.
O método mais eficiente e efetivo de se transmitir
informação para e entre uma equipe de desenvolvimento é a
conversa face a face.
A melhor forma de comunicação entre membros do time que
desenvolve o produto e entre esse time e o mundo externo é a
comunicação face a face, que é direta, síncrona e enriquecida pela
entonação de voz, olhar e linguagem corporal, entre outros
fatores. Quando a comunicação presencial não é viável (em um
projeto distribuído, por exemplo) é uma boa prática fazer-se o
melhor uso possível da tecnologia disponível para se aproximar
da comunicação face a face. Esse princípio se opõe à utilização de
documentos, e-mails, telefone e teleconferência, entre outros,
como formas padrão de comunicação em um projeto.
Software em funcionamento é a principal medida de
progresso.
O progresso do projeto ocorre à medida que partes do produto que
signifiquem valor são entregues aos clientes do projeto. Esse
princípio se opõe à prática de se gerar artefatos como protótipos e
extensos documentos de planos e especificações e, assim,
acreditar que se progrediu no projeto. Isso também se opõe à
geração de quaisquer artefatos e partes do produto — inclusive
documentação — que não gerem valor para os clientes do projeto.
Fonte: Adaptado de Sabbagh (2015, p. 24-27).

32
3.2 SCRUM
O significado da palavra Scrum vem do rugby, é definido por uma jogada onde ficam
todos juntos, frente a frente ao time adversário, quando a bola sai de campo, forçando os times
a se arrumarem novamente em campo e reiniciar o jogo. Em 1995, dois amigos chamado de
Jeff Sutherland e Ken Schwaber publicaram um método e o batizaram de Scrum. (AUDY,
2013).
Segundo seus criadores Schwaber e Sutherland (2013), Scrum é um framework que
pessoas podem tratar e resolver problemas e que dá um retorno produtivo e criativo para
entrega de produtos com o valor mais alto possível.
O Scrum é um framework ágil que serve para gerenciar projetos de qualquer escopo.
Ele foi originalmente formalizado para projetos de desenvolvimento de software, mas tem
várias possibilidades de uso e funciona com vários tipos de projeto (SCRUM ALLIANCE,
2013). Scrum é considerado um framework porque sua fundamentação está de acordo com
outros métodos, metodologias e frameworks que utilizam e seguem os princípios e valores do
manifesto para o desenvolvimento ágil de software (SABBAGH, 2013).
Ainda citando Sabbagh (2013), apresenta-se os valores do manifesto para
desenvolvimento ágil de software que se aplicam ao Scrum na Tabela 2.
Tabela 2 – Valores do manifesto ágil aplicados no Scrum
Valor Significado
Foco
Os times mais produtivos trabalham em apenas um projeto de cada vez,
evitando a multitarefa. O time trabalha focado em metas de negócios claras
e alcançáveis com as quais se comprometem. Ao mesmo tempo, essas
metas, definidas e negociadas como Product Owner, mantêm o foco do
trabalho nas necessidades de negócios mais urgentes em cada momento.
Além disso, para auxiliar o time a manter seu foco no seu trabalho, há no
Scrum um facilitador que remove impedimentos e protege o time de
distrações e interferências externas, chamado de Scrum Master;
Coragem
As pessoas que trabalham no projeto têm coragem para aceitar a mudança
como parte natural do processo de desenvolvimento do produto. O Product
Owner e a organização têm coragem para confiar no time e deixá-lo livre
para realizar o trabalho necessário para atingir metas acordadas. O time
tem coragem para falhar e criar visibilidade sobre os problemas e, assim,
aprender com essas falhas e problemas o mais cedo possível. Tanto time
quanto Product Owner têm coragem para mostrar e entregar com frequência
as partes do produto criadas. O Scrum Master tem coragem para remover
impedimentos e realizar as mudanças necessárias na organização, de
forma a ajudar a equipe a se tornar mais produtiva;

33
Franqueza
A franqueza ou transparência é necessária para que se possa realizar a
inspeção e adaptação. Assim, o time busca melhorar sua forma de trabalhar
a partir do feedback frequente de seus membros, o que cria visibilidade
sobre os problemas e estimula a busca por soluções. O time também busca
validar os resultados de seu trabalho a partir do feedback frequente sobre o
que produzem, o que cria visibilidade sobre as mudanças necessárias. Ele
mantém visível o progresso de seu trabalho, para poder tomar medidas de
correção necessárias. Ao mesmo tempo, sente-se seguro para estabelecer
e informar suas estimativas de quanto trabalho acredita que pode ser
realizado. O time também contacta o Product Owner para esclarecer
dúvidas e o Scrum Master para remover impedimentos o mais cedo
possível, sempre que necessário;
Compromisso
O time determina como seu trabalho será realizado, monitora seu progresso
e realiza as correções de rumo que achar necessárias. Assim, é
responsável e responsabilizado pelos seus resultados. Esse controle maior
que ele tem sobre seu trabalho o torna mais comprometido como sucesso
do projeto. Em cada ciclo de desenvolvimento, o time se compromete em
alcançar a meta de negócio acordada como Product Owner e, assim, se
compromete em dar o seu melhor para fazê-lo. Por sua vez, o Product
Owner se compromete a estabelecer as prioridades de trabalho de forma a
satisfazer as necessidades de negócios do projeto, interagindo com quem
for necessário para fazê-lo;
Respeito
Os membros do time trabalham juntos, compartilhando responsabilidades,
e assim ajudam-se uns aos outros em seu trabalho. Todos que trabalham
no projeto respeitam as opiniões uns dos outros, ouvem e buscam entender
os diferentes pontos de vista. O Product Owner respeita as decisões
técnicas dos membros do time, que respeitam suas decisões de negócios.
Por fim, são respeitados o bem-estar e o direito das pessoas que trabalhm
no projeto a uma vida privada.
Fonte: Adaptado de Sabbagh (2015, p. 28-29).
O objetivo do Scrum é dar visibilidade aos problemas do cliente e servir como guia na
resolução dos problemas do mesmo (VARASCHIM, 2009). Por se definir um framework, o
Scrum serve como um guia de boas práticas para atingir o sucesso, mas, as escolhas de quando
e como usá-lo, utilização de táticas e estratégias para conseguir produtividade e realizar as
entregas definidas, fica de responsabilidade de quem estiver aplicando (PORTELA, 2009).

34
3.2.1 Fluxo do Scrum
O Scrum tem seu fluxo baseado em iterações bem definidas, que possuem duração de
2 a 4 semanas, que são nomeadas de Sprints. Este fluxo é apresentado graficamente na Figura
3.
Figura 3 - Fluxo do Scrum
Fonte: Burgos (2010, online).
Antes de uma Sprint ser realizada, ocorre uma reunião para definir o documento Visão
(Vision) que contém o objetivo do projeto, definição do problema e definição da visão. Em
seguida, o responsável pelo cliente (Product Owner) faz uma lista de demanda do que deve ser
feito. Depois ocorre uma Reunião de Planejamento (Sprint Planning Meeting) onde o time
(Scrum Team) de desenvolvedores tem contato com o representante do cliente (Product Owner)
para priorizar o trabalho que deve ser feito, selecionar e estimar as tarefas que o time de
desenvolvedores poderá realizar no decorrer de uma Sprint. A próxima fase é a Execução da
Sprint, onde o time controla o andamento do desenvolvimento realizando Reuniões Diárias
(Daily Metting), que não devem ultrapassar 15 minutos de duração, e observando o seu
progresso usando um gráfico chamado Sprint Burndown. Na parte final de uma Sprint, é feita
uma revisão no produto entregue para verificar se tudo foi concluído e implementado
corretamente e uma Reunião de Revisão (Sprint Review), onde o time demostra o produto
gerado ao Product Owner e o mesmo valida se o objetivo foi atingido. Após o Sprint Review,

35
realiza-se a Reunião de Retrospectiva (Sprint Retrospective), uma reunião para a discussão de
lições aprendidas, com o objetivo de melhorar o processo, ou o time e/ou produto para próxima
Sprint (PORTELA, 2009).
3.2.2 Ciclo de vida
Ciclo de vida de um software é definido por um conjunto de etapas que contem
processos, atividades e tarefas, que abrange desde de a análise dos requisitos até entrega do
produto para o cliente destinado (MACÊDO; SPÍNOLA, 2013). O ciclo de vida do Scrum,
seguido neste projeto, é demostrado graficamente na Figura 4.
Figura 4 - Ciclo de vida do Scrum
Fonte: Autores (2015).

36
3.2.2.1 Pré-Game
A fase de Pré-Game “tem como objetivo delimitar o escopo do projeto, verificar a sua
viabilidade econômica e eliminar riscos a partir de uma arquitetura estável” (SZIMANSKI,
2009, p. 89).
Nesta fase, ocorrem os seguintes passos: o documento Visão (Vision) é criado pelo
Product Owner para que todos na equipe tenham uma noção de onde está querendo se chegar
com o produto. Em seguida, o Product Backlog também é criado pelo Product Owner, que é
atualizado pelo time de acordo com o mesmo. Mais tarde, ocorre uma reunião (Sprint Planning
1) para escolher estórias do Product Backlog e assim, em seguida gerar uma lista de estórias
escolhidas. Posteriormente, é feita uma nova reunião (Sprint Planning 2), só que dessa vez o
objetivo é tentar quebrar estórias em tarefas para que possam ser melhor desenvolvidas. No
final dessa fase é criada uma lista que contém tarefas que precisam ser feitas pelo Scrum Team.
3.2.2.2 Game
Na fase do game, o objetivo é criar versões funcionais do software para o cliente, e
nessa fase ocorre: as divisões das tarefas que serão implementadas entre membro do time, a
priorização por parte da equipe. Durante a fase de game, ocorrem diariamente reuniões onde
os membros relatam o andamento da execução das suas atividades e levantam impedimentos
(SZIMANSKI, 2009).
3.2.2.3 Pós-Game
O Pós-Game é uma fase do Scrum que tem o objetivo de apresentar o resultado do
produto para o cliente, para que o mesmo possa validar (ou rejeitar) o que foi feito através da
cerimônia Sprint Review. Em seguida, ocorre uma reunião (Sprint Retrospective) onde se busca
melhorar o processo utilizado e avaliar a capacidade de produção da equipe envolvida
(SZIMANSKI, 2009).

37
Nessa fase pode ser feita a integração do que já foi desenvolvido, testes para
funcionalidades que acabaram de ser concluídas e concluir as documentações do projeto.
3.2.3 Papéis
Apenas três papéis são definidos pelo Scrum: o Time de Desenvolvimento (Scrum
Team), o Representante do Cliente (Product Owner) e o Scrum Master. Esses papéis são
desempenhados por pessoas e as mesmas assumem responsabilidades pelos resultados do
trabalho e tem que estar comprometidas (SABBAGH, 2013). Esses papéis estão representados
na Tabela 3.
Tabela 3 – Papéis do Scrum
Papel Descrição
Time de Desenvolvimento (Scrum Team)
É um grupo que é responsável por desenvolver o
produto, determinar como será desenvolvido e
planejar o produto. Ele representa
Representante do Cliente (Product
Owner)
É responsável por garantir o retorno do produto a
partir do trabalho do Time de Desenvolvimento para
os clientes.
Scrum Master É o responsável por facilitar e potencializar o
Trabalho do Time de Desenvolvimento
Os papéis do Scrum têm suas responsabilidades, o Product Owner é responsável pela
rentabilidade, por priorizar as funcionalidades e aceitar ou rejeitar o resultado do trabalho. O
Scrum Master é responsável pela aplicação dos valores e práticas do Scrum, resolver os
impedimentos, conduzir as diversas reuniões e por não deixar nada interferir no andamento do
projeto. O Scrum Team é responsável por estimas as estórias, desenvolver funcionalidades,
definir as tarefas e levantar impedimentos.

38
3.2.4 Práticas
Práticas são um conjunto de recomendações que servem como base para a organização,
que podem ser utilizadas na realidade da mesma e que ajudam na gestão do projeto (VIEIRA,
2014).
3.2.4.1 Sprint planning meeting
É uma reunião que contém como participantes o Product Owner, Scrum Master, Scrum
Team e qualquer outra pessoa interessada no projeto (Stakeholders). Na mesma, o Product
Owner descreve as funcionalidades de maior prioridade para equipe, que aproveita para tirar
dúvidas com o Prodcut Owner sobre as estórias, e quebra as funcionalidades em tarefas
técnicas (DESENVOLVIMENTOÁGIL, 2015).
Sprint Planning é uma reunião que se divide em duas etapas, a primeira chamada de
Sprint Planning 1, onde ocorre a escolha de quais itens do Product Backlog serão feitas na
Sprint. Essa escolha é feita por todo o Time de Desenvolvimento em consenso com o Product
Owner. Essa escolha é facilitada pelo Scrum Master. A segunda etapa chamada de Sprint
Planning 2, onde todo o time tenta concentrar os esforços para quebrar estórias em unidade
menores chamadas de tarefas (BURGOS, 2010; SABBAGH, 2013).
3.2.4.2 Sprint
O projeto é executado através de ciclos de desenvolvimento, e cada ciclo é denominado
de Sprint, onde a equipe executa as tarefas que foram definidas dependendo da ordem de
prioridade que é definida pelo Product Owner. As Sprints duram de 2 a 4 semanas e
diariamente as equipes tem uma reunião diária (Daily Meeting) (LOUISE, 2013).

39
3.2.4.5 Daily meeting
É uma reunião onde o Time de Desenvolvimento e o Scrum Master discutem sobre o
que foi feito no dia anterior, o que será feito no dia que está se iniciando e se está ocorrendo
algum impedimento para a conclusão da tarefa (LOUISE, 2013). Caso seja identificado algum
impedimento, após a reunião o Scrum Master irá tentar remover este.
Recomenda-se que essa reunião seja realizada em pé (Stand-up Meeting), e que dure no
máximo 15 minutos, afim de que as pessoas sejam objetivas na descrição de suas atividades e
impedimentos.
3.2.4.3 Sprint review meeting
Ao término de uma Sprint, é feito uma reunião chamada de Sprint Review Meeting. No
decorrer desta reunião o Time de Desenvolvimento (Scrum Team) mostra o que foi feito no
decorrer da Sprint. Os resultados são mostrados através de demos das novas funcionalidades
implementadas no projeto ao Product Owner (DESENVOLVIMENTOÁGIL, 2015).
3.2.4.4 Sprint retrospective
Sprint Retrospective é o principal mecanismo de visibilidade do Scrum, pois permite
enxergar áreas que precisam potencialmente de melhorias. É definida também por dar a
oportunidade para o Scrum Team discutir o que está dando certo e o que está dando errado. O
time discute sobre: o que precisam começar a fazer, o que precisam parar de fazer e o que
continuar a fazer para a próxima Sprint (ECLIPSE, 2015a).

40
3.2.5 Artefatos
3.2.5.1 Vision
Se define Documento Visão (Vision), a documentação que tem a finalidade de obter a
visão futura do software e esclarecer a estratégia utilizada para o mesmo. Contém uma boa e
clara instrução do problema, solução proposta, quem são os clientes, diferencial competitivo,
rentabilização e o que será cobrado (IBM, 2015; AUDY, 2015).
3.2.5.2 Product backlog
Product Backlog é uma lista de demandas que contém funcionalidades, que é montada
através do levantamento de requisitos. Estas demandas são geralmente escritas na forma de
estórias do usuário (User Stories) que são devidamente organizadas e priorizadas pelo Product
Owner (AUDY, 2015; DESENVOLVIMENTOÁGIL, 2015).
3.2.5.3 Sprint backlog
É uma lista que contém um conjunto de tarefas que o Scrum Team está comprometido
a fazer em uma Sprint e que foi montada pela própria equipe. Os itens que compõem o Sprint
Backlog são retirados do Product Backlog com base nas prioridades definidas pelo Product
Owner (DESENVOLVIMENTOÁGIL, 2015).
3.2.5.4 Sprint burndown
É um gráfico que permite visualizar quanto trabalho resta em uma Sprint Backlog,
visualizar e compreender o tempo que a Scrum Team demorou para concluir a tarefa e prever
o tempo necessário para que o time consiga alcançar as metas da Sprint em andamento
(MICROSOFT, 2015).

41
3.3 XP – EXTREME PROGRAMMING
XP é uma metodologia de desenvolvimento de software, criada por Kent Beck no final
da década de 90, que serve para: projetos que possuem requisitos vagos e que mudam com
frequência; sistemas desenvolvidos utilizando a técnica de orientação a objeto; equipes de
desenvolvimento pequenas com até 12 pessoas (preferencialmente); e para desenvolvimento
incremental ou iterativo quando os projetos são implementados no início e ganham
funcionalidades no decorrer do tempo (TELES, 2004).
O XP utiliza uma abordagem orientada a objetos como paradigma de desenvolvimento
predileto, e incluem um conjunto de valores e práticas constantes que se empregam no contexto
de quatro atividades metodológicas: planejamento, projeto, codificação e testes (PRESSMAN,
2011).
Essa metodologia é muito utilizada, pois permite que quem a utiliza, crie softwares de
melhor qualidade, que pode ser desenvolvido em menos tempo e que pode ser considerada mais
econômica do que as tradicionais (DESENVOLVIMENTOÁGIL, 2015).
Pode-se entender por XP, uma metodologia de desenvolvimento de software pautada
em um conjunto de valores e práticas.
3.3.1 Valores
O XP contém sua fundamentação dívida em valores que são: comunicação, coragem,
feedback, respeito e simplicidade (TELES, 2006a).
3.3.1.1 Comunicação
O valor comunicação tem como seu principal objetivo manter um grau de
relacionamento melhor possível entre o cliente e os desenvolvedores, recomendando conversas
pessoais ao invés de adotar outro meio de comunicação. A recomendação da comunicação entre

42
a equipe de desenvolvimento e o gerente do projeto, também é ressaltada através desse valor
(SOARES, 2004).
3.3.1.2 Coragem
Utilizadores do XP consideram que errar é um comportamento natural e que precisar
modificar o que está funcionando pode acontecer. Isso apresenta um risco que quem utiliza o
XP está disposto a correr, pois, a confiança nos mecanismos de proteção do mesmo são grandes.
Um método que demonstra que coragem é preciso para se implantar o XP é a junção de todos
os valores, pois não são todas as pessoas que possuem a capacidade de comunicação e
relacionamento. Outro ponto onde podemos evidenciar a coragem é quando há a possibilidade
de simplificar o software. Além desses exemplos é preciso ter coragem para lidar com o retorno
do cliente (DESENVOLVIMENTOÁGIL, 2015; SOARES, 2004).
No projeto foi adotado a coragem quando se teve que alterar o código das
funcionalidades que estavam concluídas com o objetivo de melhorar o código através de uma
fatoração.
3.3.1.3 Feedback
O valor feedback tem como objetivo que a equipe que está desenvolvendo o software
tenha informações regularmente do cliente e de suas funcionalidades. As informações de suas
partes funcionais são dadas através de testes constantes, que demonstram os erros contidos. O
que demonstra o feedback para o cliente é que este terá sempre uma parte de software para
testar. A partir disso, o cliente dá um retorno para equipe através de novas características e
informações. Isso faz com que erros sejam identificados e tratados para que o cliente tenha no
final do projeto, suas expectativas alcançadas (SOARES, 2004).
O feedback foi utilizado com frequência no projeto, quando se teve que reunir com o
cliente para poder receber a validação ou rejeição do mesmo, para que houvesse uma correção.

43
3.3.1.4 Respeito
O valor respeito fortalece os demais, pois para que uma equipe seja consideravelmente
boa, é preciso que os componentes se preocupem em comunicar-se uns com os outros, para que
se importem igualmente. Respeito pode ser considerado um valor primordial para um projeto,
de modo que se o mesmo não existir, não se pode ter segurança que o projeto conseguirá se
consolidar com sucesso. Para que um projeto dê certo é preciso com que todos os componentes
da equipe estejam aptos a ouvir, compreender e respeitar o ponto de vista dos outros
(DESENVOLVIMENTOÁGIL, 2015).
A equipe que desenvolveu o projeto utilizou o respeito, quando tiveram ponto de vistas
diferentes para mudanças no projeto. A equipe manteve o respeito, pois, as ideias de ambos
foram somadas para consolidar o projeto.
3.3.1.5 Simplicidade
O valor simplicidade defende que o código desenvolvido, em um projeto utilizando XP,
deve ser simples e que não deve possui em si coisas desnecessárias. Para que seja denominado
código simples, o mesmo precisa conter o menor número de classes e métodos. Também se
leva em consideração o emprego da simplicidade quando se é implementado apenas os
requisitos atuais e não implementar funcionalidades que serão importantes no futuro
(SOARES, 2004).
A simplicidade foi adotada no projeto, pois desenvolveu-se somente o que foi
necessário em cada fase, e buscando sempre o que fosse necessário utilizar na criação de classes
e métodos.

44
3.3.2 Práticas
As práticas no XP são a representação do que será feito diariamente no projeto e podem
ou não ser aplicadas dependendo do contexto. Práticas podem ser tratadas como
recomendações a menos que tenha algum proposito, como por exemplo utilizar de uma prática
como a programação em par, simplesmente por estar seguindo as recomendações ou para
demonstrar domínio, não é válido. O que é válido é utilizar a programação em par para
aumentar a comunicação entre a equipe, para nivelar os participantes e assim construir pessoas
com maior conhecimento para demonstrarem mais rápido o que está sendo pedido para que o
cliente dê o feedback (TELES, 2006b). A seguir, são descritas as práticas do XP incorporadas
neste projeto.
3.3.2.1 Cliente presente
O XP sugere que o cliente esteja sempre presente no dia-a-dia participando do projeto
através de feedback e especificando o mesmo ao longo do projeto, pois, se o cliente não estiver
participando do projeto, a equipe pode não conseguir entregar um software que se adeque as
expectativas do cliente. Quanto menos o cliente participar do projeto, mais riscos ao projeto
isso representa (TELES, 2005; KUHN; PAMPLONA, 2004).
3.3.2.2 Jogo do planejamento
O XP recomenda que o planejamento para o desenvolvimento tenha foco no que gera
mais valor para o cliente. Isso é feito várias vezes no decorrer do projeto, quando o cliente
solicita funcionalidades que ele deseja em forma de estórias, estima a prioridade e a equipe
estima o custo que significa cada estória para pode gerar releases e iterações (KUHN;
PAMPLONA, 2004).

45
3.3.2.3 Stand up meeting
É uma reunião breve que é realizada normalmente pela manhã, pela equipe de
desenvolvimento, que tem o intuito de compartilhar informações sobre o projeto e priorizar as
atividades que serão feitas. Nessa reunião, ocorre um diálogo entre todos os componentes da
equipe e que, se possível, também envolve o cliente para que compartilhem e troquem
informações sobre o projeto (TELES, 2007).
O XP orienta que uma reunião diária com a equipe com aproximadamente 20 minutos.
Para dar mais brevidade, a reunião ocorre em pé, para que seja evitado bate-papos paralelos e
faça com que os integrantes abordem diretamente o assunto. A reunião tem o objetivo de
atualizar os participantes sobre o que já foi implementado no dia que se passou para que sejam
trocadas experiências e dificuldade enfrentadas. Nessa mesma reunião também ocorre a
escolhas das estórias que serão implementadas no dia que está ocorrendo a reunião e os
responsáveis por fazê-las (KUHN; PAMPLONA, 2004).
3.3.2.4 Programação em Par
O XP sugere que todo o código produzido no projeto, seja implementado por duas
pessoas juntas, utilizando o mesmo computador e revezando o mesmo (TELES, 2006c). Essa
prática tem o objetivo de nivelar a equipe, pois deve unir uma pessoa com o conhecimento
avançado sobre alguma tecnologia que o projeto utilizará, e uma pessoa leiga sobre a
tecnologia.
3.3.2.5 Código coletivo
É uma prática que tem como objetivo deixar claro que o código produzido pela equipe
é propriedade de todos, assim, os componentes da equipe de desenvolvimento tem a devida
autoridade para editar o código ao longo do tempo fazendo com que código seja revisado e
refatorado (KUHN; PAMPLONA, 2004).

46
3.3.2.6 Design simples
É uma prática que tenta fazer com que as expectativas do cliente sejam atendidas
seguindo alguns princípios que um usuário espera de um software como: que faça a coisa certa,
que funcione, que seja fácil de utilizar e que posso evoluir com o tempo. Para que o sistema
faça a coisa certa e esteja funcionando, o desenvolvimento é executado em iterações curtas
onde cada iteração possui um conjunto implementado de estórias (TELES, 2005). Para ser fácil
de utilizar, os desenvolvedores implementam funcionalidade exatamente com o que foi pedido
pelo cliente e o software evolui com o tempo através das iterações.
3.3.2.7 Refatoração
É a prática do XP que orienta alterar com frequência pequenas partes do sistema sempre
que tiver oportunidade de melhorar o código que já foi desenvolvido, tornando-o mais legível
e limpo, mais claro e mais fácil de ser entendido por qualquer membro da equipe. Essas
alterações servem para melhorar a estrutura do código desenvolvido (TELES, 2006d).
3.3.2.8 Ciclo semanal
É uma prática do XP que recomenda divisão por semanas, que devem obedecer uma
reunião semanal onde os desenvolvedores se juntam ao cliente para priorizar um pequeno grupo
de funcionalidades que possam ser implementadas e testadas naquela semana. Depois dessa
iteração, o cliente deve utilizar e avaliar o que foi produzido (TELES, 2006e).

47
3.4 FASES DO PROCESSO
O processo de desenvolvimento do Mozapp seguiu as fases do ciclo de vida do Scrum
juntamente com as práticas de desenvolvimento do XP, conforme modelagem realizada nas
notações do SPEM 2.0, apresentada na Figura 5.
Figura 5 - Fases do processo de desenvolvimento do Mozapp
Inicialmente, foi realizada a fase de Pré-Game, onde foi coletado os requisitos com o
cliente, gerado a documentação inicial do projeto, definido um cronograma com a equipe,
gerado um protótipo. Posteriormente, foi realizada a fase de Game onde ocorreu a
implementação das funcionalidades do aplicativo, tanto o design quanto a parte funcional
foram feitas nessa fase que foi repetida até o termino do aplicativo. No final, ocorreu a fase de
Pós-Game, onde se apresentou o que foi construído no decorrer do projeto para o cliente.

48
3.4.1 Pré-game
Figura 6 - Fase de Pré-Game do Mozapp
A Figura 6 apresenta graficamente a fase de Pré-Game. Inicialmente, definiu-se a Visão
do Produto (ver Apêndice A) na tarefa 1.1 Definir Visão, que contém a descrição em alto nível
do produto a ser desenvolvido. Em seguida, o Product Owner definiu estórias de usuários,
contendo as funcionalidades desejadas para o sistema. Estas estórias do usuário estão descritas
no Product Backlog (ver Apêndice B), através da tarefa 1.2 Definir Product Backlog.
Posteriormente, se construiu os protótipos do projeto (ver Apêndice C), a partir da
execução da tarefa 1.3 Definir Protótipos, que apresenta visualmente como o aplicativo irá se
parecer, para que os desenvolvedores tenham uma forma de referência. Em seguida, o Scrum
Team e o Product Owner, em uma reunião, avaliam e validam os requisitos do projeto como
nas tarefas 1.4 Avaliar Requisitos e 1.5 Validar Requisitos. Caso os requisitos não fossem
validados, a equipe deveria retornar para tarefa 1.2 Definir Product Backlog.
Após os requisitos validados, ocorreu o estabelecimento de cronograma, onde
definiram-se ciclos semanais. Nos primeiros ciclos, realizaram-se o planejamento (Pré-Game,
que durou 2 semanas). Em seguida, foram realizados 10 ciclos de desenvolvimento, onde no
final de cada ciclo era gerado um incremento do aplicativo. Por fim, realizou-se a apresentação

49
e validação do aplicativo com o cliente, na fase de Pós Game, que durou 1 semana. Destaca-se
que durante os ciclos de desenvolvimento ocorreu o monitoramento e controle do projeto,
através de reuniões diárias, quadro de trabalho e gráficos burndown que não tiveram
necessidade de serem utilizados, pois, foi definido 1 estória por ciclo. Depois da definição do
cronograma, ocorre a apresentação do planejamento (ver Apêndice E) para o Product Owner e
para a equipe na tarefa 1.7 Apresentar Planejamento. Assim, a fase de Pré-Game é concluída e
se avança para a fase de Game.
3.4.2 Game
Figura 7 - Fase de Game do Mozapp
A Figura 7 representa graficamente a fase de Game. Inicialmente, ocorreu a elaboração
da interface do aplicativo na tarefa 2.1 Elaborar Interface onde se repetiu a cada ciclo até
finalização da mesma. Em seguida, foi integrado o XML (Extensible Markup Language) do
Android com a classe Java através da classe R do Android na tarefa 2.2 Integrar Interface com
o Java. Em seguida, ocorreu a validação da interface do aplicativo junto ao cliente na tarefa 2.3
Validar Interface. Se a interface foi validada com o cliente, ela vai para a codificação de sua
funcionalidade específica que contém uma lógica a ser desenvolvida de acordo com a

50
funcionalidade na tarefa 2.4 Codificação da Funcionalidade, senão o ciclo volta para a tarefa
2.1 Elaborar Interface. Posteriormente, ocorreram testes das funcionalidades que acabaram de
ser implementadas na tarefa 2.5 Realizar Testes. Se a funcionalidade foi testada e validada com
sucesso, a fase de Game é concluída e se avança para a fase de Pós-Game, senão retorna-se
para a tarefa 2.4 Codificar Funcionalidade.
3.4.3 Pós-game
Figura 8 - Fase de Pós-Game do Mozapp
A Figura 8 representa graficamente a fase de Pós-Game. Primeiramente, se apresenta
para o cliente as funcionalidades criadas para que o mesmo valide nas tarefas 3.1 Apresentar
para o Cliente e 3.2 Validar Funcionalidade. Em seguida, se o cliente validou as
funcionalidades, integra-se a mesma ao produto final, senão implementa-se mudanças e
retorna-se para o fluxo normal nas tarefas 3.4 Integrar ao produto e Implementar Mudanças
respectivamente. Ao final do ciclo, se o produto estiver concluído, finaliza-se o processo de
desenvolvimento do Mozapp.

51
3.5 MODELAGEM DO MOZAPP
3.5.1 Caso de Uso
É um modelo que exemplifica e descreve os papéis que interagem com o sistema para
resolver um problema. Nesse modelo, ocorre a descrição de interações entre os usuários e o
sistema e metas do mesmo, e o comportamento que o sistema utilizará para satisfazer as metas.
(ECLIPSE, 2015b). Para a modelagem do aplicativo Mozapp, se utilizou uma notação UML
(Unified Modeling Language) 2.4, conforme demonstrado na Figura 9.
Figura 9 - Diagrama de caso de uso do aplicativo Mozapp
O caso de uso Fazer Cadastro consiste em que o usuário forneça suas informações
cadastrais, como o nome, e-mail e senha para poder autenticar-se e acessar o sistema.

52
O caso de uso Fazer Autenticação consiste em que o usuário forneça suas informações
que foram cadastradas no sistema para que o mesmo posso entrar e utilizar o aplicativo.
O caso de uso Ver Perfil consiste em o usuário conseguir visualizar suas informações
cadastradas.
O caso de uso Selecionar Aula consiste em o usuário escolher uma aula que queira
fazer.
O caso de uso Selecionar Exercício consiste em o usuário escolher um exercício para
praticar.
3.5.2 Wireframe do Aplicativo Mozapp
Wireframe é uma representação simplificada do design, que utiliza formas retas, preto
e branco e que não contém imagens. É utilizado como uma forma mais rápida de se entender
como será o design do que está sendo desenvolvido e contém uma estrutura de embasamento
de como deve ser o que vai ser desenvolvido (ÁVILA, 2012). A Figura 10 exibe o wireframe
do aplicativo Mozapp.
Figura 10 - O wireframe da tela inicial

53
3.5.3 Diagrama de Entidade-Relacionamento do Aplicativo Mozapp
O modelo de entidade-relacionamento idealizado por Peter Char, tem como objetivo
possibilitar a visualização das características essenciais de um domínio de abstração (banco de
dados) (CHAR, 1977). A Figura 11 representa o Diagrama de Entidade-Relacionamento do
Mozapp.
Figura 11 - Diagrama de Entidade-Relacionamento do Mozapp
3.6 ARQUITETURA
O sistema operacional Android contém uma grande gama de recursos para aplicativos
móveis que se assemelham a uma pilha (ABLESON et al, 2012). O Android pode ser
comparado a um bolo, pois consiste em várias camadas, cada camada possui características e
finalidades próprias, além de ter interatividade entre as mesmas (GARGENTA, 2011). A pilha
do Android possui 4 camadas que contém: núcleo Linux, biblioteca nativa, framework de
aplicação e aplicações. A arquitetura padrão do Android, ilustrada na Figura 12, foi adotada
inteiramente no aplicativo Mozapp.

54
Figura 12 - A pilha do Android e sua divisão de camadas
Fonte: Gargenta (2011, p. 8).
3.6.1 Núcleo Linux
O Android é desenvolvido sobre um kernel Linux e sobre uma máquina virtual que é
otimizada para aplicativos Java, e essas tecnologias são de extrema importância para o
funcionamento do Android. O componente kernel da pilha é responsável pela agilidade e
portabilidade para que seja utilizado da melhor forma o hardware. O Ambiente Java é
responsável por tornar acessível aos desenvolvedores de software Java (ABLESON et al,
2012).

55
3.6.2 Bibliotecas nativas
As bibliotecas nativas do Android são escritas nas linguagens de programação C e C++,
que foram muitas vezes construídas pela comunidade de código aberto (open source) com o
objetivo de proporcionar serviços necessários para as camadas da pilha do Android
(GARGENTA, 2011). Entre essas bibliotecas estão:
 SQLite: oferece suporte nativo a um banco de dados;
 OpenGL (Open Graphics Library): para geração de gráfico 3D;
 Bibliotecas de mídia: permite a execução de áudio e vídeo;
 SSL (Secure Socket Layer): protocolo de comunicação de rede com segurança;
3.6.3 Framework de Aplicação
O framework de aplicação do Android é um ambiente rico que provê um grande número
de serviços para o desenvolvedor de aplicativos, que ajudam o mesmo a criar aplicativos que
possam utilizar todas as funções que o Android provê (GARGENTA, 2011).
3.6.4 Aplicações
O Android contém um nível superficial, onde estão contidas as aplicações ou pacotes
de aplicação (APK) (GARGENTA, 2011). Essa camada é composta pelos seguintes itens:
 Recursos: os itens que não são trechos de código, que incluem imagens, vídeos e os
arquivos de layout que no Android utilizam a extensão XML;
 Bibliotecas nativas: bibliotecas que podem ser incorporadas ao aplicativo;
 O executável Dalvik: contém o código da aplicação gerado pela Android Runtime;

56
3.7 FERRAMENTAS E TECNOLOGIAS
3.7.1 Ferramentas
São mostradas a seguir, as ferramentas que foram utilizadas para o desenvolvimento do
aplicativo Mozapp. Cada uma dessas ferramentas contribuiu para acelerar e melhorar o
desenvolvimento do produto, e a finalizar a construção dos protótipos.
Adobe Photoshop CS6 - Foi utilizado para criar e modificar imagens que são exibidas
no aplicativo de forma geral. Para este trabalho, foi utilizada a versão 13.0.6 da ferramenta. A
Figura 13 mostra a interface da ferramenta, com uma das imagens que foi utilizada no
aplicativo.
Figura 13 - Adobe Photoshop

57
Android Studio – Esta ferramenta, exibida na Figura 14, foi utilizada para desenvolver
(codificar) o aplicativo. Para este trabalho foi utilizada a versão 1.4.1 da ferramenta.
Figura 14 - Android Studio
Fonte: Autores (2015)
Astah Community – Esta ferramenta foi utilizada para desenvolver a modelagem dos
diagramas UML. Para este trabalho, foi utilizada a versão 7.0 da ferramenta. A Figura 15
mostra a interface da ferramenta, com o diagrama UML do aplicativo Mozapp.
Figura 15 - Astah Community

58
Balsamiq Mockups – Esta ferramenta, exibida na Figura 16, foi utilizada no
desenvolvimento dos wireframes do projeto. Para este trabalho, foi utilizada a versão 3.2.4 da
ferramenta.
Figura 16 - Balsamiq Mockups
FL Studio – Essa ferramenta, exibida na Figura 17, foi utilizada para criar e manipular
os sons presentes no aplicativo. Para este trabalho foi utilizada a versão 11 da ferramenta.
Figura 17 - FL Studio

59
Genymotion – Esta ferramenta foi utilizada para emular e testas o aplicativo na
máquina. Para este trabalho, foi utilizada a versão 2.5.4 da ferramenta. A Figura 18 mostra o
aplicativo Mozapp sendo executado na ferramenta Genymotion.
Figura 18 - Genymotion
GIMP - Foi utilizado para criar e modificar imagens que são exibidas no aplicativo de
forma geral. Para este trabalho, foi utilizada a versão 2.8.6 da ferramenta. A Figura 19 mostra
a interface da ferramenta, com uma das imagens que foi utilizada no aplicativo.
Figura 19 - GIMP

60
Microsoft Paint – Esta ferramenta, exibida na Figura 20, foi utilizada para modificar e
criar imagens que são utilizadas no aplicativo. Para este trabalho, foi utilizada a versão da
ferramenta presente no sistema Windows 10.
Figura 20 - Paint
Spider-PM – Esta ferramenta foi utilizada para modelar o processo de
desenvolvimento do aplicativo Mozapp, na versão 2.0. A Spider-PM é uma ferramenta que foi
desenvolvida pela Universidade Federal do Pará (UFPA) como parte integrante do projeto
SPIDER, que propõe uma suíte de ferramentas para qualidade de software. A Figura 21 mostra
a tela inicial da ferramenta Spider-PM.
Figura 21 - Spider-PM

61
MySQL Workbench – Esta ferramenta, exibida na Figura 22, foi utilizada para
modelar o Diagrama de Entidade e Relacionamento (DER) do projeto. Para este trabalho, foi
utilizada a versão 6.3.5 da ferramenta.
Figura 22 - MySQL Workbench
Trello - Esta ferramenta foi utilizada para organizar as tarefas do projeto do aplicativo
em ordem cronológica e dividi-las entre os membros do projeto. Para este trabalho, foi utilizada
a última versão online da ferramenta disponível no período de 09/2015 a 11/2015. A Figura 23
mostra uma captura de tela das tarefas do projeto do Mozapp, divididas entra as tarefas não
iniciadas, iniciadas, finalizadas e em teste.
Figura 23 - Trello

62
3.7.2 Tecnologias Utilizadas
Todas as tecnologias que foram utilizadas para o desenvolvimento do aplicativo
Mozapp estão detalhadas a seguir.
Java – É uma linguagem de programação orientada a objetos que é adotada como
linguagem nativa da plataforma Android, além de possuir um suporte nativo para se trabalhar
com a linguagem SQL (Structured Query Language). Possui uma grande gama de
desenvolvedores e comunidades, e possui uma vasta gama de bibliotecas.
SQL – Abreviação de Structured Query Language, é uma linguagem de pesquisa
declarativa, que tem como objetivo armazenar, manipular, e obter dados armazenados em
banco de dados relacionais. É uma linguagem utilizada mundialmente para se trabalhar com
banco e é altamente suficiente.
SQLite – É uma biblioteca feita na linguagem C que implementa um banco de dados
SQL embutido. É o banco de dados nativo do Android.
XML – Abreviação de Extensible Markup Language, é uma linguagem de marcação
composta de tags que organizam e demarcam elementos de design no Android, possibilitando
formatar e organizar.

Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp

Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (8)

Semelhante a Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp

Semelhante a Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp (20)

Aplicativo de Apoio ao Ensino de Teoria Musical Para a Plataforma Android - Mozapp