FEES - CBSoft 2013 - Universidade de Brasília

congresso Brasileiro de Software: Teoria e Prática
29 de setembro a 04 de outubro de 2013
Brasília-DF
Anais
FEES 2013
Fórum de Educação em Engenharia de Software
FEES 2013
Fórum de Educação em Engenharia de Software
02 e 03 de outubro de 2013
Brasília-DF, Brasil
ANAIS
Volume 01
ISSN: 2175-­9677
COORDENAÇÃO DO CBSOFT 2013
Genaína Rodrigues – UnB
Rodrigo Bonifácio – UnB
Edna Dias Canedo - UnB
Realização
Universidade de Brasília (UnB)
Departamento de Ciência da Computação (DIMAp/UFRN)
Promoção
Sociedade Brasileira de Computação (SBC)
Patrocínio
CAPES, CNPq, Google, INES, Ministério da Ciência, Tecnologia e Inovação, Ministério do Planejamento,
Orçamento e Gestão e RNP
Apoio
Instituto Federal Brasília, Instituto Federal Goiás, Loop Engenharia de Computação, Secretaria de Turismo
do GDF, Secretaria de Ciência Tecnologia e Inovação do GDF e Secretaria da Mulher do GDF
FEES 2013
October 2 to 3, 2013
Brasília-DF, Brazil
PROCEEDINGS
Volume 01
ISSN: 2175-­9677
CBSOFT 2013 gENERAL CHAIRS
Genaína Rodrigues – UnB
Rodrigo Bonifácio – UnB
Edna Dias Canedo - UnB
ORGANIZATION
Universidade de Brasília (UnB)
Departamento de Ciência da Computação (DIMAp/UFRN)
PROMOTION
Brazilian Computing Society (SBC)
SPONSORS
CAPES, CNPq, Google, INES, Ministério da Ciência, Tecnologia e Inovação, Ministério do Planejamento,
Orçamento e Gestão e RNP
SUPPORT
Instituto Federal Brasília, Instituto Federal Goiás, Loop Engenharia de Computação, Secretaria de Turismo
do GDF, Secretaria de Ciência Tecnologia e Inovação do GDF e Secretaria da Mulher do GDF
Autorizo a reprodução parcial ou total desta obra, para fins acadêmicos, desde que citada a fonte
FEES 2013
Apresentação
O Fórum de Educação em Engenharia de Software (FEES) tem como objetivo expor, analisar e debater
sobre as particularidades e dificuldades do ensino e da aprendizagem de Engenharia de Software,
propondo e discutindo estratégias de apoio às atividades educacionais. O FEES é um fórum anual
vinculado ao Simpósio Brasileiro de Engenharia de Software (SBES) desde 2008. As edições anteriores
do FEES foram realizadas em Natal (2012), São Paulo (2011), Salvador (2010), Fortaleza (2009) e
Campinas (2008).
O FEES 2013 tem como tema central “Educação Aberta: Desafios e Oportunidades para a Educação em
Engenharia de Software”. O termo Educação Aberta busca combinar, de forma efetiva, facilidade de
acesso à educação, qualidade de instrução, menor custo e escalabilidade ilimitada. Como a educação e
o treinamento em Engenharia de Software podem se beneficiar desse modelo? E quais são os desafios
associados? Neste contexto, o programa do FEES 2013 inclui a palestra intitulada “Os dilemas didáticos
da engenharia de software: nós no pódio e ... eles nas nuvens” a ser apresentada pela Profa. Itana
Maria Gimenes.
O comitê de programa do FEES 2013 contou com a participação de 21 pesquisadores brasileiros. Foram
submetidos 15 artigos ao Fórum, provenientes de diversas regiões do país, sendo que 7 foram aceitos
para apresentação e publicação nos anais. Cada artigo foi avaliado por, pelo menos, três membros do
Comitê de Programa, segundo critérios pré-estabelecidos. Os coordenadores tomaram a decisão final a
partir de análise dos comentários dos avaliadores e da relevância do tema do artigo para o Fórum.
Finalmente, o programa do FEES 2013 inclui uma oficina de trabalho, sob a coordenação do Prof. Daltro
Nunes, para discutir e trabalhar aspectos dos currículos de graduação em Engenharia de Software.
Gostaríamos de agradecer aos membros do comitê de programa e revisores pelo trabalho cuidadoso
realizado, e aos professores Itana Gimenes e Daltro Nunes, por aceitar nosso convite e enriquecer
nosso Fórum com sua valiosa experiência na área. Agradecemos, finalmente, a todos os autores de
trabalhos, patrocinadores e membros do comitê organizador local do CBSOFT 2013, e aos professores
Hilmer Neri e Wander Cleber Silva pelo apoio e contribuição para o sucesso do FEES 2013.
Esperamos que o Fórum seja uma experiência positiva para todos.
Brasília, Outubro de 2013.
Christina Chavez e Regina Braga
Coordenadoras do Comitê de Programa do FEES 2013
5
FEES 2013
Foreword
The Forum on Software Engineering Education (FEES) aims to expose, analyze and discuss the
particularities and difficulties of teaching and learning Software Engineering, proposing and discussing
strategies to support educational activities. The FEES is an annual forum co-located with the Brazilian
Symposium on Software Engineering (SBES) since 2008. The previous FEES editions were held in Natal
(2012), São Paulo (2011), Salvador (2010), Fortaleza (2009) and Campinas (2008).
The central theme of FEES 2013 is “Open Education: Challenges and Opportunities for Software
Engineering Education”. The term Open Education seeks to combine, effectively, easy access to
education, education quality, lower cost and unlimited scalability. How education and training in
software engineering can benefit from this model? And what are the associated challenges? In this
context, the FEES 2013 program includes an invited talk entitled “The dilemmas of teaching software
engineering: we are on the podium and ... they are in the clouds “ to be presented by Prof. Itana Maria
Gimenes.
In 2013, the FEES program committee included 21 Brazilian researchers. 15 papers were submitted to
the Forum, from different regions of the country, and 7 were accepted for presentation and publication
in the proceedings. Each paper was evaluated by at least three members of the Program Committee,
according to pre-established criteria. The program chairs took the final decision from the analysis of
the comments of the evaluators and the relevance of the theme of the article to the Forum.
Finally, the program FEES 2013 includes a workshop, under the coordination of Prof. Daltro Nunes, to
discuss and work on aspects of undergraduate curricula in software engineering.
We would like to thank the members of the program committee and reviewers for their careful work,
Prof. Itana Gimenes and Prof. Daltro Nunes, for accepting our invitation and enriching our Forum with
their valuable experience in the field. Finally, we thank the authors, sponsors and members of the
local organizing committee of CBSoft 2013, Prof. Hilmer Neri and Prof. Wander Cleber Silva, for their
support and contribution to the success of FEES 2013.
We hope that the Forum is a positive experience for everyone.
Brasília, October 2013.
Christina Chavez and Regina Braga
FEES 2013 Program Chairs
6
FEES 2013
Biografia dos coordenadores / FEES 2013 Chairs Short Biographies
Christina von Flach Garcia Chavez
Christina von Flach Garcia Chavez é Professora Associada no Departamento de Ciência da Computação
(DCC) da Universidade Federal da Bahia (UFBA) desde 1990. É Doutora em Informática pela Pontifícia
Universidade Católica do Rio de Janeiro (2004), Mestre em Ciência da Computação pela Universidade
Estadual de Campinas (1992) e Bacharel em Ciência da Computação pela Universidade Federal da Bahia
(1987). Atualmente, coordena o curso de Doutorado do Programa de Pós-graduação Multiinstitucional
em Ciência da Computação (PMCC). Participa do Laboratório de Engenharia de Software da UFBA (LES
@ UFBA) e coordena o grupo de pesquisa em Design e Evolução de Software da UFBA (aSide @ UFBA).
Atua como pesquisadora e líder do grupo de Arquitetura de Software no Fraunhofer Project Center –
UFBA (FPC-UFBA). Seus interesses de pesquisa incluem diversos tópicos relacionados a arquitetura e
evolução de software e educação em engenharia de software.
Christina von Flach Garcia Chavez is an Associate Professor at the Department of Computer Science
(DCC) of the Federal University of Bahia (UFBA) since 1990. She has PhD in Computer Science from
the Pontifical Catholic University of Rio de Janeiro (2004), Master in Computer Science from the
State University of Campinas (1992) and BS in Computer Science from the Federal University of Bahia
(1987). She is currently coordinating the Ph.D. Graduate Program in Computer Science (PMCC) at UFBA.
She participates in the Software Engineering Laboratory of UFBA (LES @ UFBA) and coordinates the
research group on Software Design and Evolution at UFBA (aside @ UFBA). She works as a researcher
and team leader in Software Architecture at the Fraunhofer Project Center - UFBA (FPC-UFBA). Her
research interests include various topics related to software architecture and evolution, and software
engineering education.
Regina Maria Maciel Braga
Regina Braga é professora associada da Universidade Federal de Juiz de Fora desde 2004. Graduada
em Ciência da Computação pela Universidade Federal de Juiz de Fora (1991). É doutora em Engenharia
de Sistemas e Computação pela Universidade Federal do Rio de Janeiro (2000). Recebeu o título de
mestre em Engenharia de Sistemas e Computação pela Universidade Federal do Rio de Janeiro em
1995. Atualmente trabalha na graduação em Ciência da Computação e é coordenadora do mestrado
em Ciência da Computação. Tem experiência em ciência da computação, com ênfase em engenharia de
software e banco de dados, especificamente nos seguintes tópicos: ontologias, integração de dados,
LPS e workflows científicos.
Professor Braga is an associate professor at the Federal University of Juiz de Fora since 2004.
Graduated in Computer Science from Federal University de Juiz de Fora (1991). She is Ph.D. in
Computer Science and Systems Engineering form Federal University of Rio de Janeiro ( 2000) and
received her master degree in Computer and Systems Engineering from Federal University of Rio de
Janeiro in 1995. She currently works on the undergraduate program in Computer Science and is the
coordinator of the Master Program of Computer Science. Braga has experience in computer science,
with emphasis on software engineering and databases, specifically in the following topics: ontologies,
data integration, SPL and scientific workflows.
7
FEES 2013
Comitês Técnicos / Technical Committees
Ana Regina Rocha, COPPE/UFRJ
Andréa Mendonça, IFAM
Christiane Gresse von Wangenheim, UFSC
Christina Chavez,UFBA
Claudia Werner, COPPE/UFRJ
Dalton Dario Serey Guerrero, UFCG
Daltro Nunes, UFRGS
Eduardo Almeida, UFBA
Eduardo Figueiredo, UFMG
Ellen Francine Barbosa, ICMC-USP
Fernanda Campos, UFJF
Heitor Costa, UFLA
Itana Maria de Souza Gimenes, UEM
Jair Leite, UFRN
José Maria David, UFJF
Julio Leite, PUC-Rio
Rafael Prikladnicki, PUCRS
Regina Braga, UFJF
Roberto de Almeida Bittencourt, UEFS
Tayana Conte, UFAM
Vera Werneck, UERJ
Comitê organizador / Organizing Committee
COORDENAÇÃO GERAL
Genaína Nunes Rodrigues, CIC, UnB
Rodrigo Bonifácio, CIC, UnB
Edna Dias Canedo, CIC, UnB
COMITÊ LOCAL
Diego Aranha, CIC, UnB
Edna Dias Canedo, FGA, UnB
Fernanda Lima, CIC, UnB
Guilherme Novaes Ramos, CIC, UnB
Marcus Vinícius Lamar, CIC, UnB
George Marsicano, FGA, UnB
Giovanni Santos Almeida, FGA, UnB
Hilmer Neri, FGA, UnB
Luís Miyadaira, FGA, UnB
Maria Helena Ximenis, CIC, UnB
8
FEES 2013
Palestrante convidada / invited keynote
Itana Maria de Souza Gimenes
Universidade Estadual de Maringá (UEM)
Os dilemas didáticos da engenharia de software: nós no pódio e ... eles
nas nuvens / Dilemmas of teaching software engineering: we are on the
podium and...they are in the clouds
Resumo: Partimos de problemas vivenciados atualmente no ensino superior ilustrando com
exemplos da engenharia de software, fazendo uma análise da relação entre professor aluno e o
eventual efeito, por exemplo, na qualidade de software. O cenário vai mostrar a necessidade de
uma evolução, até retórica, que já atingiu uma crise. Como refletir sobre esse cenário e usar os
recursos atuais disponíveis para motivar e melhorar a educação. O que há de novo que já pode ser
utilizado em engenharia de software? Como agir em comunidade, colaborar, compartilhar e promover
conhecimento?
Summary: We start from problems experienced in higher education currently illustrating with examples
of software engineering, making an analysis of the relationship between teacher and student, and the
possible effect, for example, on software quality. The scenario will show the need for an evolution, even
rhetorical, which has reached a crisis. How to reflect on this scenario and use the current resources
available to motivate and improve education? What are the advances that can already be used in
software engineering? How to act in community, collaborate, share and promote knowledge?
9
FEES 2013
Biografia da palestrante / keynote Short Biographie
Itana Maria de Souza Gimenes é professora titular em engenharia de software na Universidade Estadual
de Maringá (UEM), Paraná, Brazil. Ela fez estágio de pós-doutorado senior na Open University, Reino
Unido (2011) em uma pesquisa relacionada a projeto de aprendizagem aplicada a engenharia de
software. Em 2005, fez pós-doutorado na School of Computer Science, University of Waterloo, ON,
Canada onde a pesquisa concentrou-se em linha de produto de software. Ela tem PhD em Ciência da
Computação na University of York, Department of Computer Science, UK (1992). Foi Presidente da
Comissão Especial de Engenharia de Software da Sociedade Brasileira de Computação (SBC) em 20072008 e 1998-1999. Atualmente é coordenadora local (UEM) do Instituto Nacional de Tecnologia para
Sistemas Embarcados Críticos, um projeto estratégico do CNPq coordenado pelo ICMC/USP. Itana tem
experiência em vários projetos nacionais e internacionais.
Itana Maria de Souza Gimenes is a professor in software engineering at the State University of
Maringá (UEM), Paraná, Brazil. Her senior postdoctoral training was held at the Open University, UK
(2011) in a research related to learning projects applied to software engineering. In 2005, she held
a post-doctorate at the School of Computer Science, University of Waterloo, ON, Canada in which her
research focused on software product lines. She has a PhD in Computer Science at the University of
York, Department of Computer Science, UK (1992). She was the Chairman of the Special Committee
on Software Engineering of the Brazilian Computer Society (SBC) in 2007-2008 and 1998-1999. She
is currently the local coordinator (at UEM) of the National Technology Institute for Critical Embedded
Systems, a strategic CNPq project coordinated by the ICMC / USP. Itana has experience in various
national and international projects.
10
FEES 2013
Índice de Artigos / Table of Contents
Proposta e Avaliação de um Curso Aberto em
Engenharia de Software
12
Juliana Pereira (Federal University of Minas Gerais (UFMG)), Lucas Garcia
(UFMG), Eduardo Figueiredo (Federal University of Minas Gerais (UFMG))
SimulES-W: Retroalimentação Evolutiva num Jogo
para Ensino na Engenharia de Software
20
Elizabeth Monsalve (Puc-Rio), Vera Werneck (Universidade do Estado do Rio
de Janeiro), Julio Leite (Pontificia Universidade Catolica do Rio de Janeiro)
Jogos digitais como instrumentos no processo de
avaliação formativa da aprendizagem na disciplina
de Engenharia de Software
38
Glauber Araujo (Universidade Federal do Rio Grande do Norte), Eduardo
Aranha (Universidade Federal do Rio Grande do Norte)
Uma Abordagem para o Ensino de Engenharia de
Software no Desenvolvimento de Jogos Digitais
36
Emanuel Coutinho (Universidade Federal do Ceará (UFC), Carla Ilane Moreira
Bezerra (Universidade Federal do Ceará - UFC)
Learning Software evolution: curriculum,
approaches and an experience report
44
Debora Nascimento (Federal University of Sergipe), Christina Chavez
(Universidade Federal da Bahia), Roberto Bittencourt (Universidade Estadual
de Feira de Santana)
Tecnologia Social: A influência das empresas
juniores na academia e na indústria de software
52
Nadja Rodrigues (Instituto Federal de Educação, Ciência e Tecnologia da
Paraíba)
Uma Experiência de Integração de Design Thinking
e Metodologias Ágeis para o Desenvolvimento de
Software
Cleidson de Souza (UFPA), Mylena Ferreira (UFPA), Fagner Pantoja (UFPA),
Mayara Figueiredo (Universidade Federal do Pará)
11
60
Proposta e Avaliação de Educação Aberta para
Engenharia de Software
Juliana Alves Pereira, Lucas Garcia, Eduardo Figueiredo
Laboratório de Engenharia de Software (LabSoft), Departamento de Ciência da
Computação (DCC), Universidade Federal do Minas Gerais (UFMG)
Belo Horizonte – MG – Brasil
{juliana.pereira, lucas.sg, figueiredo}@dcc.ufmg.br
Abstract. Massive Open Online Course (MOOC) is an emerging method of
online lecturing whose application in education is not bounded by space and
location constraints. The successful implementation of MOOCs requires
conceptual changes in how instructors and students behave in an open
unbounded education environment. There are some emerging MOOC
initiatives for Software Engineering. However, the knowledge about the best
practices for learning Software Engineering processes, methods, and tools in
such an open environment is still limited. This paper presents a MOOC, based
on a face-to-face course, for introductory Software Engineering courses. Over
60 students are taking this MOOC, which is composed of 44 video lectures, 60
questions in 6 quizzes, and several discussion topics. To evaluate the proposed
MOOC, we (i) compared students’ performance in online vs. face-to-face
courses and (ii) applied a questionnaire to the students taking the course.
Resumo. Curso Aberto Disponível na Internet (CADI) é um método emergente
de ensino online que não é limitado por restrições de espaço e localização. A
implantação bem sucedida de um CADI exige mudanças conceituais na forma
como professores e alunos se comportam em um ambiente aberto de ensino.
Existem algumas iniciativas emergentes de CADIs para a Engenharia de
Software. No entanto, ainda é limitado o conhecimento sobre as melhores
práticas de Engenharia de Software para o ensino de processos, métodos e
ferramentas em tal ambiente aberto. Este artigo apresenta um CADI para um
curso introdutório de Engenharia de Software proposto a partir de um curso
presencial. Mais de 60 estudantes estão participando deste CADI, que é
composto de 44 aulas em vídeo, 60 perguntas em 6 questionários de revisão e
vários tópicos de discussão. Para avaliar o CADI proposto: (i) foi comparado
o desempenho de alunos no curso online e em cursos presenciais e (ii) foi
aplicado um questionário para os alunos que participam do curso online.
1. Introdução
Curso Aberto Disponível na Internet (CADI) é um método emergente de ensino online
que não é limitado por restrições de espaço e localização [4]. Atualmente, várias
universidades dos principais centros influentes em educação ao redor do mundo criaram
ou estão criando CADIs com suporte total ou parcial via internet. Os exemplos são
significativos. A Universidade de Harvard e o MIT (Massachusetts Institute of
12
Technology), por exemplo, estão investindo na criação de vários CADIs por meio do
portal edX1. Outras mais de 80 universidades americanas e européias, entre elas
Princeton e Stanford, estão envolvidas na criação de centenas de CADIs em diversas
áreas pelo portal Coursera2. Muitos outros cursos similares estão sendo criados, com
bastante sucesso, como os do portal Udacity3 e, no Brasil, o Veduca4.
A implantação bem sucedida de um CADI exige mudanças conceituais na forma
como professores e alunos se comportam em um ambiente aberto de ensino [4]. Adeptos
desse tipo de curso argumentam que o suporte de material disponível na Internet para
que os alunos possam acompanhar o curso no seu próprio ritmo e horário constitui uma
ferramenta importante no processo de aprendizagem. Tal inovação em termos de
educação permite, por exemplo, que o tempo em sala de aula seja predominantemente
voltado para discussões, soluções de dúvidas e atividades de interação mais próximas
entre alunos e o professor. Portanto, é de fundamental importância que profissionais de
educação experimentem e analisem CADIs de modo a entender como e se de fato tais
cursos podem ser usados para aprimorar o processo de aprendizagem.
Existem algumas iniciativas emergentes de CADIs para a Engenharia de
Software, como o curso de Arquitetura de Software Orientada a Serviços [6] e Software
como Serviços [9]. Apesar de o potencial impacto de CADIs sobre a educação em
Engenharia de Software ainda ser desconhecida, tais cursos não podem ser ignorados se
quisermos que o impacto seja positivo. Por exemplo, jogos educacionais [5] [7] têm
sido usados para apoiar o ensino de Engenharia de Software, tanto em cursos presenciais
quanto em CADIs. Entretanto, ainda é limitado o conhecimento sobre quais as melhores
práticas para o ensino de processos, métodos e ferramentas de Engenharia de Software
em um curso aberto na Internet.
Neste contexto, este artigo apresenta um CADI para um curso introdutório de
Engenharia de Software. O curso foi proposto a partir de um curso presencial da
Universidade Federal de Minas Gerais (UFMG) que atende anualmente mais de 100
alunos em 4 turmas (duas turmas por semestre). Este CADI é atualmente composto de
44 aulas em vídeo, 60 perguntas em 6 questionários de revisão e vários tópicos para
discussão em formato de fórum. Neste estudo piloto, 35 alunos da UFMG estavam
academicamente matriculados e outros 28 alunos (externos) se registraram no curso
online; totalizando 63 alunos matriculados no CADI até a presente data. O material
usado no curso (e.g., livro texto, apresentações, exercícios, etc.) é exatamente o mesmo
tanto para os alunos presenciais quanto para os alunos externos. Entretanto, além das
aulas virtuais do CADI, os alunos academicamente matriculados também podem assistir
às aulas presenciais.
Este artigo apresenta também uma avaliação preliminar do CADI de Engenharia
de Software proposto. Nesta avaliação, foi comparado o desempenho de alunos no curso
online (2013) com o desempenho de alunos no curso presencial do ano anterior (2012)
no qual o CADI não era oferecido. Os resultados indicam que o desempenho médio dos
alunos melhorou no curso atual (2013). Vale ressaltar que os alunos do ano de 2013
1
http://www.edx.org/
http://www.coursera.org/
3
http://www.udacity.com
4
http://www.veduca.com.br/
2
13
também tiveram aulas presenciais, além do material disponível no CADI. Em outra
dimensão de avaliação, foi aplicado um questionário para que os alunos se
manifestassem sobre os pontos positivos e negativos do curso online.
O restante do artigo está organizado da seguinte forma. A Seção 2 discute
algumas iniciativas para educação aberta, com foco em cursos para a Engenharia de
Software. A Seção 3 propõe um CADI em Engenharia de Software para alunos
brasileiros e a Seção 4 apresenta uma avaliação preliminar deste CADI. A Seção 5
conclui este artigo e propõe direções para trabalhos futuros.
2. Educação Aberta em Engenharia de Software
A Internet tem se tornado uma importante ferramenta capaz de revolucionar a educação
por meio dos Cursos Abertos Disponíveis na Internet (CADIs). Diversas universidades
de grande prestígio estão oferecendo CADIs que têm atraído interesse de centenas de
milhares alunos ao redor do mundo [10]. Dentre algumas das principais iniciativas de
CADIs, podemos citar o Coursera, edX e Udacity. O Coursera2, por exemplo, foi
lançado a partir de uma parceria entre quatro prestigiadas universidades dos Estados
Unidos: Stanford, Princeton, Pennsylvania e Michigan. Assim como em outras
iniciativas de sucesso, os CADIs do Coursera são oferecidos de forma semelhante às
disciplinas presenciais das respectivas universidades. Além de aulas em vídeo, os alunos
registrados em um CADI podem participar de exercícios práticos e serem avaliados. Em
alguns casos, o aluno que concluir o curso com sucesso pode obter um certificado.
Há também iniciativas brasileiras de CADIs. Por exemplo, o Veduca4 foi
recentemente lançado como uma alternativa para estudantes em idioma português. O
portal reúne conteúdo de centenas de cursos em ensino superior organizado por áreas de
conhecimento. Os cursos são selecionados a partir de variadas universidades, sobretudo
dos EUA, com adição de legendas em português. Há também material de universidades
brasileiras, como USP, Unesp e Unicamp. Além do Veduca, podemos citar algumas
outras iniciativas brasileiras, como a FGV Online5 e a Univesp TV6, que oferecem
CADIs em diversas áreas do conhecimento. Vale ressaltar que essas plataformas não
fornecem volume significativo de conteúdo para disciplinas de Computação e, até onde
vai nosso conhecimento, são poucas as iniciativas de CADI para Engenharia de
Software no Brasil. Além disso, praticamente inexiste avaliação destes cursos para
verificar se eles realmente apoiam o aprendizado de Engenharia de Software.
Apesar de poucas iniciativas no Brasil, educação aberta para Engenharia de
Software é um tema que vem ganhando crescente atenção mundial. Por exemplo, um
trabalho [3] publicado recentemente em Communications of the ACM aborda o tema.
Este trabalho relata o uso de técnicas de desenvolvimento ágil para ministrar um curso
presencial com mais de 100 alunos na Universidade de Berkeley. Os autores [3] também
discutem suas experiências ao ofertarem a primeira parte do curso no formato de CADI
para mais de 50.000 alunos, a maioria dos quais trabalham no setor de TI com 5 a 10
anos de formados. Entretanto, o artigo não apresenta nenhuma avaliação para verificar
os pontos positivos e negativos do CADI no aprendizado dos alunos.
5
6
http://www5.fgv.br/fgvonline/
http://univesptv.cmais.com.br/
14
Diferentemente de tal artigo [3], o nosso trabalho busca oferecer conteúdo
abrangente para uma disciplina introdutória de Engenharia de Software. O ambiente
disponível para os alunos (Seção 3) conta com aulas em vídeo, fóruns de discussões,
questionários, dentre outros recursos interativos. Mais importante, este trabalho
apresenta um estudo comparativo entre o desempenho de alunos que cursaram a mesma
disciplina em diferentes modalidades (Seção 4): aulas integralmente presenciais e aulas
que combinam atividades presenciais com atividades online.
3. Uma Proposta Brasileira de CADI para Engenharia de Software
Todos os anos o curso de Engenharia de Software tem sido ministrado presencialmente
para mais de 100 alunos da Universidade Federal de Minas Gerais (UFMG). Entretanto,
com a popularização dos CADIs e aumento do número de alunos matriculados em
função do REUNI, o professor, a estagiária em docência e o monitor da disciplina –
coletivamente chamados instrutores – decidiram criar um curso aberto e implantá-lo em
2013 (a partir de março). Assim, a proposta de CADI para Engenharia de Software [1]
foi gradativamente materializada ao longo do primeiro semestre de 2013. A Seção 3.1
apresenta algumas características do curso criado. A Seção 3.2 discute o perfil dos 63
alunos atualmente registrados no curso.
3.1. Características do Curso
O CADI para Engenharia de Software (acessível em [1]) foi implantado no ambiente
Udemy. Udemy é uma plataforma de aprendizagem online e gerência de conteúdo que
permite aos instrutores criarem cursos pagos ou gratuitos. O CADI para Engenharia de
Software é um curso gratuito. Utilizando o Udemy, os instrutores disponibilizaram aulas
em vídeo, apresentações, questionários e arquivos complementares para a criação do
curso. A plataforma permite ainda que os alunos participem e interajam com os
instrutores através de fóruns de discussão. Na verdade, os estudantes possuem uma série
de recursos para apoiar o aprendizado, como fazer anotações durante os vídeos das aulas
e acesso ao conteúdo utilizando dispositivos móveis.
O objetivo inicial do curso foi disponibilizar aos alunos da UFMG
academicamente matriculados um ambiente online para assistir as aulas perdidas ou
revisar a matéria da disciplina. Portanto, os alunos teriam normalmente as 4 horas de
aulas presenciais por semana, além do conteúdo online. Entretanto, com o andamento do
semestre, alguns alunos - autorizados pelo professor - optaram por não frequentarem as
aulas presenciais, acompanhando o curso apenas pelo CADI. Além disso, pelo perfil
aberto e gratuito do curso, vários alunos se registraram no CADI apesar de não estarem
academicamente matriculados na disciplina presencial correspondente.
O material usado no curso (e.g., livro texto, apresentações, exercícios, etc.) é
exatamente o mesmo tanto para os alunos academicamente matriculados quanto para os
alunos externos. Entretanto os alunos matriculados fazem provas presenciais. O CADI
possui atualmente 44 aulas em vídeo totalizando mais de 20 horas de conteúdo gravado,
além de 6 questionários de revisão com 60 perguntas e 14 tópicos para discussão no
formato de fórum. Cada questionário foi respondido por pelo menos 20 alunos e os
tópicos para discussão possuem quase 1000 postagens no total. Estes números mostram,
não somente a relevância do conteúdo disponível, mas também o engajamento dos
15
alunos no curso. Dos seis alunos que avaliaram o curso no portal, cinco atribuíram 5
estrelas (melhor avaliação) e um atribuiu 4 estrelas para o curso em uma escala de 0 a 5
estrelas [1].
3.2. Os Alunos Matriculados
O CADI para Engenharia de Software possui atualmente 63 estudantes registrados,
sendo 35 academicamente matriculados na disciplina presencial e 28 externos. O baixo
número de estudantes externos está relacionado à dois fatores principais: (i) o curso foi
criado a apenas 4 meses e (ii) o curso não foi divulgado publicamente até o momento.
Os estudantes academicamente matriculados pertencem principalmente a dois cursos de
graduação (bacharelado): Sistemas de Informação e Ciência da Computação. A Figura 1
mostra uma visão geral do perfil dos alunos registrados no CADI.
Figura 1. Perfil e curso dos estudantes matriculados no CADI
Como apresentada na Figura 1, apesar da não divulgação do curso, o percentual
de estudantes academicamente matriculados é apenas 8% maior que o de alunos
externos. Os instrutores optaram pela não divulgação neste primeiro semestre para que
houvesse um maior controle na avaliação do curso (Seção 4). A Figura 1 mostra que os
alunos academicamente matriculados pertencem a quatro diferentes cursos de
graduação. Entretanto, aproximadamente 75% dos estudantes são de Sistemas de
Informação ou Ciência da Computação, pois a disciplina de Engenharia de Software é
obrigatória para estes cursos. A disciplina é optativa para os outros cursos.
4. Avaliação do Curso
Esta seção apresenta uma avaliação do CADI para Engenharia de Software proposto. A
Seção 4.1 discute o engajamento dos estudantes por meio de estatísticas de acesso e
indicadores de participação. A Seção 4.2 confronta o desempenho dos alunos do curso
atual com o desempenho de alunos em anos anteriores nos quais não havia o CADI.
Finalmente, a Seção 4.3 resume a opinião dos alunos em relação ao curso.
4.1. Estatísticas de Acesso e Envolvimento dos Alunos
Segundo informações da ferramenta Google Analytics7, a página principal do CADI
teve mais de 3000 visualizações no período de março a junho de 2013. A Figura 2
7
http://www.google.com/analytics/
16
mostra a estatística de visualizações à página principal do curso no mês de abril de
2013. Pelos dados desse gráfico, observa-se que as visualizações aumentam
gradativamente a partir do dia 20/04 com ápice no dia no dia 24/04. No dia 24/04 foi
aplicada a primeira prova da disciplina e, portanto, o gráfico confirma que os alunos
usaram o ambiente virtual com forma de revisar a matéria para prova.
Figura 2. Visualizações do curso no mês de abril.
A Figura 3 mostra a taxa de acerto dos alunos que responderam aos seis questionários
de revisão. Pelo menos 20 estudantes responderam cada questionário. O primeiro
questionário teve o maior número de respondentes (34) enquanto o último teve o menor
número de respondentes (20). É interessante observar que, exceto pelo Questionário 1, a
porcentagem de acertos sempre aumentou de um questionário para o seguinte. Este
resultado sugere um crescente engajamento dos estudantes no decorrer do curso.
Figura 3. Relação de erros e acertos por questionário de revisão
4.2. Comparação entre o Curso Puramente Presencial e com Apoio do CADI
Esta seção realizada uma comparação entre o desempenho dos alunos no curso atual
(2013) e no 1º semestre do ano anterior (2012). Esses cursos foram lecionados pelo
mesmo professor. Entretanto, no ano anterior o curso foi puramente presencial. Não
foram usados dados de semestres consecutivos para minimizar distorções causadas por
alunos repetentes. Para auxiliar essa comparação, duas questões da primeira prova de
2013 – denominadas questões idênticas Q1 e Q2 – foram extraídas da prova equivalente
no ano anterior. As demais questões da prova não estão sendo usados nesta análise.
Portanto, garantimos que a grau de dificuldade era exatamente o mesmo para os alunos
em ambas as turmas (2012 e 2013).
Utilizamos nesta análise o teste-t [8] para verificar se a média de dois grupos é
significativamente diferente. O teste-t pode utilizar métodos diferentes para
observações: pareadas e não pareadas [8]. Neste trabalho, faremos uma análise de
observação não pareada, pois temos amostras independentes de cada uma de duas
populações. Ou seja, grupos distintos de estudantes foram submetidos a duas
metodologias de ensino distintas. A Tabela 1 sumariza as médias, desvios padrão,
17
variância e tamanhos amostrais (N) para ambas as amostras. Utilizando-se da
distribuição t, obtemos que o intervalo de confiança (IC) é de 90%. Este resultado
mostra que, com o nível de significância de 90%, as médias das notas dos alunos
submetidos aos dois tipos de metodologia são diferentes.
Tabela 1. Dados das amostras para os anos de 2012 e 2013
Sumarização
Média
Desvio Padrão
Variância
N
2012
5,9
1,6
2,7
56
2013
7,0
1,4
1,9
35
Para verificar se a frequência dos alunos em aulas presenciais no ano de 2013 foi
fator determinante para boas notas, aplicamos a regressão linear [8]. A Figura 4 mostra
gráficos de dispersão dos pontos considerando a nota dos alunos nas questões idênticas
(eixo x) e a sua frequência (eixo y). O modelo de regressão é mostrado por uma linha
reta. Pelos dados da Figura 4 (esquerda), a regressão linear explica 50% das notas
tiradas pelos alunos de 2012 em função da frequência. Por outro lado, a Figura 4
(direita) mostra que a regressão linear explica somente 7% das notas tiradas pelos
alunos de 2013 em função da frequência. Este resultado sugere que a frequência dos
alunos em aulas presenciais não é fator determinante para suas respectivas notas curso
com CADI.
Figura 4. Gráficos de Dispersão com Regressão Linear da Juliana
4.3. Opinião dos Alunos sobre o Curso
Foi aplicado um questionário para que os alunos se manifestassem sobre os pontos
positivos e negativos do curso online. Os alunos discutiram como o curso disponível na
internet contribui para o aprendizado de Engenharia de Software em comparação ao
curso tradicional, i.e., inteiramente presencial. Foi possível observar que 82% dos
alunos avaliaram as aulas em vídeo e os questionários como contribuições essenciais
para o aprendizado. Ou seja, no geral os alunos se mostraram muito satisfeitos com o
material disponível online. Entretanto, 27% dos alunos responderam que a disciplina
presencial não poderia ser substituída por um curso completamente online.
18
5. Conclusões e Trabalhos Futuros
Este artigo apresentou um Curso Aberto Disponível na Internet (CADI) para Engenharia
de Software proposto a partir de um curso presencial da Universidade Federal de Minas
Gerais (UFMG). Este CADI é composto de 44 aulas em vídeo, 60 perguntas em 6
questionários de revisão e tópicos para discussão em formato de fórum. Em um estudo
preliminar, o CADI foi avaliado em função de 35 alunos da UFMG academicamente
matriculados. Os resultados do estudo sugerem que (i) os alunos se mostraram
engajados e motivados a participarem do curso online, especialmente como forma de
revisar para provas, (ii) as notas dos alunos no curso presencial com apoio do CADI são
estatisticamente maiores do que as notas de alunos cursando a mesma disciplina
puramente presencial, e (iii) a frequência dos alunos no curso com apoio do CADI não
foi fator determinante para as suas boas notas. Como trabalhos futuros, pretende-se (i)
melhor a qualidade de som e imagem das aulas em vídeo, (ii) incluir novos exercícios de
revisão e atividades práticas no curso, e (iii) elabora novas dimensões de avaliação.
Agradecimentos
Este trabalho recebeu apoio financeiro da PROGRAD UFMG processo PIQEG2013-41; do
CNPq processo 485235/2011-0; e da FAPEMIG processos APQ-02376-11 e APQ-02532-12.
Referências
[1] Engenharia de Software. http://www.udemy.com/engenharia-de-software-ufmg/
[2] Derwin, E. (2009) Critical Thinking in Online vs. Face-to-Face Higher Education.
Media Psychology Review, vol. 2(1).
[3] A. Fox and D. Patterson. (2012) Crossing the Software Education Chasm.
Communications of the ACM, 55(5), 44–49.
[4] K. Masters. (2011) A Brief Guide to Understanding MOOCs. The Internet Journal
of Medical Education, 1.
[5] L. Meirelles et al. (2011) “Uso de Jogos para o Ensino de Engenharia de
Software”. Anais do V Fórum de Educação em Engenharia de Software (FEES).
[6] Pattern-Oriented Software Architectures. https://www.coursera.org/course/posa
[7] H. Potter e M. Schots. (2011) InspectorX: Um Jogo para o Aprendizado em
Inspeção de Software. Anais do V Fórum de Educação em Engenharia de
Software (FEES).
[8] R. Jain, J. Wiley and Sons. (1991). “The Art of Computer System Performance
Analysis: Techniques for Experimental Design, Measurement, Simulation and
Modeling”. ISBN: 0-471-50336-3.
[9] Software as a Service (SaaS). http://www.edx.org/course/uc-berkeley/cs1691x/software-service/691
[10] N. Tillmann et al. (2013) "Teaching and Learning Programming and Software
Engineering via Interactive Gaming". In Int'l Conf. on Software Eng. (ICSE).
19
SimulES-W: Retroalimentação Evolutiva em um Jogo para
Ensino na Engenharia de Software
Elizabeth Suescún Monsalve1, Vera Maria B. Werneck2, Julio Cesar Sampaio do
Prado Leite1
1
Pontifícia Universidade Católica de Rio de Janeiro (PUC-Rio), Rio de Janeiro, Brasil
2
Universidade do Estado do Rio de Janeiro (UERJ), Rio de Janeiro, Brasil
[email protected], [email protected], www.inf.puc-rio.br/~julio
Abstract. In the context of software engineering teaching the feedback is the
materialization of ideas and suggestions that students make in order to
improve the learning process. With this in mind, this paper presents the
development of a game for software engineering teaching called SimulES-W in
which we use this strategy to its evolution and improvement, based on
experiments using the game on board and digital version.
Resumo. No contexto do ensino da engenharia de software a retroalimentação
é a materialização de ideias e sugestões que os estudantes fazem visando a
melhoria do processo do aprendizado. Com isto em mente, este trabalho
apresenta a evolução de um jogo para ensino na engenharia de software
chamado de SimulES-W no qual utilizamos esta estratégia para sua evolução
e aprimoramento com base numa experimentação que usa o jogo em tabuleiro
e digital.
1. Introdução
A aceitação dos jogos como uma prática habitual no ensino é cada vez maior. Esta vem
sendo motivada pela massificação da tecnologia e ferramentas cada vez mais accessíveis
em ambientes cada vez mais realistas. Desta forma o uso de jogos no ensino permite
treinar, ensinar, aprender e identificar elementos que não são fornecidos com métodos
tradicionais. Jogos para ensino têm, também, um potencial de serem melhoradores do
processo no qual estão inseridos, por estarem em constante evolução visando incorporar
as melhoras e sugestões dos usuários destas ferramentas.
No ensino da Engenharia de Software devem ser considerados tanto os conceitos
teóricos quanto aspectos práticos que visam o desenvolvimento de software de
qualidade com profissionais cada vez mais competitivos. Neste contexto têm surgido
propostas de ensino através de projetos (Pressman, 2006), (Claypool e Claypool, 2005) e
(Sweedyk e Keller, 2005) e de alguns jogos de tabuleiros, de cartas e simuladores
(Baker, 2003), (SESAM, 2009), (Jain e Boehm, 2006), (Birkhoelzer et al, 2005) para
apoiar o ensino de aspectos práticos de engenharia de software. E finalmente temos o
SimulES-W (Monsalve, 2010), um jogo computacional com tabuleiro e cartas para
ensino de Engenharia de Software. A evolução do SimulES-W é o resultado do análise
de retroalimentações de estudantes nas aulas de classes.
20
Com o SimulES-W visamos a principio o aprimoramento do jogo para depois
utilizá-lo no ensino da engenharia de software. Neste contexto, a retroalimentação é
visualizada como um processo que nos fornece informação, descrevendo o pensamento,
o sentimento e a forma de atuar dos estudantes, além de promover a participação ativa
de todos os envolvidos. No uso do SimulES-W, a retroalimentação tem permitido
conhecer como é o desempenho e as falhas do jogo, além de fornecer ideias de como
melhorar e evoluir o SimulES-W.
O objetivo do trabalho é apresentar a retroalimentação como uma estratégia de
aprimoramento do uso do SimulES-W, além de verificar possíveis mudanças que não
foram incorporadas nesta versão Web. Por outro lado, esta é a primeira vez que usamos
as duas versões (tabuleiro e digital) numa mesma atividade e com isso pretende-se
verificar também se no uso do tabuleiro existem conceitos melhor explorados ou não.
Este artigo está dividido em cinco seções. Na seção 2 apresentamos uma resenha
do Jogo SimulES-W. Na seção 3 relatamos uma experiência com o SimulES-W na
versão digital e na versão do tabuleiro. Na seção 4 relatamos as melhorias realizadas no
SimulES-W com base nas retroalimentações dos alunos e na observação das atividades.
Finalmente na seção 5 as conclusões e trabalhos futuros são abordados.
2. Visão Geral do SimulES-W
As primeiras versões do jogo foram compiladas num jogo do tabuleiro conhecido como
SimulES (Figueiredo, 2007). Ele está direcionado para o ensino de engenharia de
software e foi concebido a partir da evolução do jogo "Problems and Programmers"
(PnP) (Baker, 2003). A evolução do SimulES para um software que roda na Web, foi
chamado de SimulES-W. Esta evolução foi realizada com base num estudo de literatura
sobre jogos educacionais na engenharia de software e nas experiências de uso do jogo
(Serrano et al 2007), (Monsalve, 2010), (Monsalve, Werneck e Leite, 2010), (Monsalve,
Werneck e Leite, 2011) entre outras.
As diferentes versões do jogo conservam a filosofia geral, que é construir um
produto de software baseado num projeto comum para todos os jogadores (objetivo
principal do jogo). Para isso o aluno assume o papel de gerente de projeto e deve lidar
com o orçamento, contratação e demissão de engenheiros de software, e construção de
diversos artefatos necessários para término do projeto, entre outras atividades. O jogador
deve criar uma estratégia que irá melhorar o seu jogo em relação à dos seus adversários,
ao mesmo tempo deve fazer jogadas que desestabilizem os jogos de seus adversários.
Mas os adversários podem responder com conceitos de engenharia de software e
bloquear o ataque de um jogador com uns artefatos chamados de Cartas Conceito e
Problema. A partida é ganha quando um jogador constrói todos os artefatos necessários
para completar o projeto e se estes têm a qualidade estipulada. Ou seja, para vencer o
jogo, é preciso completar os módulos do projeto definidos no cartão de projeto
selecionado no início do jogo com a qualidade exigida. Após serem construídos os
artefatos estes devem ser empacotados em uma instância do jogo chamada Rodada de
Ações e depois submetidos como produto final.
Para contextualizar descreveremos brevemente cada uma das rodadas das quais
dispõe o jogo: A primeira é a jogada de inicio nela é escolhido aleatoriamente o projeto
que deve ser tratado durante todo o jogo, como também o primeiro Engenheiro de
21
Software para cada um dos jogadores. A segunda é a jogada de ações que começa com
o lançamento do dado e de acordo com o número tirado, retira 1 a 3 Cartas Conceito ou
Cartas Problema e se o valor do dado for mais de 4 pode pegar também (dado–3) Cartas
de Engenheiro de Software. A terceira, a jogada de ações nela o jogador da vez deve
escolher a subatividade de construir, inspecionar ou empacotar os artefatos dispostos no
tabuleiro individual. Na construção pode retirar novas Cartas de Artefato dependendo da
complexidade do projeto e da habilidade de sua equipe de Engenheiros de Software. A
habilidade determina quantos “pontos de tempo” o Engenheiro de Software tem e,
portanto, quantas ações ele pode desempenhar por vez. Analogamente, ele pode
inspecionar dependendo, também, da habilidade da sua equipe. A seguir vem a jogada
de conceitos e tratamento de problemas, onde os jogadores podem ser atacados e
atacam seus adversários usando as Cartas Conceitos e Cartas Problemas com conceitos
típicos da engenharia de software. Por último, a submissão do produto, onde o primeiro
jogador a chegar nesta instância sem defeitos em seu produto de software e que não
tenha penalidade alguma a ser resolvida ganha o jogo. Ressaltarmos que as jogada de
ações, jogada de conceitos e tratamento de problemas vão se repetindo até terminar o
jogo.
Para ilustrar, a Figura 1 apresenta a tela principal do SimulES-W onde são
dispostas as mensagens trocadas entre os jogadores e as informações sobre jogadas e
estado do jogo. Nesta tela temos também as informações de projeto escolhido para a
jogada e os jogadores on-line, e finalmente a lista das jogadas aceitadas ou não entre os
jogadores.
Figura 1. Tela principal de SimulES-W
Na Figura 2 temos o Tabuleiro Individual em duas situações: a) Construção de
Artefato onde o jogador tem os Engenheiros de Software contratados para a construção
dos diferentes artefatos, cada um deles com um link que apresenta as informações dos
22
Engenheiros de Software. Na parte a dessa figura as cartas de artefato brancas e as cartas
de artefato cinza aparecem sem terem sido desviradas. Na parte inferior desta tela
aparecem, também, as operações possíveis a serem realizadas dentro do tabuleiro. A
Figura 2 parte b apresenta uma situação de Inspeção de Artefatos, pois o jogador já
construiu o artefato (parte a) e ele pode inspecioná-lo. Nessa segunda parte da Figura 2 é
ilustrado o resultado de uma inspeção quando o artefato tem erro e quando não tem.
SimulES-W aleatoriamente escolhe a qualidade da carta de artefato branca ou carta
cinza, sendo que as cartas brancas têm menos possibilidades de terem erro que as cartas
cinzas entretanto estas custam o dobro da outra.
Uma das características principais do SimulES-W é a possibilidade de edição
das cartas de problemas e das cartas de conceitos, fazendo portanto que o material a ser
enfatizado pelo curso seja customizado pelo professor.
3. Relatando uma experiência do Uso do SimulES-W
No período 2012-2 na Universidade Estadual Rio de Janeiro (UERJ) foi realizada uma
atividade com estudantes do curso de ciência da computação dos três primeiros
semestres. No total 15 estudantes (13 homens e 2 mulheres) participaram da atividade
onde eles utilizaram SimulES-W e SimulES (jogo de tabuleiro). Distribuídos assim: um
primeiro grupo de 8 estudantes jogaram SimulES do tabuleiro, estes ficaram em grupos
de duas pessoas, ou seja, o jogo foi utilizado com 4 tabuleiros individuais. Um segundo
grupo de 7 estudantes jogou SimulES-W onde foram criados 3 grupos de 2 estudantes e
um estudante jogou sozinho. O objetivo da atividade era observar os estudantes jogando
e visualizar os diferentes comportamentos tanto na versão do tabuleiro como na versão
digital do jogo. Outro propósito era, também identificar elementos de melhoria vindo
de retroalimentação dos estudantes e da observação da atividade. Para isso analisamos
os dados guardados no jogo e os questionários preenchidos pelos estudantes.
Figura 2. Tabuleiro Individual nas situações de Construção de Artefato e
Inspeção de Artefato (Monsalve, 2010)
Os estudantes foram instruídos sobre a atividade, com uma apresentação e
explicação do jogo. Durante a atividade os estudantes preencheram um questionário
sobre o tipo de aprendizado dinâmico que eles preferiam. Na Figura 3 vemos uma clara
preferência dos estudantes pela utilização de atividades que envolvam cooperação com
um 67% ou seja, 10 estudantes, seguido de um aprendizado competitivo 27%, 4
23
estudantes. Finalmente, um estudante reportou que preferia um aprendizado individual,
isso representou 6% da mostra.
Figura 3. Preferência do Tipo de da Atividade de Aprendizado
A seguir os estudantes foram perguntados sobre o nível de instrução em
processos de engenharia de software. Como eram estudantes dos primeiros semestres do
curso era de esperar a representação que vemos na Figura 4. 46% dos estudantes tinham
recebido insuficiente instrução (7 estudantes), seguida de nenhuma, não conhece ou na
responderam com um 27% (4 estudantes), e finalmente, suficiente 27% (4 estudantes).
Figura 4. Nível de instrução recebido em processos e princípios de engenharia
de software
Os estudantes também reportaram quais eram as mídias preferidas por eles num
curso de ensino. Eles podiam escolher um ou vários itens da lista. O item preferido por
eles foram laboratórios (10 escolhas), seguido de jogos (7 escolhas), depois tutoriais (6
escolhas), finalmente palestras (4 escolhas). Casos de estudo baseados em artigos e
outros não foram escolhidos.
Algumas perguntas abertas foram formuladas (Tabela 1) dentro das respostas
fornecidas pelos estudantes queremos ressaltar: Na pergunta um (1) sobre os objetivos
dentro do jogo, os estudantes reportaram que o jogo passa a ideia de desenvolvimento
de software e suas dificuldades, além do conceito da contratação e representação de
possíveis eventos que podem acontecer nos projetos. Para a pergunta dois (2) sobre o
objetivo do jogo, eles identificaram este como: otimizar o processo de desenvolvimento
de um projeto, minimizar riscos e visar a entrega no menor tempo possível e com
qualidade. Na pergunta três (3) eles identificaram os processos de análise, modelagem e
codificação. Na pergunta quatro (4) sobre que aspectos da vida real foram identificados
dentro do jogo, forma obtidas as seguintes repostas: o jogo reflete aspectos humanos dos
engenheiros de software, e essas características podem afetar positiva e negativamente
os projetos; o uso da internet de forma inadequada; planejar e fazer testes são elementos
fundamentais para um bom desenvolvimento; e o jogo passa a ideia do processo de
criação de um software. Na pergunta cinco (5) os estudantes falaram que jogos podem
24
ser usados para analisar riscos de projeto e que do jogo eles levariam para sua vida
profissional os conceitos de processo, preocupação com inspeção e a importância de
testar os softwares. Na pergunta seis (6), os seguintes aspectos colaborativos foram
identificados: trabalhar em equipe para desenvolver um software; colaborar para atribuir
problemas aos outros; e colaborar na solução dos próprios problemas. Além disso, eles
observaram que trabalhar em equipe ajuda a pensar em vários alternativas de solução e a
discutir com os colegas qual é a melhor decisão a ser tomada. Na pergunta sete (7) os
aspectos de competitividade identificados foram: terminar o projeto quanto antes;
equipes mais avançadas tendem a ser prejudicadas pelas equipes em maior
desvantagens; retardar o desenvolvimento do adversário. Na pergunta oito (8) os
estudantes apontaram como mais motivador: o fato de enviar problemas para os
adversários, fazer inspeção e descobrir que não tinha erro (bugs), terminar o projeto
rápido, contratar um engenheiro muito bom.
Figura 5. Mídias de preferência num curso de ensino
Tabela 1. Perguntas abertas sobre o SimulES-W
Opinião sobre o SimulES-W e a atividade.
1. Descrever o objetivo dentro Jogo
2. Descrever o objetivo do Jogo
3. Descreva aspectos do desenvolvimento de software identificados no jogo
4. Descreva que elementos da vida real dos projetos de desenvolvimento foram identificados no jogo.
5. Que elementos da atividade você utilizaria no seu futuro profissional
6. Que aspectos colaborativos dentro da atividade foram identificados
7. Que aspectos de competitividade dentro da atividade foram identificados
8. Que parte da atividade foi mais motivadora
9. Que parte da atividade achou mais cansativa
10. Que melhoria faria no jogo
Em suma, com este tipo de atividade foi possível aprimorar o jogo para seu uso e
tornar os estudantes sejam mais ativos no processo de aprendizagem. Porém
acreditamos que através deste jogo esse processo pode ser mais interativo e lúdico,
estimulando a curiosidade e o trabalho em equipe, simulando de algum modo elementos
da engenharia de software na tomada de decisões e resolução de problemas. Com estas
informações recopiladas que os estudantes transmitiram através das suas opiniões, foi
considerado que o objetivo do jogo está sendo atendido.
25
4. Retroalimentação no processo evolutivo do SimulES-W
As perguntas nove (9) e dez (10) da Tabela 1 foram deixadas para esta seção, pois elas
estão diretamente relacionadas com as melhorias que podem se refletir no SimulES-W.
Além do escrito pelos estudantes há, também, aspectos observados nas atividades
consideradas nesta seção.
Na pergunta nove (9), sobre os aspectos mais cansativos da atividade, os
estudantes reportaram que a escolha do problema para ser jogado para outros jogadores
pode ser cansativo, e as rodadas e as regras parecem muito repetitivas. Assim como
também, muitos problemas fazem o jogo se atrasar. Já na pergunta (10) os estudantes
mencionaram que gostariam de ver no jogo fatores econômicos como: aquisição de um
empréstimo, financiamento por algum tipo de empresa, uso de features, open-source e
outsourcing. Estes últimos poderiam estar representados em cartas ou objetos dentro do
jogo. Os estudantes gostariam que na tela de jogar problemas ficassem visíveis,
também, os Tabuleiros Individuais dos outros jogadores e assim tornaria mais rápido a
definição de que problema enviar para os outros. Eles também falaram que as cartas
(conceito e problema) são boas, no entanto, seria mais interessante criar cartas deste tipo
que fossem mais divertidas, mais reais e aumentar a diversidade das mesmas.
Em síntese, a retroalimentação vinda das atividades aqui apresentadas tem
influenciando diretamente a tomada de decisões para a melhoria e atualização do jogo,
como resultado temos considerado as seguintes melhorias: (i) os jogadores devem jogar
no mínimo em dupla. Assim fica mais interessante a atividade, pois os jogadores
discutem entre eles os conteúdos das cartas e também fica menos tediosa a espera dos
jogadores e, com efeito, eles ficam discutindo as possibilidades e analisando as cartas
até chegar sua vez. Além de se identificar que nas atividades com o SimulES-W os
jogadores preferem aprender cooperando entre eles. (ii) o número de problemas que um
jogador esteja atendendo não deve ser maior do que dois, assim como também a
quantidade de problemas que possa enviar para os outros não deve ser superior a essa
mesma quantidade, ou seja, limitar a dois problemas a serem submetidos por jogador.
De fato, enviar problemas e atender problemas demora muito a rodada de conceitos e os
outros jogadores ficam parados aguardando para realizar suas jogadas. (iii) Por ultimo,
se deveria ter a possibilidade que o engenheiro de software contratado possa ser
utilizado imediatamente depois de ele ser contratado e não ter que aguardar até a
próxima rodada.
5. Conclusões e Trabalhos Futuros
Um dos processos menos usados dentro da avaliação educativa é a retroalimentação.
Isso é compreensível pois se deve levar em consideração uma quantidade importante de
itens. Sem retroalimentação não é possível identificar se estamos no rumo certo. Por
conseguinte, com o uso de SimulES-W desde sua concepção até a data de hoje foi
identificado que a retroalimentação é um mecanismo vital que ajuda na validação se os
objetivos planejados estão sendo conseguidos. Além demais, essa atividade tem
permitido aperfeiçoar e corrigir elementos da ferramenta e da atividade que envolvem
ele.
Assim a retroalimentação deveria ser um processo permanente no contexto de
ensino-aprendizagem, O uso de jogos possibilita que a retroalimentação seja realizada
26
pelos estudantes, servindo de mecanismo de melhoria no processo de ensino. Avaliar a
qualidade do ensino é difícil, no entanto, jogos podem ser usados pelos estudantes para
expressar a eficácia e propor melhorias naquelas atividades que eles participam. Os
estudantes se sentem agradecidos quando são estimulados a fornecer suas opiniões sem
dificuldades em externá-las pois estão numa atividade lúdica.
Referências
Baker, A. (2003). “Problems and Programmers”. Honors Thesis, Department of
Informatics, School of Information and Computer Science, University of California,
Irvine, CA.
Birkhoelzer, T., Navarro, E. e Van Der Hoek, A. (2005). “Teaching by Modeling instead
of by Models”, Proceedings of the 6th International Workshop on Software Process
Simulation and Modeling, MO.
Claypool, K. e Claypool, M. (2005). “Teaching software engineering through game
design”. ACM SIGCSE Bulletin, v.37 n.3.
Figueiredo, Eduardo; Lobato, Cidiane; Dias, Klessis; Leite, Julio e Lucena, Carlos.
(2007). “Um Jogo para o Ensino de Engenharia de Software Centrado na Perspectiva
de Evolução” em Workshop sobre Educação em Computação (WEI – 2007), 15, Rio
de Janeiro, , 37-46.
Jain, A. e Boehm, B. (2006). “SimVBSE: Developing a Game for Value-Based
Software Engineering. Proceedings 19th Conference on Software Engineering
Education and Training”. 103 -114.
Monsalve, E. S. (2010), “Construindo um Jogo Educacional com Modelagem
Intencional Apoiado em Princípios de Transparência”, Dissertação de Mestrado,
PUC–Rio, Março de 2010.
Monsalve, E.; Werneck, V.; Leite, J.C.S.P. (2010a), “Evolución de un Juego
Educacional de Ingeniería de Software a través de Técnicas de Elicitación de
Requisitos”, Proceedings of XIII Workshop on Requirements Engineering
(WER’2010), Cuenca, Ecuador, Abril 2010, 12–23.
Monsalve, E.; Werneck, V.; Leite, J.C.S.P. (2010b). SimulES-W: Um Jogo para o
Ensino de Engenharia de Software. FEES, SBES, Bahia.
Monsalve, E., Werneck, V. & Leite, J.C.S.P. (2011). Teaching Software Engineering
with SimulESW. Proceedings of XXIV Conference on Software Engineering
Education and Training (CSEE&T 2011), Hawaii, USA. (pp. 31–40).
Pressman, Roger (2006). “Software Engineering: A Practitioner's Approach”, 7ª Edição,
Mc Graw Hill.
Serrano, M.; Serrano, M.; Napolitano, B.; Soares, B. (2007). “Evolução do SimulES
Versão 2.0”, Monografia em Ciências da Computação, Departamento de Informática.
PUC–Rio.
Software Engineering Simulation by Animated Models (SESAM) (2009), Stuttgart,
Alemanha,
Disponível
em:
<http://www.iste.unistuttgart.de/se/research/sesam/overview/index_e.html> acesso em 7 de abril.
Sweedyk, Elizabeth e Keller, Robert M., (2005), “Fun and games: a new software
engineering course”, Proceedings of the 10th annual SIGCSE.
27
Jogos digitais como instrumentos no processo de avaliação
formativa da aprendizagem na disciplina de Engenharia de
Software
Glauber G. de Araujo1, Eduardo Henrique da S. Aranha1
1
Departamento de Informática e Matemática Aplicada (DIMAp) – Universidade Federal
do Rio Grande do Norte (UFRN)
Avenida Senador Salgado Filho, 3000 - 59072-970 - Natal, RN – Brasil
[email protected], [email protected]
Abstract. Formative assessment of learning is a process that verifies that the
pedagogical actions have produced effective results in apprentices. However,
some teachers under the argument of complexity reject this evaluation
function. In addition, its conventional instrumentation becomes an obstacle
with the tedious forms and difficult logistics. The practice in the teaching of
software engineering is not different from the others and has difficulties in this
aspect. In this sense, this paper presents a proposal for formative assessment
Instrumentation in games as an effort to discuss solutions to the problems
presented. This proposal was instantiated as a proof of concept and still needs
evaluations through experiments.
Resumo. A avaliação formativa da aprendizagem é um processo que verifica
se as ações pedagógicas produziram resultados nos aprendizes. Entretanto,
essa avaliação é rejeitada por muitos professores por serem complexas. Além
disso, sua instrumentação convencional torna-se um entrave com seus
formulários maçantes e de logística difícil. A prática no ensino de engenharia
de software não é diferente das demais e também tem suas dificuldades nesse
aspecto. Nesse sentido, este artigo apresenta uma proposta de instrumentação
da avaliação formativa em jogos digitais como um esforço de discutir soluções
para a problemática apresentada. Essa proposta foi instanciada apenas como
prova de conceito e necessita ainda ser avaliada através de experimentos.
1. Introdução
No contexto da Educação, a construção do conhecimento do aprendiz precisa ser
regulada a partir de uma avaliação da sua formação ao longo do processo ensinoaprendizagem [Perrenoud, 1999]. A regulação da aprendizagem é um modo de garantir
que o aprendiz receba o apoio do professor para sanar possíveis deficiências de
aprendizagem ainda durante o processo de ensino-aprendizagem mediante informações
coletadas das avaliações formativas [Perrenoud, 1999].
Até a aferição dos resultados dessa avaliação, é necessário um acompanhamento
qualitativo, que no contexto de qualquer ação pedagógica, deve ser contínua e
sistemática, concentrando-se especialmente nas funções da avaliação com concepções
centradas na melhoria do processo ensino-aprendizagem [Jorba; Sanmarti, 2003].
28
Não obstante, alguns obstáculos dificultam a avaliação formativa, como as
avaliações que se preocupam apenas com a classificação conceitual dos aprendizes e são
estas as mais arraigadas entre os professores [Hadji, 2001]. Sob outro ângulo, faltam aos
professores recursos pedagógicos suficientemente diversificados que os auxiliem na
geração de dados e tempo para interpretá-los, como também a realização das
intervenções regulatórias no momento apropriado [Perrenoud, 1999; Quinquer, 2003].
Avaliar sistematicamente durante todo o processo ensino-aprendizagem não é
uma tarefa fácil, ainda mais avaliar individualmente os aprendizes, em meio a turmas
grandes e heterogêneas. Ademais, avaliar ainda é a "prática pedagógica que menos
motiva os professores e mais aborrece", "ao mesmo tempo que para os alunos é a
atividade mais temida e menos gratificante" [Veslin apud Jorba, Sanmarti, 2003].
A instrumentação convencional da avaliação formativa é também um entrave à
sua prática. Entende-se por instrumentação todos os meios que geram dados de
conhecimento do aprendiz, como provas, portfólios, entrevistas, relatórios e
questionários. O processo realizado com questionários impressos, por exemplo,
aplicados várias vezes ao longo do período letivo, são maçantes para os aprendizes e
têm uma logística difícil para o professor.
Nesse contexto de busca por superação dos entraves à avaliação formativa, há
iniciativas que a aplicam em ambiente computacional (presencial e a distância) que
conseguem atender à dinâmica desse tipo de avaliação minimizando o problema da
complexa logística do processo. Ainda assim, essas iniciativas continuam sendo
cansativas, porque apenas transportam o questionário impresso para um computador.
Essa problemática motivou um estudo organizado em duas etapas. A primeira no
mestrado, no qual foi desenvolvido um framework conceitual, instanciado apenas como
prova de conceito, no domínio da avaliação da aprendizagem, para apoiar avaliações
formativas da aquisição de conhecimento instrumentadas em jogos digitais. A segunda
no doutorado, no qual serão desenvolvidos os jogos digitais e realizados os
experimentos e estudos de casos para verificar e validar a consistência do framework.
A prática pedagógica no contexto do ensino de engenharia de software não é
diferente das demais e também tem suas dificuldades. O ensino é fundamentado em
“apresentar e vivenciar os principais conceitos e práticas utilizadas e estudadas na área
[...] fornecendo uma visão geral de como desenvolver softwares sistematicamente”. A
realização de trabalhos práticos que queiram “abranger todas ou grande parte das
técnicas difundidas [...] é além de impraticável, tedioso [SILVA, 2004].
Nesse sentido a área necessita de abordagens que apoiem a avaliação da
aprendizagem dos alunos de modo sistemático e contínuo, mas também que reduza o
tédio ao qual estão expostos os aprendizes devido ao grande volume de informações que
precisam assimilar e formas de avaliação maçantes e nada estimulantes.
O framework, ora proposto, une a instrumentação da avaliação formativa em
ambiente computacional com os elementos lúdicos presentes nos jogos digitais. A
finalidade é tornar a tarefa de avaliar a formação na disciplina de engenharia de software
mais estimulante para o aprendiz e mais factível para o professor. Mais estimulante
porque permite a imersão dos alunos em jogos que oferecem desafios constantes, que
quando solucionados classificam o aluno em um ranking visível a todos do grupo. É
29
mais factível para o professor porque não baseia a avaliação cotidiana somente em
aspectos intuitivos e subjetivos, presentes na observação em sala de aula.
Para a melhor compreensão do contexto onde se insere esse artigo, seguem os
fundamentos teóricos que o norteiam.
1.1. Avaliação da aprendizagem
Para avaliar é necessário ter clareza do que fazer com as informações que são coletadas
no processo, fazendo da avaliação e da tomada de decisões a partir dos resultados,
questões-chaves para melhorar o conhecimento dos aprendizes [Parcerisa, 2003].
Embora a avaliação ainda seja amplamente utilizada apenas como instrumento
de medição para seleção e classificação, crescem as concepções que defendem outra
lógica emergente da avaliação, e a concebem com a finalidade de "ajudar a melhorar o
processo de aprendizagem dos alunos e ser útil para aprimorar o ensino" [Parcerisa,
2003].
Nesse sentido, Jorba e Sanmarti (2003) defende que a avaliação tem duas
funções básicas: (a) uma de seleção e classificação, que ocorre depois do ensino,
conhecida como somativa; (b) outra de ajuste do processo de ensino-aprendizagem, de
reconhecimento das mudanças, representadas por duas avaliações conhecidas por
diagnóstica e formativa e que ocorrem antes e durante o ensino, respectivamente.
A avaliação formativa da aprendizagem gera dados úteis para a adequação das
atividades de ensino-aprendizagem às necessidades dos aprendizes [Jorba, Sanmarti,
2003] e, dessa maneira, melhora a qualidade do ensino, aproximando-se mais das
necessidades de cada aluno, considerando a sua singularidade, procurando superar a
perspectiva de um modelo de ensino "tamanho único" que é demais para alguns e
insuficiente para outros.
1.2. Aprendizado baseado em jogos digitais
As concepções sobre jogos são várias e abordam desde elementos de entretenimento,
passando por elementos pedagógicos até elementos culturais.
A história da contribuição dos jogos nas outras áreas do conhecimento é longa e
continua com maior ênfase com os jogos digitais suportados pelas novas tecnologias,
não só com o apoio lúdico, como também com o apoio computacional e mais
recentemente com o apoio na concepção de projetos (por exemplo, administração e
educação) através dos princípios que regem o desenvolvimento e o funcionamento dos
jogos: a gamificação. Entende-se por gamificação a aplicação das dinâmicas de jogos a
situações cotidianas das áreas do conhecimento.
Nesse sentido, jogos digitais podem ser mediadores de aprendizagem e podem
contribuir para o despertar de competências, habilidades e melhor compreensão dos
conteúdos em diversas áreas. Para Huizinga (2000), "todo jogo é capaz, a qualquer
momento, de absorver inteiramente o jogador" em uma espécie de imersão, o que
Caillois (1990) corrobora afirmando que "o jogo é essencialmente uma ocupação
separada, cuidadosamente isolada do resto da existência".
30
Segundo Mattar (2010), jogar games "desenvolve a capacidade de deduzir regras
pela observação e manipular sistemas complexos, características essenciais para o
trabalho em ciências". A atenção e o raciocínio lógico, principalmente em jogos de
estratégia, são também elementos estimulados com o uso de jogos digitais. O exercício
da atenção nos jogos provoca a imersão do jogador, um estado de extrema concentração
na tarefa que está desempenhando.
2. Trabalhos correlatos
Uma pesquisa bibliográfica foi realizada no sentido de localizar trabalhos que tratassem
especificamente sobre avaliação formativa e jogos digitais. Um total de vinte e cinco
trabalhos entre artigos e iniciativas foram encontrados com títulos apontando nessa
direção. Contudo, ao ler os resumos, apenas três artigos foram selecionados [Araujo,
2013], como segue:
O trabalho desenvolvido por Cuomo (2011) “Full Formative Assessment based
on Educacional Video Games”, trata de uma portal na internet (PlayLearn) para
exploração de jogos educativos a longo prazo e testes online. O portal registra os
parâmetros de aprendizagem para análise em tempo real pelos professores com o
objetivo de melhorar o processo de aprendizagem. O jogo é baseado na "jornada do
herói", no qual o personagem do jogador deve recolher diamantes ao longo da jornada
enquanto responde a questões sobre o conteúdo estudado.
Em “Web-based quiz-game-like formative assessment: Development and
evaluation” [Wang, 2007], é apresentado um sistema de múltipla escolha baseada em
Web quiz-jogo como avaliação formativa chamado de GAM-WATA. Também compara
a eficácia de três diferentes tipos de avaliação formativa em um ambiente de e-Learning:
teste de papel e lápis (PPT), teste normal baseado na Web (NWBT) e GAM-WATA.
Participaram da pesquisa 165 alunos do ensino fundamental em Taiwan central.
Gonçalves (2011), em seu trabalho “Avaliação da aprendizagem em
Experimentos com Jogo educativo de engenharia de requisitos”, apresenta uma forma de
avaliar alunos de engenharia de requisitos utilizando o jogo educativo ilha dos
requisitos. O objetivo do jogo é ajudar o personagem, a fugir da ilha dos requisitos −
uma ilha habitada por tribos canibais que tem um vulcão prestes a entrar em erupção. O
jogador deve enfrentar uma série de desafios relacionados ao conteúdo da disciplina de
engenharia de requisitos. Para avaliar as hipóteses sobre a efetividade de aprendizagem
do jogo a pesquisa se utiliza do teste estatístico não paramétrico de Mann-Whitney.
Os artigos analisados tratam de avaliação formativa utilizando jogos, mas não
definem um método sistemático que qualifica e mede a aquisição de conhecimento dos
alunos de modo a subsidiar as ações do professor. É nesse ponto que o framework, ora
proposto, pode contribuir com essa discussão de um modo efetivo.
Outros artigos foram encontrados com o contexto próximo ao pesquisado, como
os relacionados a seguir:
 O ludismo e avaliação da aprendizagem: possibilidades para o ensino de
química [Cavalcanti, 2010].
 A evolução dos jogos de física, a avaliação formativa e a prática reflexiva do
professor [Ferreira; Carvalho, 2004].
31

Avaliação da aprendizagem por meio do jogo didático "Jogando Limpo",
nas aulas de Ciências [Souza-Lomba et al, 2010].
Tratam apenas da aprendizagem baseada em jogos, seja refletindo sobre as
possibilidades ou apresentando experiências com a sua utilização. O foco maior é no
ensino de conteúdos por meio do jogo digital sem um procedimento claro sobre a
avaliação da aprendizagem.
3. Framework conceitual de avaliação formativa
Com base nos estudos de IHC (Interação Humano Computador), um framework
conceitual é um conjunto de ideias e conceitos que se inter-relacionam para descrever
como um sistema deve se comportar, se parecer e ser compreendido pelos usuários da
maneira pretendida [Preece et al, 2005].
O framework conceitual, ora proposto, apoia a instrumentação da avaliação
formativa no ambiente computacional do jogo digital. Sua função é sistematizar o
processo de avaliação de modo que respostas, competências e habilidades dos alunos
sejam coletadas e analisadas para subsidiar as ações pedagógicas do professor. Sua
estrutura consiste em quatro componentes que desempenham funções específicas que se
inter-relacionam em um fluxo cíclico contínuo: (a) instrumentar; (b) coletar; (c) analisar
e; (d) regular, conforme são descritos a seguir.
3.1 Instrumentar
Instrumentar é o componente que consiste na forma do questionamento aos aprendizes e
do registro das respostas. Pode explorar os vários tipos de instrumentos avaliativos
conhecidos que se adaptam às situações de ensino e de aprendizagem propostas pelo
professor, como também pode explorar os vários gêneros de jogos digitais como
instrumentos de verificação de competências e habilidades.
A forma de questionamento pode ser explícita ou tácita. A primeira estimula
respostas diretas do aprendiz por meio de questões acerca do conteúdo estudado.
Consiste de alguns tipos de instrumentações convencionais, como provas, entrevistas e
questionários.
A segunda forma captura “respostas” do aprendiz sem que este seja questionado
diretamente sobre qualquer conteúdo estudado. Consiste no uso de alguns gêneros de
jogos (por exemplo: Casuais, Simulação, Esportes, Adventure, RPG, Estratégia, Puzzle)
que estimulam a prática de habilidades capazes de expressar competências para a
solução de desafios nos domínios da linguagem, da matemática e dos fenômenos
naturais, bem como o enfrentamento de situações-problema, a construção de
argumentações consistentes e a elaboração de propostas que atentem para as questões
sociais, como preconizam os Parâmetros Curriculares Nacionais [BRASIL, 1997].
3.2 Coletar
Coletar é o componente que consiste na captura das respostas registradas pelo
instrumento de avaliação. A coleta é realizada mediante o atendimento a critérios que
expressam os objetivos almejados pelo professor e as respostas coletadas precisam ser
valoradas segundo indicadores quantificadores que expressam os critérios.
32
O processo inicia pela definição da relação entre as capacitações do domínio do
conhecimento e do domínio dos processos cognitivos, conforme a taxonomia de Bloom
revisada [Anderson et al, 2001], chamada de critério formativo [Araujo, 2013].
O critério formativo deve expressar qualitativamente os objetivos pedagógicos
almejados pelo professor. Por exemplo, para o objetivo no qual o aluno deverá ser capaz
de: Reconhecer os aspectos da qualidade de um software, o critério formativo emitido
será: Estabelecer relações entre os aspectos da qualidade e as métricas de software
utilizadas no processo de engenharia e controle de qualidade e entre suas partes que as
fazem funcionar em conjunto (conceitual) por meio do domínio sobre a produção da
informação certa a partir da memória (lembrar) [Araujo, 2013].
A segunda etapa do processo é a definição dos indicadores formativos que
quantificam os critérios formativos emitidos a partir das respostas coletadas nas formas
de questionamentos. Por exemplo, a partir das respostas coletadas no instrumento de
avaliação “questionário” os indicadores formativos que atendem ao critério formativo
no exemplo anterior podem ser: Número de erros, Número de acertos, Número de
acertos consecutivos e Número de abstenções [Araujo, 2013].
3.3 Analisar
O componente analisar é fundamental para verificar se os dados coletados conforme os
critérios e indicadores formativos e submetidos às métricas expressam e como
expressam a aquisição de conhecimento dos alunos.
As métricas utilizadas devem ser capazes de analisar os indicadores definidos
para cada critério formativo submetido e encontrar resultados que sejam legíveis para o
professor, que é o analista desses dados.
Por exemplo, analisando os números de acertos e erros coletados no exemplo
anterior e considerando que questões acerca dos conceitos-chaves estudados (por
exemplo: qualidade de um software) aparecem repetidamente em todas as atividades de
avaliação formativa desenvolvidas pelo professor, pode-se verificar por meio de gráficos
a evolução da aquisição do conhecimento individual e em grupo dos alunos naqueles
conceitos-chaves ao longo do processo ensino-aprendizagem. Desde que as medidas de
desempenhos dos alunos nas atividades tenham sido ponderadas.
3.4 Regular
A regulação da aprendizagem é desenvolvida pelo professor a partir dos resultados
emitidos pelas análises de dados realizadas, com a finalidade de sanar possíveis
deficiências detectadas em tempo de processo ensino-aprendizagem. Alguns relatórios
orientam as ações do professor no sentido de reverter essas deficiências. As ações
pedagógicas ainda durante o processo ensino-aprendizagem é vital para que o aprendiz
não chegue ao final do período letivo com acúmulos de dificuldades nos conceitos.
3.5 Ambiente computacional do Jogo Digital
O jogo digital é o ambiente computacional que apoia o instrumento de avaliação
formativa em suas duas formas de questionamento. Fornece a ele não só os recursos
computacionais como também o ambiente lúdico para a imersão do aprendiz e permite a
33
coleta de dados da interação do jogador com o jogo e do desempenho do aprendiz nas
soluções dadas nas formas de questionamentos.
Em tese, qualquer gênero de jogo digital pode ser utilizado para instrumentação
de avaliações formativas. O framework, ora proposto, pode orientar a concepção de
jogos digitais quando incluído no seu projeto de desenvolvimento.
4. Conclusão
A pesquisa ora apresentada surge na interface entre ciência da computação e a
educação. Compreende, por um lado, a importância dos jogos digitais no contexto
educacional, tendo em vista a estreita relação dos aprendizes com o universo das
tecnologias da informação e da comunicação na atualidade. Por outro, evidencia as
dificuldades em se avaliar continuamente o conhecimento, considerando o universo
complexo, amplo e heterogêneo de alunos, com os quais os educadores têm que lidar
cotidianamente. Assim sendo, o presente artigo destaca um aspecto da pesquisa cujo
intuito é contribuir para o trabalho de avaliação do professor durante suas ações
pedagógicas na área de engenharia de software, a fim de que o processo ensinoaprendizagem obtenha resultados mais coerentes com os seus propósitos iniciais.
Com base nos pesquisadores da área da educação, fica clara a complexidade do
ato de avaliar continuamente. Para o enfrentamento de um aspecto tão importante
quanto difícil do processo ensino-aprendizagem, é necessária a utilização de várias
ferramentas. Para tanto, é preciso destacar que nessa pesquisa, envolvem-se a concepção
de um framework conceitual que se propõe a apoiar jogos digitais contendo
instrumentos de avaliação. A intenção é que, trabalhado com uma metodologia que
envolva várias ferramentas, auxilie o professor a melhorar a qualidade e o controle do
nível de aquisição de conhecimento dos alunos, uma vez que será possível mensurar, de
forma não manual, o domínio dos conceitos-chaves que ele, professor, definiu como
importante para os seus aprendizes internalizarem.
O conjunto de conceitos propostos no framework, integrados ao instrumento de
avaliação formativa utilizados em jogos digitais podem contribuir para romper com as
dificuldades frequentes relacionadas pelos professores na medida em que conseguem dá
a esses professores informações efetivas acerca do conhecimento dos seus alunos
individualmente e antes que finde o período letivo, ou seja, no decorrer do processo
ensino-aprendizagem, que de fato é o momento no qual essas informações fazem mais
sentido e efeito.
5. Referências Bibliográficas
ANDERSON et al. A Taxonomy for Learning, Teaching and Assessing: a revision of
Bloom's taxonomy of educational objectives. New York: Addison Wesley Longman,
2001.
ARAUJO, Glauber G. Um Framework Conceitual para apoiar a instrumentação da
Avaliação Formativa da Aprendizagem em Jogos Digitais. 2013. Dissertação de
Mestrado – Universidade Federal do Rio Grande do Norte, Natal.
BRASIL. Secretaria de Educação Fundamental. Introdução ao parâmetros curriculares
nacionais. Brasília: MEC/SEF, 1997.
34
CAILLOIS, Roger. Os jogos e os Homens. trad. José Garcez Palha. Lisboa: Edições
Cotovia, 1990.
CAVALCANTI, Eduardo L. D. et al. O ludismo e avaliação da aprendizagem:
possibilidades para o ensino de química. In: XV Encontro Nacional de Ensino de
Química (XV ENEQ). Brasília: UNB, 2010.
CUOMO, Salvatore et al. Full Formative Assessment based on Educacional Video
Games. 2011. Disponível em: http://weblab.dmi.unisa.it/weblab/images/.../det102.pdf. Acesso em: 26/01/2013.
FERREIRA, Marli Cardoso; CARVALHO, Lizete Maria Orquiza. A evolução dos jogos
de Física, a avaliação formativa e a prática reflexiva do professor. Revista Brasileira
de Ensino de Física, v. 26, n. 1, p. 57-61 (2004).
GONÇALVES, Rafael Q. et al. Avaliação da aprendizagem em Experimentos com Jogo
educativo
de
engenharia
de
requisitos.
2011.
Disponível
em:
http://www.lbd.dcc.ufmg.br/colecoes/sbqs/2011/SBQS2011-TT14_82900_1.pdf.
Acesso em: 19/06/2012.
HADJI,C. Avaliação desmistificada. Porto Alegre: Artes Médicas, 2001.
HUIZINGA, Johan. Homo Ludens. trad. João Paulo Monteiro. São Paulo: Ed.
Perspectiva, 2000.
JORBA, Jaume; SANMARTÍ, Neus. A função pedagógica da avaliação. In:
BALLESTER, Margarida (Org.). Avaliação como apoio à aprendizagem. trad.
Valério Campos. Porto Alegre: Artmed, 2003. Pág. 23-45.
MATTAR, João. Games em Educação: Como os nativos digitais aprendem. São Paulo:
Editora Pearson Prentice Hall, 2010.
PARCERISA, Artur. Introdução. In: BALLESTER, Margarida (Org.). Avaliação como
apoio à aprendizagem. trad. Valério Campos. Porto Alegre: Artmed, 2003. Pág. 11.
PERRENOUD, Philippe. Avaliação: da excelência à regulação das aprendizagens entre duas lógicas. trad. Patrícia Chittoni Ramos. Porto Alegre: Artmed, 1999.
PREECE, J.; ROGERS, I.; SHARP, H. Design de Interação: Além da Interação
Humano-Computador; Porto Alegre: Bookman, 2005.
QUINQUER, Dolors. Modelos e enfoques sobre a avaliação: O modelo comunicativo.
In: BALLESTER, Margarida (Org.). Avaliação como apoio à aprendizagem. trad.
Valério Campos. Porto Alegre: Artmed, 2003. Págs. 15-22.
SILVA, Lyrene F.; LEITE, Julio Cesar S. do Prado; BREITMAN, Karin K. Ensino de
Engenharia de Software: Relato de Experiências. In: XII WEI-Workshop de
Educação em Informática (XXIV SBC). Salvador: UFBA, 2004.
SOUZA-LOMBA Fernanda Cristina M. et al. Avaliação da aprendizagem por meio do
jogo didático "Jogando Limpo", nas aulas de Ciências. In: II Congresso Internacional
de Educação. Ponta Grossa: 2010.
WANG, Tzu-Hua. Web-based quiz-game-like formative assessment: Developmet and
avaluation. 2007. Disponível em: http://www.sciencedirect.com/science/article/.
Acesso em: 26/03/2013.
35
Uma Abordagem para o Ensino de Engenharia de Software no
Desenvolvimento de Jogos Digitais
Emanuel Ferreira Coutinho1 , Carla Ilane Moreira Bezerra2
1
Instituto UFC Virtual
Universidade Federal do Ceará (UFC)
Fortaleza – CE – Brasil
2
Universidade Federal do Ceará (UFC)
Quixadá – CE – Brasil
[email protected],[email protected]
Abstract. The discipline of Software Engineering is commonly taught in undergraduate courses in areas related to Computer Science. However the way in
which it is taught is not often adherent to certain kinds of developments, such
as digital games. The development of digital games has got peculiarities that
usually are not found in books on Software Engineering, as the Game Design
Document (GDD) and the platforms aware development style. In this context,
this work proposes an approach to facilitate the teaching of Software Engineering for digital game development, with a focus on engineering and management
activities. Finally, an evaluation of the approach is performed in a Software Engineering course.
Resumo. A disciplina de Engenharia de Software é comumente ministrada em
cursos de graduação de áreas relacionadas à Ciência da Computação. Porém
muitas vezes a maneira na qual ela é ministrada não se adere a certo tipos de
desenvolvimentos, como é o caso dos jogos digitais. O desenvolvimento de jogos
digitais possui peculiaridades que normalmente não encontradas nos livros de
Engenharia de Software, como o Game Design Document (GDD) e o estilo de
desenvolvimento orientado à plataformas. Neste contexto, este trabalho propõe
uma abordagem para facilitar o ensino de Engenharia de Software no desenvolvimento de jogos digitais, com foco nas atividades de engenharia e gestão. Ao
final do trabalho, é realizada uma avaliação da abordagem na aplicação desta
em uma disciplina de Engenharia de Software.
1. Introdução
Engenharia de Software é uma disciplina normalmente ministrada em cursos de
computação. Muitas vezes essa disciplina é ministrada de maneira tradicional, como
normalmente é descrito em [Sommerville 2011] e [Pressman 2011], referências básicas
geralmente adotadas nestes cursos.
Porém, a maneira na qual é ministrada atualmente a disciplina de Engenharia de
Software muitas vezes se adéqua apenas a ciclos de vida mais tradicionais como o cascata.
O desenvolvimento de outros sistemas, por exemplo jogos digitais, não se adéqua à metodologia de ensino tradicional de Engenharia de Software. Sendo assim, uma adaptação
36
para o ensino de Engenharia de Software para o desenvolvimento de jogos digitais é necessária para a correta adequação à realidade desse tipo de desenvolvimento.
Neste contexto, este artigo propõe uma abordagem para o ensino de Engenharia
de Software no desenvolvimento de jogos digitais. Não é intenção deste trabalho elaborar uma metodologia para o desenvolvimento de jogos digitais que resolva todas as
peculiaridades deste tipo de produto, e sim apenas facilitar o entendimento dos conceitos
de Engenharia de Software de forma aplicada a esse tipo de desenvolvimento, focando
apenas no ensino.
O presente trabalho possui a seguinte estrutura, além desta introdução: na Seção
2, trabalhos relacionados são discutidos, a abordagem proposta é descrita na Seção 3, na
Seção 4 uma avaliação da abordagem é apresentada, e finalmente na Seção 5, conclusões
e trabalhos futuros são apresentados.
2. Trabalhos Relacionados
Diversas ferramentas foram propostas para o ensino de alguma atividade de Engenharia
de Software, mas poucas são relacionadas ao desenvolvimento de jogos digitais. Em
[Sousa et al. 2012] uma ferramenta, o iTestLearning, foi desenvolvida para ensinar sobre
especificamente a atividade de testes. Nesta ferramenta o objetivo é o aprendizado das
atividades de um processo de testes de software.
Em [Morales and Nelson 2007] foi proposto um processo de desenvolvimento de
jogos móveis de acordo com o processo de design de jogos. Dessa forma, o processo
funciona mais como um guia de criação de jogos móveis do que um processo de desenvolvimento propriamente dito. O processo de desenvolvimento do produto integrado é
composto de cinco passos, os quais são: 1) geração e avaliação de idéias; 2) desenvolvimento de modelo de negócios e caso de negócios; 3) aspectos legais; 4) projeto de pesquisa de mercado e experiência do usuário e 5) Implementação. Os testes são realizados
na fase de implementação onde o software é construı́do. Uma lista com os dispositivos
móveis relevantes para o mercado alvo é elaborada desde cedo no projeto. Dessa forma,
os testes são feitos diretamente nos dispositivos móveis alvo e conduzidos por planos de
teste padronizados e protocolos de testes.
Outro trabalho identificado na literatura descreve o uso de desenvolvimento de jogos móveis como ferramenta motivacional para envolver os alunos no inı́cio de cursos de
computação, descrevendo uma abordagem para desenvolvimento. Isso porque, segundo
os autores, comparado ao desenvolvimento de jogo tradicional, a programação de jogos
móveis é menos complexa, permitindo alunos com pouca experiência em programação
criar jogos móveis [Kurkovsky 2009].
Em [Rodrigues et al. 2010] é apresentada uma proposta de Modelo de Processo
para o desenvolvimento de jogos para aplicação na área de saúde para desenvolver um
serious game para educação em higiene bucal de adulto. O modelo de processo desenvolvido se baseia na estrutura do RUP e possui um conjunto de quatro fases (Concepção, PréProdução, Produção e Pós-Produção) e dez disciplinas, estas divididas em sete disciplinas
de criação (Análise de Mercado, Projeto Pedagógico-Educacional, Game Design, Projeto
Técnico, Implementação, Teste e Distribuição) e três disciplinas de apoio (Gerência de
Configuração e Mudanças, Gerência de Projeto e Ambiente).
37
3. Abordagem para o Ensino de Engenharia de Software no Desenvolvimento
de Jogos Digitais
A adaptação para o ensino de Engenharia de Software visando o desenvolvimento de jogos digitais é uma atividade que depende muito do ferramental utilizado. Caracterı́sticas
de mercado muitas vezes influenciam no processo de desenvolvimento de um tipo de
software, pois muitas caracterı́sticas dos projetos são dependentes de ferramentas, plataformas de software e hardware, e prazos de lançamento de produtos. Considerando
estas restrições foi proposta neste trabalho uma abordagem para o ensino de Engenharia
de Software no desenvolvimento de jogos digitais. Nesta abordagem, diversos conceitos
tradicionais da Engenharia de Software podem ser trabalhados juntamente com as caracterı́sticas inerentes ao desenvolvimento de jogos digitais. Para a construção da abordagem
foi utilizado como base as atividades descritas por [Flynt and Salem 2005].
A abordagem tem o foco no ensino, portanto muitos pontos considerados importantes e comumente utilizados no desenvolvimento comercial não serão abordados. Sendo
assim, as atividades da abordagem são: Especificar Requisitos, Projetar Produtos, Implementar Produtos e Testar Produtos. Atividades relacionadas à gestão também serão introduzidas na abordagem, especificamente Gerenciar Projetos e Gerenciar Configuração. A
Figura 1 descreve a abordagem de maneira gráfica e ao longo do tempo.
Figura 1. Visualização da abordagem proposta em alto nı́vel
A abordagem segue um modelo de ciclo de vida cascata para facilitar a adaptação
à disciplina. Essa versão da abordagem é bastante simplificada em relação a um projeto
de desenvolvimento de software tradicional, pois possui apenas fins didáticos. Porém, a
abordagem só será aplicada após serem ministradas as aulas de ciclo de vida, modelos de
processo e fases do processo. O professor atuará como cliente, mas também agirá como
suporte ao processo e gestão. Espera-se com a realização dessas atividades que se possa
adicionar o conhecimento de Engenharia de Software ao desenvolvimento de jogos de
maneira que não mude as caracterı́sticas da área e que possa se beneficiar da utilização de
atividades básicas de Engenharia de Software.
Em geral, o desenvolvimento de jogos segue um Game Design Document (GDD).
Normalmente este documento possui elementos do ambiente, narrativa, tecnologia e
38
mecânica. Este, por sua vez, não é suficiente para o desenvolvimento tradicional de sistemas, aplicado pela Engenharia de Software. Então, na atividade Especificar Requisitos,
os alunos devem elaborar User Stories ou requisitos funcionais em alto nı́vel para complementar os requisitos do GDD.
Como o GDD não é completo do ponto de vista de projeto, alguns elementos são
adicionados para facilitar o projeto do jogo. Na atividade Projetar Produtos, um protótipo
de telas ou do próprio jogo devem ser desenvolvidos, um diagrama de atividades também
pode ser elaborado para facilitar a navegabilidade ou ações, e a arquitetura é descrita.
Muitas vezes a arquitetura é dependente da ferramenta/plataforma de desenvolvimento
utilizada no projeto, como o Unity3D1 . Nesse caso, a arquitetura acaba sendo orientada à
plataforma. No caso de uma aplicação web, a arquitetura segue as tecnologias da plataforma utilizada, como java ou C#. No caso de desenvolvimento de aplicações móveis, a
arquitetura também segue as caracterı́sticas da tecnologias envolvidas, como Android ou
iOS.
Em Implementar Produtos, o desenvolvimento dos produtos de trabalho ocorre
orientado à arquitetura definida na atividade anterior, gerando o código fonte do jogo,
testado de maneira individual (testes unitários), e as unidades integradas.
Finalmente, na atividade Testar Produtos, os produtos desenvolvidos são testados.
Os alunos realizam seus testes, e o professor testa todos os jogos desenvolvidos, a nı́vel
de testes funcionais. Para isso, casos de teste são elaborados e utilizado para realizar o
aceite final do produto.
Apenas duas atividades de gestão foram consideradas: Gerenciar Projetos e Gerenciar Configuração. Na atividade de Gerenciar Projetos, o professor juntamente com os
alunos irá elaborar o planejamento do projeto, definindo as fases e os produtos a serem
construı́dos. Cada projeto deverá definir datas de entrega parciais com produtos. O professor irá realizar um acompanhamento dos projetos semanalmente. Caso haja necessidade
de replanejamento, as datas poderão ser revistas. No caso de dificuldades, o professor poderá mediar a resolução do problema, semelhante ao gerenciamento de impedimentos do
SCRUM. Na atividade Gerenciar Configuração é utilizado o Dropbox como repositório
de artefatos, permitindo a controle de acesso através de login/senha, compartilhamento
dos artefatos, controle de versão e controle de mudanças. O produto final (jogo completo e documentação) deverá ser armazenado em pasta especı́fica para facilitar os testes.
Também deverá ser adicionado ao repositório um manual de instalação e configuração do
jogo, assim como arquivos necessários.
A Tabela 1 descreve cada uma das atividades de engenharia e gestão propostas de
maneira resumida.
4. Avaliação da Abordagem
Como estudo de caso, a abordagem foi empregada na disciplina de Engenharia de Software do curso de graduação Sistemas e Mı́dias Digitais (SMD)3 da Universidade Federal
do Ceará. O SMD possui a disciplina de Engenharia de Software para as habilitações de
Sistemas de Informação Multimı́dia (SIM) e Jogos Digitais. Para a habilitação de SIM,
1
3
Unity3D - http://unity3d.com/
Sistemas e Mı́dias Digitais - http://smd.virtual.ufc.br/
39
Tabela 1. Resumo das atividades da abordagem proposta.
Atividade
Especificar Requisitos
Projetar Produtos
Implementar Produtos
Testar Produtos
Gerência de Projetos
Gerência de Configuração
Descrição
Elaborar GDD para o projeto e adicionar algum requisito
complementar.
Desenvolver a arquitetura jogo, orientada à plataforma
de desenvolvimento.
Desenvolver os produtos especificados.
Testar os produtos desenvolvidos conforme especificados.
Elaborar o planejamento do projeto, definindo fases e
produtos a serem construı́dos.
Utilização do Dropbox2 como repositório para atividades
de gestão de configuração.
a disciplina de Engenharia de Software é idêntica a que tradicionalmente oferecida em
cursos de computação em geral. Para a habilitação em Jogos Digitais, o graduado terá
perfil de: designer de jogos, desenvolvedor de jogos para computadores e consoles de
video game, desenvolvedor de jogos para dispositivos móveis (celulares, tablets, etc), desenvolvedor de jogos para TV digital interativa, programador de sistemas para simulação
computacional, projetista de aplicações para entretenimento eletrônico, dentre outras.
A disciplina de Engenharia de Software foi ofertada no semestre 2012.2 para as
duas habilitações. Para a habilitação de SIM a abordagem não foi aplicada, pois o foco
da turma era desenvolvimento de sistemas comerciais tradicionais. Para a habilitação
de jogos a turma utilizou a abordagem. Apenas 5 alunos estavam matriculados nessa
disciplina, porém todos desenvolvem jogos digitais e já possuem experiência em projetos
de desenvolvimento de jogos digitais em plataformas diferentes.
O plano de aula da disciplina foi baseado nos cursos de Engenharia de Software e composto pelos seguitnes módulos: processos, modelos, requisitos, análise e projeto, implementação, testes, homologação, implantação, manutenção, metodologias ágeis,
gerência de configuração, gerência de projeto e gerência de qualidade.
4.1. Aplicação da Abordagem
A disciplina segue uma ementa tradicional de cursos de Engenharia de Software. Os conceitos mais utilizados foram explicados e exemplificados. Após algumas aulas os alunos
já possuiam um conhecimento mı́nimo sobre processo de software, e então a abordagem
foi apresentada.
No trabalho final da disciplina, os alunos teriam que elaborar uma documentação
alinhada com a abordagem e ter um jogo digital desenvolvido. A documentação consistia
da elaboração de um GDD com a adição de requisitos funcionais mais formalizados,
porém em alto nı́vel, a descrição da arquitetura, casos de teste, e o executável. Os alunos
teriam cerca de dois meses para cumprir todas as etapas da abordagem e também deveriam
realizar acompanhamentos com o professor semanais e utilizar gerência de configuração
no desenvolvimento.
Na atividade Especificar Requisitos todos os alunos entregaram um GDD, vari-
40
ando apenas o artefato de requisito complementar, que foram casos de uso e lista de
requisitos em alto nı́vel, geralmente uma lista com requisitos funcionais e não funcionais.
Em Projetar Produtos, os alunos entregaram a arquitetura do jogo, composta por diagramas arquiteturais com visões diferentes (visão em camadas, visão de implantação, etc).
Muitas vezes foi totalmente orientada à plataforma de desenvolvimento. Adicionalmente,
diagramas de classe foram elaborados para todos os jogos. Diagramas de sequência, atividades e telas foram desenvolvidos em alguns jogos. Na atividade Implementar Produtos,
os códigos fonte foram desenvolvidos e realizados testes de unidade. Como a maioria
dos jogos era dependente da plataforma utilizada pelos alunos, as tecnologias (linguagem
de programação, componentes e padrões) também eram limitadas ao que a plataforma
fornecia. Em Testar Produto, um pacote de instalação do jogo foi produzido. A exceção
de uma aplicação Android para celular, todos foram disponibilizados para instalação na
web. Casos de teste foram elaborados para que o professor avaliasse o jogo, assim como
manuais de instalação e configuração.
As atividades de gestão foram realizadas durante as aulas ou por email. Estas
atividades demandaram um esforço maior no inı́cio da disciplina para o planejamento
de tarefas, quais produtos seriam desenvolvidos e os prazos de entrega. Em paralelo
o ambiente de desenvolvimento foi preparado e disponibilizado no ambiente de gestão
de configuração. O Dropbox foi utilizado por todos os alunos durante a disciplina. O
acompanhamento do projeto foi orientado à produtos e tarefas, e realizado a cada aula,
com identificação de problemas, e os devidos ajustes realizados conforme necessidade.
Alguns alunos necessitaram de um acompanhamento mais rı́gido, pois tiveram dificuldade em cumprir os prazos estabelecidos e dificuldade na elaboração de alguns artefatos.
Porém, essas dificuldades foram resolvidas com a elaboração de artefatos alternativos que
descreviam aspectos estáticos e dinâmicos do jogo.
A Figura 2 exibe alguns jogos desenvolvidos pelos alunos durante a disciplina.
Figura 2. Jogos desenvolvidos na disciplina
4.2. Dificuldades e Lições Aprendidas
A experiência de utilizar uma abordagem adaptada ao desenvolvimento de jogos digitais
permitiu identificar diversos benefı́cios e dificuldades conforme os itens descritos a seguir:
• Atividades da Engenharia de Software: O desenvolvimento de jogos baseado
em um GDD é mais narrativo do que gráfico. Assim, alguns aspectos da Engenharia de Software são perdidos. Alguns alunos trabalham em empresas de desenvolvimento de jogos, e não se sentiram confortáveis com alguns artefatos, como
casos de uso e cronogramas. No inı́cio da disciplina os alunos sentiram dificuldades em relação aos modelos de ciclo de vida. Devido aos alunos serem usuários
41
de ferramentas de desenvolvimento de jogos, com foco em programação, eles não
entendiam a utilidade da documentação de requisitos funcionais e não funcionais.
Uma dificuldade que os alunos tiveram foi a descrição da arquitetura dos jogos
quando mudava a plataforma das quais eles estavam acostumados a desenvolver.
Uma prática comum no deenvolvimento de jogos são testes parciais (“beta” ou
“demo”). Percebeu-se que o processo de implantação de um jogo pode ser ajustado como ocorre atualmente em muitas plataformas de desenvolvimento de jogos.
Os alunos se identificaram com esta atividade, pois já haviam trabalhado anteriormente. A distribuição através de uma mı́dia fı́sica ou de um download, com as
atualizações obtidas através da internet também foram situações descritas pelos
próprios alunos. Tais atividades serão exploradas em turmas posteriores.
• Experiência Docente: Uma dificuldade de aplicação da disciplina foi a pouca
experiência do professor em desenvolvimento jogos digitais, apesar do professor possuir experiência no ensino de Engenharia de Software e Desenvolvimento
de Sistemas. Livros para Engenharia de Software tradicional, como Sommerville [Sommerville 2011] e Pressman [Pressman 2011], adotados nos cursos de
computação descrevem um processo de desenvolvimento especı́fico para jogos
digitais, nem situações de jogos como exemplos ou artefatos comumente utilizados no desenvolvimento de jogos, como o GDD. Apenas um livro especı́fico para
Engenharia de Software para jogos foi encontrado, que foi adotado na disciplina
[Flynt and Salem 2005]. Por outro lado, com a experiência de aplicação da abordagem, foi possı́vel adquirir uma quantidade razoável de artefatos utilizados no
processo de desenvolvimento de exemplos de jogos digitais, como: arquiteturas,
modelos de desenvolvimento, requisitos e GDD. Um benefı́cio da abordagem foi
a conclusão de que o GDD não é suficiente para o desenvolvimento, pois diversos aspectos não estavam claros ou não existiam no documento, como exemplo as
atividades de testes. Outra dificuldade foi encontrar exemplos de modelagem de
jogos que seguissem aspectos mı́nimos da Engenharia de Software. Os exemplos
foram construı́dos pelos próprios alunos ao longo do semestre.
• Identificação com RAD e Metodologias Ágeis: Os alunos não se interessaram
no inı́cio por modelos de ciclo de vida. Porém ao estudarem o modelo de ciclo de vida Rapid Application Development (RAD), perceberam que era o que
eles mais consideraram alinhado para o desenvolvimento de jogos devido a sua
natureza de equipes multidisciplinares trabalhando em paralelo maneira independente, não necessariamente somente equipes de desenvolvimento, e ao final, uma
fase para a integração. Normalmente exemplos de equipes são: programação, arte,
design e som. As metodologias ágeis, especificamente o SCRUM, se justificam
na colaboração ao desenvolvimento de jogos pela natureza prática do desenvolvimento de jogos e pela divisão de tarefas que podem ser distribuı́das em pequenos
incrementos (sprints). Uma dificuldade foi a utilização de fases e ciclos de desenvolvimento durante o trabalho, o que não ocorreu. Pretende-se adaptar a abordagem para que em futuras versões ela suporte o desenvolvimento com ciclos.
• Abordagem de Desenvolvimento: Muitos dos itens citados anteriormente foram
identificados devido a aplicação da abordagem proposta. O maior benefı́cio da
abordagem foi o conhecimento por parte do professor de práticas comuns ao desenvolvimento de jogos, e para os alunos, conceitos de Engenharia de Software
aplicados a jogos digitais, que eles normalmente utilizam, mas de maneira dife-
42
rente, seja com uma ferramenta, seja com um artefato de nomenclatura diferente.
Ao final da disciplina foi realizada uma pequena discussão sobre a abordagem. Os
alunos, que a princı́pio não estavam confortáveis com a utilização dos conceitos,
se mostraram mais flexı́veis na utilização das práticas pois perceberam a aplicabilidade de diversos conceitos, desde que orientados à realidade do desenvolvimento
de jogos.
5. Conclusão
Este trabalho propôs uma abordagem para o ensino de Engenharia de Software no desenvolvimento de jogos digitais. Essa necessidade se dá devido ao fato de que certos tipos
de aplicações necessitam de uma adaptação das práticas da Engenharia de Software para
que possam ter a devida utilidade, eficiência e produtividade.
Foi realizado uma avaliação da abordagem, mas ainda de forma limitada aos alunos de uma turma de Engenharia de Software do curso de Sistemas e Mı́dias Digitais,
cujo foco foi o desenvolvimento de jogos. Como primeira avaliação e primeira versão
da abordagem o resultado foi satisfatório em relação ao desempenho dos alunos, porém
ainda são necessários vários ajustes para que a abordagem tenha um melhor desempenho.
O fato de ter sido a primeira vez em que a disciplina foi ofertada no curso teve um impacto
nos objetivos da disciplina, que deverão ser ajustados em novas versões da abordagem.
Como trabalhos futuros é necessário refinar e praticar mais as atividades definidas
na abordagem. A utilização de metodologias ágeis de forma mais presente na abordagem
também pode colaborar com o aumento no desempenho na turma. A utilização de ferramentas pelos alunos no auxı́lio tanto do projeto quanto da gestão é outro trabalho futuro
a ser executado. Por fim, a aplicação da abordagem em outras turmas de Engenharia de
Software.
Referências
Flynt, J. P. and Salem, O. (2005). Software Engineering for Game Developers. Thomson/Course Technology.
Kurkovsky, S. (2009). Engaging students through mobile game development. In Proceedings of The 2009 Technical Symposium on Computer Science Education (SIGCSE
2009), Chattanooga, TN.
Morales, C. and Nelson, D. (2007). Mobile 3D Games: From Start to Market. Charles
River Media.
Pressman, R. (2011). Engenharia de Software. McGraw-Hill Interamericana do Brasil,
7a. edition.
Rodrigues, H. F., Machado, L. S., and Valença, A. M. G. (2010). Definição e aplicação de
um modelo de processo para o desenvolvimento de serious games na Área de saúde.
In Proceedings of the CSBC 2010 - Workshop de Informática Médica, Belo Horizonte,
MG.
Sommerville, I. (2011). Engenharia de Software. Addison Wesley, 9a. edition.
Sousa, V., Bezerra, C. I. M., Coutinho, E. F., and Santos, I. S. (2012). itest learning: Um
jogo para o ensino do planejamento de testes de software. In CBSoft2012 - SBES FEES 2012, Natal - RN.
43
Learning Software Evolution: Curriculum, Approaches and
an Experience Report
Debora Maria Coelho Nascimento1 , Christina Chavez2 , Roberto Almeida Bittencourt 3
1
2
3
Federal University of Sergipe (UFS)
São Cristovão – SE – Brazil
Federal University of Bahia (UFBA)
Salvador – BA – Brazil
State University of Feira de Santana (UEFS)
Feira de Santana – BA – Brazil
[email protected], [email protected], [email protected]
Abstract. Software evolution tasks impose increasing challenges and require
huge investments from industry and software engineers seem to be not prepared
properly to deal with them. One possible way to handle this problem is teaching
software evolution in graduate and undergraduate courses. To this end, several reference materials have been proposed and some courses try to implement
them to achieve improved competencies for their students. This paper presents
preliminary results of an investigation we have performed on how software evolution topics have been approached within reference curricula and some academic courses, and also reports our own experience within a graduate course
on software evolution.
1. Introduction
Literature provides reports of studies where software evolution accounts for more than
65% of the total software cost [Petrenko et al. 2007]. In case of systems with a long
lifetime, software maintenance and evolution (SME) activities account for up to 50-75%
of total software life-cycle costs [Koskinen 2011]. Thus, it is usual for software engineers
in industry to spend a majority of their time understanding and evolving legacy software
[McCartney et al. 2012]. These statistics provide evidence on the importance of these
activities in the field of Software Engineering (SE).
Evolving a large software product is a challenging task [van Deursen et al. 2003].
One needs to comprehend and modify a system that was mostly developed by others,
that many users depend upon, and which is frequently complex and poorly structured.
Often there is no other documentation apart from the source code, or the documentation
is outdated.
Previous research has been performed to facilitate such activities. However, there
is still little impact of this research on software industry practices, which are frequently
performed as a craft activity, without the support of proper methods. Furthermore, despite
the availability of tools, software engineers were not trained for them and do not know
how to interpret their outputs [van Deursen et al. 2003]. Beyond this, we can add the
fact that maintaining a software system is usually the first activity assigned for recent
graduates in their first jobs. Consequently, it is their first responsibility.
44
At the university, most SE courses overly emphasize software construction as
opposed to maintenance and evolution [McCartney et al. 2012]. Students are trained
in developing small programs, in size and complexity, starting from scratch, and
are barely exposed to software change tasks on more realistic software projects
[van Deursen et al. 2003]. Evolving large and complex software systems comprises: (i)
understanding documentation; (ii) recovering and understanding the architecture; (iii) understanding some part of the source code; (iv) locating changes; (v) performing impact
analysis, among other activities. These activities are quite challenging, both for industrial
and academic settings.
Mens et al [Mens et al. 2005] described some research challenges in software evolution, emphasizing that “one of the best ways to place change and evolution in the center
of the development process is to educate future generations of software engineers”. In
this context, one challenging question is how software evolution topics can be properly
approached in software engineering curricula.
This paper presents the preliminary results of an investigation we have performed
on how software evolution has been dealt within some reference curricula. We have provided some examples of courses and also reported our own experience on a graduate
course on software evolution.
This document is organized as follows. Section 2 presents a brief summary on
how important reference curricula treat this topic. Section 3 presents some interesting academic initiatives that work with software evolution topics. Section 4 reports our own onesemester initiative on teaching software evolution topics and Section 5 discusses some
topics. Finally, Section 6 presents some concluding remarks.
2. Software Evolution in the Curriculum
In order to better understand how software evolution is treated within the curriculum, we
first analysed some reference curricula and guidelines, and their account of this subject
area. Later, we provide examples of curricula implementation from undergraduate courses
offered by three Brazilian universities.
The Association for Computing Machinery (ACM) and the IEEE Computer Society have published the Computing Curricula Series [ACM and IEEE 2006], providing
recommendations to five undergraduate programs, described below.
In the 2010 Information Systems (IS) Curriculum [ACM and AIS 2010], the term
“maintenance” is used at the discipline scope, but no specific course, topic or unit was
proposed. “Systems Analysis & Design” is defined as a core course and “Application
Development” as an elective course. While the former focuses on requirements, the latter
focuses on design, implementation and testing. Both courses are foundations to one career
track called “Application Developer”, what reveals the importance assigned to software
development, in contrast to SME.
In the 2008 Computer Science (CS) Curriculum [ACM and IEEE 2008a], “Software Evolution” is a core topic within the “Software Engineering” knowledge area (KA).
The topic must have a minimum core coverage time of 3 hours, handling software maintenance, features of maintainable software, reengineering legacy systems, refactoring and
software reuse. “Maintenance” is also mentioned in the “Software Processes” and “Spe-
45
cialized Systems” topics.
In the 2008 Information Technology Curriculum [ACM and IEEE 2008b], only
one KA, “System Administration and Maintenance”, references the term “maintenance”.
However, it is not related to SE and covers topics such as operating systems, applications,
and administrative activities and domains.
The SE 2004 Curriculum Guidelines for Software Engineering
[ACM and IEEE 2004b] states that “evolution is a broad concept that expands upon
the traditional notion of software maintenance” and defines “Software Evolution” as a
KA with a minimum coverage time of 10 hours. But the term “maintenance” is also
mentioned in the “Software Process” and “Software Quality” KAs, and a topic is included
in the “Software Management” KA.
The Computer Engineering (CE) Curriculum [ACM and IEEE 2004a] describes
two units: the “Software Maintenance” unit within the “Computer Systems Engineering”
KA and “Software Evolution” within the “Software Engineering” KA, both with a minimum core coverage time of 2 hours. However, the topics specified for these two units
have some overlapping content, such as software maintenance, impact analysis and reuse.
ACM also provides recommendations for the graduate degree in SE
[iSSEc Project 2009]. In this case, “Software Maintenance” is a unit within the “Software Engineering” KA, which is subdivided into topics about maintenance fundamentals,
processes and techniques. There is also another unit called “Operation, Maintenance and
Supporting” within the “Systems Engineering” KA, but the topics are not described. The
text emphasizes that it is a mistake to view the other development KAs as independent
areas of software maintenance and to focus on development from scratch.
Finally, the SWEBOK – Software Engineering Body of Knowledge Guide – currently in the public review phase of its third version [IEEE 2013], provides a reference to
Lehman’s Laws of Evolution, defining that “maintenance is evolutionary development”
and “maintenance is continued development”. The guide sets software maintenance as
one of the fifteen knowledge areas (KA) that provide the foundational knowledge for SE,
thus reinforcing the relevance of the subject for the software engineer’s background.
In Brazil, the Brazilian Computer Society (SBC) has also produced recommendations for four undergraduate programs. The 2003 IS curriculum [SBC 2003] mentions
“maintenance” as an activity in the software development process, with no emphasis at
all. On the other hand, the CS and CE Curricula are described in a single document, available since 2005 [SBC 2005]. This document treats maintenance, reverse engineering and
reengineering as topics in the “Software Engineering” subject matter within the “Computing Technology” core. In the Computing Education reference curriculum [SBC 2002], it
is recommended that the area of SE should be comprehensively studied with emphasis on
developing environments and systems for use in learning and other educational processes.
The reference curriculum for Software Engineering has not been yet completed.
The proposal for curricular guidelines from the Brazilian Ministry of Education
(MEC) [MEC 2012] cites the term “evolution” when describing the expected competencies for CS, SE or IS graduates. However, the topic “software evolution” only shows up
in the SE curriculum.
46
The Federal University of Sergipe offers three undergraduate programs: IS, CS
and CE. Software maintenance is one topic within the “Software Development III” course,
only in the CS Undergraduate Curriculum. For the other two curricula, there is no reference to software maintenance or evolution [UFS 2008]. However, faculty responsible for
the courses on SE report that they address the topic in, at least, one lecture. The State University of Feira de Santana offers the Computer Engineering Undergraduate program. By
insistence of some faculty, the “Software Evolution and Maintenance” was added as an
optional course [UEFS 2012]. Finally, the Federal University of Bahia also offers three
undergraduate programs: CS, IS and Computing Education [UFBA 2013]. In the CS
course, since 2007, the “Software Evolution” elective course is provided every year. In
the other two curricula, maintenance is one topic in the “Software Engineering” course.
3. Some Initiatives
El-Ramly described an experience whose goal was to provide MSc. students with basic
knowledge and training in reengineering [El-Ramly 2006]. The course covered reverse
engineering and the forward engineering aspect of reengineering. Their approach used
lectures, discussion classes, and computer labs with some tools where students had to
work in a project to practice and expand on what they had learned. Among the lessons
learned reported in their study, we highlight the need to cover practical tools and some
industrial case studies and the use of few tools to reduce students’ workload.
Petrenko et al. offered a course to senior undergraduates and first-year graduate
students, in which they learnt about tasks, tools and techniques of an evolution process
and practiced on software systems of considerable size [Petrenko et al. 2007]. Students
had introductory lectures about software change process and tools, and had to perform
required changes of increasing difficulty in an open source project.
Koskinen [Koskinen 2011] used systematic seminars to teach software maintenance and evolution. The seminars were organized as part of a “Software Engineering”
course, usually taken during the second year for undergraduate students in computing.
Before the seminars, the instructor introduced the related area by means of lectures. Students had to form groups autonomously, and each group had to analyze one scientific
paper and present its analysis at the seminar, write a careful summary report of the paper,
serve as the opponent to another group, and listen to the presentations of other groups.
The first two papers emphasized the importance of the students participating in
practical projects, especially in projects closer to industrial reality, while the last one
emphasized the use of seminars to provide a broad scientific view of the area to students.
4. Our Experience
In this section, we report our experience in teaching software evolution to graduate students. Two authors of this paper were responsible for the ”Topics in Software Engineering
1” course, in an elective course from the Computer Science Graduate Program at the Federal University of Bahia.
4.1. Methodology
The topics covered in our course were basic concepts of evolution and maintenance,
laws of software evolution, software aging, software comprehension, reverse engineer-
47
ing, change requests, change classification, concept location, impact analysis, refactoring,
tests in the change context and the mining of software repositories.
Since the audience was composed of graduate students, we decided for a research
approach. Students had to discuss concepts and trends in the area of software evolution
based on scientific papers. They also had to use techniques and tools to study attributes
of one software project during its evolution and present the results of the analysis.
The topics were presented in lectures or individual seminars. Except for the first
class, students had to prepare critical reviews for one or two scientific articles suggested.
The goal was to generate discussion about the theme and the quality of the articles.
A list of themes was suggested for the seminars, so that each student could choose
one with better fit to his/her background and interests. A set of papers about each theme
was also provided, but the student could research other sources and tools to support activities related to the chosen theme. The seminar was an individual task.
To add a more practical view of the research, students, in pairs or in groups of
three, had to produce research on mining software repositories related to evolution or
maintenance for one or more available software projects chosen by the students. Thus,
students had to identify issues, define research questions and methodology, perform the
data collection, and analyze the results. The study proposal was initially validated by the
faculty. Finally, students had to present the work in an oral session and write a report.
The faculty effort was distributed into planning and leading. The effort during
planning was reduced because of the previous experience in similar courses. Most of
the time was used to define the themes and pre-select papers related to them, and also to
define the evaluation criteria. Leading, time was needed to read the suggested papers and
assessing the critical reviews, seminars and practical projects.
4.2. Students’ Perspective
To obtain student’s appraisal on course relevance and methodology, they were asked to
fill an anonymous web survey, which had 8 responses in an universe of 11 students.
Since the students were graduate students, we decided to characterize their experience in industry. Only one student did not have any work experience and most (75%) of
them had more than five years experience. For those, 57% had 50% of their time working
with maintenance activities and 43% had 75% of their time.
When the students were questioned if they had previously studied software evolution, 50% answered that had never done it, while 10% had studied at a company, 10% on
their own, and only 30% had studied it in college. However, 100% considered important
that the theme be addressed in computer courses in academy, from that 50% considers
that should exist a dedicated course for the theme. The opinion about this importance was
changed after their participation in this course, for 75% of the students.
Regarding the used methodology, 88% considered the duration appropriate, 100%
considered the content appropriate, of whom 38% considered the content very important
and 25% considered it important for a software engineer working in industry. Only 12.5%
considered inappropriate the approach using seminars and practical projects, while 50%
considered it good and 37.5% found it very good. In a self-assessment, 12.5% found their
48
learning less than satisfactory, 12.5% found it satisfactory and 75% found it good.
From open questions, students could suggest improvements and indicate what they
liked best. Some improvements suggested were: reducing the number of assignments of
critical reviews, more feedback about the reviews, dedicating more time to discussions;
faculty should discuss the seminar with the student preparing it before the oral presentations, for better quality and more uniform contents; the project should start at the beginning of the course, with more discussion about it, during the whole course.
Students especially appreciated: the diversity of content that allowed a broad view
of the maintenance and evolution area; the free choice of theme for seminars and practical
project; knowledge and experience of students and faculty allowed enriching discussions;
the practical project that allowed the comprehension of some aspects related with software
evolution; and finally the critical reading of the scientific papers reported in the reviews.
4.3. Faculty’s Perspective
The faculty answered an evaluation questionnaire. The third author of this study was in
charge of elaborating and evaluating answers of both questionnaires to avoid bias.
Analyzing the students’ results, the instructors considered: (i) good results for
critical reviews, with quality increase after the first results, although some students insisted on not do a critical analysis and only summarized the articles; (ii) for seminars, the
results were regular, a few were very good, some were good, but many failed; and (iii)
for the projects, the results were very good, surprising the instructors. In general, they
considered having good results.
Regarding the methodology, they considered that the success was partial. On
the one hand, seminars turn students more active and cover a broad view of topics, on
the other hand, when it fails, all students are harmed, since the topic is not covered in
adequate way anywhere else. The tool demonstrations were mostly incomplete, reducing
the potential practical impact on the students’ daily work. Although the critical reviews
increased the students’ workload, they stimulated the discussions in class. In general,
the practical projects were very good, providing students some experience in performing
research and a view of evolution from the perspective of mining repositories. Regarding
class time, it was adequate for a graduate course, where it is required more individual and
extra-class work from students.
Reflecting about what could be better, they concluded that is necessary: (i) to
increase the monitoring of the projects, setting some milestones during the execution
phase; (ii) to assure the content coverage with more lectures and assuring that the seminars
have appropriate depth; and (iii) to improve the use of tools, maybe by adopting tutorials.
5. Discussion
In the beginning of this study, we discussed the relevance of the software evolution area.
This fact was supported by our survey results, where all graduate students participating
in this study that had already worked at industry used at least 50% from their work time
with maintenance activities. Despite this involvement, 75% of the students changed their
opinion about the importance of teaching software maintenance and evolution, only after
studying it in our course. One possible cause for this lack of awareness could be the
49
relative lack of knowledge about the techniques to evolve or maintain software systems.
Perhaps, this is because teaching maintenance in college, most of the times is focused on
the maintenance process, prioritization and impact analysis. And, as we mentioned, lots
of concepts, processes and techniques must be covered.
Regarding computing curricula, starting with ACM recommendations, we noticed
the absence of coverage of the subject in the IS Curriculum, regardless of the large number
of legacy systems existing in companies that must be maintained. For the CS and CE
Curricula, the minimum core coverage time specified only allows a shallow learning of
concepts. To practice the techniques, extra time is needed. Considering the SBC and MEC
recommendations and the relevance of the theme, from our point of view, the matter has
been neglected. In practice, using three Brazilian universities as examples, we identified
that, in present, the coverage of this area depends on faculty staff’s interests, even though
this interest has increased in recent years.
In our opinion, to introduce SME in the curriculum by a more traditional approach,
there should exist one core course for SE and IS undergraduate programs, and one elective
course for CS and CE programs. In a more revolutionary approach, following recently
ideas [Rajlich 2013], the SE discipline could be introduced using a software evolution
approach. Since SME covers important aspects of the software engineering area and
corresponds to majority of activities which graduates will perform in their future jobs.
6. Conclusion
In this study, we aimed to highlight the relevance of teaching and learning software evolution, so that universities can better prepare computing professionals to the challenges
of industry of maintaining important software systems. Therefore, craft activities need
to be replaced by proper methods. However, we noticed some failed coverage of SME
in university-level, on the examples studied, possibly reflecting the importance found in
curricula references. One solution would be raising faculty awareness about the relevance
of evolving and maintaining a software system, activities as important as developing new
systems from scratch, as it typically happens in most colleges and universities. Studies
like this can help in this task.
Teaching software maintenance and evolution is not an easy task, but there are
some interesting initiatives that can be followed and adapted for different contexts. In this
study, we reported our experience in teaching software evolution in a graduate course.
The methodology used critical reviews, seminars and a practical project and was deemed
satisfactory in this case.
Beyond the adoption of the improvements suggested in the next graduate course,
we are planning one undergraduate course that will be offered in the second term of the
present academic year. The approach will be different, because, in this case, the practical
project should reflect activities found in industry.
References
ACM and AIS (2010). IS 2010: Curriculum Guidelines for Undergraduate Degree Programs in Information Systems.
ACM and IEEE (2004a). Computer Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Computer Engineering.
50
ACM and IEEE (2004b). Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering.
ACM and IEEE (2006). Computing Curricula 2005: The Overview Report.
ACM and IEEE (2008a). Computer Science Curriculum 2008: An Interim Revision of
CS 2001.
ACM and IEEE (2008b). Information Technology 2008: Curriculum Guidelines for Undergraduate Degree Programs in Information Technology.
El-Ramly, M. (2006). Experience in Teaching a Software Reengineering Course. In Proc.
of the 28th Int. Conf. on Software engineering - ICSE ’06, page 699.
IEEE (2013). SWEBOK V3 Review: Guide to the Software Engineering Body of Knowledge.
iSSEc Project (2009). Graduate Software Engineering 2009: Curriculum Guidelines for
Graduate Degree Programs in Software Engineering.
Koskinen, J. (2011). Seminars on Software Maintenance and Evolution An Empirical
Study of the Background Factors Affecting Student Success.
McCartney, R., Gokhale, S. S., and Smith, T. M. (2012). Evaluating an Early Software
Engineering Course with Projects and Tools from Open Source Software. In Proc. 9th
International Computing Education Research - ICER ’12, page 5.
MEC (2012). Parecer CNE/CES No :136/2012 - Diretrizes Curriculares Nacionais para os
cursos de graduação em Computação.
Mens, T., Wermelinger, M., Ducasse, S., Demeyer, S., Hirschfeld, R., and Jazayeri, M.
(2005). Challenges in Software Evolution. In Proc. of 8th Int. Workshop on Principles
of Software Evolution, page 10.
Petrenko, M., Poshyvanyk, D., Rajlich, V., and Buchta, J. (2007). Teaching Software
Evolution in Open Source. Computer, 40(11):25–31.
Rajlich, V. (2013). Teaching Developer Skills in the First Software Engineering Course.
In Proc. of the 35th Int. Conf. on Software engineering - ICSE 2013, page 8.
SBC (2002). Currı́culo de Referência para Cursos de Licenciatura em Computação.
SBC (2003). Currı́culo de Referência da SBC para Cursos de Bacharelado em Sistemas
de Informação - Versão 2003.
SBC (2005). Currı́culo de Referência para Cursos de Graduação em Bacharelado em
Ciência da Computação e Engenharia da Computação.
UEFS (2012). Resolução CONSEPE 206/2012.
UFBA (2013). Departamento de Ciência da Computação - UFBA - Graduação.
http://wiki.dcc.ufba.br/DCC/EnsinoGraduacao.
UFS (2008). Resolução n. 50/2008/CONEPE.
van Deursen, A., Favre, J.-M., Koschke, R., and Rilling, J. (2003). Experiences in Teaching Software Evolution and Program Comprehension. In Proc. Int. Symposium on
Micromechatronics and Human Science - MHS2003., pages 283–284.
51
Tecnologia Social: A Influência das Empresas Juniores na
Academia e na Indústria de Software
Nadja N. Rodrigues
Instituto Federal de Educação, Ciência e Tecnologia da Paraíba (IFPB) – Campus João
Pessoa – PB – Brasil
[email protected]
Abstract. Understanding the influence of Junior Companies (JC) in computing
education and technology centers foundation, especially in technologically
disadvantaged regions, this article presents aspects of the project of creating a
JC in the Hinterland of Paraíba. The main contributions of the project are the
dissemination of EJ implantation, as academic and technical resources, the
support for the professional training of students and the value added to these
through the use of the best industry practices, as well as the generation of
quality products at affordable costs to society.
Resumo. Entendendo a influência das Empresas Juniores (EJ) no ensino de
computação e na formação de pólos de tecnologia, especialmente em regiões
tecnologicamente desfavorecidas, este artigo relata aspectos do projeto de
criação de uma EJ no Sertão da Paraíba. As principais contribuições do
projeto são a disseminação de implantação das EJ, enquanto recursos
acadêmicos e técnicos, o apoio à formação profissional dos alunos e o valor
agregado a estes, através do uso das boas práticas da indústria, além da
geração de produtos de qualidade, a custos acessíveis, para a sociedade.
1. Introdução
O Brasil tem passado, em especial nas últimas décadas, por inúmeras transformações
econômicas, sociais, políticas e tecnológicas, o que tem provocado um repensar na
sociedade, visando à definição de responsabilidades e a adoção de atitudes proativas
perante as principais questões sociais [Novo e Melo 2003]. As Instituições de Ensino
Superior (IES), em virtude de serem essencialmente baseadas em ensino, pesquisa e
extensão, devem ser vistas como elementos imprescindíveis para definir as mudanças
que devem ser promovidas no mundo. Pode-se afirmar que ao longo da história da
humanidade, poucas instituições contribuíram tanto e de forma tão marcante no
processo de construção do futuro como a universidade [Novo e Melo 2003].
Uma educação de qualidade é tema de constante debate na mídia. Mas quais são
as medidas de ação que vinculam de melhor forma o aprendizado e a experiência
[Maciel et al. 2007]? Reconhecendo que as mudanças do mundo globalizado estão cada
vez mais profundas e velozes, as IES também vêm promovendo reflexões, com vistas ao
encontro de alternativas, para que por meio de seus segmentos de ensino, pesquisa e
extensão possam promover a construção de um futuro melhor, aliando produção e
disseminação do conhecimento ao desenvolvimento da cidadania e melhoria da
qualidade de vida da sociedade [Novo e Melo 2003].
Para Novo e Melo (2003), o estreitamento das relações entre a universidade e o
setor produtivo surge da necessidade de criação de uma nova concepção de
52
universidade, a Universidade Empreendedora. Um exemplo são as EJ de Computação,
especialmente aquelas inseridas em regiões tecnologicamente desfavorecidas. Em uma
era onde as tecnologias e os sistemas movem o mundo, ainda existem lugares onde esses
recursos são escassos, por sua inexistência, ou por preços elevados, muitas vezes fora
dos padrões vividos pela comunidade. A ideia é que os alunos mudem esses cenários,
com as EJ de tecnologia. Vivencia-se nas últimas décadas a evolução da tecnologia
computacional e suas aplicações em vários setores da sociedade. A informação adquiriu
importância econômica e a revolução tecnológica é um dos fatores para as
transformações sociais, culturais, políticas e econômicas da atualidade [Vieira 2011].
Este trabalho retrata o projeto de criação e desenvolvimento da EJ do Curso
Superior de Tecnologia em Análise e Desenvolvimento de Sistemas (CSTADS) do
IFPB – Cajazeiras. Este projeto se propôs a promover a inserção da EJ enquanto recurso
acadêmico, para professores e alunos, e como referência empresarial, em uma região
onde não existiam empresas de Análise e Desenvolvimento de Sistemas (ADS). A EJ se
encaixou como instrumento para ensino aplicado, estágios, e se tornou a empresa de
ADS da cidade, representando um estímulo à criação de pólos de tecnologia na região.
Este artigo apresenta, na seção II, o referencial teórico do trabalho; na seção III, a
metodologia; na seção IV, os resultados obtidos; na seção V, as considerações finais.
2. Referencial Teórico
2.1. Empresas Juniores: Laboratórios de Aprendizagem Prática
A preocupação com a capacitação técnica dos egressos das IES está refletida nos
esforços em agregar, à grade curricular dos cursos de graduação, atividades de extensão
universitária, com o objetivo de desenvolver competências e proporcionar aprendizagem
profissional aos acadêmicos. Através das teorias repassadas ao aluno, possibilita-se uma
nova visão e atuação no processo produtivo das organizações e, principalmente,
compreender e interagir com o meio em que vive [Dal Piva et al. 2006].
Criar espaços e oportunidades que resultem em melhor qualificação dos
universitários deve ser iniciativa das instituições, dos professores e principalmente dos
alunos [Pazzetto e Assad 2006]. Para Novo e Melo (2003), um meio de alunos
interagirem com o mundo e que sustenta a criação e o desenvolvimento de empresas é a
EJ. As EJ têm sido vistas como laboratórios de aprendizagem prática, e a dinâmica de
praticar a teoria vista tem acontecido em tempo real [Pazzetto e Assad 2006].
A EJ é uma empresa de verdade, só que com alunos de perfil empreendedor
ocupando os cargos hierárquicos de uma companhia, orientados por professores que
assinam projetos de verdade, dando consultoria para pequenos e microempresários do
mundo real [Maciel et al. 2007]. A prática de administrar uma empresa durante o curso
de graduação desenvolve habilidades como responsabilidade, autoconfiança, iniciativa,
criticidade, visão interdisciplinar e empreendedorismo [Pazzetto e Assad 2006]. Uma EJ
representa um laboratório prático onde, diferentemente da maioria dos estágios
convencionais, os alunos têm um alto grau de liberdade de pensar nos processos, e
soluções criativas são construídas mais facilmente. Para Dal Piva et al. (2006), com a
visão da teoria à prática, o acadêmico tem acesso às últimas tendências tecnológicas,
observando as empresas. Com isso as organizações participam da formação prática dos
alunos, permitindo o aumento do nível de competência dos acadêmicos envolvidos no
53
laboratório de aprendizagem. Aproximando o acadêmico da realidade das organizações,
as empresas também melhoram seus arranjos produtivos.
Maciel et al. (2007) explicam que as EJ objetivam ampliar o conhecimento
acadêmico e técnico de seus colaboradores, por meio da elaboração de projetos que
contribuam com o desenvolvimento socioeconômico da comunidade, além de estimular
o espírito empreendedor de seus colaboradores, em especial dos discentes.
2.2. Empresas Juniores: Mecanismos de Integração com a Sociedade
As IES estão se defrontando com inúmeras mudanças e estão inseridas em um espaço
caracterizado como um ambiente de construção do conhecimento e da busca de como
facilitar a integração entre academia e mundo empresarial [Dal Piva et al. 2006]. Para
Romanó (2006), IES devem ampliar sua ação formadora em direção às necessidades do
mundo empresarial, reduzindo a distância entre realidade das empresas e conhecimentos
adquiridos em sala de aula. Para Cunha (1999), cabe à universidade se aproximar das
empresas, identificar suas demandas e supri-las, contribuindo para o crescimento da
empresa, da própria universidade e da sociedade. Novas necessidades estão surgindo e é
preciso identificá-las e canalizá-las para as competências da universidade [Cunha 1999].
Uma vez que teoria e prática representam instrumentos para o desenvolvimento
da sociedade, a parceria universidade-empresa apresenta-se como um investimento para
crescimento mútuo. Empresas e universidades, diante da complexidade natural do
processo de cooperação, criaram uma série de mecanismos que vêm permitindo ampliar
e melhorar o entendimento e o fluxo entre as parcerias [Novo e Melo 2003]. Esses
mecanismos permitiram maior fluidez nas relações com a sociedade, e um deles é a EJ.
Para Flores e Flores (2009), na EJ o aluno tem a oportunidade do primeiro
emprego, vivenciando as relações de trabalho, cumprimento de metas, trabalho em
equipe, negociações de projetos, e o professor aplica conhecimentos teóricos em caso
real e desenvolve pesquisas. Para Maciel et al. (2007), a IES pode disseminar seu nome
e escalar o ranking do MEC. As EJ conseguem, com um custo relativamente baixo,
desenvolver soluções muito similares às do mercado corporativo, utilizando as mesmas
tecnologias e garantindo qualidade para os produtos desenvolvidos [Romanó 2006].
Para Oliveira (2013), a ideia da EJ contempla o tripé da universidade. Em
relação ao ensino, as atividades são monitoradas e orientadas por docentes, que
estabelecem uma relação continua de teoria e prática, através de consultorias e
assessorias para as organizações; para realizar tanto a organização técnica como
administrativa, os alunos deverão utilizar pesquisa e investigação contínua para
constituição e desenvolvimento da EJ; em relação à extensão, sua principal missão é
estender à região serviços especializados que contribuam para ações bem planejadas, em
busca de resultados efetivos para construção de uma sociedade mais digna de se viver.
2.3. A Indústria de Análise e Desenvolvimento de Sistemas
Assim como qualquer processo produtivo, o desenvolvimento de software necessita de
sistematização [Rodrigues e Estrela 2012a]. Sommerville (2011) explica que a ES se
preocupa com os aspectos da produção de software, desde os estágios iniciais até a
manutenção. Os Processos de Desenvolvimento de Software (PDS) constituem o elo
entre métodos e ferramentas, apresentando uma sequencia de atividades que leva a um
produto de software [Rodrigues e Estrela 2012a].
54
Os PDS se dividem em prescritivos (tradicionais), e não prescritivos (ágeis,
tentam simplificar o PDS). Teles (2006) classifica os PDS como tradicionais (baseiamse no desenvolvimento em cascata) ou ágeis (iterativos e simplificados, em termos de
esforços técnicos). Rodrigues e Estrela (2012a) explicam que cada modelo tem suas
características definidas de acordo com cenários indicados para sua aplicação, podendo
ser utilizados por completo, ou vistos como frameworks para a definição de novos PDS.
A indústria apresenta diversos modelos de PDS, e à medida que esses são instanciados,
novos modelos surgem pela necessidade de adaptação das suas práticas aos novos
cenários de desenvolvimento [Rodrigues e Estrela 2012b].
Além dos PDS, outros conhecimentos e boas práticas em ES têm contribuído
para o refinamento da construção de softwares. Neste conjunto de recursos, alguns têm
sido vistos como referência, na indústria ou na academia: Project Management Body of
Knowledge (PMBoK) - conjunto de técnicas, métodos e processos que apoia o
gerenciamento de projetos sob a ótica de várias áreas de conhecimento [PMBoK 2013];
Scrum - framework que pode empregar diversos processos e técnicas e usa uma
abordagem iterativa e incremental, otimizando previsão e controle dos riscos [Schwaber
2004]; Rational Unified Process (RUP) - processo que apoia a iteração, ilustra boas
práticas e fornece abordagem disciplinada para tarefas, cobrindo o ciclo de vida inteiro
do desenvolvimento de software [Kruchten 2003]; eXtreme Programming (XP) - o XP é
incremental, composto por valores e boas práticas [Teles 2006], como Cliente Presente,
Programação em Par e Releases Curtos; XP1 [XP1 2013] e easY Process (YP)[Garcia et
al. 2004] - exemplos de PDS ágeis utilizados em ambientes universitários.
3. Metodologia
Quanto aos objetivos, a pesquisa realizada é exploratória- descritiva, no que se refere
aos seus aspectos de investigação: como criar e desenvolver uma EJ; como preparar
tecnicamente esta EJ para trabalhar com desenvolvimento de software; como derivar
desta EJ recursos para ensino prático de Computação, especialmente em Engenharia de
Software Aplicada (ESA). Quanto aos procedimentos técnicos, a pesquisa é
bibliográfica, fazendo um apanhado teórico acerca dos principais conceitos das EJ, dos
cenários de desenvolvimento e boas práticas da indústria de software. Além disso, a
pesquisa contempla aspectos relacionados à observação na EJ e investigação
documental, como dados quantitativos sobre recursos da empresa (pessoas, projetos,
propostas) e qualitativos sobre projetos (especificações técnicas, por exemplo).
4. Resultados e Análises
4.1. Criação e desenvolvimento da Empresa Júnior
Para que uma EJ seja criada e desenvolvida, devem ser executados passos burocráticos
como registro no Cadastro Nacional de Pessoas Jurídicas (CNPJ), definição de produtos,
prospecção de mercado, entre outros. Nessa etapa, os alunos mantiveram contato com
agentes do cenário empresarial (como PB Júnior e Brasil Júnior), desenvolvendo teoria
e prática referentes aos conhecimentos e habilidades em empreendedorismo, gestão e
negócio, e obtendo desenvolvimento técnico e interpessoal. O desenvolvimento da EJ
vem se dando através da sua integração ao Movimento de Empresas Juniores (MEJ), na
busca de conhecimento, e ainda da orientação dos professores no desenvolvimento das
rotinas organizacionais e dos projetos técnicos. A equipe inicial da EJ foi composta por
55
dezessete alunos e uma professora de ADS. Com o tempo, ficaram mais evidentes os
aspectos multidisciplinares do projeto e o quadro de consultores da EJ passou a ter um
professor de Administração e três ligados a subáreas diferentes de ADS.
4.2. Preparação técnica para a área de Análise e Desenvolvimento de Sistemas
Referente à preparação técnica da EJ, os alunos avaliaram recursos da indústria e da
academia, suas características e seus contextos de aplicação, de forma a definir um PDS
próprio para a EJ, baseado nas boas práticas da ES e adequado à realidade dos seus
projetos. Através da revisão bibliográfica, esses alunos puderam perceber que os
cenários prescritivos se mostraram complexos, recomendando o uso de muitos
elementos (atividades, papéis e artefatos) e de vários relacionamentos entre eles. Por
outro lado, esses cenários apresentaram-se mais cautelosos com relação ao
desenvolvimento de sistemas. Os cenários ágeis se mostraram mais simples,
apresentando apenas o que consideraram imprescindível para os projetos. As escolhas
dos elementos do PDS buscaram adaptá-lo às particularidades da EJ: alta rotatividade; a
equipe não tem o mesmo horário e não dispõe de 8h diárias de trabalho.
Nesse contexto foi criado o Simple Way Process (SWP) [Rodrigues e Estrela
2012b], um PDS que sugere o desenvolvimento iterativo e incremental, visando obter
feedback e poder fazer entregas rápidas de releases. O SWP sugere os papéis de gerente
de projetos, líderes de grupo, analista, desenvolvedor, testador e cliente. Papéis
diversificados viabilizam a entrada de alunos dos primeiros aos últimos semestres,
proporcionando diferentes contribuições à EJ, e ao desenvolvimento de cada aluno. O
SWP sugere tanto práticas prescritivas como ágeis, visando acomodá-las às
necessidades da EJ, como exemplo, ter que manter registros dos projetos bem
documentados, em virtude da alta rotatividade da equipe. Por outro lado, a necessidade
de entregas rápidas é incompatível com um processo complexo. O SWP tenta equilibrar
esses aspectos. O SWP envolve atividades referentes às disciplinas Modelagem de
Negócio, Requisitos, Análise e Projeto, Implementação, Testes, Implantação, Gerência
de Projetos, Gerência de Mudanças e Ambiente. O SWP sugere a execução do processo
no tempo e define procedimentos (orientações para atividades), templates (modelos de
artefatos) e ferramentas (sugeridas para o PDS), de forma a apoiar a sua sistematização.
Para apoiar a execução dos projetos, os alunos criaram um ambiente na web (site) para
usuários autorizados, com estrutura de navegação simples, beneficiando usuários
iniciais e apresentando os elementos do SWP, a partir das seguintes páginas: “O que...”,
(atividades); “Quem...” (papéis); “Quando...” (atividades no tempo); “Como...” (com
links para subpáginas “Procedimentos”, “Templates” e “Ferramentas”).
O SWP trouxe mais sistematização à EJ. O trabalho técnico, antes apoiado pelo
XP1 e ajustado com dificuldade (pela simplificação de papéis, carência de templates
adequados e falta de padronização de ferramentas e procedimentos), passou a ser guiado
pelo SWP, tendo os papéis e elementos necessários para a execução do projeto. Para dar
início às atividades da EJ e testar infraestrutura, PDS e habilidades técnicas dos alunos,
foram desenvolvidos dois projetos pilotos (Sistema Bibliotecário e Sistema de
Refeitório - demandas internas do Campus). Através de análise do mercado percebeu-se
que algumas demandas de software na região estariam relacionadas a tecnologias que
não constavam nos planos de ensino do CSTADS. Neste caso, treinamento dos alunos e
acompanhamento dos projetos foram realizados por consultores com expertise técnica.
56
4.3. Empresa Júnior enquanto recurso acadêmico
A EJ favoreceu a prática de atividades ligadas ao ensino, pesquisa e extensão. Em
relação à pesquisa, os alunos puderam se envolver em projetos voltados à resolução de
problemas práticos. Os alunos se envolveram na definição do SWP, e assim puderam
conhecer diversas teorias e práticas da ES ligadas à academia e à indústria, e analisá-las
de forma crítica, conforme citado anteriormente. Um segundo projeto, referente à
melhoria de processos de software em pequenas empresas está em andamento e prevê a
realização de um estudo de caso na EJ para validação dos seus produtos. Espera-se que
as demandas da EJ continuem a estimular a investigação contínua junto aos alunos.
Quanto ao ensino, a EJ apoiou a redefinição de metodologias, especialmente
para as disciplinas ESA e Estágio Supervisionado [Rodrigues e Estrela 2012a],
favorecendo a aplicação de práticas espelhadas nas rotinas técnicas do SWP e com base
no seu ambiente. Alguns projetos da disciplina foram subprojetos reais da EJ. Na
execução dos projetos, os alunos, integrantes da EJ ou não, puderam imergir nesta e
viver a rotina de trabalho em uma empresa de ADS, desenvolvendo projetos em grupo,
compartilhando conhecimento e respeitando o rodízio entre papéis, atividades e
artefatos do SWP, para que pudessem se familiarizar com as diversas etapas da
construção de software. Os alunos de estágio também fizeram uso do SWP e do seu
ambiente. Durante o estágio, os alunos receberam parte do escopo de um projeto real e
para este passaram pelas disciplinas do SWP. A execução dos projetos nas aulas e no
estágio foi orientada por docentes, visando estabelecer relação continua de teoria vista
em academia e prática da indústria, ambas cooperando para melhoria contínua de seus
alicerces. Uma metodologia direcionada ao ensino de Qualidade de Software [Rodrigues
2013] também foi definida com base no SWP e testada nas aulas de ESA.
Em relação à extensão, a EJ oferece à comunidade, especialmente, sistemas de
software, trabalhando com tecnologias da indústria, de acordo com as demandas dos
clientes. Antes de fechar contratos externos, conforme explicado, a EJ desenvolveu
projetos para o Campus, visando testar e afinar recursos e diretrizes de trabalho,
preparando-se para demandas externas. Esses projetos se encontram em produção, com
demandas de manutenção referentes à sua evolução. A EJ já respondeu a diversos
pedidos de propostas para desenvolvimento de sistemas e em 2012 a empresa entregou
seu primeiro projeto externo, um Sistema de Gerenciamento de Conteúdo de Maçonaria.
Os benefícios multilaterais promovidos a partir da parceria entre EJ e seus
stakeholders podem ser acompanhados de forma quantitativa. Indicadores da parceria
com a IES, referentes a ensino, pesquisa e extensão, podem ser vistos na Tabela 1.
Tabela 1 – Indicadores referentes a ações de ensino, pesquisa e extensão
Indicador
Coleta de Dados
Número de projetos de pesquisa do CSTADS
desenvolvidos a partir da EJ = 3
Dados quantitativos referentes aos projetos desenvolvidos
entre 2010 e 2012.
Número de projetos de extensão do CSTADS
desenvolvidos a partir da EJ = 1
Dados quantitativos referentes aos projetos desenvolvidos
entre 2010 e 2012.
Número de instrumentos voltados ao ensino e
desenvolvidos a partir da EJ = 3 (2 metodologias de
ensino; 1 ambientes de apoio ao ensino)
Dados quantitativos referentes às turmas 2011.1, 2011.2 e
2012.1.
Número de disciplinas envolvidas diretamente com as
atividades da EJ = 2 (ESA e Estágio)
Dados quantitativos referentes às turmas 2011.1, 2011.2 e
2012.1.
57
Número de alunos que utilizaram o SWP (e seu
ambiente) nas aulas de ESA = 42
Dados quantitativos referentes às turmas 2010.2, 2011.1,
2011.2, 2012.1.
Número de alunos que realizaram o estágio na EJ = 8
Dados quantitativos de Estágio Supervisionado–CSTADS
Número de projetos desenvolvidos no estágio na EJ=2
Dados quantitativos referentes às turmas 2011.1 e 2011.2.
% de alunos que fizeram o estágio supervisionado na
EJ e baseado no SWP = 100%
Dados quantitativos referentes às turmas 2011.1 e 2011.2.
Indicadores de resultados ligados aos benefícios voltados à EJ, e promovidos a
partir da parceria entre esta empresa e a IES, podem ser vistos na Tabela 2:
Tabela 2 – Indicadores referentes ao desenvolvimento da EJ
Coleta de Dados
Indicador
Número de produtos (projetos de software) da EJ
gerados com o apoio do SWP = 3
Dados
quantitativos
referentes
aos
desenvolvidos na EJ, entre 2010 e 2012.
projetos
% de projetos da EJ gerados com o apoio do SWP =
100%
Dados
quantitativos
referentes
aos
desenvolvidos na EJ, entre 2010 e 2012.
projetos
Número de integrantes da EJ que se basearam no SWP
para a geração dos seus projetos = 22
Dados quantitativos referentes aos alunos envolvidos
em projetos da EJ, entre 2010 e 2012.
% de integrantes da EJ que se basearam no SWP para a
geração dos seus projetos = 100%
Dados quantitativos referentes aos alunos envolvidos
em projetos da EJ, entre 2010 e 2012.
Número de produtos (projetos de software) da EJ
gerados a partir do Estágio Supervisionado = 2
Dados quantitativos referentes às turmas 2011.1 e
2011.2.
% de produtos (projetos de software) da EJ gerados a
partir do Estágio Supervisionado = 66,7%
Dados quantitativos referentes às turmas 2011.1 e
2011.2.
Número de consultores (professores do CSTADS) que
apoiam diretamente as atividades da EJ = 4
Dados quantitativos referentes ao ano 2012.
Número de solicitações de propostas da comunidade
externa para novos projetos: 09 (aproximadamente)
Dados quantitativos referentes às solicitações de
propostas recebidas pela EJ, entre 2010 e 2012.
Referente às dificuldades para implantação da EJ, um dos problemas foi a falta de
conhecimento em gestão organizacional pela equipe (alunos e professores), inicialmente,
uma vez que os integrantes eram da área de Informática. Percebida essa fragilidade,
convidou-se uma professora de Administração para compor o grupo de consultores, que
passou a ser multidisciplinar. Para a geração dos projetos da EJ, o problema percebido foi
o receio de integrar a empresa, nos alunos dos últimos semestres do curso, em virtude da
alta carga de projetos das disciplinas nesses semestres. Visando mitigar esse problema,
buscou-se o envolvimento dos demais professores e do coordenador do curso com a EJ, no
sentido de que projetos desta fossem direcionados às disciplinas, quando possível.
5. Considerações Finais
Este artigo pretendeu mostrar a importância das EJ, especialmente em localidades onde as
tecnologias ainda são emergentes. O projeto vislumbrou a EJ sob dois aspectos: enquanto
recurso acadêmico, favorecendo o apoio à formação profissional dos alunos, e o valor
agregado a estes, através do uso das boas práticas da indústria; enquanto recurso técnico,
viabilizando a geração de produtos de qualidade, a custos acessíveis, para a sociedade. Para
mostrar a viabilidade desses cenários, foi apresentada a criação da EJ do CSTADS, sua
preparação técnica e estratégias associadas a ensino, pesquisa e extensão,baseadas nesta EJ.
Associados à EJ vieram diversos resultados diretos, como a preparação desta
empresa para a indústria de software, o contato dos alunos com o conhecimento técnico e
58
em gestão organizacional, além dos sistemas de informação entregues e em produção.
Referente às atividades de ensino, pesquisa e extensão, a EJ viabilizou o desenvolvimento
de ações integradas no tripé das IES, a partir de demandas da empresa. Essas ações
referenciam projetos de pesquisa e extensão desenvolvidos, e instrumentos de ensino (como
metodologias e ambiente) aplicados com foco na prática a partir de recursos da EJ
(inclusive projetos reais). Ainda podem ser citados resultados indiretos associados à EJ,
como incentivo ao perfil empreendedor dos alunos, que recentemente aprovaram projeto
em edital para incubar uma empresa em ADS na cidade. A EJ proporcionou a oportunidade
de integrar a indústria a vários alunos, obtendo valorização profissional. A cidade ganhou
uma empresa especializada em ADS com produtos de qualidade, a preços acessíveis.
Como trabalho futuro espera-se criar um projeto multidisciplinar para avaliar o
envolvimento direto das demais disciplinas do CSTADS com a EJ, de forma a ampliar o
escopo das ações de ensino, pesquisa e extensão relacionadas a esta empresa.
Referências
Cunha, N. C. V. (1999). Mecanismos de Interação Universidade-Empresa e seus Agentes.
REAd: Revista Eletrônica de Administração, UFRGS, Ed. 09, v. 5, n. 1, mar./abr. 1999.
Dal Piva, A. R. et al. (2006). “Empresa Júnior: Um Laboratório de Aprendizagem como
Diferencial para a Formação Acadêmica”. Anais do XIII Simpep, Bauru - SP, 2006.
Flores,L., Flores,R.(2009).Empresa Júnior Elemento da Cooperação Empresa–Universidade. IX
Colóquio Internacional sobre Gestão Universitária na América do Sul,Florianópolis-SC, 2009.
Garcia, F. P. et al. (2004). easYProcess: Um Processo de Desenvolvimento para Uso no
Ambiente Acadêmico. XII WEI, XXIV CSBC, Salvador - BA, 2004.
Kruchten, P. (2003). Introdução ao RUP: Rational Unified Process, Ciência Moderna.
Maciel, M. M. et al. (2007). Do Conhecimento Acadêmico às Práticas Empresarias: O Caso da
Empresa Júnior de Administração da UFPB. Anais do IX Enex, UFPB, 2007.
Novo, L. F., Melo, P. A. (2003). Universidade Empreendedora. III Conferência Internacional
sobre Gestão Universitária na América do Sul. Buenos Aires, Argentina, 2003.
Oliveira, E. M. (2013). Empreendedorismo Social e Empresa Júnior no Brasil. FAE Centro
Universitário.http://www.fae.edu/publicacoes/pdf/iiseminario/politicas/politicas_04.pdf.Abril.
Pazzetto, V., Assad R. (2006). Empresa Júnior - Realidade Cada Vez Mais Presente na Vida
Acadêmica. Gestão:Revista Científica de Administração e SI,Curitiba, v.7, n.7,jul./dez 2006.
PMBok (2013). Project Management Body of Knowledge. PMBoK GUIDE.
Rodrigues, N. N. (2013). “Praticando Qualidade de Software: Ensinando e Aprendendo seus
Valores através de Ambiente Real”. IX SBSI, João Pessoa - PB, 2013.
Rodrigues, N. N., Estrela, N. (2012a). “Simple Way: Ensino e Aprendizagem de Engenharia de
Software Aplicada através de Ambiente e Projetos Reais”. VIII SBSI, São Paulo – SP, 2012.
Rodrigues, N. N., Estrela, N. (2012b). “SimpleWayProcess: Da Academia à Indústria de
Software”. XXXII CSBC. XX WEI. Curitiba – PR, 2012.
Romanó, R. S. (2006). Empresa Júnior no Curso de Sistemas de Informação da Faculdade
Expoente. Gestão: Revista Científica de Administração e SI, Curitiba, v.7, n7, jul./dez. 2006.
Schwaber, K. (2004). Agile Project Management with Scrum,. Microsoft Press.
Sommerville, I (2011). Engenharia de Software, 8ª ed.SP: Pearson.
Teles, V. M. (2006). Extreme Programming: aprenda como encantar seus usuários
desenvolvendo software com alta qualidade, SP: Novatec.
Vieira, M. F. (2011). 25 ANOS DE INFORMÁTICA NA EDUCAÇÃO BRASILEIRA:
avanços e retrocessos. Anais do XXII SBIE - XVII WIE, Aracajú - SE, 2011.
XP1
(2013).
“XP1:
Um
Processo
de
Desenvolvimento”.
http://dsc.ufcg.edu.br/~jacques/projetos/common/xp1/xp1.html. Março.
59
Uma Experiência de Integração de Design Thinking e
Metodologias Ágeis para o Desenvolvimento de Software
Cleidson R. B. de Souza, Mylena R. Ferreira, Fagner L. Pantoja, Mayara
Figueiredo
Universidade Federal do Pará (UFPA)
Belém – PA – Brasil
[email protected], [email protected], [email protected],
[email protected]
Resumo. Este artigo apresenta uma experiência no ensino de engenharia de
software através de uma proposta de integração de técnicas de Design
Thinking com Metodologias Ágeis. Esta experiência foi conduzida com alunos
de Bacharelado em Ciência da Computação cursando uma disciplina de
Engenharia de Software visando avaliar a proposta desenvolvida, e,
principalmente, a melhoria da qualidade dos sistemas desenvolvidos pelos
alunos.
1. Introdução
Metodologias Ágeis (MA) surgiram como uma resposta às metodologias tradicionais
prescritivas e baseadas em planos. Elas procuram acelerar a produção de software,
porém possuem técnicas limitadas para extração dos desejos e necessidades do cliente
para elaboração do produto [Hildenbrand e Meyer 2012]. Com isso, Design Thinking
(DT) [Brown, 2008], ao dispor de técnicas para elaboração de ideias e busca por
insights, pode ser uma alternativa para preencher esta lacuna das Metodologias Ágeis.
Em contrapartida, as Metodologias Ágeis podem se apresentar como uma ferramenta de
complementação para implementar as ideias obtidas pelo processo de ideação e
inovação geradas durante o processo de Design Thinking. Em resumo, a integração
destas duas abordagens visa o complemento mútuo de ambas a fim de estruturarmos um
processo de desenvolvimento de software, focado primeiramente nas técnicas e
ferramentas do Design Thinking e gradualmente redirecionando para as Metodologias
Ágeis. Este artigo apresenta brevemente a proposta de integração que está em
desenvolvimento pelos autores e detalha como a mesma foi avaliada com alunos de
graduação em ciência da computação durante o primeiro semestre de 2012.
2. Design Thinking
O termo design possui o estereótipo de se referir apenas à estética, contudo a essência
original do design é transformar a situação existentente em algo melhor, analisando sua
concepção, propósito e funcionalidade [Brown, 2008 e 2009]. Steve Jobs descreve o
design da seguinte forma: “Design não é somente o que se vê ou o que se sente. Design
é também como funciona” [Isacson, 2011]. Ao alicerçar o design à gestão e análise, ou
seja, aliar a inovação com a divisão de tarefas e funções tem-se como resultado um
produto ou serviço de alto valor para o público alvo, algo que seja desejável, além de
ser uma necessidade [Pinheiro e Alt 2011].
60
Deste modo, o Design Thinking propõe uma forma diferente de lidar com
problemas e de propor soluções para resolvê-los. A DT tem como característica
principal o foco diferenciado na relação entre pessoas, desde a forma de coleta de
dados, passando pela relação com a equipe de desenvolvimento, até a prototipação. É
uma abordagem que pode ser implantada na coleta de requisitos e criação de ideias, pois
enfatiza o estímulo à criatividade. Empatia, colaboração e curiosidade são
características-chave para o sucesso no Design Thinking. Desta forma, é possível
solucionar problemas, reduzir chances de fracasso, além de deixar o produto/serviço
mais desejável ao cliente, bonito e mais planejado [Pinheiro e Alt 2011].
Essa forma diferenciada de lidar com situações pode ser melhor entendida e
aplicada se forem analisados os quatro pilares do DT: (1) a empatia, para compreender o
público; (2) a colaboração, entre a equipe de trabalho no desenvolvimento de ideias; (3)
a prototipação, quando estas ideias são testadas; e a (4) realização ou implementação, na
qual a equipe trabalhará diretamente no desenvolvimento do produto [Brown, 2008 e
2009]. Os dois primeiros pilares são também referenciados como imersão e ideação
respectivamente, pois a empatia faz com que a equipe seja inserida no universo do
cliente (como em uma imersão), e a colaboração suscita criação de ideias (daí o termo
“ideação”). Estas são justamente as duas etapas mais importantes e que podem ser
integradas aos métodos ágeis de desenvolvimento de software visando minimizar as
formas limitadas de extração dos desejos e necessidades do cliente para elaboração do
produto que existem nos métodos ágeis [Hildenbrand e Meyer 2012].
3. Integração entre Design Thinking e Metodologias Ágeis
Técnicas que tem por objetivo extrair as necessidades do usuário para transformá-las em
requisitos para o produto são pouco exploradas pelo desenvolvimento de software
[Hildenbrand e Meyer 2012]. Por outro lado, Design Thinking tem sua ênfase
justamente na organização dos insights e ideias para a criação de produtos. Nesse
sentido, DT pode ser um apoio ao desenvolvimento de software, mais especificamente
no contexto de métodos ágeis. Sendo assim, visando uma maior integração entre essas
duas abordagens, algumas das ferramentas do DT foram selecionadas para integrar o
pensamento criativo à exigência industrial de prazos e qualidade embutida, que é uma
das necessidades que as Metodologias Ágeis buscam suprir. Ao mesmo tempo, algumas
práticas de MA foram selecionadas para viabilizar a fase de realização do DT.
Para ser mais especifico, a proposta de integração prevê a utilização de
ferramentas de Design Thinking no processo inicial de desenvolvimento de software e
ferramentas dos métodos ágeis são usadas na etapa de “implementação” de Design
Thinking. Esta integração é relativamente simples dado o caráter iterativo de ambas as
abordagens. As ferramentas de DT selecionadas são: pesquisa exploratória, personas,
shadowing e prototipação em papel; enquanto que as “ferramentas” de MA são o quadro
kanban e desenvolvimento incremental. Esta integração está representada na Figura 1
abaixo. Infelizmente, por questões de espaço estes conceitos não podem ser definidos
neste artigo. Mais detalhes podem ser encontrados em [Ferreira et. al, 2013].
Durante as etapas de imersão e ideação ideias são coletadas, organizadas e
selecionadas como possíveis requisitos para o software. Isto é feito através de técnicas
como shadowing – que consiste na observação dos usuários, atuais ou futuros, de um
sistema de software para entender os problemas que os mesmos enfrentam – a pesquisa
exploratória – que visa definir os perfis estatísticos destes usuários (sexo, idade, poder
61
aquisitivo, grau de educação, etc) – e as personas que são usuários prototípicos de um
sistema de software. Cada um destes passos informa ao próximo, por exemplo, as
personas são definidas somente após a pesquisa exploratória cujos resultados são
usados para informar o número de personas e as características das mesmas.
Posteriormente, é necessário apresentar estas ideias ao cliente, que irá verificar se estas
ideias estão de acordo com suas necessidades, bem como validar a implementação
delas. Para essa validação do produto pelo cliente é proposta a técnica da prototipação
em papel, que instancia fisicamente as ideias coletadas durante as fases de ideação. A
seleção das ideias que darão origem a protótipos é feita levando em consideração
questões como relevância dentro do projeto e complexidade.
Figura 1. Representação esquemática da integração entre MA e DT.
A prototipação em papel apresenta pontos positivos à equipe responsável pela
implementação do software na medida em que, ao projetar os protótipos, as ideias
começam a tonar-se mais claras, familiarizando a equipe com o produto que será
desenvolvido. A justificativa pela escolha da prototipação em papel se dá pelo fato desta
demandar um tempo relativamente pequeno se comparado a outras formas de validação,
como por exemplo, a prototipação em formato digital ou a codificação de telas não
funcionais. Por outro lado, a prototipação em papel também é interessante para o
cliente, pois ao interagir com o protótipo ele pode avaliá-lo, o que pode gerar insumos
para evolução e aperfeiçoamento do produto assim como gerar novas ideias. Os
protótipos são elaborados para os itens presentes no mapa conceitual que apresentem
alta complexidade e/ou são itens de alto valor para o produto. Depois de prontos, os
protótipos são levados para os usuários do sistema e/ou cliente validarem, se o protótipo
receber aprovação ele será um item a ser adicionado ao product backlog. Caso o
protótipo seja reprovado na validação, a equipe deve corrigir os erros encontrados e
submetê-lo a uma nova validação.
Como o processo de desenvolvimento ágil é essencialmente iterativo, é de se
esperar que nem todos os requisitos estejam ainda claramente definidos e, assim, alguns
protótipos em papel sejam reprovados. Assim, a prototipação pode ser uma atividade
realizada não somente antes da elaboração do product backlog, mas também em
qualquer momento que uma nova ideia surgir, mesmo que o processo de implementação
do produto já tenha sido iniciado, inclusive a elaboração e validação deste protótipo
podem ser consideradas como tarefas a serem realizadas dentro do sprint. Dessa
maneira, a prototipação em papel pode também servir como uma técnica que vai validar
62
os itens que entrarão na próxima iteração do desenvolvimento.
4. Avaliação da Proposta de Integração
Durante o primeiro semestre de 2012, a proposta de integração acima foi apresentada a
uma turma de 16 alunos de graduação em Ciência da Computação da Universidade
Federal do Pará. Os alunos estavam formalmente matriculados na disciplina Laboratório
de Engenharia de Software com carga horaria de 90 h semestrais. Esta disciplina é
ofertada após duas disciplinas (Engenharia de Software I e II), cada uma com 60 horas
onde os conceitos básicos e teóricos de engenharia de software são apresentados. Desta
forma, esta disciplina mostrava-se adequada à realização da avaliação da proposta de
integração apresentada na seção anterior.
Os alunos foram divididos em 4 equipes de 4 alunos e, durante um semestre
letivo, desenvolveram 4 sistemas computacionais diferentes definidos por eles mesmos.
Aproximadamente a primeira metade do semestre foi dedicada às técnicas de Design
Thinking enquanto que a segunda metade foi dedicada ao desenvolvimento ágil. Os
alunos tiveram aulas presenciais sobre cada um dos assuntos vistos em sala de aula com
especialistas nos tópicos abordados. Após cada aula, os alunos eram responsáveis pela
realização das atividades associadas ao tópico abordado dentro e/ou fora de sala de aula.
Ao final das atividades, os alunos apresentavam os resultados obtidos sendo que eram
sempre orientados para enfatizar como as atividades realizadas informaram o design do
seu sistema computacional. Por exemplo, os alunos apresentavam o protótipo em papel
inicialmente desenvolvido e depois o protótipo modificado após a apresentação deste
protótipo aos usuários finais. A ideia era fazer com que eles refletissem e avaliassem
como cada tópico abordado produzia resultados significativos e importantes para o
sistema em desenvolvimento. É importante mencionar, que os alunos executaram
diversas etapas do processo descrito na seção anterior, a saber: pesquisa exploratória,
shadowing, personas, prototipação em papel, entre outras1.
Uma das preocupações dos autores era a reação dos alunos às técnicas
apresentadas, visto que as mesmas não são tradicionalmente vistas em cursos de ciência
da computação. Pôde-se observar que este não foi um problema, visto que os alunos
foram capazes de discutir o valor de cada nova técnica em suas apresentações da
disciplina. Ao final do semestre, um questionário foi entregue aos alunos visando obter
a opinião dos mesmos, de maneira anônima, sobre a disciplina. A análise dos mesmos
sugere que o resultado foi positivo, pois as técnicas ensinadas mostraram-se úteis aos
alunos. De fato, dos 4 grupos da disciplinas, dois deles deram continuidade aos seus
projetos: um grupo pretende abrir uma empresa para comercializar o produto
desenvolvido, enquanto que o outro ainda está explorando possíveis modelos de
negócio para o projeto desenvolvido.
É importante ressaltar que os autores reconhecem as limitações desta primeira
avaliação desenvolvida, visto que a mesma não foi rigorosa. Justamente por isto, o titulo
deste artigo enfatiza apenas a descrição de uma experiência. Pretende-se resolver estas
limitações nas próximas turmas da disciplina, conforme descrito na próxima seção.
1
Devido a limites de tempo, não foi possível apresentar todas as etapas propostas neste trabalho.
63
5. Conclusões e Trabalhos Futuros
Este artigo apresentou brevemente uma proposta de integração de técnicas de Design
Thinking com técnicas provenientes das Metodologias Ágeis. O motivo para tal
integração é o apoio limitado às técnicas que visam entender as necessidades dos
usuários existentes na engenharia de software [Hildenbrand e Meyer 2012].
A integração proposta pelos autores foi desenvolvida e apresentada em uma
disciplina para alunos de graduação em ciência da computação da Universidade Federal
do Pará. O resultado da disciplina foi bastante positivo, visto que os alunos avaliaram a
disciplina e a experiência de utilização das técnicas de Design Thinking de maneira
bastante positiva.
Durante o primeiro semestre de 2013, esta disciplina está sendo ofertada para
uma nova turma de alunos. Neste caso, entrevistas com os alunos têm sido realizadas de
maneira periódica visando entender em mais detalhes como esta integração pode ser
positiva para o ensino da engenharia de software. Além disso, pretende-se apresentar
todas as etapas da proposta para se obter uma avaliação mais adequada.
Agradecimentos
Este trabalho tem apoio financeiro do CNPq através de uma bolsa de iniciação científica
a segunda autora.
Referências
Brown, T. 2008. “Design Thinking.” Harvard Business Review, June: 84-92.
Brown. T. 2009. Change by Design: How Design Thinking Transforms Organization
and Inspires Knnovation. New York: Harper Collins.
Cohn, M. (2011). “Desenvolvimento de software com scrum – Aplicando métodos ágeis
com sucesso.”, Editora Bookman.
Ferreira, M., Pantoja, F., Figueireido, M., de Souza, C. R. B. Integração de Design
Thinking e Metodologias Ágeis para o Desenvolvimento de Software, Relatório de
Atividades, Programa de Bolsas de Iniciação Cientifica PIBIC-CNPq, Universidade
Federal do Pará, 2013.
Hildenbrand, T., Meyer, J. (2012). “Intertwining Lean and Design Thinking: Software
Product Development from Empathy to Shipment”. Software for People,
Management for Professionals, 217 DOI 10.1007/978-3-642-31371-4_13, #
Springer-Verlag, 2012
Isaacson, W. (2011) “Steves Jobs – A biografia”, Companhia das Letras, Brasil.
Pinheiro, T. Alt, L. (2012), “Design Thinking Brasil: empatia, colaboração e
experimentação para pessoas, negócios e sociedade”, Elsevier, 1ª edição.
64